UCAN is not just another wallet-login or bearer-token format. The spec frames it as a local-first, user-originated authorization system built around delegable capabilities rather than central authorization servers.
The most important design move is inversion of control: the resource (or resource owner) is treated as the root of trust, and proofs travel with requests instead of requiring a live lookup against a central ACL or auth server.
The system is decomposed into delegation, invocation, promise, and revocation layers, which makes authorization legible as a graph of portable proofs rather than one opaque session artifact.
The Delegation spec is especially revealing: authority is expressed through issuer/audience/subject relationships plus command paths, policy predicates, nonces, and time bounds. That means command-taxonomy design and executor-side policy interpretation are real governance/control surfaces.
The sub: null Powerline pattern is a distinctive reusable mechanism. It allows stable authority to flow across multiple devices/agents without private-key sharing, but it also creates a broad automatic-delegation surface that needs careful handling.
The conformance-test site is a good maturity signal. The working group is publishing shared fixtures for verify/refute/build/CID tasks, which suggests the ecosystem is trying to standardize behavior beyond prose alone.
Specific source signals worth retaining
UCAN spec README: strongest source for the high-level claim that UCAN is a trustless, local-first, user-originated distributed authorization system and for the explicit rejection of centralized auth-server assumptions.
UCAN Delegation spec: strongest source for the actual authority grammar — subject, command, policy, expiration, and Powerline delegation.
Getting-started docs: best concise implementation-oriented articulation of how UCAN differs from OAuth/ACL systems and how delegation/invocation are intended to be used in practice.
Conformance-test index: useful evidence that the spec is being operationalized into fixtures rather than remaining purely conceptual.
Why this entry belongs in the corpus
It strengthens the wallet/auth/authority cluster with a capability-native model that is broader and more local-first than SIWE-style login standards.
It gives the corpus a better comparison point for products that claim non-custodial permissions, agent delegation, or device-spanning authority without clearly separating delegation, invocation, and revocation.
The durable insight is that authorization can be modeled as portable, attenuated proof chains rooted in resource ownership rather than as app-local sessions rooted in an auth server.