x401: Identity Protocol for Agentic Commerce
The x401 protocol, introduced by Proof, is an open, actively developed identity framework enabling AI agents in agentic commerce to cryptographically prove the verified human authorization behind digital transactions over standard HTTP, addressing a critical gap in existing agentic commerce systems by providing verifiable human delegation chains and portable digital identities for banks to enhance security, accountability, and fraud prevention.
New
Proof launches portable digital identity for banks
Introducing portable identity
Open protocol · Agentic identity
x401
The identity protocol for agentic commerce
x401 v0.1.0 · OpenID4VP · DCQL · jwt_vc_json · Active development
AI agents are transacting on the web. x401 lets any service ask an agent “can you prove who's behind this request?”— over standard HTTP — and get a verifiable credential back before it grants access.
Read the spec → Register for our webinar
Live agent ledger
✓
agt_3b8e…0c4
POST /checkout · $248.00
Authorizedby Vertex Pay
⟳
agt_b934…7c2
PATCH /subscription
Verifying…
✓
agt_9f2c…a71
POST /checkout · $248.00
Authorizedby Sam Okafor
✕
agt_3b8e…0c4
POST /transfer · $1,500.00
Blockedno identity
✓
agt_77d1…e90
POST /sign · DocID 8841
Authorizedby Jordan Lee
The problem
Every major agent protocol has the same blind spot
Every major agentic commerce framework — Visa TAP, Stripe ACP, Mastercard Agent Pay, Google AP2 — defines what a credential can do. None define who is behind it. When an agent executes a financial transaction, there is currently no mechanism to prove a verified human authorized that specific action, under specific constraints, at that specific time.
Today — every agentic platform
Agent presents credentials — no verifiable human delegation chain behind them
Scope is asserted by the agent — not constrained by a signed human mandate
Counterparty cannot verify the human behind the transaction
No cryptographic evidence if a chargeback, fraud dispute, or audit is filed
Identity verified at onboarding — not re-bound to each action
With x401
Every agent request carries a signed mandate from an IAL2-verified human
Scope is cryptographically constrained — actions outside mandate are rejected
Counterparty verifies human identity, scope, and authorization timestamp independently
Non-repudiable record exists at the moment of every transaction — before dispute
Identity travels with the transaction — bound to each action, not just to session
Protocol mechanics
The complete delegation chain
x401 defines four nodes in the authorization chain. Each node has a verifiable artifact. Remove any node and the chain breaks — the transaction cannot proceed.
Node 01
Human · IAL2 verified
Identity-verified once via biometric + government ID at IAL2. Holds a verifiable credential in a cloud wallet. Enrollment is permanent — identity re-bound per mandate, not per session.
Verifiable Credential · jwt_vc_json
Node 02 Proof
Signed mandate
Human authorizes a scoped credential: which agent, which merchant, what action category, what amount ceiling, what time window. Cryptographically signed — the agent cannot exceed it.
Scoped VC · VC-AL2/AL3
Node 03 Proof
Agent · scoped credential
Agent presents the credential via OpenID4VP at the point of action. Cannot exceed scope. If the action falls outside the mandate parameters — it is rejected.
VP via OpenID4VP
Node 04
Merchant · verified
Independently verifies the presentation: credential, assurance level, scope, and the challenge bound together. Non-repudiable record exists before any dispute is filed.
PROOF-PRESENTATION → 200 OK
IMPLEMENTation
Three things happen every time an agent acts
x401 rides on plain HTTP — no new transport layer to adopt. Three exchanges between the service and the agent's wallet, carried in standard headers, complete the entire proof handshake.
1
HTTP 401 · Proof required
Service provider challenges the agent
HTTP/1.1 401 Unauthorized PROOF-REQUIRED: <base64url-x401-payload> Cache-Control: no-store
2
Presenting · OpenID4VP
Agent presents the signed mandate
POST /accounts/applications HTTP/1.1 Host: bank.example.com PROOF-PRESENTATION: <base64url-vp-artifact-json>
3
HTTP 200 · Authorized
Service provider verifies and proceeds
HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store
Spec · Reference implementation
What an x401 proof requirement looks like
Before it grants access, a verifier returns a small JSON payload in the PROOF-REQUIRED header — naming the credential the agent must present to prove the verified human behind it. Nothing hidden in a proprietary format. Here's the canonical example from the spec.
x401 payload · PROOF-REQUIRED (base64url-decoded)
Proof requirementVP artifactToken
Copy
{
"scheme": "x401",
"version": "0.1.0",
"proof": {
"presentation_protocol": "openid4vp", // wallet-facing protocol
"dcql_query": { // Digital Credentials Query
"credentials": [\
{\
"id": "financial_customer",\
"format": "jwt_vc_json", // JWT-encoded W3C VC\
"meta": {\
"type_values": ["FinancialCustomerCredential"]\
},\
"claims": [\
{\
"path": ["credentialSubject", "assurance_level"],\
"values": ["VC-AL2", "VC-AL3"] // required assurance level\
}\
]\
}\
]
},
"challenge": {
"value": "x401:aHR0cHM6Ly9iYW5rLmV4YW1wbGUuY29t:uX7Vq3mZJH6MeN0qz2L7SQ",
"expires_at": "2026-05-06T18:45:00Z" // challenge TTL
},
"oauth": {
"token_endpoint": "https://bank.example.com/oauth/token"
},
"issuers": {
"trust_establishment_url": "https://bank.example.com/.well-known/x401/trust/financial-customer-v1"
},
"request_id": "proof-template-financial-customer-v1",
"satisfied_requirements": [\
"urn:example:x401:satisfaction:financial-customer:v1"\
]
}
}
Presentation protocol
OpenID4VP
The agent turns the proof requirement into a wallet-facing OpenID4VP request — no bespoke handshake.
Credential query
DCQL
Digital Credentials Query Language names the exact credential, type, and claims a route requires.
Credential format
jwt_vc_json
JWT-encoded W3C Verifiable Credential, returned by the wallet inside a verifiable presentation.
Transport
Proof headers
PROOF-REQUIRED, PROOF-PRESENTATION, and PROOF-RESPONSE carry x401 over ordinary HTTP.
Assurance level
VC-AL2 / AL3
Credential assurance gates which verified credentials satisfy a route — the human is real and vetted.
Token exchange
OAuth 2.0
A satisfied proof exchanges for a reusable bearer token (RFC 8693). The next call skips the round-trip.
Ecosystem
Early adopters are already building on it
x401 is being developed with organizations actively deploying agents at scale across payments, insurance, and financial services. Formal announcements are coming. The spec is open now — these use cases illustrate why early implementers are moving fast.
Use case · Payments infrastructure
Agent-initiated payments
A global payments network is adopting x401 as the identity layer for agent-initiated transactions. When an AI agent executes a payment on a user's behalf, the receiving institution needs cryptographic proof that a verified human authorized the specific transaction — amount, merchant, and time window — before funds move.
Identity layer · Agent-to-payment rail
Use case · Enterprise insurance
Delegated account actions
A Tier 1 insurer is evaluating x401 to govern customer-authorized agents filing claims, opening accounts, and submitting applications. The requirement: every agentic action must be traceable to a verified human identity with a signed, scoped mandate — not an API key or a session token.
Protocol reviewer · Agentic enterprise deployment
Proof's role
The reference implementation for the identity layer
x401 is an open protocol — any CA can issue conformant credentials. Proof is the primary implementer: a WebTrust-certified CA with FIPS 140-2 Level 3 infrastructure, Kantara IAL2 enrollment, and an 8,000+ relying-party network. Build on Proof and your agents start with credentials that are trusted by default — no onboarding friction for your users.
8,000+
Relying parties in the Proof identity network
IAL2
Identity assurance behind every credential
OpenID4VP
The wallet presentation protocol x401 uses
Open
Any CA, any wallet, any agent
Enrollment
One API call
IAL2 enrollment, credential issuance, and wallet provisioning in a single OpenID4VP flow. No app download required.
Compliance
WebTrust · AATL
WebTrust for CA certified and on the Adobe AATL — credentials trusted by default in enterprise environments.
Infrastructure
FIPS 140-2 L3
Keys generated and stored in FIPS 140-2 Level 3 HSMs. Root CA is offline, air-gapped, and ceremony-controlled.
Start building
Start implementing x401
The spec is open. The reference implementation is live. Leading organizations in payments and enterprise insurance are already building on it. The window to establish the proof layer for agentic commerce is now.