# Fireproof UCAN
## Access Control
I think one of the key innovations in web3.storage was recognition that following roles in the system could be played by different actors
- **Resource owner** - Actor that generated a space and has full authority over it.
- **Service customer** - Actor responsible for handling billing for a provided service
- **Service consumer** - Actors that are (cryptographically) authorized to perform set of operations on resource(s).
In traditional systems customer = owner, which implies they have to handle access control.
### Roles
#### Resource Owner
Resource owner is responsible for setting up resource access as they find fit without having to coordinate with a *service* or *customer* handling billing. They could create a groups _(teams, projects or whatever you want to call them)_
```mermaid
flowchart
space{{did:key:space}}
team(did:key:team)
space --> team
```
```json
{
"iss": "did:key:space",
"aud": "did:key:teamXYZ",
"sub": "did:key:space",
"cmd": "/space/*", // <- can choose operations
"plc": [], // <- can setup a policy
"exp": null // <- can choose expiry
}
```
Team manager _(holder of the team key)_ can add members by delegating access to them
```mermaid
flowchart
space{{did:key:space}}
team(did:key:teamXYZ)
dev1(did:key:dev1XYZ)
dev2(did:key:dev2XYZ)
space --> team
team --> dev1
team --> dev2
```
```json
{
"iss": "did:key:teamXYZ",
"aud": "did:key:dev1XYZ",
"sub": "did:key:space",
"cmd": "/space/blob/*", // <- can limit operations
"plc": [ // <- can limit access policy
["<=", ".size", 128_000_000] // <- max 128mb
],
"exp": 13876728 // <- can set expiry
}
```
> ℹ️ It is worth calling out that from UCAN perspective there is no difference between teams