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)

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

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