UCANs

[sestinj]

Permissions are highly necessary even for our first use case, so need to figure out whether we are going to use UCANs now, even with them being in development, or if we'll go with our original plan. And whether the original plan can continue into UCAN work without too much unused work.

My first thought is that we want to not be developing our own UCAN library. It's unlikely that we'd have the resources to do better than the UCAN team, and if they haven't built it yet, then it probably isn't ready. I do believe that their library could be sufficient for now, but if it wasn't, and we needed to wait: I think we would continue with the model of permissions being stored on the producer's node. Assuming you can embed the same type of JSON document inside a UCAN, or similar, it should be code that can be reused. But first, let's play around with the UCAN library.

[TyDunn]

@sestinj maybe look into how https://litprotocol.com/ does access control too?

[sestinj]

Determined that the go-ucan library can actually do what we want, despite its being in heavy beta. This is exciting! Planning to go ahead tomorrow and try to fully integrate this in place of our current permissions.

[sestinj]

Key points to work on:

• When a resource is registered, this is when you create the root UCAN token and save it. May also consider just having it be default that the DID associated with the URL automatically has root access.
• When a subscription is requested, must delegate a new UCAN and send this in the response. Also want to record permissions on the node though still, because we want to see a list of everyone who has subscribed and manage this.
• When a subscription acceptance is received, need to store the UCAN somewhere
• When someone reads or writes, we must parse and verify the UCAN before allowing the action.
• Later: see what information you can slip inside of a UCAN: will it fit the entire IAM language?
• Later: does it make sense to use UCANs for kind of a permissions algebra to accumulate rules downstream?

[sestinj]

Notable: It's very easy to make UCANs work for basic stuff, but there's a lot to do in order to make things more efficient and bridge the gap to full IAM language. For example: if you send a subscription request for multiple resources, multiple actions with different expirations, what is the fewest number of UCAN tokens you can create to satisfy all capabilities? And how should the subscriber store and retrieve these quickly depending on what actions they wish to take? Also: if you're going to revoke some permission, how can this be done without revoking all permissions attached to the same token? For this reason, should a separate token be made for every user+resource+action combination? This is sad because it neglects some of the power of UCANs. But maybe users should be able to just request a new UCAN. This causes less worry around losing them, and makes it more natural to revoke and send new ones.