# Identifiers 

We have IDs in port OS. 

The format of the ID is in the format of 

`<namespace>/<owner-type>/<owner-id>/<resource-type>/<resource-id>`

For example: 

`port1/account/bob/endpoint/lightbulb-zero`

Breaking this down: 
- `port1` is a namespace that contains group of IDs. 
- `account` is the type of the owner of the resource. 
- `bob` is the unique identifier of the account that owns the resource. 
- `endpoint` is the type of the resource. 
- `lightbulb-zero` is the unique idenntifier of the account that owns the resource.

Basically, that ID is bob's lightbulb-zero in the port1 namespace. 

## Technical details on why

### Encoding namespaces into the identifier space

Storing a namespace allows us to generate new identifier spaces that operate
independently when needed. 

### Encoding ownership details into the resource identifiers

The identifier space encodes ownership details so that the access control system
ends up being independent from the resource systems. 

The access control space can work independent of having to look into the various
resource services. 

### Versioning

The current ID space is the v1 id space. We expect new versions to be introduced in the future,
and newer versions will encode a version prefix like /v2/port1 to denote the difference. 

## Length

The names are generally quite long, and should be treated as opaque identifiers
from the customers perspective as much as possible. One choice we can make later is
to make the names shorter using aliasing. We leave this for later. 

## Why not use URIs? 

It sort of is. From a more generic URI perspective, the resource is more generally: 
- <ApiUrl />/port1/account/bob/endpoint/lightbulb-zero

We mostly remove the top level domain information.