AWAKE

  • Name: AWAKE (Authorized Wire for Authenticated Key Exchange)
  • URL: https://github.com/ucan-wg/awake
  • Category: capability-rooted authenticated key exchange / P2P secure-session bootstrap / UCAN-to-MLS authority-validation protocol
  • Summary: AWAKE is best understood as a capability-rooted session-bootstrap protocol for open-channel peer-to-peer systems rather than as a generic key exchange or a generic UCAN extension. Its core move is to start from a public channel, use temporary X25519 identities plus encrypted UCAN-based authority proofs to validate that the counterparty can actually perform the requested actions, and then hand the session off to MLS for ongoing secure messaging. That makes AWAKE a useful comparison class for CAIP-25 session flows, WalletConnect Auth, UCAN, and other local-first trust bootstraps: the important question is not just how two parties encrypt a channel, but how they prove relevant authority before the channel becomes trusted.
  • What it does:
    • Defines a mutually authenticating authenticated-key-exchange flow for P2P applications operating over open or weakly trusted public channels
    • Starts with a public broadcast from a requestor using a fresh temporary X25519 DID plus explicit capability criteria that the provider must prove
    • Has the provider return an encrypted, signed, nullipotent UCAN proving access to the requested resources without yet delegating usable authority to the requestor
    • Uses X25519 for shared-secret generation, HKDF for key derivation, and XChaCha-Poly1305 for the pre-MLS encrypted envelope during handshake bootstrapping
    • Requires UCAN as the signature/authz envelope for the handshake so trust is rooted in provable capabilities rather than only in endpoint identity
    • Hands successful sessions off to Messaging Layer Security (MLS) for the ongoing secure group or point-to-point channel after the initial authorization checks complete
    • Separates provider authorization from requestor authorization, making counterparty-capability proof a first-class stage instead of an implementation detail
  • Key claims:
    • The AWAKE spec abstract describes it as a mutually authenticating AKE for P2P applications that roots authority using UCAN capability chains, which is the clearest reason to catalog it as session-bootstrap and authority-validation infrastructure rather than as generic messaging.
    • The introduction says AWAKE bootstraps a secure session “on top of a public channel,” which is analytically important because it targets the trust problem in open-channel and local-first environments instead of assuming the dialed endpoint is already the right one.
    • The motivation and approach sections explicitly argue for emphasizing “what they have access to” over “who they are,” which makes AWAKE a strong comparison point for capability-first trust models and for products that overclaim identity when they really prove actionability.
    • The spec intentionally composes existing tools rather than inventing a whole new stack: UCAN provides authority proof, while MLS provides the post-handshake secure channel. That split makes the trust bootstrap layer legible instead of flattening it into the transport.
    • The protocol sequence is especially useful: public intent broadcast, provider authorization, requestor authorization, then MLS traffic. This separates counterparty proof, challenge method choice, and final secure-session establishment into distinct control surfaces.
    • The provider’s “nullipotent UCAN” is a meaningful mechanism detail because it proves capability possession without granting usable authority yet, which is a sharper decomposition than most auth handshakes provide.
    • The cryptographic choices in the current spec — fresh X25519 session material, HKDF-derived secrets, and XChaCha-Poly1305 envelopes before switching to MLS — show that the protocol is trying to minimize reused state and keep the bootstrap phase narrow.
    • The current governance and versioning materials also matter: this is still a working-group-style specification with community-spec governance, so it belongs in the corpus more as a promising control-plane design and comparison object than as already-dominant production infrastructure.
  • Whitepaper: No standalone AWAKE whitepaper or litepaper surfaced in this pass. The clearest current primary materials were the specification README and repository governance materials collected in ../whitepapers/awake-primary-sources-2026-05-12.md.
  • Sources:

Internal linkages

  • Capability-first authority substrate that AWAKE explicitly composes for handshake proof: ucan.
  • Wallet/session comparables that also turn an initial approval into durable machine-readable authority: caip-25 and walletconnect-auth.
  • Read AWAKE when a system claims to provide a secure channel but the real question is which layer proves counterparty authority before the channel becomes trusted.
  • Last reviewed: 2026-05-30 UTC