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

Backlinks

Linked Pages

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

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

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

x401 - HTTP Proof Requirement Protocol

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.