UCAN

Identity Protocol

User Controlled Authorization Network: a specification for authorization that is public-key verifiable, delegable and openly extensible, with no central authority needed to check a permission. A UCAN is a signed token in which one party, identified by a decentralized identifier (DID), grants a capability over a resource to another and may allow that party to pass it on in narrower form; a chain of such tokens is the proof that a request is authorised, and anyone can verify the chain offline. The specification is split into sub-specifications for delegation, invocation, promise and revocation. It was designed for local-first and peer-to-peer settings and positions itself as a successor to access control lists and as an authorization layer for applications and AI agents .

Community
Links
Visit Website See this tool in the graph Suggest an edit

Details

License Specification text under the Community Specification License 1.0; any source code or reference code in the repository is under the MIT licence . https://github.com/ucan-wg/spec
Dev Status 🟢 Active
Owner A community working group around the ucan-wg organisation; the specification's editor is Brooklyn Zelenka (Witchcraft Software) and its listed authors are from Protocol Labs, Bluesky, number zero and Witchcraft Software
Owner - List
  • Protocol Labs
Governing Body UCAN Working Group (ucan-wg) with a governance document in the repository; the cited sources do not describe how decisions are made beyond that
Country Not stated by the project.
Start Year 2021
Stack DAG-CBOR-encoded signed tokens, DIDs for principals, public-key signatures; sub-specifications for delegation, invocation, promise and revocation
Funding Not stated by the project.
Last Investigated Oct 29, 2026

Topology view

This tool in the centre and the things it is directly related to. Each line names the kind of relationship.

Topology view: UCANThis tool in the centre and the things it is directly related to. Each line names the kind of relationship.UCANKeyhive (Basis for, Conforming implementations, Inspired)KeyhiveDIDs (Conforms to, Speaks protocol)DIDsProtocol Labs (Developed by)ProtocolLabsArweave (Interoperates with)ArweaveIPFS (Interoperates with)IPFS
  • Keyhive (Tool): Basis for, Conforming implementations, Inspired
  • DIDs (Tool): Conforms to, Speaks protocol
  • Protocol Labs (Organization): Developed by
  • Arweave (Tool): Interoperates with
  • IPFS (Tool): Interoperates with

Open in Graph Explorer

Use Case Domains

Identity & Trust

Affordances

Sovereign identity Portable attestations

Identity Protocol Attributes

Owner - List
  • Protocol Labs
Origins Authorization for local-first and peer-to-peer systems: replace access control lists on a central server with user-originated, delegable capabilities that can be verified offline, building on the SPKI/SDSI and object-capability traditions
Database N/A
Query Language N/A
Data Formats UCAN tokens encoded with DAG-CBOR; principals as DIDs; the delegation, invocation, promise and revocation formats are given in the sub-specifications
Mobile Support Library-level: the project lists libraries; the specification itself is platform-independent
Web Support Yes: a project website with a UCAN inspector, and JavaScript libraries listed by the project
Native Apps Library-level only; UCAN is a token format, not an application
Terms Free and open: the specification is published under the Community Specification License 1.0, with sample code under MIT
Funds Not stated by the project.
Based On SPKI/SDSI certificates and object-capability security; DIDs and DAG-CBOR; the specification cites the lineage of capability systems
Permissions The model is the permission model: capabilities are delegated downward and can only be narrowed, never widened (attenuation)
Authentication & Identity Principals are identified by DIDs and prove control by signing; authorization is carried as a chain of delegations to the subject DID rather than a login
Storage Model Tokens are self-contained and carried by the parties; no registry or ledger is required for verification
Interoperability Designed to work across DID methods and with content-addressed storage and web APIs; the site names IPFS, Arweave and API access as use cases
Data Portability Authority is portable: a chain of delegations can be presented to any verifier that understands the format, independent of the service that issued the first token
Governance & Decision Making Working-group process documented in the repository's governance file and scope document; changes are made through issues and pull requests
Protocol Maturity / Standardization Specification version 1.0.0 in the README with a v1.0 release candidate tagged; Community Specification License; not a standards-body deliverable
Identity Standards DIDs (W3C); DAG-CBOR and content identifiers; a UCAN is not itself a W3C or IETF standard
Identity Standards - List
DID Methods Supported Any DID method that can resolve a verification key; the specification does not mandate one
Key Management Each principal holds its own signing key; delegation is by signature, so key custody is left to the application or wallet
Credential Types Capabilities (delegations and invocations) rather than identity credentials
Credential Types - List
Verification Method A validator checks the signatures, time bounds and attenuation along the whole delegation chain, offline, without contacting the issuer
Privacy Features Limited by design: a token reveals the issuer, audience and capability granted; the specification does not describe zero-knowledge or selective disclosure
Authentication Methods Public-key signatures by the issuing principal over the token
Revocation Mechanism A separate revocation sub-specification; tokens can also carry expiry times and the site mentions blacklisting support
Agent Types Supported Any agent with a DID, including people, organisations, services and, the site says, AI agents
Wallet/Client Types Libraries and applications that hold keys; no dedicated wallet is described in the cited sources
Recovery Mechanisms Not stated by the project.
Compliance / Regulations Not stated by the project.
Credential Exchange Protocols Invocation and delegation are defined by the specification; transport (HTTP, peer-to-peer, other) is left to the application
Credential Exchange Protocols - List
Trust Framework Cryptographic proof chains rooted at the resource's owner, with no central registry; the verifier decides which roots to trust
Cost Model Free to use
Censorship Resistance High for verification, since no central party is consulted; issuance and storage depend on the application

Relationships

How this tool connects to other tools and organizations, from relationships reviewed by the OpenHaven data steward. They describe how projects connect, not how good they are.

Conforms to
Developed by
  • Protocol Labs
Speaks protocol
Interoperates with
Basis for
Conforming implementations
Inspired