x401: HTTP Proof Requirement Protocol

Reference: Buchner, D. (Proof) & Agarwal, B. (Circle), eds. (2025). x401: HTTP Proof Requirement Protocol, v0.2.0 (Draft). Reviewers from Okta, OpenAI, Visa & MATTR. Latest spec.

Summary

x401 is an HTTP-native protocol that lets a protected resource demand a cryptographic proof of credentials — proof of personhood, residency, membership, or organisational standing — before granting access, without bolting onto the traditional HTTP authentication schemes. Where an ordinary server answers an unauthorised request with 401 Unauthorized plus a WWW-Authenticate challenge, an x401 verifier answers with a route-scoped PROOF-REQUIRED header carrying a base64url-encoded proof request describing exactly which credential claims the route needs. The requester — a browser, wallet, or autonomous agent — obtains a matching Verifiable Presentation and retries the route with it, optionally trading a one-time proof for a reusable access token.

The protocol is deliberately a thin coordination layer rather than a new credential format: it composes with the W3C Digital Credentials API, OpenID4VP, and OAuth 2.0 instead of replacing them, so the actual presentation can be invoked natively by the user agent, relayed to a remote wallet, or generated remotely and returned by reference. x401 also draws a sharp line between proof of credentials and payment: it keeps 402 Payment Required for the money case and explicitly refuses to overload credential proofs as payment proofs, leaving it complementary to agent payment rails (e.g. the x402 payment scheme and AP2) rather than competing with them. The editing organisations (Proof, Circle) and reviewer roster (Okta, OpenAI, Visa, MATTR) place it squarely in the emerging stack for letting AI agents transact and authenticate across the open web.

Key Ideas

Route-scoped proof requirements: a resource declares, per route, which credential claims it requires — the proof requirement travels with the HTTP response, not out of band.
Four protocol legs: (1) Proof Declaration — verifier returns a PROOF-REQUIRED header with a base64url-encoded request; (2) Presentation Acquisition — the agent obtains a presentation natively, via wallet relay, or by remote generation; (3) Proof Delivery — the agent retries the route with the presentation inline or by reference; (4) Token Exchange — optionally swap a verified proof for a reusable access token.
Composes, doesn’t reinvent: built on the W3C Digital Credentials API, OpenID4VP, and OAuth 2.0; the credential cryptography lives in VCs/VPs and DIDs, not in x401 itself.
Agent-native acquisition paths: an agent can invoke the credential request directly, relay it to a remote wallet, or accept a remotely generated result — making the protocol usable by headless autonomous agents, not just interactive browsers.
Strict separation from payment: 402 Payment Required stays the payment signal; x401 credentials are never overloaded as payment proofs, keeping authorisation-by-credential and payment as orthogonal concerns.
Draft, multi-stakeholder: v0.2.0 Draft, edited by Proof and Circle with reviewers from identity (Okta, MATTR), AI (OpenAI), and payments (Visa).

Connections

Conceptual Contribution

Claim: Access control on the open web should be expressible as a per-route proof requirement — “show me a credential proving X” — declared in-band over HTTP, so that any client, including an autonomous agent, can discover the requirement, fetch a matching presentation, and proceed, all without coupling credential proof to payment or to a single identity provider.
Mechanism: A four-leg HTTP exchange (Proof Declaration via a PROOF-REQUIRED header carrying a base64url proof request → Presentation Acquisition → Proof Delivery, inline or by reference → optional Token Exchange) layered over the W3C Digital Credentials API, OpenID4VP, and OAuth 2.0, deliberately disjoint from the 402 Payment Required payment path.
Concepts introduced/used: Verifiable Presentation, Verifiable Credential, DID, OpenID4VP, OAuth 2.0, W3C Digital Credentials API, Agent Infrastructure
Stance: specification / protocol design (draft standard)
Relates to: Operationalises the Decentralized Identifiers credential stack as an HTTP authorisation handshake; sits in the Agent Infrastructure attribution layer alongside Model Context Protocol and Agent-to-Agent Protocol; complements the payment side handled by Agent Payments Protocol and the x402 payment scheme; inherits the authority-not-identity instinct of SPKI-SDSI.

Backlinks

Linked Pages

SPKI-SDSI

SPKI / SDSI: A Simple Distributed Security Infrastructure with Linked Local Names

Reference: Rivest, R. L. & Lampson, B. (1996). SDSI — A Simple Distributed Security Infrastructure. (Working document, MIT.) Followed by: Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B. & Ylonen, T. (1999). SPKI Certificate Theory. RFC 2693, IETF. (Also: Clarke, D. E., Elien, J.-E., Ellison, C., Fredette, M., Morcos, A. & Rivest, R. L. (2001). Certificate Chain Discovery in SPKI/SDSI. Journal of Computer Security 9(4).) Open access (RFC 2693) · SDSI 1.0 (Rivest-Lampson, MIT) · Chain discovery (Elien MIT MS thesis 1998)

Summary

Rivest, Lampson, Ellison and the SPKI working group develop SPKI/SDSI, a public-key infrastructure that takes a sharply different stance from the X.509 / hierarchical-CA tradition: instead of a global namespace of certified identities rooted in a chain of certificate authorities, SPKI/SDSI gives each principal its own local namespace and certificates that bind keys to authorisations rather than identities. SDSI’s central innovation is linked local names: K_alice's friends is a name in K_alice’s namespace; K_alice's friends's secretary is a chain of links — no global registry needed. Authority delegation is similarly local: a certificate K_a → K_b : auth issued by K_a grants authority auth to K_b, optionally with delegation rights. Authority is what matters, not who — a distinction Lampson summarised as “we’re moving from authentication to authorization.” The SPKI Certificate Theory (RFC 2693) formalises this: certificates are 5-tuples <Issuer, Subject, Delegation, Authority, Validity>; chain discovery (Clarke et al. 2001) gives a sound and complete algorithm for deriving “does this principal have this authority?” from a collection of certificates. The design directly anticipates modern decentralised identity / object-capability composition: SPKI/SDSI is the conceptual bridge between the object-capability tradition (E, Spritely) and the cryptographic-identity tradition (X.509, PGP). DIDs and Verifiable Credentials inherit substantial conceptual machinery from SPKI/SDSI; Macaroons (Birgisson et al. 2014) are SPKI-style attenuable capability tokens for HTTP APIs.

Key Ideas

Authorization, not authentication: certificates bind keys to authorities — what the principal is permitted to do — rather than to identities. The question “who is this key?” is replaced by “what is this key allowed to do?”
Local namespaces (SDSI): each principal has its own namespace; names are local identifiers like K_alice's bob, with no global resolution. Linked local names chain across namespaces: K_alice's bob's friends resolves through K_alice’s and then K_bob’s namespaces.
Delegation as a first-class certificate field: a certificate may grant authority with or without the right to re-delegate; chains of delegated certificates are the principal authority-derivation mechanism.
5-tuple certificates: <Issuer, Subject, Delegation-flag, Authorization-S-expression, Validity> (RFC 2693 §2.4 calls the field “Authorization”, not “Authority”); the Authorization is an S-expression in a structured language (action, object, qualifier) that supports rich access-control specifications.
Chain discovery (Clarke et al. 2001): given a goal K_principal has authority A, the chain-discovery algorithm searches the certificate collection for a derivation; sound and complete; polynomial in the size of the certificate collection for many practical fragments.
No mandatory identity binding: certificates may bind keys to local names (SDSI-style) or directly to authorisations (SPKI-style) — identity is just one kind of authority. The system can be used without ever assigning a global “real name” to a key.
Capability composition: SPKI authorities compose under intersection and chain; the resulting authority is the most-restrictive intersection along the chain. This is exactly the capability-security composition rule lifted to a certificate-based distributed setting.

Connections

Conceptual Contribution

Claim: A distributed security infrastructure should bind cryptographic keys to authorisations (what they may do) rather than to identities (who they “really” are); each principal should have its own local namespace; authority delegation should be first-class with an explicit chain-discovery algorithm. The X.509 hierarchical-CA model is the wrong fit for most distributed-system access-control needs.
Mechanism: 5-tuple certificate format (issuer / subject / delegation / authority / validity); local namespaces with linked-local-names resolution; sound and complete chain-discovery algorithm; authority composition under intersection.
Concepts introduced/used: SPKI, SDSI, Linked Local Names, Capability Certificate, Authority-not-Identity, Chain Discovery.
Stance: foundational systems-design paper / IETF specification.
Relates to: Direct conceptual bridge between the object-capability tradition (Dennis & Van Horn 1966, EROS, the E-language line in Miller 2006) and the cryptographic-identity tradition (X.509, PGP). SPKI/SDSI explicitly takes the capability stance — unforgeable name = capability — and lifts it into a distributed cryptographic setting where the unforgeability comes from the public-key cryptography rather than from memory protection. The Macaroons paper (Birgisson, Politz, Erlingsson, Taly, Vrable & Lentczner 2014) is SPKI/SDSI’s most-deployed modern descendant: HMAC-chained authority tokens with attenuation, used in production at Google and elsewhere. Modern decentralised-identity standards — W3C DIDs, Verifiable Credentials, the Authorization Capabilities (zCaps) work — inherit substantial conceptual machinery from SPKI/SDSI even when they do not cite it directly. Within this vault, SPKI/SDSI is the missing distributed-cryptographic counterpart of the in-process capability work in Capability Myths Demolished and Robust Composition - Towards a Unified Approach to Access Control and Concurrency Control — it is what those frameworks become when keys cross machine boundaries. The Lowe/PKI Layer Cake - Kaminsky Patterson Sassaman-style critiques of X.509 PKI are simultaneously arguments for SPKI-style local-name systems: parser differentials and the trust-collapse-by-CA-misissuance problem largely vanish when certificates bind authority rather than identity.

Agent Payments Protocol (AP2)

Google-led protocol letting AI agents perform financial transactions on behalf of users, with cryptographic mandates bounding what each agent may pay and to whom.

In this vault

Agent-to-Agent Protocol

A2A — protocol for inter-agent communication among autonomous LLM agents.

Discussed in:

Model Context Protocol

MCP — an open protocol (Anthropic, 2024) standardising how LLM applications connect to external tools and data sources.

Discussed in:

Agent Infrastructure

Technical systems and shared protocols external to individual AI agents that mediate their interactions with each other, humans, and institutions. Three core functions per Chan et al. 2025: attribution (agent IDs, credentials, audit), interaction shaping (protocols, mechanism design, reputation), and detection & remediation (anomaly detection, rollback, compensation).

In this vault

Decentralized Identifiers

W3C-standardised globally resolvable identifiers (DIDs) that are created, owned and controlled by their subject without a central registry. Each DID resolves to a DID Document containing public keys and service endpoints, supporting self-sovereign agent identity.

In this vault

W3C Digital Credentials API

A browser API, standardised at the W3C, that lets web pages request digital credentials from a user’s wallet (on-device or via a remote/cross-device flow) through the user agent, building on the Credential Management mechanism. It provides the user-agent-mediated plumbing by which a site can invoke a credential request and receive a Verifiable Presentation — handling user consent and wallet selection — while leaving the credential format and exchange protocol (e.g. OpenID4VP) to other specs. It is one of the standards that x401 composes with for its presentation-acquisition leg.

In this vault

OAuth 2.0

The IETF authorization framework (RFC 6749) that lets a client obtain delegated, scoped access to a protected resource on behalf of a resource owner without handling the owner’s credentials. An authorization server issues access tokens — typically short-lived bearer tokens — that the client presents to the resource server; scopes bound the granted authority. OAuth 2.0 is an authorization (not authentication) protocol, and is one of the existing standards that x401 composes with — its token-exchange leg can trade a verified credential proof for a reusable OAuth-style access token.

In this vault

OpenID4VP

OpenID for Verifiable Presentations — an OpenID Foundation protocol that extends the OAuth 2.0 / OpenID Connect family to request and deliver verifiable presentations of credentials held in a user’s wallet. A verifier sends a presentation request describing the required claims; the wallet returns a cryptographically verifiable presentation derived from the holder’s credentials, supporting selective disclosure. It is one of the credential-exchange standards that x401 composes with rather than replacing, supplying the actual presentation mechanism behind an HTTP proof requirement.

In this vault

Decentralized Identifier

A W3C-standardised globally-unique URI of the form did:method:identifier whose resolution is governed by a DID method algorithm rather than by any centralised registry. The portion before the colon names the resolution method (did:key, did:web, did:ion, …); the resolution result is a DID Document containing public keys, service endpoints, and verification relations. The substrate of self-sovereign identity; the modern descendant of SPKI/SDSI capability-style PKI.

In this vault

Verifiable Credential

A W3C-standardised signed assertion (JSON-LD or JWT) issued by one DID-identified party (the issuer) about another DID-identified party (the subject). Carries issuer, credentialSubject, dates, claims, and a cryptographic proof. Supports selective disclosure (BBS+ signatures), zero-knowledge predicates (zk-SNARK proofs over claims without revealing them), and revocation via status-list credentials. Presented to a verifier via a Verifiable Presentation.

In this vault

Verifiable Presentation

A signed package wrapping one or more Verifiable Credentials (or selectively-disclosed subsets thereof), presented by a holder to a verifier with a proof of possession anchored to a key in the holder’s DID Document. Supports zero-knowledge proofs of credential possession without revealing the credentials themselves; the privacy-preserving counterpart of “show me your driver’s licence.”

In this vault

HTTP 402 Payment Required

(page does not exist)

Authentication Protocol

A cryptographic protocol whose goal is to allow one principal to verify the identity of another (and typically to establish a shared session key for subsequent secure communication). Canonical examples: Needham-Schroeder Protocol (1978), Kerberos (1980s), TLS handshake, Signal X3DH/PQXDH, FIDO2/WebAuthn. Verification is the subject of BAN Logic, the Spi Calculus, and modern symbolic provers (ProVerif, Tamarin) under the Dolev-Yao threat model.

In this vault

Capability Security

Access-control style where authority is conveyed by unforgeable object references; lexical scope in languages like Scheme suffices as a capability kernel.

In this vault

DID Document

The resolution result of a Decentralized Identifier — a JSON-LD or JSON document containing verificationMethod (public keys), verification relations (authentication, assertionMethod, keyAgreement, capabilityDelegation, capabilityInvocation), and service endpoints. The capabilityInvocation and capabilityDelegation relations support SPKI-SDSI-style authority-not-identity authorisation flows.

x401: HTTP Proof Requirement Protocol

Summary

Key Ideas

Connections

Conceptual Contribution

Tags

Backlinks