Open protocol · Agentic identity

x401

The proof layer 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 →View docs

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.

● HTTP 401 · Proof required

Service provider challenges the agent

When an agent attempts a protected action, the service returns an HTTP 401 with a PROOF-REQUIRED header. The base64url payload names the credential the agent must present — the proof that a verified human stands behind it — plus the OpenID4VP protocol, a challenge to bind to, and where to exchange the proof.

HTTP/1.1 401 Unauthorized
PROOF-REQUIRED: <base64url-x401-payload>
Cache-Control: no-store

● Presenting · OpenID4VP

Agent presents the signed mandate

The agent turns the requirement into a wallet-facing OpenID4VP request, gets a verifiable presentation back from the human's wallet — the scoped mandate they authorized — and returns it to the verifier in a PROOF-PRESENTATION header, bound to the challenge so it can't be replayed.

POST /accounts/applications HTTP/1.1
Host: bank.example.com
PROOF-PRESENTATION: <base64url-vp-artifact-json>

● HTTP 200 · Authorized

Service provider verifies and proceeds

The verifier validates the presentation — credential type, assurance level, the challenge, and issuer trust. If it checks out, the action proceeds. A reusable verification token can be issued via OAuth token exchange so the next call skips the round-trip.

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

{
  "scheme": "x401",
  "version": "0.1.0",
  "proof": {
    "presentation_protocol": "openid4vp",
    "dcql_query": {
      "credentials": [{
        "id": "financial_customer",
        "format": "jwt_vc_json",
        "meta": { "type_values": ["FinancialCustomerCredential"] },
        "claims": [{ "path": ["credentialSubject", "assurance_level"],
          "values": ["VC-AL2", "VC-AL3"] }]
      }]
    },
    "challenge": {
      "value": "x401:aHR0cHM6Ly9iYW5rLmV4YW1wbGUuY29t:uX7Vq3mZJH6MeN0qz2L7SQ",
      "expires_at": "2026-05-06T18:45:00Z"
    },
    "oauth": { "token_endpoint": "https://bank.example.com/oauth/token" },
    "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.