With the rise of Web3, there is a renewed interest in the benefits of distributed systems. Distributed systems are scalable, fault-tolerant, cost-effective, and used to power blockchains, Internet of Things (IoT) devices, social media networks, and more.
But are all distributed systems truly decentralized? When it comes to authorizing users, the answer isn't always yes. Blockchains, for example, use cryptographic key signatures to provide access to resources. But what about non-blockchain examples?
If any server instances in a network are using an access control list (ACL), they are not fully decentralized.
So how do we handle authorization in a distributed system?
What is a UCAN?
In 2019, Fission's co-founder and CTO, Brooklyn Zelenka, created the UCAN. UCAN stands for User-Controlled Authorization Network. It is a user-originated authorization and revocation scheme that is trustless and secure, with no ACL required. UCANs provide public-key verifiable, delegable, expressive, and openly extensible capabilities by extending the familiar JWT structure.
How Do UCANs Work?
There are three main parts of a UCAN: Header, Payload, and Signature.
Header
The Header is a standard JWT header. It includes the algorithm (EdDSA) used to sign the UCAN.
Payload
The Payload includes a Decentralized Identifier or DID, the period during which the UCAN is valid, the capabilities (what the receiver of the UCAN, or audience, is allowed to do), and embedded encoded UCANs used as proofs for delegated capabilities.
It's important to understand capabilities, as they are at the heart of the UCAN token. Below is the anatomy of a capability:
{ $RESOURCE: { $ABILITY: [ ...$CAVEATS ] } }A resource is a unique URI whose associated abilities include what the UCAN receiver can or cannot do, like send a message "msg/send". The issuer or delegator may also include caveats only if the eventual invocation can read them.
Signature
The Signature (which must match the DID in the issuer) denotes the validity of the UCAN.
Authority in a Distributed System
To authorize a user, there must be some authority that can approve them to carry out various tasks. In the case of UCANs, the set of capabilities delegated by the UCAN is its authority. Furthermore, except for rights amplification, every unique delegation MUST have equal or narrower capabilities from their delegator. This also controls the flow of authority in the system.
The Lifecycle of a UCAN
After the UCAN is generated, there are a few ways it can be managed.
Delegation
The UCAN holder can delegate the capability to use a resource they have. A proof acts as authorization. Proofs are either the owner's signature or a UCAN with access to that capability in its authority. In other words, another user who has been delegated access to a resource by a UCAN can, in turn, delegate that resource to someone else.
Invocation
An important note is that delegation is a separate concept from invocation. Delegation is the act of granting a capability to another, not the act of using it. UCAN invocation defines a standard for authorizing, chaining, and executing compute tasks. In addition, invocation lays out the format for completed receipts (proof that the computation was completed and what the result was) and how to optimize and resolve inputs for correlated computation tasks.
Attenuation
Attenuation is the process of constraining the capabilities in a delegation chain. It checks that the claimed capabilities match the proofs.
Revocation
Revocation invalidates a UCAN after the fact, outside of the limitations placed on it by the UCAN's fields (such as its expiry). This must be done by a proof's issuer.
Use Cases
We've reviewed how UCANs function, and now let's consider some exciting use cases.
1- Authorized Data Retrieval
UCANs offer a secure way to ensure files are only accessible by authorized users. Fission's ODD SDK uses UCANs to manage access to files in WNFS-enabled apps.
2- App Write Access
Capyloon, a resurrected version of Firefox OS, allows users to locally create DIDs and use them to grant capabilities to 3rd party websites through UCAN tokens, allowing selective access to device resources.
3- Fediverse
Federated social media accounts distribute control and data across multiple independent servers or instances. UCANs offer a way to handle account authorization so the server administrator doesn't have access to participant credentials but can still revoke access as needed.
4- Internet of Things
Computing at the edge requires fast processing and minimal friction. IoT devices need to be able to work even with intermittent Internet access. Since UCANs include the necessary authorization proofs, they can be used to keep the process moving without delay.
UCANs Today
UCAN is an open-source protocol and has stabilized at 0.10.0! As you can see, it's already gaining adoption in the DWeb community. There are Rust, TypeScript, and IPLD libraries, and other implementations are underway. There is also a Go library that needs a maintainer.
If you're interested in learning more about UCANs, or getting involved as a collaborator, we encourage you to check out the following resources:
GitHub - includes the spec and UCAN working group
Community Calls - we host public calls every month and discuss improvements to the protocol
Community Website - use the UCAN validator to break down the parts of the UCAN, read blog posts, watch talks, and even play games all focused on UCAN education