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

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

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

Presenting · OpenID4VP

Agent presents the signed mandate

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

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 requirement VP artifact Token

{
  "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.

Read the spec →x401 Demos Talk to Proof