Summary: UCAN is best understood as a user-controlled delegated-authority substrate rather than as a wallet-login standard or a generic API token format. Its core move is to replace centrally checked who can do what lists with signed, composable capability proofs that can be created, delegated, invoked, and revoked without an always-online authorization server. That makes UCAN a useful comparison class for ERC-5573/ReCaps, CAIP-74, WalletConnect Auth, smart-account permission systems, and local-first app auth: the important shift is from session bootstrap toward portable authority graphs where the main control surfaces become root resource ownership, delegation attenuation, proof interpretation, revocation delivery, and executor-side validation.
What it does:
Defines a trustless, local-first authorization model built around signed capability delegations instead of centralized ACL checks
Splits the system into explicit delegation, invocation, promise, and revocation sub-specifications rather than collapsing authorization into one opaque token type
Uses DIDs for issuers, audiences, and subjects so authority can be delegated and verified across distributed systems and peer-to-peer topologies
Lets delegators attenuate authority with command paths, policy predicates, time bounds, and proof chains rather than only granting binary access
Keeps verification local: executors can validate signature chains and authorization proofs without needing a live authorization server round-trip
Includes a sub: null “Powerline” pattern for automatically carrying authority across multiple agents/devices without sharing private keys directly
Publishes conformance fixtures so implementations can test verify/refute/build/CID behavior against shared examples instead of inventing incompatible interpretations
Key claims:
The UCAN spec README describes the system as a “trustless, secure, local-first, user-originated, distributed authorization scheme” with public-key-verifiable, delegable capabilities, which is the clearest reason to catalog UCAN as delegated-authority infrastructure rather than a login convenience layer.
The motivation section explicitly contrasts UCAN with ACL/RBAC-style systems and argues that ahead-of-time centralized rule maintenance creates scaling, privacy, and confused-deputy problems, which makes UCAN analytically useful as an inversion away from list-based authorization.
The spec says there is no Authorization Server sitting between requestors and resources and frames the resource owner as the effective root of trust, which is a major control-surface shift compared with OAuth-like systems and hosted wallet-auth middleware.
The Delegation spec makes the authority model concrete: each delegation binds issuer, audience, subject, command, policy, nonce, and validity period, which shows that UCAN is not just bearer-token auth but an explicit capability-language and attenuation system.
The Delegation spec’s policy language and hierarchical command paths are especially important because they move practical power into command taxonomy design, selector semantics, and executor-side interpretation rather than into one universal permission registry.
The sub: null Powerline pattern is a reusable mechanism insight: UCAN can express stable user authority spread across multiple devices without threshold custody or raw-key sharing, but that convenience also creates a powerful delegation surface that must be handled carefully.
The current conformance-test site is useful evidence that UCAN has moved beyond pure philosophy into shared implementation discipline: the working group publishes fixtures for verifying, refuting, building, and CID-encoding tokens.
The durable corpus insight is that UCAN separates identity, delegated authority, invocation intent, and revocation logistics more cleanly than most wallet-auth systems, making it a strong comparison point whenever a product claims to offer non-custodial permissions or local-first auth.
Whitepaper: No standalone UCAN whitepaper or litepaper surfaced in this pass. The clearest current primary materials were the working-group specification README, the Delegation spec, the community quick-start/docs site, and the conformance-fixture index collected in ../whitepapers/ucan-primary-sources-2026-05-12.md.