# 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)_

flowchart
space{{did:key:space}}
team(did:key:team)
space --> team

{
  "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

flowchart
space{{did:key:space}}
team(did:key:teamXYZ)
dev1(did:key:dev1XYZ)
dev2(did:key:dev2XYZ)
space --> team
team --> dev1
team --> dev2

{
  "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