Fission co-founder and CTO Brooklyn Zelenka shares how UCANs simplify authorization while keeping it decentralized and preserving user agency.

When we think about authorization, an image of a central authority determining what a person is and is not allowed to do comes to mind. In technology, this translates to authorization servers checking a list to see if the person has the correct permissions to access a service.

Even on the decentralized web, this still occurs. For example, if a user is on a machine that isn't running an IPFS node, or the IPFS node they are trying to access is asleep, the only way they can access the namespace that that IPFS node is managing is to log in through some other mechanism. The same goes for many edge apps or dapps. They create a point of centralization, even in a mostly distributed system.

But what if we got rid of the authorization server entirely? What if the user acted as their own auth server? Then we would have decentralized auth. This is where UCAN comes in.


There are two ways to handle authorization - access control lists and capabilities.

Access Control Lists are designed for when users are sharing a terminal. Think of a shared computer register where each sales associate logs in and out of the machine to tie their transactions to their individual profile.


  • Stateful Auth - There is a user, a gatekeeper, and a service. The gatekeeper determines if the user can access the service according to the list.
  • Pro - There are three clear stages in the process.
  • Con - Neither the user nor the service is in control. They have no agency, and all the data is centralized in one list.

Capabilities are designed for networking.


  • Stateless Auth - There is a user who has an address (pointer) to the service they are trying to access and a cryptographic token that says that they can access the service.
  • Pro - The user and service are in control.
  • Pro - All the required info is in the token. We can make copies of the token, share those copies with others, and revoke access to copies if we choose. Access can also be set to expire after a certain timeframe has elapsed.

UCANs vs DIDs - DID you know UCAN have both?

How are UCAN tokens different from DIDs?

  • DIDs are building blocks inside of UCANs!
  • DIDs say who you are. They give you a public key, and you can prove you're allowed to sign (AuthN - authentication)
  • UCANs say what you can do (AuthZ - authorization)

The UCAN Token

The UCAN comprises three main components: The JWT Header, the Payload (which includes the issuer / a DID - and proofs / CIDs), and the Signature (which must match the DID in the issuer).

The proofs demonstrate what capabilities the user has access to. The capabilities include a resource (for example, a path to a document), read or write access, and other extensible fields, like an email address.

The best part, we can delegate authority without sharing keys, making the process much more secure!

What UCAN do with UCANs

Authorized Data Retrieval - When you make your files shareable, UCAN ensures no unauthorized users can request them. In other words, unless you have a valid UCAN, you can't download a content address.

Apps - UCANs are used to delegate write access in WNFS, and WNFS, in turn, is used in many different apps like FxFotos and Fission Drive to manage files.

Authorized Channels - If you'd like to set up a group chat or gossip with specific peers, you will want a way for folks to prove that they are allowed to be in that channel so they can be admitted. Giving peers a shared capability provides them with that proof.

Decentralized Compute - We're using UCANs in IPVM to power distributed pipelines and collaborative processes.

IPFS Thing 2023 Presentation

Watch Brooklyn's full presentation below:

Brooklyn's Presentation Slides

If you'd like to learn more, UCAN visit the GitHub working group, check out the UCAN validator on the community site, or even play a fun adventure game to see UCANs in action!