diff --git a/.prettierignore b/.prettierignore
new file mode 100644
index 0000000..3a02d32
--- /dev/null
+++ b/.prettierignore
@@ -0,0 +1,4 @@
+dist
+spec/spec.md
+spec/fixtures/
+spec/normative-ledger.json
diff --git a/CLAUDE.md b/CLAUDE.md
index 235f973..3e7f64c 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -1,18 +1,22 @@
 # @proof.com/x401-node - AI Assistant Guide
 
-ESM TypeScript library implementing the x401 protocol (https://x401.proof.com/spec):
-the PROOF-REQUIRED / PROOF-PRESENTATION / PROOF-RESPONSE wire format, the Verifier Challenge,
-the VP Artifact, the x401 Token / Error objects, and the OAuth Token Exchange profile.
+ESM TypeScript library implementing the x401 protocol (https://x401.proof.com/spec, **v0.2.0**):
+the PROOF-REQUIRED / PROOF-PRESENTATION / PROOF-RESPONSE wire format, the composed Digital
+Credentials request (`presentation_requirements`), the VP Artifact (inline result or
+`presentation_uri` reference), the x401 Token / Error objects, and the OAuth Token Exchange profile.
 
 Two consumer roles, exported as namespaces:
 
-- `agent.*` — decode PROOF-REQUIRED (header or embedded `<data>`), package a wallet result as a VP
-  Artifact, encode PROOF-PRESENTATION, build a token-exchange request, decode PROOF-RESPONSE errors.
-- `verifier.*` — create/verify the Verifier Challenge, build/encode the payload, emit the embedded
-  `<data>` mirror, decode incoming VP Artifacts / Token Objects, parse token-exchange requests,
-  encode error objects.
+- `agent.*` — decode PROOF-REQUIRED (header or embedded `<data>`), read the Verifier-composed
+  `presentation_requirements`, package a presentation result as a VP Artifact (inline or by
+  reference), encode PROOF-PRESENTATION, build a token-exchange request, decode PROOF-RESPONSE errors.
+- `verifier.*` — build/encode the flat payload (carrying the caller-composed
+  `presentation_requirements`), emit the embedded `<data>` mirror, decode incoming VP Artifacts /
+  Token Objects, parse token-exchange requests, encode error objects.
 
-Plus `createEncryptor` (AES-GCM verifier-protected nonce state).
+Spec-conformance harness lives under `spec/` (pinned schema + extracted examples + normative ledger)
+and `scripts/` (`sync-spec-fixtures.ts`, `extract-normative.ts`). See `spec/UPGRADING.md` for the
+repeatable spec-upgrade loop and `spec/conformance.md` for the requirement→code map.
 
 ## Hard Rules
 
@@ -55,14 +59,12 @@ Plus `createEncryptor` (AES-GCM verifier-protected nonce state).
 
 ## Source Map
 
-- `src/constants.ts` — scheme/version, header names, schema URL, token-exchange URNs.
-- `src/types.ts` — wire-format types (no runtime code).
+- `src/constants.ts` — scheme/version (`0.2.0`), `DC_API_PROTOCOL` (signed/unsigned), header names, schema URL, token-exchange URNs.
+- `src/types.ts` — wire-format types (no runtime code): flat `X401Payload`, `DigitalCredentialRequest`, `PresentationResult`, `VPArtifact`.
 - `src/encoding.ts` — base64url JSON helpers over `@owf/identity-common`; proof-header comma guard.
 - `src/validate.ts` — structural validators / type guards (`X401ValidationError`).
-- `src/encryptor.ts` — `createEncryptor` (AES-GCM + HKDF verifier-protected nonce state; `encrypt`/`decrypt`).
-- `src/challenge.ts` — Verifier Challenge construct/verify (binds verifier id, route, method, expiry).
-- `src/agent.ts` — agent-side primitives.
-- `src/verifier.ts` — verifier-side primitives (re-exports challenge functions).
+- `src/agent.ts` — agent-side primitives (`getDigitalCredentialRequest`, `buildVPArtifact`/`buildVPArtifactReference`, …).
+- `src/verifier.ts` — verifier-side primitives (`buildPayload`, `embedHtmlData`, decoders, token-exchange parse, error builder).
 - `src/index.ts` — public barrel (explicit named exports; `agent`/`verifier` namespaces).
 
 ## Publishing
diff --git a/README.md b/README.md
index d2846e9..240da65 100644
--- a/README.md
+++ b/README.md
@@ -1,23 +1,24 @@
 # @proof.com/x401-node
 
-Node.js SDK for the [x401 protocol](https://x401.proof.com/spec).
+Node.js SDK for the [x401 protocol](https://x401.proof.com/spec) (v0.2.0).
 
 x401 gates an HTTP resource behind an identity proof requirement. The server (_verifier_) returns a
-[`PROOF-REQUIRED`](https://x401.proof.com/spec/#proof-header-fields) header and the user _agent_ retries
-with a [`PROOF-PRESENTATION`](https://x401.proof.com/spec/#route-retry-headers) header carrying a
-Verifiable Credential Presentation. This package implements the data types and processing rules for both the _verifier_ and the user _agent_.
+[`PROOF-REQUIRED`](https://x401.proof.com/spec/#proof-header-fields) header carrying a composed
+[Digital Credentials API](https://www.w3.org/TR/digital-credentials/) request; the user _agent_
+obtains a presentation for that request and retries with a
+[`PROOF-PRESENTATION`](https://x401.proof.com/spec/#route-retry-headers) header. This package
+implements the data types and processing rules for both the _verifier_ and the user _agent_.
 
-It does **not** verify credentials — the `vp_token` is opaque, so pair it with a credential library
-such as [`@proof.com/proof-vc-common`](https://www.npmjs.com/package/@proof.com/proof-vc-common). It
-also does **not** build the wallet-facing OpenID4VP request; that is the user agent's responsibility.
+It does **not** verify credentials — the presentation result is opaque, so pair it with a credential
+library such as [`@proof.com/proof-vc-common`](https://www.npmjs.com/package/@proof.com/proof-vc-common).
+It also does **not** compose or sign the OpenID4VP request, nor invoke the wallet; the verifier
+authors the request (out of scope here) and this package carries it opaque in `presentation_requirements`.
 
 ## Table of Contents
 
 - [Installation](#installation)
 - [Verifier](#verifier)
   - [Protect a resource (`PROOF-REQUIRED`)](#protect-a-resource-proof-required)
-    - [Proof challenge](#proof-challenge)
-    - [Proof requirement](#proof-requirement)
   - [Verify a Proof (`PROOF-PRESENTATION`)](#verify-a-proof-proof-presentation)
 - [Agent](#agent)
   - [Read a Proof requirement (`PROOF-REQUIRED`)](#read-a-proof-requirement-proof-required)
@@ -35,84 +36,44 @@ npm install @proof.com/x401-node
 
 ### Protect a resource (`PROOF-REQUIRED`)
 
-A protected route returns a [Proof requirement](#proof-requirement) built around a
-[Proof challenge](#proof-challenge).
-
-#### Proof challenge
-
-The Proof challenge contains a nonce tied to the resource the agent wants to access. The agent
-submits that nonce, inside a [VP Artifact](https://x401.proof.com/spec/#vp-artifact), to access the
-protected resource. The challenge must follow the
-[challenge format](https://x401.proof.com/spec/#verifier-challenge-format). Provide your own, or use
-the built-in challenge encryptor to create one.
-
-##### Built-in challenge encryptor
-
-`createEncryptor` binds the route context into the nonce, so the verifier holds no per-challenge
-state. The same secret must be present wherever challenges are verified.
+The [x401 payload](https://x401.proof.com/spec/#x401-payload) carries the Verifier-composed
+[Digital Credentials request](https://x401.proof.com/spec/#presentation-requirements) and the OAuth
+token endpoint used for [token exchange](#exchange-a-proof-for-a-token). You compose and (for the
+RECOMMENDED signed mode) sign the OpenID4VP request yourself; this package carries it opaque.
 
 ```ts
-import { createEncryptor, verifier } from "@proof.com/x401-node";
-
-const encryptor = createEncryptor({ key: process.env.X401_KEY! });
-
-const challenge = await verifier.createChallenge({
-  verifierId: "https://research.example.com",
-  resource: "https://research.example.com/papers/medical-study-123",
-  method: "GET",
-  encryptor,
-  ttlSeconds: 600,
-});
-```
-
-The nonce is an AES-256-GCM token (HKDF-derived key). [Verify a Proof](#verify-a-proof-proof-presentation)
-rejects any value whose nonce was tampered with.
-
-##### Supply your own challenge
-
-You can construct a [`VerifierChallenge`](https://x401.proof.com/spec/#verifier-challenge-format) if you prefer storing
-the challenge server side or prefer a different nonce generation algorithm.
-
-```ts
-const challenge = {
-  value: `x401:${Buffer.from("https://research.example.com").toString("base64url")}:${myStoredNonce}`,
-  expires_at: new Date(Date.now() + 600_000).toISOString(),
-};
-```
-
-#### Proof requirement
+import { verifier } from "@proof.com/x401-node";
 
-The [x401 payload](https://x401.proof.com/spec/#x401-payload) carries the challenge, the credential
-query and the OAuth token endpoint used for [token exchange](#exchange-a-proof-for-a-token).
-
-##### Create the payload
-
-`buildPayload` requires exactly one credential query: `dcql_query` or `scope`. `oauth.token_endpoint`
-is required.
-
-```ts
 const payload = verifier.buildPayload({
-  proof: {
-    challenge,
-    oauth: { token_endpoint: "https://research.example.com/oauth/token" },
-    scope: "urn:proof:params:scope:verifiable-credentials:basic",
+  presentationRequirements: {
+    requests: [
+      {
+        protocol: "openid4vp-v1-signed",
+        data: { request: signedOpenId4vpRequestJwt },
+      },
+    ],
   },
+  oauth: { token_endpoint: "https://research.example.com/oauth/token" },
+  trustEstablishment:
+    "https://research.example.com/.well-known/x401/trust/basic-v1",
+  requestId: "proof-template-basic-v1",
+  satisfiedRequirements: ["urn:proof:x401:satisfaction:basic:v1"],
 });
 ```
 
-##### Payload in the header
+`protocol` is `openid4vp-v1-signed` (RECOMMENDED) or `openid4vp-v1-unsigned`, and its `data`
+carries the request you composed and signed. `trustEstablishment`, `requestId`, and
+`satisfiedRequirements` are optional hints.
 
-Return the Proof requirement as a header:
+Return it as a header:
 
 ```ts
 response.setHeader("PROOF-REQUIRED", verifier.encodePayload(payload));
 ```
 
-##### Payload in HTML
-
 For clients that read the body but not the headers, mirror the requirement as an
-[embedded `<data>` element](https://x401.proof.com/spec/#embedded-proof-requirements-in-html-content).
-The header remains authoritative and must still be set.
+[embedded `<data>` element](https://x401.proof.com/spec/#embedded-proof-requirements-in-html-content)
+(the `$schema` marker is added automatically). The header remains authoritative and must still be set.
 
 ```ts
 const html = `<article>…</article>${verifier.embedHtmlData(payload)}`;
@@ -120,9 +81,11 @@ const html = `<article>…</article>${verifier.embedHtmlData(payload)}`;
 
 ### Verify a Proof (`PROOF-PRESENTATION`)
 
-Decode the artifact and authenticate the challenge. Then verify `vp_token` with your credential
-library and apply route policy. On failure, return an
-[x401 Error Object](https://x401.proof.com/spec/#x401-error-object) in `PROOF-RESPONSE`. See the full
+Decode the artifact, then validate the presentation against the request you composed (binding,
+`nonce` freshness, credential query) with your credential library and route policy. The artifact may
+carry the result inline (`response`) or by reference (`presentation_uri`, which you dereference). On
+failure, return an [x401 Error Object](https://x401.proof.com/spec/#x401-error-object) in
+`PROOF-RESPONSE`. See the full
 [verifier processing rules](https://x401.proof.com/spec/#verifier-processing-rules).
 
 ```ts
@@ -130,25 +93,19 @@ const artifact = verifier.decodeVPArtifact(
   request.headers["proof-presentation"],
 );
 
-const check = await verifier.verifyChallenge({
-  value: artifact.challenge,
-  encryptor,
-  expectedVerifierId: "https://research.example.com",
-  expectedResource: "https://research.example.com/papers/medical-study-123",
-  expectedMethod: "GET",
-});
+const result = artifact.response
+  ? artifact.response
+  : await fetchPresentation(artifact.presentation_uri!);
 
-if (!check.ok) {
+if (!validatePresentation(result)) {
   response.setHeader(
     "PROOF-RESPONSE",
     verifier.encodeErrorObject(
-      verifier.buildErrorObject({ error: "invalid_challenge" }),
+      verifier.buildErrorObject({ error: "invalid_presentation" }),
     ),
   );
   return;
 }
-
-// verify artifact.vp_token with your credential library, then apply route policy
 ```
 
 ## Agent
@@ -157,8 +114,9 @@ See the full [agent processing rules](https://x401.proof.com/spec/#agent-process
 
 ### Read a Proof requirement (`PROOF-REQUIRED`)
 
-`detectProofRequirement` reads the header, falling back to the embedded `<data>` element. Take the
-nonce and credential query to build your OpenID4VP request (out of scope for this package).
+`detectProofRequirement` reads the header, falling back to the embedded `<data>` element.
+`getDigitalCredentialRequest` returns the Verifier-composed request unmodified — pass it straight to
+the Digital Credentials API (or relay it). The agent MUST NOT alter it.
 
 ```ts
 import { agent } from "@proof.com/x401-node";
@@ -170,21 +128,26 @@ const requirement = agent.detectProofRequirement({
 });
 
 if (requirement) {
-  const nonce = agent.getNonce(requirement.payload);
-  const query = agent.getCredentialQuery(requirement.payload); // { scope } | { dcql_query }
+  const dcRequest = agent.getDigitalCredentialRequest(requirement.payload);
+  const result = await navigator.credentials.get({ digital: dcRequest });
 }
 ```
 
+If you're an intermediary relaying the request to a **remote handler** (which POSTs the result
+back rather than invoking the DC API itself), add an `https` `return_uri` to the forwarded payload
+with `agent.addReturnUri(payload, returnUri)`. Only a relaying intermediary sets this — never the
+Verifier.
+
 ### Present a Proof (`PROOF-PRESENTATION`)
 
-Wrap the wallet's `vp_token` in a [VP Artifact](https://x401.proof.com/spec/#vp-artifact) and retry
-the same route.
+Wrap the `{ protocol, data }` presentation result in a
+[VP Artifact](https://x401.proof.com/spec/#vp-artifact) and retry the same route. Use the
+by-reference form for results too large for a header.
 
 ```ts
 const artifact = agent.buildVPArtifact({
-  payload: requirement.payload,
-  agentId: "did:web:agent.example",
-  vpToken,
+  response: result,
+  requestId: requirement.payload.request_id,
 });
 
 await fetch(url, {
@@ -192,6 +155,16 @@ await fetch(url, {
 });
 ```
 
+Or, by reference:
+
+```ts
+const artifact = agent.buildVPArtifactReference({
+  presentationUri:
+    "https://research.example.com/.well-known/x401/presentations/abc",
+  expiresAt: "2026-05-06T18:50:00Z",
+});
+```
+
 ### Exchange a Proof for a token
 
 Exchange the artifact for a reusable Verification Token via
@@ -213,4 +186,6 @@ const tokenHeader = agent.encodeTokenObject(
 await fetch(url, { headers: { "PROOF-PRESENTATION": tokenHeader } });
 ```
 
+## Contributing
+
 [Contribution guidelines for this project](CONTRIBUTING.md)
diff --git a/package.json b/package.json
index 03e0a22..a76e5e5 100644
--- a/package.json
+++ b/package.json
@@ -48,6 +48,8 @@
   },
   "devDependencies": {
     "@types/node": "^25.9.1",
+    "ajv": "^8.20.0",
+    "ajv-formats": "^3.0.1",
     "eslint": "^10.4.0",
     "eslint-plugin-unused-imports": "^4.4.1",
     "prettier": "^3.8.4",
diff --git a/scripts/extract-normative.ts b/scripts/extract-normative.ts
new file mode 100644
index 0000000..31ba9fb
--- /dev/null
+++ b/scripts/extract-normative.ts
@@ -0,0 +1,99 @@
+/**
+ * Track the spec's RFC 2119 normative statements across spec revisions.
+ *
+ * Usage:
+ *   node scripts/extract-normative.ts            # diff spec vs the committed ledger
+ *   node scripts/extract-normative.ts --list      # print every normative statement
+ *   node scripts/extract-normative.ts --update    # rewrite the ledger to match the spec
+ *
+ * The ledger (spec/normative-ledger.json) is a snapshot of every normative statement at
+ * the pinned spec ref. After `sync-spec-fixtures.ts` pulls a new spec revision, the diff
+ * mode prints exactly which MUST/SHALL/REQUIRED statements were ADDED or REMOVED — the
+ * precise list to triage in spec/conformance.md before updating the code. Keyed by text
+ * (not line number) so reflowed prose still matches. Exits 1 when there is undated drift.
+ *
+ * Run scripts/sync-spec-fixtures.ts first; it caches spec/spec.md.
+ */
+import { existsSync, readFileSync, writeFileSync } from "node:fs";
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+
+const ROOT = join(dirname(fileURLToPath(import.meta.url)), "..");
+const SPEC_MD = join(ROOT, "spec", "spec.md");
+const LEDGER = join(ROOT, "spec", "normative-ledger.json");
+
+const KEYWORD = /\b(MUST NOT|MUST|SHALL NOT|SHALL|REQUIRED)\b/;
+const HEADER_TOKENS = /PROOF-(REQUIRED|PRESENTATION|RESPONSE)/g;
+
+/** Whitespace-insensitive key so reflowed prose still matches across revisions. */
+function keyOf(text: string): string {
+  return text.replace(/\s+/g, " ").trim();
+}
+
+function normativeStatements(md: string): string[] {
+  const out: string[] = [];
+  let inFence = false;
+  for (const raw of md.split("\n")) {
+    const text = raw.trim();
+    if (text.startsWith("```")) {
+      inFence = !inFence;
+      continue;
+    }
+    if (inFence || !text) continue;
+    // Strip the header field names so "PROOF-REQUIRED" stops matching "REQUIRED".
+    if (KEYWORD.test(text.replace(HEADER_TOKENS, ""))) out.push(keyOf(text));
+  }
+  return [...new Set(out)].sort();
+}
+
+function main(): void {
+  const current = normativeStatements(readFileSync(SPEC_MD, "utf8"));
+
+  if (process.argv.includes("--list")) {
+    for (const s of current) console.log(s);
+    console.log(`\n${current.length} normative statement(s).`);
+    return;
+  }
+
+  if (process.argv.includes("--update")) {
+    writeFileSync(LEDGER, JSON.stringify(current, null, 2) + "\n", "utf8");
+    console.log(`Ledger updated: ${current.length} normative statement(s).`);
+    return;
+  }
+
+  if (!existsSync(LEDGER)) {
+    console.error("No ledger. Run: node scripts/extract-normative.ts --update");
+    process.exitCode = 1;
+    return;
+  }
+
+  const ledger: string[] = JSON.parse(readFileSync(LEDGER, "utf8"));
+  const prev = new Set(ledger);
+  const now = new Set(current);
+  const added = current.filter((s) => !prev.has(s));
+  const removed = ledger.filter((s) => !now.has(s));
+
+  console.log(
+    `Spec has ${current.length} normative statement(s); ledger has ${ledger.length}.`,
+  );
+  if (added.length === 0 && removed.length === 0) {
+    console.log("No drift. Every normative statement is accounted for.");
+    return;
+  }
+  if (added.length > 0) {
+    console.log(
+      `\nADDED (${added.length}) — triage each in spec/conformance.md:`,
+    );
+    for (const s of added) console.log(`  + ${s}`);
+  }
+  if (removed.length > 0) {
+    console.log(`\nREMOVED (${removed.length}) — drop stale handling/tests:`);
+    for (const s of removed) console.log(`  - ${s}`);
+  }
+  console.log(
+    "\nAfter triaging, run: node scripts/extract-normative.ts --update",
+  );
+  process.exitCode = 1;
+}
+
+main();
diff --git a/scripts/sync-spec-fixtures.ts b/scripts/sync-spec-fixtures.ts
new file mode 100644
index 0000000..0680e6e
--- /dev/null
+++ b/scripts/sync-spec-fixtures.ts
@@ -0,0 +1,155 @@
+/**
+ * Sync spec-authored ground truth into `spec/`.
+ *
+ * Fetches `spec.md` from the proof/x401 repo at a pinned git ref, extracts the
+ * Appendix C JSON Schema and every JSON example block, classifies them by content,
+ * and writes them to `spec/fixtures/`. Also refreshes `spec/SPEC_SOURCE.json`.
+ *
+ * Usage:
+ *   node scripts/sync-spec-fixtures.ts [<git-ref>]
+ *
+ * The ref defaults to the value recorded in spec/SPEC_SOURCE.json. Requires the
+ * GitHub CLI (`gh`) to be installed and authenticated.
+ *
+ * This script is the reproducible step in the spec-upgrade runbook (spec/UPGRADING.md):
+ * it pins the fixtures to an exact spec commit so the conformance tests check the code
+ * against spec text, not a paraphrase of it.
+ */
+import { execFileSync } from "node:child_process";
+import { mkdirSync, readFileSync, writeFileSync, rmSync } from "node:fs";
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+
+const REPO = "proof/x401";
+const SPEC_PATH = "spec.md";
+const ROOT = join(dirname(fileURLToPath(import.meta.url)), "..");
+const SPEC_DIR = join(ROOT, "spec");
+const FIXTURES_DIR = join(SPEC_DIR, "fixtures");
+const SOURCE_FILE = join(SPEC_DIR, "SPEC_SOURCE.json");
+
+interface SpecSource {
+  repo: string;
+  ref: string;
+  branch: string;
+  version: string;
+  spec_url: string;
+  schema_url: string;
+  fetched_at: string;
+}
+
+function readSource(): SpecSource {
+  return JSON.parse(readFileSync(SOURCE_FILE, "utf8")) as SpecSource;
+}
+
+function fetchSpec(ref: string): string {
+  const b64 = execFileSync(
+    "gh",
+    [
+      "api",
+      `repos/${REPO}/contents/${SPEC_PATH}?ref=${ref}`,
+      "--jq",
+      ".content",
+    ],
+    { encoding: "utf8", maxBuffer: 64 * 1024 * 1024 },
+  );
+  return Buffer.from(b64, "base64").toString("utf8");
+}
+
+/** Extract the bodies of every fenced ```json block, in document order. */
+function jsonBlocks(md: string): string[] {
+  const blocks: string[] = [];
+  const re = /```json\n([\s\S]*?)```/g;
+  let m: RegExpExecArray | null;
+  while ((m = re.exec(md)) !== null) {
+    if (m[1] !== undefined) blocks.push(m[1].trim());
+  }
+  return blocks;
+}
+
+function isObject(v: unknown): v is Record<string, unknown> {
+  return typeof v === "object" && v !== null && !Array.isArray(v);
+}
+
+function write(name: string, value: unknown): void {
+  writeFileSync(
+    join(FIXTURES_DIR, name),
+    JSON.stringify(value, null, 2) + "\n",
+    "utf8",
+  );
+  console.log(`  wrote spec/fixtures/${name}`);
+}
+
+function main(): void {
+  const source = readSource();
+  const ref = process.argv[2] ?? source.ref;
+  console.log(`Fetching ${REPO}:${SPEC_PATH} at ${ref} ...`);
+  const md = fetchSpec(ref);
+
+  // Cache the raw spec so extract-normative.ts and conformance review run offline.
+  mkdirSync(SPEC_DIR, { recursive: true });
+  writeFileSync(join(SPEC_DIR, "spec.md"), md, "utf8");
+  console.log("  wrote spec/spec.md");
+
+  rmSync(FIXTURES_DIR, { recursive: true, force: true });
+  mkdirSync(FIXTURES_DIR, { recursive: true });
+
+  const parsed = jsonBlocks(md).flatMap((raw) => {
+    try {
+      return [JSON.parse(raw) as unknown];
+    } catch {
+      return []; // skip non-parseable blocks (e.g. truncated "..." JARs)
+    }
+  });
+
+  let payloads = 0;
+  let vpArtifacts = 0;
+  let oid4vpRequests = 0;
+  let schemaFound = false;
+
+  for (const obj of parsed) {
+    if (!isObject(obj)) continue;
+    if (
+      typeof obj["$schema"] === "string" &&
+      obj["$schema"].includes("json-schema.org") &&
+      obj["title"] !== undefined
+    ) {
+      write("request.schema.json", obj);
+      schemaFound = true;
+    } else if (obj["scheme"] === "x401") {
+      if (obj["presentation_requirements"] !== undefined) {
+        write(`payload-${++payloads}.json`, obj);
+      } else if (obj["error"] !== undefined) {
+        write("error-object.json", obj);
+      } else if (obj["access_token"] !== undefined) {
+        write("token-object.json", obj);
+      }
+    } else if (
+      obj["response"] !== undefined ||
+      obj["presentation_uri"] !== undefined
+    ) {
+      write(`vp-artifact-${++vpArtifacts}.json`, obj);
+    } else if (obj["response_type"] === "vp_token") {
+      // Informative: the decoded OpenID4VP request the Verifier signs into the JAR.
+      write(`openid4vp-request-${++oid4vpRequests}.json`, obj);
+    }
+  }
+
+  if (!schemaFound) {
+    throw new Error("Appendix C JSON Schema not found in spec.md.");
+  }
+  if (payloads === 0) {
+    throw new Error("No x401 payload examples found in spec.md.");
+  }
+
+  const updated: SpecSource = {
+    ...source,
+    ref,
+    fetched_at: new Date().toISOString(),
+  };
+  writeFileSync(SOURCE_FILE, JSON.stringify(updated, null, 2) + "\n", "utf8");
+  console.log(
+    `Done. ${payloads} payload(s), ${vpArtifacts} VP artifact(s), ${oid4vpRequests} OID4VP request(s).`,
+  );
+}
+
+main();
diff --git a/spec/SPEC_SOURCE.json b/spec/SPEC_SOURCE.json
new file mode 100644
index 0000000..24de614
--- /dev/null
+++ b/spec/SPEC_SOURCE.json
@@ -0,0 +1,9 @@
+{
+  "repo": "proof/x401",
+  "ref": "4057cacc41e9e20547f6a6949946e9e1115b37d2",
+  "branch": "main",
+  "version": "0.2.0",
+  "spec_url": "https://x401.proof.com/spec",
+  "schema_url": "https://x401.id/spec/schemas/request.json",
+  "fetched_at": "2026-06-24T08:55:14.795Z"
+}
diff --git a/spec/UPGRADING.md b/spec/UPGRADING.md
new file mode 100644
index 0000000..17f8669
--- /dev/null
+++ b/spec/UPGRADING.md
@@ -0,0 +1,84 @@
+# Upgrading this SDK to a new x401 spec revision
+
+A repeatable loop: read the spec diff → re-pin spec-authored fixtures → see exactly which
+normative statements changed → update the code → let the harness prove the code matches the
+spec, not a paraphrase of it. Requires the GitHub CLI (`gh`) authenticated against `proof/x401`.
+
+## The harness (what does the checking)
+
+| Artifact                            | Role                                                                       |
+| ----------------------------------- | -------------------------------------------------------------------------- |
+| `spec/SPEC_SOURCE.json`             | Pins the exact spec repo + git ref the fixtures came from                  |
+| `spec/spec.md`                      | Cached spec text at that ref (so normative checks run offline)             |
+| `spec/fixtures/request.schema.json` | Appendix C JSON Schema, extracted verbatim                                 |
+| `spec/fixtures/*.json`              | Every JSON example from the spec (payloads, VP artifacts, error/token)     |
+| `spec/normative-ledger.json`        | Snapshot of every MUST/SHALL/REQUIRED statement at the ref                 |
+| `spec/conformance.md`               | Human map: each in-scope requirement → code + test; out-of-scope rationale |
+| `scripts/sync-spec-fixtures.ts`     | Fetches spec at a ref; rewrites `spec.md`, fixtures, `SPEC_SOURCE.json`    |
+| `scripts/extract-normative.ts`      | Diffs spec vs ledger; lists ADDED/REMOVED statements to triage             |
+| `tests/spec-schema.test.ts`         | Validates payloads (and `buildPayload` output) against Appendix C          |
+| `tests/spec-fixtures.test.ts`       | Parses + round-trips every spec example fixture                            |
+| `tests/x401.test.ts`                | Hand-written unit + negative cases for the current wire shapes             |
+
+## Steps
+
+1. **Read the diff in full** — do not summarize away details:
+
+   ```sh
+   gh pr diff <PR#> --repo proof/x401      # or: gh api repos/proof/x401/compare/<old>...<new>
+   ```
+
+2. **Re-pin the fixtures** to the new ref (PR head SHA, or the merged `main` SHA once merged):
+
+   ```sh
+   node scripts/sync-spec-fixtures.ts <git-ref>
+   ```
+
+   This rewrites `spec/spec.md`, `spec/fixtures/*`, and the `ref`/`fetched_at` in `SPEC_SOURCE.json`.
+   Also update `branch`/`version` in `SPEC_SOURCE.json` by hand if they changed.
+
+3. **See what changed normatively:**
+
+   ```sh
+   node scripts/extract-normative.ts        # prints ADDED / REMOVED vs the ledger
+   ```
+
+   Triage each ADDED statement in `spec/conformance.md` (enforce it + cite the test, or mark it
+   out of scope with the responsible layer). Drop handling/tests for REMOVED statements. Then:
+
+   ```sh
+   node scripts/extract-normative.ts --update
+   ```
+
+4. **Update the code** in dependency order:
+   `src/constants.ts` → `src/types.ts` → `src/validate.ts` → `src/agent.ts` / `src/verifier.ts`
+   → `src/index.ts`. Keep wire fields snake_case; carry externally-signed/opaque blobs opaque.
+
+5. **Run the harness:**
+
+   ```sh
+   yarn test
+   ```
+
+   `spec-schema` + `spec-fixtures` fail loudly if a field name, enum value, required/optional, or
+   object shape drifts from the spec's own schema and examples.
+
+6. **Adversarial review** — have an independent reviewer (subagent or person) read the spec diff
+   against the changed `src/` files and try to _refute_ the implementation: wrong field names /
+   enum values / `version`; VP Artifact one-of and by-reference semantics; and any straggler of a
+   removed concept left behind in `src/`. Resolve every confirmed finding.
+
+7. **Full gate:**
+
+   ```sh
+   yarn check-all      # format, lint, typecheck, test, publint
+   ```
+
+8. **Publishing** is separate and gated — see `CLAUDE.md` › Publishing. Do not bump the npm
+   package version or release without explicit confirmation.
+
+## Hard rules that constrain every upgrade
+
+From `CLAUDE.md`: only runtime dep is `@owf/identity-common`; never verify credentials here; do
+not build/sign the OpenID4VP request or wallet transport; no `eslint-disable`/`@ts-ignore`;
+`engines.node >= 22`. Schema/test tooling (`ajv`, `ajv-formats`) is **devDependencies** only.
diff --git a/spec/conformance.md b/spec/conformance.md
new file mode 100644
index 0000000..0502975
--- /dev/null
+++ b/spec/conformance.md
@@ -0,0 +1,70 @@
+# x401 conformance map
+
+Maps the spec's RFC 2119 normative statements to where this library enforces them — or
+records why they are out of scope. The goal is to make "did we miss a MUST?" answerable.
+
+- **Source of truth:** `spec/spec.md` at the ref in `spec/SPEC_SOURCE.json` (currently
+  x401 **0.2.0**, proof/x401 `main` — PR #15 merged).
+- **Drift detection:** `spec/normative-ledger.json` snapshots every normative statement.
+  After `node scripts/sync-spec-fixtures.ts`, run `node scripts/extract-normative.ts` to see
+  what was **added/removed** since the ledger. Triage new statements here, then
+  `node scripts/extract-normative.ts --update`.
+- **Scope of this library:** it produces, encodes, decodes, and structurally validates the
+  x401 **wire objects**. It does **not** verify credentials, validate presentation bindings,
+  sign/compose the OpenID4VP request, perform the DC API call, or make HTTP/transport
+  decisions. Those statements are marked out of scope with the responsible layer.
+
+## In scope — enforced or produced by this library
+
+| Spec requirement                                                                                                                                                                                                      | Where                                                                                                                                                                                     |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `scheme` MUST be `"x401"` (payload, error, token)                                                                                                                                                                     | `validate.ts` `parseX401Payload` / `parseX401ErrorObject` / `parseX401TokenObject`; builders in `verifier.ts`/`agent.ts` set the constant. Tests: `x401.test.ts`, `spec-fixtures.test.ts` |
+| `version` REQUIRED                                                                                                                                                                                                    | `validate.ts` (all three parsers); `X401_VERSION` constant                                                                                                                                |
+| `presentation_requirements` REQUIRED; `requests` a non-empty array; each `protocol` is `openid4vp-v1-signed`/`openid4vp-v1-unsigned`; each `data` an object                                                           | `validate.ts` `parseX401Payload`, `verifier.ts` `buildPayload`. Tests: `spec-schema.test.ts` (Appendix C schema), `x401.test.ts`                                                          |
+| `oauth` REQUIRED; `oauth.token_endpoint` REQUIRED                                                                                                                                                                     | `validate.ts` `parseX401Payload`. Tests: `spec-schema.test.ts`, `x401.test.ts`                                                                                                            |
+| Payload encoded value MUST be base64url UTF-8 JSON (RFC 4648 §5, no padding); decoded MUST be a single JSON object                                                                                                    | `encoding.ts` (`@owf/identity-common` base64url)                                                                                                                                          |
+| MUST NOT combine multiple objects in one proof header via commas/lists; comma value MUST be treated as invalid                                                                                                        | `encoding.ts` `decodeProofHeader` comma guard. Test: `x401.test.ts`                                                                                                                       |
+| VP Artifact MUST contain exactly one of `response` / `presentation_uri`                                                                                                                                               | `validate.ts` `parseVPArtifact`. Tests: `x401.test.ts` (both/neither), `spec-fixtures.test.ts`                                                                                            |
+| `response` is the `{ protocol, data }` DC API result                                                                                                                                                                  | `validate.ts` `parseVPArtifact`; `agent.ts` `buildVPArtifact`                                                                                                                             |
+| `presentation_uri` MUST be an `https` URL                                                                                                                                                                             | `validate.ts` `parseVPArtifact`. Test: `x401.test.ts` (non-https rejected)                                                                                                                |
+| Token Object `token_type` MUST be `"Bearer"`; `access_token` REQUIRED                                                                                                                                                 | `validate.ts` `parseX401TokenObject`; `agent.ts` `buildTokenObject`                                                                                                                       |
+| Error Object `error` REQUIRED                                                                                                                                                                                         | `validate.ts` `parseX401ErrorObject`                                                                                                                                                      |
+| Token-exchange fixed params (`grant_type`, `subject_token_type`, Bearer) MUST NOT be repeated in the payload                                                                                                          | not present in the payload type; set only on the form by `agent.ts` `buildTokenExchangeForm`; verified by `verifier.ts` `parseTokenExchange`. Test: `x401.test.ts`                        |
+| Embedded `<data>`: tag `data`, `value="application/json;x401=proof-required"`, `hidden`, single JSON object that is a valid payload and MUST include a `$schema` member = `https://x401.id/spec/schemas/request.json` | `verifier.ts` `embedHtmlData`; `agent.ts` `detectProofRequirement` + `parseX401Payload`. Test: `x401.test.ts` (embedded round-trip)                                                       |
+| Embedded object subject to the same structural validation as a header payload                                                                                                                                         | `agent.ts` `detectProofRequirement` runs `parseX401Payload`. Test: `x401.test.ts`                                                                                                         |
+| Agent MUST NOT modify any entry in `presentation_requirements`                                                                                                                                                        | `agent.ts` `getDigitalCredentialRequest` returns it unmodified; library never mutates it                                                                                                  |
+| A relaying intermediary MUST add a `return_uri` member (an `https` URL) to the forwarded payload; the Verifier never sets it                                                                                          | `agent.ts` `addReturnUri` (https-validated; `buildPayload` never emits it); `validate.ts` `parseX401Payload` enforces https. Tests: `x401.test.ts`                                        |
+
+## Out of scope — responsibility of another layer
+
+These normative statements are real but fall outside an encode/decode/validate library.
+
+- **Remote handler processing** (matching `requests[]` against held credentials, satisfying
+  `dcql_query` incl. `credential_sets`/`claim_sets`, Holder selection, producing the presentation,
+  POSTing it to `return_uri`): the remote wallet/handler. This SDK only adds and validates the
+  `return_uri` member; it does not act as a handler.
+- **Verifier proof validation & crypto** (the "The Verifier MUST:" list, Verifier Binding,
+  nonce freshness/replay, dereferencing a `presentation_uri`, unique-URI issuance, issuer
+  trust enforcement, `trusted_authorities`): the verifier application. This library does not
+  verify presentations or sign requests (`CLAUDE.md` Hard Rules 1–3).
+- **Credential verification** (issuer trust, status, revocation, claim satisfaction):
+  `@proof.com/proof-vc-common`. `vp_token`/`response.data` is opaque here.
+- **Agent runtime / transport** (obtaining a presentation via `navigator.credentials.get`,
+  relaying, remote fulfillment, retrying the route): the Agent application.
+- **OpenID4VP request composition/signing** (the JAR, `client_id`, `expected_origins`,
+  `nonce`, `dcql_query`, `exp`): the verifier; carried opaque in `data`. This includes the
+  "Composing a Request for Both Native and Relayed Fulfillment" rules added when PR #15 merged
+  (self-contained request, `x5c`/resolvable `client_id`, carrying all inputs inside the request
+  object, transport members optional) — all verifier request-authoring concerns, not wire-object
+  structure.
+- **HTTP semantics** (status-code independence, `WWW-Authenticate` non-use, `402` payment
+  separation, `Cache-Control`/`Vary`, CORS exposure): the HTTP server/deployment.
+- **Verification Token issuance, scope, binding, holder identity**; **Agent binding**
+  (OPTIONAL): the verifier/deployment.
+
+## Known coverage gap
+
+Only the **PROOF-REQUIRED payload** has an official JSON Schema (Appendix C). The VP Artifact,
+Error Object, and Token Object are checked against extracted spec examples + these parsers, not a
+published schema. If the spec later publishes schemas for those objects, add them to
+`spec/fixtures/` via `sync-spec-fixtures.ts` and extend `spec-schema.test.ts`.
diff --git a/spec/fixtures/error-object.json b/spec/fixtures/error-object.json
new file mode 100644
index 0000000..ffe5864
--- /dev/null
+++ b/spec/fixtures/error-object.json
@@ -0,0 +1,7 @@
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "error": "invalid_presentation",
+  "error_description": "The presentation did not satisfy the route proof requirement.",
+  "request_id": "proof-template-financial-customer-v1"
+}
diff --git a/spec/fixtures/openid4vp-request-1.json b/spec/fixtures/openid4vp-request-1.json
new file mode 100644
index 0000000..ed23808
--- /dev/null
+++ b/spec/fixtures/openid4vp-request-1.json
@@ -0,0 +1,36 @@
+{
+  "response_type": "vp_token",
+  "response_mode": "dc_api",
+  "client_id": "x509_san_dns:bank.example.com",
+  "expected_origins": [
+    "https://bank.example.com"
+  ],
+  "nonce": "uX7Vq3mZJH6MeN0qz2L7SQ",
+  "dcql_query": {
+    "credentials": [
+      {
+        "id": "financial_customer",
+        "format": "jwt_vc_json",
+        "meta": {
+          "type_values": [
+            "FinancialCustomerCredential"
+          ]
+        },
+        "claims": [
+          {
+            "path": [
+              "credentialSubject",
+              "assurance_level"
+            ],
+            "values": [
+              "VC-AL2",
+              "VC-AL3"
+            ]
+          }
+        ]
+      }
+    ]
+  },
+  "client_metadata": {},
+  "exp": 1746557100
+}
diff --git a/spec/fixtures/openid4vp-request-2.json b/spec/fixtures/openid4vp-request-2.json
new file mode 100644
index 0000000..240d8ac
--- /dev/null
+++ b/spec/fixtures/openid4vp-request-2.json
@@ -0,0 +1,35 @@
+{
+  "response_type": "vp_token",
+  "response_mode": "dc_api",
+  "client_id": "x509_san_dns:bank.example.com",
+  "expected_origins": [
+    "https://bank.example.com"
+  ],
+  "nonce": "uX7Vq3mZJH6MeN0qz2L7SQ",
+  "dcql_query": {
+    "credentials": [
+      {
+        "id": "financial_customer",
+        "format": "jwt_vc_json",
+        "meta": {
+          "type_values": [
+            "FinancialCustomerCredential"
+          ]
+        },
+        "claims": [
+          {
+            "path": [
+              "credentialSubject",
+              "assurance_level"
+            ],
+            "values": [
+              "VC-AL2",
+              "VC-AL3"
+            ]
+          }
+        ]
+      }
+    ]
+  },
+  "exp": 1746557100
+}
diff --git a/spec/fixtures/payload-1.json b/spec/fixtures/payload-1.json
new file mode 100644
index 0000000..042b3c6
--- /dev/null
+++ b/spec/fixtures/payload-1.json
@@ -0,0 +1,10 @@
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "presentation_requirements": {},
+  "oauth": {},
+  "trust_establishment": "https://...",
+  "request_id": "...",
+  "satisfied_requirements": [],
+  "payment": {}
+}
diff --git a/spec/fixtures/payload-2.json b/spec/fixtures/payload-2.json
new file mode 100644
index 0000000..6e485a9
--- /dev/null
+++ b/spec/fixtures/payload-2.json
@@ -0,0 +1,21 @@
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "presentation_requirements": {
+    "requests": [
+      {
+        "protocol": "openid4vp-v1-signed",
+        "data": {
+          "request": "eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWF1dGh6LXJlcStqd3QifQ..."
+        }
+      }
+    ]
+  },
+  "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"
+  ]
+}
diff --git a/spec/fixtures/payload-3.json b/spec/fixtures/payload-3.json
new file mode 100644
index 0000000..058f99c
--- /dev/null
+++ b/spec/fixtures/payload-3.json
@@ -0,0 +1,18 @@
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "presentation_requirements": {
+    "requests": [
+      {
+        "protocol": "openid4vp-v1-signed",
+        "data": {
+          "request": "eyJ..."
+        }
+      }
+    ]
+  },
+  "oauth": {
+    "token_endpoint": "https://bank.example.com/oauth/token"
+  },
+  "return_uri": "https://mcp.example/x401/return/9f1c2a"
+}
diff --git a/spec/fixtures/payload-4.json b/spec/fixtures/payload-4.json
new file mode 100644
index 0000000..f8caafd
--- /dev/null
+++ b/spec/fixtures/payload-4.json
@@ -0,0 +1,22 @@
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "presentation_requirements": {
+    "requests": [
+      {
+        "protocol": "openid4vp-v1-signed",
+        "data": {
+          "request": "eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWF1dGh6LXJlcStqd3QifQ..."
+        }
+      }
+    ]
+  },
+  "oauth": {
+    "token_endpoint": "https://bank.example.com/oauth/token"
+  },
+  "trust_establishment": "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"
+  ]
+}
diff --git a/spec/fixtures/payload-5.json b/spec/fixtures/payload-5.json
new file mode 100644
index 0000000..525c7b4
--- /dev/null
+++ b/spec/fixtures/payload-5.json
@@ -0,0 +1,17 @@
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "presentation_requirements": {
+    "requests": [
+      {
+        "protocol": "openid4vp-v1-signed",
+        "data": {
+          "request": "eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWF1dGh6LXJlcStqd3QifQ..."
+        }
+      }
+    ]
+  },
+  "oauth": {
+    "token_endpoint": "https://bank.example.com/oauth/token"
+  }
+}
diff --git a/spec/fixtures/request.schema.json b/spec/fixtures/request.schema.json
new file mode 100644
index 0000000..9af2e9b
--- /dev/null
+++ b/spec/fixtures/request.schema.json
@@ -0,0 +1,134 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://x401.id/spec/schemas/request.json",
+  "title": "x401 Proof Requirement Payload",
+  "description": "Schema for an x401 proof requirement payload as defined by the x401 specification.",
+  "type": "object",
+  "required": [
+    "scheme",
+    "version",
+    "presentation_requirements",
+    "oauth"
+  ],
+  "properties": {
+    "$schema": {
+      "type": "string",
+      "format": "uri",
+      "description": "Optional informational marker. When the payload is embedded in HTML as a <data> element, this SHOULD be set to https://x401.id/spec/schemas/request.json so that content processors can recognize the object as an x401 proof requirement."
+    },
+    "scheme": {
+      "type": "string",
+      "const": "x401",
+      "description": "MUST be the string \"x401\"."
+    },
+    "version": {
+      "type": "string",
+      "description": "The x401 payload version."
+    },
+    "presentation_requirements": {
+      "type": "object",
+      "required": [
+        "requests"
+      ],
+      "description": "The composed Digital Credentials request (a DigitalCredentialRequestOptions value), usable as the digital member of navigator.credentials.get().",
+      "properties": {
+        "requests": {
+          "type": "array",
+          "minItems": 1,
+          "description": "Digital Credentials request entries. Every entry MUST be a valid OpenID4VP request for the DC API.",
+          "items": {
+            "type": "object",
+            "required": [
+              "protocol",
+              "data"
+            ],
+            "properties": {
+              "protocol": {
+                "type": "string",
+                "enum": [
+                  "openid4vp-v1-signed",
+                  "openid4vp-v1-unsigned"
+                ],
+                "description": "The DC API protocol identifier. openid4vp-v1-signed is RECOMMENDED; openid4vp-v1-unsigned is permitted. See Verifier Binding."
+              },
+              "data": {
+                "type": "object",
+                "description": "Protocol-specific request data. For openid4vp-v1-signed, an object carrying the signed OpenID4VP request (e.g. { \"request\": \"<JWT>\" }); for openid4vp-v1-unsigned, the OpenID4VP request parameters directly.",
+                "properties": {
+                  "request": {
+                    "type": "string",
+                    "description": "The signed OpenID4VP request (a JWT-Secured Authorization Request); present for openid4vp-v1-signed."
+                  }
+                }
+              }
+            }
+          }
+        }
+      }
+    },
+    "oauth": {
+      "type": "object",
+      "required": [
+        "token_endpoint"
+      ],
+      "properties": {
+        "token_endpoint": {
+          "type": "string",
+          "format": "uri",
+          "description": "OAuth 2.0 token endpoint where the Agent can exchange a VP Artifact for a Verification Token."
+        },
+        "audience": {
+          "type": "string",
+          "description": "Optional OAuth token exchange audience value the Agent should request."
+        },
+        "resource": {
+          "type": "string",
+          "format": "uri",
+          "description": "Optional OAuth token exchange resource value the Agent should request."
+        }
+      },
+      "additionalProperties": false
+    },
+    "trust_establishment": {
+      "type": "string",
+      "format": "uri",
+      "description": "Optional acquisition and discovery hint: HTTPS URL for a DIF Credential Trust Establishment document. Issuer enforcement is governed by the signed request (DCQL trusted_authorities), not by this member."
+    },
+    "request_id": {
+      "type": "string",
+      "description": "Optional Agent-visible hint: a stable verifier-defined identifier for the proof template."
+    },
+    "satisfied_requirements": {
+      "type": "array",
+      "items": {
+        "type": "string"
+      },
+      "description": "Optional Agent-visible reuse hint: stable verifier-defined identifiers for the reusable proof requirements this proof would satisfy."
+    },
+    "return_uri": {
+      "type": "string",
+      "format": "uri",
+      "description": "Optional. Added by a relaying intermediary (never by the Verifier) to tell a remote handler where to POST the presentation result. See Relayed Delivery to a Remote Handler."
+    },
+    "payment": {
+      "type": "object",
+      "description": "Informational hint that payment is additionally required. Does not replace 402 Payment Required.",
+      "properties": {
+        "required": {
+          "type": "boolean",
+          "description": "Whether payment is additionally required."
+        },
+        "scheme_hint": {
+          "type": "string",
+          "description": "Hint naming the expected payment protocol."
+        },
+        "notes": {
+          "type": "string",
+          "description": "Human-readable notes."
+        }
+      },
+      "additionalProperties": false
+    }
+  },
+  "additionalProperties": false
+}
diff --git a/spec/fixtures/token-object.json b/spec/fixtures/token-object.json
new file mode 100644
index 0000000..ade17e2
--- /dev/null
+++ b/spec/fixtures/token-object.json
@@ -0,0 +1,6 @@
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "token_type": "Bearer",
+  "access_token": "<x401-verification-token>"
+}
diff --git a/spec/fixtures/vp-artifact-1.json b/spec/fixtures/vp-artifact-1.json
new file mode 100644
index 0000000..c1e7aed
--- /dev/null
+++ b/spec/fixtures/vp-artifact-1.json
@@ -0,0 +1,7 @@
+{
+  "request_id": "proof-template-financial-customer-v1",
+  "response": {
+    "protocol": "openid4vp-v1-signed",
+    "data": "<wallet-returned-presentation-result>"
+  }
+}
diff --git a/spec/fixtures/vp-artifact-2.json b/spec/fixtures/vp-artifact-2.json
new file mode 100644
index 0000000..c1e7aed
--- /dev/null
+++ b/spec/fixtures/vp-artifact-2.json
@@ -0,0 +1,7 @@
+{
+  "request_id": "proof-template-financial-customer-v1",
+  "response": {
+    "protocol": "openid4vp-v1-signed",
+    "data": "<wallet-returned-presentation-result>"
+  }
+}
diff --git a/spec/fixtures/vp-artifact-3.json b/spec/fixtures/vp-artifact-3.json
new file mode 100644
index 0000000..2e6855e
--- /dev/null
+++ b/spec/fixtures/vp-artifact-3.json
@@ -0,0 +1,5 @@
+{
+  "request_id": "proof-template-financial-customer-v1",
+  "presentation_uri": "https://bank.example.com/.well-known/x401/presentations/abc123",
+  "expires_at": "2026-05-06T18:50:00Z"
+}
diff --git a/spec/fixtures/vp-artifact-4.json b/spec/fixtures/vp-artifact-4.json
new file mode 100644
index 0000000..c1e7aed
--- /dev/null
+++ b/spec/fixtures/vp-artifact-4.json
@@ -0,0 +1,7 @@
+{
+  "request_id": "proof-template-financial-customer-v1",
+  "response": {
+    "protocol": "openid4vp-v1-signed",
+    "data": "<wallet-returned-presentation-result>"
+  }
+}
diff --git a/spec/fixtures/vp-artifact-5.json b/spec/fixtures/vp-artifact-5.json
new file mode 100644
index 0000000..2e6855e
--- /dev/null
+++ b/spec/fixtures/vp-artifact-5.json
@@ -0,0 +1,5 @@
+{
+  "request_id": "proof-template-financial-customer-v1",
+  "presentation_uri": "https://bank.example.com/.well-known/x401/presentations/abc123",
+  "expires_at": "2026-05-06T18:50:00Z"
+}
diff --git a/spec/normative-ledger.json b/spec/normative-ledger.json
new file mode 100644
index 0000000..5f9a76b
--- /dev/null
+++ b/spec/normative-ledger.json
@@ -0,0 +1,94 @@
+[
+  "1. MUST consider the `requests[]` entries whose `protocol` and credential formats it implements, and among those, MUST attempt to satisfy each entry's `dcql_query` — including any `credential_sets` / `claim_sets` alternatives within it — against the credentials available to it, with Holder selection where applicable. Which entry is used is the *outcome* of this matching, not a prior choice; an entry is usable only if a held credential satisfies its query.",
+  "1. MUST include `PROOF-REQUIRED: <base64url-x401-payload>` when proof is required or advertised.",
+  "1. MUST make each entry a valid OpenID4VP request for the Digital Credentials API, using `protocol: \"openid4vp-v1-signed\"` (RECOMMENDED) or `protocol: \"openid4vp-v1-unsigned\"`.",
+  "1. MUST treat the parsed JSON object as an x401 payload subject to the same structural validation and composed-request processing defined elsewhere in this specification.",
+  "1. MUST treat the response as a proof requirement.",
+  "1. MUST use the tag name `data`.",
+  "1. The Agent MUST NOT modify any entry in `presentation_requirements`. The request signature binds its contents, so any modification invalidates it.",
+  "1. The `presentation_uri` MUST be an `https` URL.",
+  "1. when the deployment binds the Agent, MUST be issued to the [[ref: Agent Identifier]] bound during the retry, and MUST NOT rely on the credential subject as the token holder identity unless the credential subject is also the Agent;",
+  "10. MUST evaluate issuer trust, status, revocation, and policy constraints independently of any Agent-side interpretation of the Issuer Trust List.",
+  "10. MUST retry the same route that produced the x401 proof requirement with one of:",
+  "11. MUST NOT replace an existing application `Authorization` credential with an x401 Verification Token unless the deployment explicitly defines the returned token as valid for that route's ordinary authorization processing.",
+  "11. MUST accept a VP Artifact in a `PROOF-PRESENTATION` request header for protected-route retry, in both its inline and by-reference forms.",
+  "12. MUST treat a `PROOF-RESPONSE` carrying an x401 Error Object as an x401 proof failure for the route-scoped proof attempt, regardless of the HTTP status code.",
+  "13. MUST validate Verification Tokens on protected-route retry according to token scope, audience, expiration, any Agent binding, and satisfied requirement metadata, whether the token arrives in `Authorization` or as an x401 Token Object in `PROOF-PRESENTATION`.",
+  "14. MUST bind any Verification Token carried in `PROOF-PRESENTATION` to the existing application caller, credential, client, key, or Agent Identifier required by the protected route when an `Authorization` header is also present.",
+  "16. MUST use `402 Payment Required` separately if payment is required and remains unsatisfied.",
+  "2. For a satisfiable entry, MUST read the OpenID4VP request from its `data` — the claims of the signed request object for `openid4vp-v1-signed`, or the request parameters directly for `openid4vp-v1-unsigned` — and produce a presentation that satisfies that `dcql_query`, bound to its `nonce`. It honors `client_metadata` for accepted formats and any response-encryption key, and, for a signed request, binds the presentation's audience to the request's `client_id`.",
+  "2. MUST be scoped to the Verifier audience and to the route, policy, action, resource, or resource class for which proof was accepted;",
+  "2. MUST extract the `PROOF-REQUIRED` field value and base64url-decode it as a UTF-8 JSON [[ref: x401 Payload]].",
+  "2. MUST include a valid base64url-encoded x401 payload in `PROOF-REQUIRED`.",
+  "2. MUST make its identity and request-signing key resolvable from the request alone. The Verifier SHOULD embed its signing certificate chain in the request JWS `x5c` header, or use a `client_id` whose key material is publicly resolvable (for example a `did:` or `https:` scheme), so a handler with no prior relationship can verify the signature and confirm it matches `client_id` offline. A Verifier MUST NOT rely on a `client_id` scheme or key whose resolution depends on the invoking Web origin or on prior DC-API interaction, because neither exists on the relayed path.",
+  "2. MUST set the `value` attribute to the MIME-type expression `application/json;x401=proof-required`. The `x401` parameter identifies the embedded carrier and signals the role of the element's text content.",
+  "2. The Verifier MUST issue a unique `presentation_uri` for each presentation and MUST NOT reuse a URI value across presentations. Uniqueness per presentation is what lets the Verifier treat the reference as single-use and bind it to one retry.",
+  "3. MUST carry every input a fulfiller needs inside the request object: the `nonce`, the `dcql_query` (including any `credential_sets` / `claim_sets` alternatives), the accepted formats and any response-encryption key in `client_metadata`, and the `exp`. A remote handler reads these directly from the request `data` — the signed request object's claims for a signed request — not from any API surface, so a value referenced only through the DC-API or a same-origin session is unavailable to it.",
+  "3. MUST expire, and SHOULD be short-lived;",
+  "3. MUST set the `hidden` attribute so the element is not visually rendered.",
+  "3. MUST treat the Digital Credentials API transport members as not applicable to relayed delivery: it does not return through `response_mode: dc_api`/`dc_api.jwt` (it returns to `return_uri` instead) and does not enforce `expected_origins` (there is no invoking Web origin).",
+  "3. MUST use an HTTP status code appropriate for the overall response and MUST NOT rely on the status code alone to convey x401 proof state.",
+  "3. MUST validate the decoded payload structure and process the `proof` object.",
+  "3. The Agent MUST arrange to acquire the [[ref: Presentation Result]] returned for the request, whether it invokes the request itself, relays it, or acquires a remotely generated result.",
+  "4. MUST NOT weaken or alter the `dcql_query` or `nonce`, and MUST deliver the resulting [[ref: Presentation Result]] to `return_uri`. If it can satisfy no entry, it returns no presentation and SHOULD signal that failure to the intermediary rather than returning a partial or substitute result.",
+  "4. MUST contain a single JSON object as its text content. The JSON object MUST be a valid x401 payload as defined in [x401 Payload](#x401-payload), and MUST include a `$schema` member whose value is the JSON Schema URL for the x401 request object, `https://x401.id/spec/schemas/request.json`. The `$schema` member is an informational marker that allows AI scrapers, content processors, and validators that retain only the JSON object to recognize it as an x401 proof requirement without prior knowledge of the surrounding HTML carrier.",
+  "4. MUST include a `presentation_requirements` whose entries are valid OpenID4VP requests for the DC API, using `openid4vp-v1-signed` (RECOMMENDED) or `openid4vp-v1-unsigned`.",
+  "4. MUST treat `presentation_requirements` as the Verifier-composed [[ref: Digital Credentials Request]] and MUST NOT modify any of its entries.",
+  "4. SHOULD still set the Digital Credentials API transport members — `response_mode` (`dc_api` / `dc_api.jwt`) and `expected_origins` — for the native path, but MUST NOT make correct processing depend on them. A remote handler treats them as not applicable (it returns to `return_uri` and there is no invoking origin to pre-authorize), so a request whose only Verifier binding is `expected_origins` degrades to `nonce`-only when relayed.",
+  "5. MUST obtain a [[ref: Presentation Result]] for `presentation_requirements` by invoking it through a native credential method, relaying it to a Wallet or remote service, or acquiring a remotely generated result.",
+  "5. SHOULD use signed requests and set their `client_id` and `expected_origins`; when using unsigned requests, MUST account for the weaker binding described in [Verifier Binding](#verifier-binding).",
+  "6. MUST include OAuth token exchange metadata in `oauth`.",
+  "8. MUST NOT enumerate verifier-approved issuers inline in the x401 payload.",
+  "8. MUST NOT treat any Agent-side interpretation of the Issuer Trust List as proof of verifier acceptance.",
+  "9. MUST package the presentation result as a VP Artifact, inline or as a [[ref: Presentation Reference]].",
+  "9. MUST validate presentations according to the proof validation rules in this specification and the credential format rules it relies upon, dereferencing a [[ref: Presentation Reference]] when one is supplied.",
+  "A VP Artifact MUST contain exactly one of `response` or `presentation_uri`.",
+  "A Verifier MAY use the validated signing key, key directory authority, or derived service identity as the Agent Identifier, or as evidence that maps to an Agent Identifier. The Verifier MUST still validate the Wallet presentation binding for the request mode, the credential query satisfaction, issuer trust, token scope, and payment boundary. Web Bot Auth identifies the calling automation or service; it does not by itself prove the credential subject, satisfy the credential query, or prove end-user delegation.",
+  "A Verifier that emits embedded `<data>` elements MUST still enforce proof on the protected resource through the normal `PROOF-REQUIRED` / `PROOF-PRESENTATION` exchange. Embedding a requirement in HTML is informational disclosure and does not by itself grant access.",
+  "A Verifier that may have its request fulfilled either natively — invoked through `navigator.credentials.get()` by a Wallet enforcing the Digital Credentials API — or by a remote handler that parses the request and generates a presentation manually MUST compose the request so it is self-contained and verifiable by a party with no prior relationship and no browser context. The governing test is: *could a Wallet that has never interacted with this Verifier verify the request and produce a correctly bound presentation from the request bytes alone?* A request composed only for the native path can silently fail this test even though a DC-API Wallet accepts it. To satisfy both paths, a Verifier:",
+  "A `<data>` element placed at the document level applies to the page as a whole and SHOULD be used as a body-side mirror of the route-scoped `PROOF-REQUIRED` header so that header-blind clients can still discover the requirement. A response MAY include multiple `<data value=\"application/json;x401=proof-required\" hidden>` elements when a page surfaces multiple advertised requirements; each element MUST be a complete, independent x401 payload that can be processed without reference to the others.",
+  "A `presentation_uri` is a capability-style reference: possession of the URL is enough to retrieve the presentation. The Verifier MUST issue a unique URI per presentation, and SHOULD make it `https`, unguessable, short-lived, single-use, and scoped to the route and retry it serves; the URL SHOULD be treated as sensitive because it can leak through logs, history, and intermediaries. Because the Verifier issues these references, it SHOULD dereference only URIs it recognizes as its own, which also guards against being pointed at arbitrary locations; it SHOULD bound the response size and time of the fetch. A reference that is reused, expired, or unrecognized MUST be rejected. Integrity and authenticity of the fetched bytes do not depend on a separate digest: the presentation is validated against the issued request's `nonce` and the binding its request mode provides, so a substituted or tampered result fails normal proof validation.",
+  "A protected route MUST process the supplied `PROOF-PRESENTATION` value as a proof presentation or proof-token satisfaction attempt. If verification succeeds, the Verifier MAY return the protected resource directly.",
+  "A sender MUST NOT generate more than one field line with the same x401 proof header name in the same HTTP message. A sender MUST NOT combine multiple x401 protocol objects in a single proof header using commas or other list syntax. If a recipient receives multiple field lines for the same proof header, or receives a proof header value containing a comma-separated list of messages, it MUST treat that proof header as invalid.",
+  "A server that requires payment MUST use `402 Payment Required` and MUST NOT overload x401 to represent payment as proof.",
+  "A server that requires proof for access to a protected resource, route, representation, or operation whose response would be changed as a whole by fulfilling a single set of proof requirements MUST return `PROOF-REQUIRED: <base64url-x401-payload>`. The `PROOF-REQUIRED` header is the authoritative carrier for an x401 proof requirement that gates the entire response.",
+  "Acquisition hints MUST NOT be treated as sufficient trust material. Verifiers MUST apply their own trusted issuer policy and validation logic.",
+  "Agent binding is OPTIONAL. The presentation is bound to the Verifier, not to the Agent, so a deployment that does not bind the Agent still has a presentation it can trust. A deployment that additionally wants to tie the proof and retry to a specific Agent layers an HTTP-layer or token-layer caller authentication over x401; see [Agent Binding Options](#agent-binding-options). When a deployment binds the Agent, it MUST reject a retry whose caller cannot be bound to the required [[ref: Agent Identifier]]. Because the surface that invokes the request may differ from the Agent that retries the route, a binding mechanism that depends only on the presentation result is insufficient in relay and remote-fulfillment topologies.",
+  "An intermediary that relays the x401 payload to a remote handler MUST add a `return_uri` member to the payload it forwards. `return_uri` is an `https` URL the handler delivers the [[ref: Presentation Result]] to; it is supplied by the relaying intermediary, never by the Verifier, and SHOULD be unguessable, short-lived, single-use, and controlled by the intermediary. The handler returns the result by sending an HTTP `POST` of the `{ \"protocol\": ..., \"data\": ... }` Presentation Result to `return_uri`. The intermediary then packages that result into a VP Artifact (inline or as a [[ref: Presentation Reference]]) and retries the protected route.",
+  "DPoP can bind OAuth token requests and resource requests to an Agent-controlled key at the application layer. Because this version of x401 defines Bearer Verification Tokens, a DPoP-bound Verification Token retry needs either a deployment-specific profile or a future x401 token retry profile that permits `token_type: DPoP` and the `DPoP` proof header. When a deployment binds the Agent and uses DPoP at the token endpoint, the endpoint MUST ensure the DPoP key maps to the Agent Identifier the deployment requires for the retry.",
+  "For Verification Tokens defined by this specification, the token endpoint MUST return `token_type` with the value `Bearer`.",
+  "Implementations MUST keep proof and payment semantics separate. A proof artifact MUST NOT be treated as payment, and payment satisfaction MUST NOT be treated as proof satisfaction.",
+  "In all modes the Verifier MUST validate the binding its request mode and transport provide and MUST reject a presentation it cannot bind to the request it issued. The `nonce` provides freshness and correlation throughout; it does not, by itself, authenticate the Verifier or constrain the invocation origin.",
+  "Issuer enforcement is ultimately governed by the request, not by `trust_establishment`. Where the Verifier needs the Wallet to constrain acceptable issuers at presentation time, it expresses that with DCQL `trusted_authorities` inside the request in `presentation_requirements`. `trust_establishment` exists to help Agents and Wallets *discover* and *acquire* likely-acceptable credentials, and to convey richer ecosystem, role, or acquisition metadata than `trusted_authorities` carries; it MUST NOT enumerate approved issuers inline. The Verifier MUST enforce issuer trust during proof validation — against the `trusted_authorities` in the request and its own policy — and MUST NOT rely on the Agent's interpretation of the Issuer Trust List.",
+  "The Verifier MUST NOT treat the `request_id` or `agent_id` values inside the VP Artifact as authoritative by themselves. They are carried so the Verifier can correlate the retry. Correlation between the presentation and the issued request is established by the OpenID4VP `nonce` echoed inside the presentation result. The Verifier remains responsible for validating the presentation binding and, when it binds the Agent, authenticating the Agent Identifier.",
+  "The Verifier MUST:",
+  "The encoded value MUST be base64url-encoded UTF-8 JSON using the URL and filename safe alphabet defined by RFC 4648 Section 5 without padding. The decoded value MUST be a single JSON object.",
+  "The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **NOT RECOMMENDED**, **MAY**, and **OPTIONAL** in this document are to be interpreted as described in RFC 2119 and RFC 8174.",
+  "The submitted VP Artifact MAY carry the presentation result inline or as a [[ref: Presentation Reference]]; when it is a reference, the token endpoint dereferences it as described in [Presentation by Reference](#presentation-by-reference). The token endpoint MAY require normal OAuth client authentication. If the deployment binds the Agent and client authentication is used, the authenticated OAuth client MUST bind to the same Agent Identifier the deployment requires for the retry.",
+  "The token endpoint MUST process the submitted VP Artifact using the same proof validation rules that apply to direct protected-route retry. In particular, it MUST verify that:",
+  "The token request uses OAuth 2.0 Token Exchange. The Agent MUST use:",
+  "The x401 OAuth profile fixes `grant_type`, `subject_token_type`, and Bearer token usage. These values MUST NOT be repeated in the x401 payload.",
+  "Verification Tokens SHOULD be short-lived, revocable, and scoped to the accepted x401 proof requirement. When a deployment binds the Agent, a Verifier that issues a token MUST identify the Agent as the token holder and MUST NOT treat the credential subject as the token holder unless the credential subject is also the Agent.",
+  "When a Verifier receives a VP Artifact directly on a protected-route retry or through the OAuth token endpoint, it MUST validate the presentation against the request it composed for the route. When the VP Artifact is a [[ref: Presentation Reference]], the Verifier first dereferences `presentation_uri` to obtain the presentation result, then validates that result exactly as if it had been supplied inline.",
+  "When a x401 payload includes `trust_establishment`, that URL identifies the DIF Credential Trust Establishment document for the proof requirement. The document is an acquisition and discovery hint; it does not decide validity. Issuer constraints that must hold at presentation time belong in the request's DCQL `trusted_authorities`, and the Verifier MUST independently validate that presented credentials were issued by parties approved under that request and its own issuer policy. The Verifier MUST NOT rely on the Agent's interpretation of the Issuer Trust List.",
+  "When an Agent relays the request to a separate wallet, browser, device, or remote service, or acquires a remotely generated [[ref: Presentation Result]], the surface that obtains the result is not necessarily the Agent that retries the route. A deployment that binds the Agent in those topologies MUST choose a binding mechanism that survives the relay — for example, an HTTP-layer or token-layer caller authentication on the retry — rather than relying on the presentation result alone.",
+  "When processing a `PROOF-PRESENTATION` value that carries an x401 Token Object, the Verifier MUST decode the x401 Token Object, validate the contained Verification Token, and evaluate whether the token satisfies the route's x401 proof requirement. If an `Authorization` header is also present, the Verifier MUST ensure that the application credential and the x401 Verification Token are bound to the same Agent Identifier, client, subject, proof-of-possession key, certificate, or other verifier-accepted caller binding for the route. A Verifier MUST reject a request that combines an application credential and x401 Verification Token that cannot be safely bound to the same accepted caller context.",
+  "`access_token` | REQUIRED. The opaque or structured [[ref: Verification Token]] value issued to the [[ref: Agent]].",
+  "`error` | REQUIRED. A verifier-defined error code. The value SHOULD be a short ASCII token suitable for logs and programmatic handling.",
+  "`oauth` | REQUIRED. OAuth token exchange metadata for obtaining a reusable Verification Token. See [OAuth Members](#oauth-members).",
+  "`presentation_requirements` | REQUIRED. The composed [[ref: Digital Credentials Request]]. See [Presentation Requirements](#presentation-requirements).",
+  "`presentation_uri` | REQUIRED unless `response` is present. An HTTPS URL the Verifier dereferences with `GET` to fetch the [[ref: Presentation Result]]. The Verifier MUST issue a unique `presentation_uri` value for each presentation and MUST NOT reuse one across presentations. See [Presentation by Reference](#presentation-by-reference).",
+  "`requests[].data` | REQUIRED. The protocol-specific request data. For `openid4vp-v1-signed`, an object carrying the signed OpenID4VP request (a JWT-Secured Authorization Request); for `openid4vp-v1-unsigned`, the OpenID4VP request parameters directly.",
+  "`requests[].protocol` | REQUIRED. The DC API protocol identifier. For this version of x401 the value MUST be `\"openid4vp-v1-signed\"` (RECOMMENDED) or `\"openid4vp-v1-unsigned\"`. See [Verifier Binding](#verifier-binding) for the trade-off.",
+  "`requests` | REQUIRED. A non-empty array of Digital Credentials request entries. A Verifier MAY include more than one entry (for example, offering different credential formats) for a Wallet, handler, or remote service to select among. Every entry MUST be a valid OpenID4VP request for the DC API.",
+  "`response` | REQUIRED unless `presentation_uri` is present. The [[ref: Presentation Result]] returned by the Wallet, as the `{ protocol, data }` object produced by the Digital Credentials API.",
+  "`scheme` | REQUIRED. Value MUST be the string `\"x401\"`.",
+  "`token_endpoint` | REQUIRED. OAuth 2.0 token endpoint where the Agent can exchange a VP Artifact for a Verification Token.",
+  "`token_type` | REQUIRED. The HTTP authorization scheme the Agent uses with the token. The value defined by this specification is `Bearer`.",
+  "`token_type` | REQUIRED. The token type of the supplied Verification Token. For Verification Tokens defined by this specification, the value is `\"Bearer\"`.",
+  "`version` | REQUIRED. The x401 error object version.",
+  "`version` | REQUIRED. The x401 payload version.",
+  "`version` | REQUIRED. The x401 token object version.",
+  "x401 is intentionally separate from payment protocols. When payment is required, it MUST be handled with **HTTP 402 Payment Required** and an appropriate payment protocol. x401 MUST NOT redefine payment semantics.",
+  "~ An optional identifier for the Agent that a Verifier MAY bind to the HTTP caller. This specification does not register a single Agent Identifier scheme; a Verifier that chooses to bind the Agent MUST define which schemes it accepts, including any accepted DID, HTTPS origin, domain-bound client identifier, or certificate-bound identifier schemes. See [Agent Binding Options](#agent-binding-options)."
+]
diff --git a/spec/spec.md b/spec/spec.md
new file mode 100644
index 0000000..bc8f8fd
--- /dev/null
+++ b/spec/spec.md
@@ -0,0 +1,1659 @@
+x401: HTTP Proof Requirement Protocol
+==================
+
+Status: [[badge: Draft]]
+
+Version: 0.2.0
+
+Latest Draft: https://x401.proof.com/spec/latest/
+
+Previous Version: https://x401.proof.com/spec/0.1.0/
+
+Editors:
+~ [Daniel Buchner](https://www.linkedin.com/in/dbuchner) - [Proof](https://proof.com)
+~ [Bhushit Agarwal](https://www.linkedin.com/in/bhushitagarwal/) - [Circle](https://circle.com)
+
+Contributors & Reviewers:
+~ [Darren Louie](https://www.linkedin.com/in/darrenlouie) - [Proof](https://proof.com)
+~ [Lee Campbell](https://github.com/leecam) - [Google](https://google.com)
+~ [Tim Cappalli](https://www.linkedin.com/in/timcappalli/) - [Okta](https://okta.com)
+~ [Nick Steele](https://www.linkedin.com/in/nickelsteele/) - [OpenAI](https://openai.com)
+~ [Reema Bajwa](https://www.linkedin.com/in/reema-bajwa/) - [Google](https://google.com)
+
+Participate:
+~ [GitHub repo](https://github.com/proof/x401)
+~ [File an issue](https://github.com/proof/x401/issues)
+~ [Commit history](https://github.com/proof/x401/commits/main)
+
+------------------------------------
+
+## Abstract
+
+x401 defines an HTTP-based, route-scoped proof requirement protocol for requiring credential-based proof before access to a protected resource is granted.
+
+x401 uses:
+
+- the **`PROOF-REQUIRED` HTTP header field** to carry proof requirements
+- the **`PROOF-PRESENTATION` HTTP header field** to carry proof presentations, presentation references, or reusable proof-satisfaction tokens
+- the **`PROOF-RESPONSE` HTTP header field** to carry verifier response information, including x401 proof errors
+- **HTTP status codes** to express the overall response semantics independently of x401 proof state
+- the **W3C Digital Credentials API (DC API)** request shape as the carrier for the Verifier-composed presentation request, so the request can be executed by native credential wallet/handler methods or relayed to other wallets and remote services
+- **OpenID for Verifiable Presentations (OpenID4VP)** over the DC API for the composed presentation request, using **Digital Credentials Query Language (DCQL)** to describe the credential requirements
+- **OAuth 2.0** for optional exchange of a verified presentation for an access token
+- **DIF Credential Trust Establishment** for verifier-approved issuer policy and non-authoritative acquisition guidance
+- **OpenID for Verifiable Credential Issuance (OpenID4VCI)** for resolving credential issuer metadata when the referenced trust document identifies OpenID4VCI issuers
+
+The x401 payload carries a composed, valid Digital Credentials request authored by the Verifier. The Verifier authors the request and, in the RECOMMENDED signed mode, is its relying party. The request is placed at the payload's `presentation_requirements` member so it can be executed directly through native credential wallet/handler methods (`navigator.credentials.get({ digital: payload.presentation_requirements })`), relayed to another web wallet or remote presentation service, or handed off for fully remote generation. The payload's other top-level members — such as OAuth token exchange metadata, an issuer trust reference, and reusable requirement identifiers — carry x401-specific values that are not yet expressible inside a native Digital Credentials request.
+
+x401 is intentionally separate from payment protocols. When payment is required, it MUST be handled with **HTTP 402 Payment Required** and an appropriate payment protocol. x401 MUST NOT redefine payment semantics.
+
+This document defines the x401 payload, processing rules, interoperability requirements, and examples for proof requirements with optional payment handling.
+
+::: note Protocol Boundary
+x401 defines proof requirement semantics only. When payment is required, implementations still use `402 Payment Required` and a separate payment protocol.
+:::
+
+## Introduction
+
+HTTP provides a standard challenge mechanism for authentication via `401 Unauthorized` and `WWW-Authenticate`, but it does not define a general-purpose, machine-readable protocol for route-scoped proof requirements such as:
+
+- proving personhood
+- proving country of residency
+- proving membership or accreditation
+- proving entitlement issued by a specific issuer class
+- proving organizational standing
+- proving workload identity attributes
+
+At the same time, OpenID4VP, DCQL, OAuth, OpenID4VCI, and the W3C Digital Credentials API define interoperable mechanisms for requesting presentations, evaluating credential requirements, invoking wallets, issuing access tokens, and issuing credentials, but they are not themselves an HTTP route proof requirement protocol.
+
+x401 fills that gap by defining an HTTP-native wrapper that:
+
+- signals proof requirements at the protected route
+- carries x401 proof objects as base64url values in dedicated proof header fields
+- carries a composed, valid Digital Credentials request, authored and signed by the Verifier, at the payload's `presentation_requirements` member
+- recommends a signed OpenID4VP request for the DC API — making the Verifier the relying party and binding the request to the Verifier independently of which surface invokes it — while allowing an unsigned request when the request must be fulfilled at an invocation origin the Verifier cannot declare in advance
+- lets the [[ref: Agent]] execute the request through native credential methods, relay it to another wallet or remote service, or hand it off for fully remote generation and then acquire the result
+- includes OAuth token exchange metadata for Agents that want a reusable access token after proving
+- optionally includes a DIF Credential Trust Establishment URL that can help Agents discover acceptable credential issuers
+- composes with, but does not subsume, payment protocols
+
+In the typical flow, an [[ref: Agent]] receives an x401 proof requirement from a [[ref: Verifier]], obtains a presentation for the Verifier-composed [[ref: Presentation Request]] — by invoking the request through native credential methods, relaying it to a [[ref: Wallet]], or acquiring a remotely generated result — and retries the original protected route with the presentation result inline or by reference. An [[ref: Issuer Trust List]] can help the Agent discover credentials or issuers, but the Verifier remains authoritative for issuer trust enforcement.
+
+## Design Goals
+
+The goals of x401 are:
+
+1. Define a route-scoped proof requirement for HTTP resources.
+2. Carry a composed, valid Digital Credentials request, authored by the Verifier, that can be executed by native credential wallet/handler methods.
+3. Let the Verifier be the relying party for that request through a signed request, while allowing an unsigned request bound to the invoking origin and nonce when the invocation origin cannot be known in advance.
+4. Preserve the Agent's ability to execute the request natively, relay it to another wallet or remote service, or hand it off for fully remote generation and then acquire and present the result.
+5. Reserve the top level of the x401 payload, alongside the native request, for x401-specific values that are not yet expressible inside a native Digital Credentials request.
+6. Reuse OpenID4VP over the DC API, DCQL, OAuth, and OpenID4VCI rather than redefining them.
+7. Remain separate from payment semantics.
+8. Allow issuer discovery by reference to verifier trust policy without listing issuers inline in the x401 payload.
+9. Support stateless verifier deployments without dictating how the Verifier achieves it.
+10. Allow optional caller authentication, request signing, and delegation artifacts to compose with x401 without making any one agent identity or binding system mandatory.
+
+## Non-Goals
+
+x401 does not:
+
+- define a new credential format
+- replace OpenID4VP or the W3C Digital Credentials API
+- replace OpenID4VCI
+- redefine how a Digital Credentials request is composed, signed, or invoked
+- mandate a single transport for delivering the composed request to a Wallet
+- define a payment protocol
+- require all Verifiers to maintain server-side session state
+- require VP response encryption or any single agent authentication or binding mechanism
+
+## Terminology
+
+The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **NOT RECOMMENDED**, **MAY**, and **OPTIONAL** in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+[[def: Verifier]]:
+~ The party protecting a resource or operation and requiring proof.
+
+[[def: Agent]]:
+~ The HTTP caller that requests a protected route, receives an x401 proof requirement, obtains a presentation for the Verifier-composed [[ref: Presentation Request]] — by invoking it through native credential methods, relaying it to a Wallet or remote service, or acquiring a remotely generated result — and retries the protected route. The Agent does not compose the presentation request and is not, by default, the relying party for it. A deployment MAY additionally bind the Agent to the request using an optional [[ref: Agent Identifier]].
+
+[[def: Agent Identifier]]:
+~ An optional identifier for the Agent that a Verifier MAY bind to the HTTP caller. This specification does not register a single Agent Identifier scheme; a Verifier that chooses to bind the Agent MUST define which schemes it accepts, including any accepted DID, HTTPS origin, domain-bound client identifier, or certificate-bound identifier schemes. See [Agent Binding Options](#agent-binding-options).
+
+[[def: Holder]]:
+~ The subject or entity that possesses credentials and can authorize a Wallet to present proof.
+
+[[def: Wallet]]:
+~ Software capable of receiving an OpenID4VP request through the Digital Credentials API or another transport and returning a presentation result authorized by a [[ref: Holder]].
+
+[[def: Digital Credentials Request]]:
+~ The composed, valid Digital Credentials request the Verifier places at the payload's `presentation_requirements` member. It is a `DigitalCredentialRequestOptions` value (`{ "requests": [ ... ] }`) usable directly as the `digital` member of `navigator.credentials.get()`. Each entry is an OpenID4VP request for the DC API, signed (RECOMMENDED) or unsigned.
+
+[[def: Presentation Request]]:
+~ The Verifier-authored OpenID4VP request carried inside the [[ref: Digital Credentials Request]]. It identifies the credential requirement as `dcql_query` and carries the OpenID4VP `nonce`. When signed (RECOMMENDED), the Verifier is its relying party and it binds to the Verifier through the request signature, `client_id`, and `expected_origins`; when unsigned, it binds to the invoking origin and the `nonce`. See [Verifier Binding](#verifier-binding).
+
+[[def: Presentation Result]]:
+~ The result a Wallet returns for a [[ref: Digital Credentials Request]], shaped as `{ "protocol": ..., "data": ... }` as returned by the Digital Credentials API.
+
+[[def: Issuer Trust List]]:
+~ A verifier-controlled DIF Credential Trust Establishment document that identifies the issuers, authorities, roles, activities, credential schemas, or credential types the Verifier accepts for a proof requirement. The same document can also help Agents discover where qualifying credentials may be obtained.
+
+[[def: VP Artifact]]:
+~ A retry artifact carrying a [[ref: Presentation Result]] — either inline or as a [[ref: Presentation Reference]] — together with the x401 metadata the Verifier needs to correlate proof fulfillment, encoded for use in a `PROOF-PRESENTATION` request header or OAuth token exchange.
+
+[[def: Presentation Reference]]:
+~ A by-reference form of the [[ref: VP Artifact]] that carries a URL the Verifier dereferences to fetch a [[ref: Presentation Result]] instead of carrying it inline, for presentations that exceed header size limits or are generated at a remote location.
+
+[[def: Verification Token]]:
+~ A verifier-issued, short-lived access token returned after successful proof verification and used by the [[ref: Agent]] on later protected-route requests so that the VP Artifact does not need to be repeated. A Verification Token can be used as the route's normal `Authorization` token when the deployment supports that model, or carried as an x401 Token Object in `PROOF-PRESENTATION` when the route already uses `Authorization` for existing application authentication.
+
+[[def: x401 Token Object]]:
+~ A JSON object carried as a base64url value in `PROOF-PRESENTATION` to pass a Verification Token without replacing the route's existing `Authorization` credentials.
+
+[[def: x401 Payload]]:
+~ The JSON object defined by this specification, UTF-8 encoded, and carried as a base64url value in the `PROOF-REQUIRED` header field.
+
+[[def: x401 Error Object]]:
+~ A JSON object carried as a base64url value in the `PROOF-RESPONSE` header field to describe why a presented proof failed or could not be processed.
+
+## Protocol Overview
+
+The x401 protocol is made up of four legs: a Verifier exposes identity proof requirements that gate access to a resource by composing a Digital Credentials request, the Agent obtains a presentation for that request, the Agent presents the result back to the Verifier, and the Agent may exchange that proof for a reusable Verification Token. The tabs below summarize each leg and link to the detailed section that defines the processing rules that pertain to them.
+
+::: tabs
+
+:: 1. Gated Resource
+
+The Verifier declares a route-scoped proof requirement by returning a `PROOF-REQUIRED` header. The header carries the base64url-encoded x401 payload that defines the route's proof requirement; see [x401 Gated Resource Configuration](#x401-gated-resource-configuration) for details. The response status code describes the overall HTTP response and is not the x401 protocol carrier.
+
+```http
+HTTP/1.1 401 Unauthorized
+PROOF-REQUIRED: <base64url-x401-payload>
+Cache-Control: no-store
+```
+
+:: 2. Obtaining a Presentation
+
+The Agent decodes the x401 payload and obtains a presentation for the Verifier-composed request at the payload's `presentation_requirements` member. The Agent does not compose or alter the request; it invokes it through native credential methods, relays it to a Wallet or remote service, or acquires a remotely generated result; see [Obtaining a Presentation](#obtaining-a-presentation) for details. The composed request is directly usable as the `digital` member of `navigator.credentials.get()`.
+
+```js
+const result = await navigator.credentials.get({ digital: payload.presentation_requirements });
+// result => { protocol: "openid4vp-v1-signed", data: { /* presentation result */ } }
+```
+
+:: 3. VP Presentation
+
+After obtaining a presentation result, the Agent packages it as a VP Artifact for protected-route retry. The VP Artifact carries the Wallet-returned presentation result inline, or a reference the Verifier dereferences; see [Verifiable Presentation Delivery](#verifiable-presentation-delivery) for details.
+
+```json
+{
+  "request_id": "proof-template-financial-customer-v1",
+  "response": {
+    "protocol": "openid4vp-v1-signed",
+    "data": "<wallet-returned-presentation-result>"
+  }
+}
+```
+
+:: 4. Token Acquisition
+
+The Agent can submit the same VP Artifact to the Verifier's OAuth token endpoint to obtain a reusable Verification Token. The token exchange uses fixed x401 token-exchange parameters and then the Agent retries protected routes with either an upgraded `Authorization` token or a `PROOF-PRESENTATION` proof-satisfaction token object; see [Access Token Acquisition](#access-token-acquisition) for details.
+
+```http
+POST /oauth/token HTTP/1.1
+Host: bank.example.com
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
+subject_token_type=urn:x401:params:oauth:token-type:vp_artifact&
+subject_token=<base64url-vp-artifact-json>
+```
+
+:::
+
+### Primary Flow
+
+In the primary x401 flow, the [[ref: Agent]] is the HTTP caller and is assumed to have access to a [[ref: Wallet]], keys, credentials, or local capabilities needed to fulfill the proof requirement.
+
+1. The [[ref: Agent]] requests a protected route.
+2. The [[ref: Verifier]] determines that proof is required.
+3. The [[ref: Verifier]] returns an HTTP response with:
+   - `PROOF-REQUIRED: <base64url-x401-payload>`
+4. The [[ref: Agent]] decodes the x401 payload and reads the composed [[ref: Digital Credentials Request]] at the `presentation_requirements` member and the OAuth token endpoint.
+5. The [[ref: Agent]] obtains a [[ref: Presentation Result]] for `presentation_requirements` without altering it, by one of:
+   - invoking the request through a native credential method such as `navigator.credentials.get({ digital: payload.presentation_requirements })`,
+   - relaying the request to a Wallet or remote presentation service that can execute it, or
+   - handing the request to a remote fulfillment surface and acquiring the generated result.
+6. The chosen Wallet, handler, or service returns a presentation result bound per the request's mode — to the Verifier as relying party for a signed request, or to the invoking origin and nonce for an unsigned request.
+7. The [[ref: Agent]] retries the same protected route that produced the x401 proof requirement with one of:
+   - a [[ref: VP Artifact]] in a `PROOF-PRESENTATION` request header, carrying the presentation result inline or as a [[ref: Presentation Reference]],
+   - a [[ref: Verification Token]] carried as an x401 Token Object in a `PROOF-PRESENTATION` request header, or
+   - a [[ref: Verification Token]] in the route's normal `Authorization` request header when the deployment uses x401 proof satisfaction to upgrade or replace the route's ordinary authorization credential.
+8. The [[ref: Verifier]] validates the VP Artifact or Verification Token, dereferencing a Presentation Reference when one is supplied.
+9. If proof is satisfied and payment is not required or is already satisfied, the [[ref: Verifier]] returns the protected resource.
+10. If proof is satisfied but payment remains unsatisfied, the [[ref: Verifier]] returns `402 Payment Required` with payment protocol details. After satisfying payment, the [[ref: Agent]] retries the same route with proof or token material and the payment artifact required by the selected payment protocol.
+
+```mermaid
+sequenceDiagram
+    participant Agent
+    participant Verifier
+    participant Wallet
+    participant Payment
+    Agent->>Verifier: Request protected route
+    Verifier-->>Agent: HTTP response + PROOF-REQUIRED (composed request)
+    Agent->>Wallet: Invoke / relay verifier-composed Digital Credentials request
+    Wallet-->>Agent: Presentation result (bound to Verifier as RP)
+    Agent->>Verifier: Retry route with PROOF-PRESENTATION result or OAuth token
+    opt Payment required after proof satisfaction
+        Verifier-->>Agent: 402 Payment Required
+        Agent->>Payment: Complete payment protocol
+        Payment-->>Agent: Payment artifact
+        Agent->>Verifier: Retry same route with proof or token + payment
+    end
+    Verifier-->>Agent: Protected resource
+```
+
+### Optional OAuth Token Exchange
+
+An Agent MAY exchange a VP Artifact for a Verification Token before retrying the protected route. The token endpoint is supplied by the Verifier in the x401 payload.
+
+```mermaid
+sequenceDiagram
+    participant Agent
+    participant Verifier
+    participant Wallet
+    Agent->>Verifier: Request protected route
+    Verifier-->>Agent: HTTP response + PROOF-REQUIRED (composed request)
+    Agent->>Wallet: Invoke / relay verifier-composed Digital Credentials request
+    Wallet-->>Agent: Presentation result (bound to Verifier as RP)
+    Agent->>Verifier: OAuth token request with VP artifact
+    Verifier-->>Agent: Verification token
+    Agent->>Verifier: Retry same route with Authorization token or PROOF-PRESENTATION token object
+    Verifier-->>Agent: Protected resource
+```
+
+The technical sections that follow are organized by the four main legs of the protocol: x401 gated resource configuration, obtaining a presentation, verifiable presentation delivery, and access token acquisition.
+
+## x401 Gated Resource Configuration
+
+The initial leg of the protocol defines how a protected HTTP resource declares what proof is required. The Verifier responds to the original protected-route request with a `PROOF-REQUIRED` header whose value contains the base64url-encoded x401 payload.
+
+The requirement is route-scoped. If a representation includes gated and ungated material, this version of x401 does not define per-fragment requirements or separate requirement mapping inside the page. Fulfillment of the complete credential demand in the `PROOF-REQUIRED` payload satisfies the route's x401 gate.
+
+```http
+POST /accounts/applications HTTP/1.1
+Host: bank.example.com
+Accept: application/json
+
+HTTP/1.1 401 Unauthorized
+PROOF-REQUIRED: <base64url-x401-payload>
+Cache-Control: no-store
+```
+
+### HTTP Semantics
+
+HTTP status or condition | Meaning in a x401-capable deployment | Agent expectation
+------------------------ | ------------------------------------ | ----------------
+Any response with `PROOF-REQUIRED` | Proof is required, advertised, or not yet satisfied for the route | Decode the x401 payload from the `PROOF-REQUIRED` field value
+Any response with `PROOF-RESPONSE` containing an x401 Error Object | A presented x401 proof failed or could not be processed | Decode the x401 error object and treat the x401 proof branch as failed
+`2xx` with `PROOF-REQUIRED` | The HTTP response is otherwise successful, but the route includes x401-gated material or actions | Process the response normally and fulfill the route-scoped proof requirement when access to the gated material is needed
+`4xx` with `PROOF-REQUIRED` | The route cannot be completed without proof | Fulfill the route-scoped proof requirement before retrying
+`402 Payment Required` | Payment remains unsatisfied | Switch to the payment protocol
+
+The x401 proof header fields are the x401 protocol carriers. HTTP status codes describe the overall response and do not, by themselves, define x401 proof state.
+
+#### Status Code Independence
+
+A server that requires proof for access to a protected resource, route, representation, or operation whose response would be changed as a whole by fulfilling a single set of proof requirements MUST return `PROOF-REQUIRED: <base64url-x401-payload>`. The `PROOF-REQUIRED` header is the authoritative carrier for an x401 proof requirement that gates the entire response.
+
+The response MAY use any HTTP status code appropriate for the whole response. A Verifier can use a successful status code when the response body is still useful without proof, or a client or server error status when the requested operation cannot proceed until proof is satisfied.
+
+Example:
+
+```http
+HTTP/1.1 200 OK
+PROOF-REQUIRED: <base64url-x401-payload>
+Cache-Control: no-store
+```
+
+An x401 proof requirement carried in `PROOF-REQUIRED` SHOULD NOT require the Agent to parse a response body in order to understand the proof requirement.
+
+This specification does not carry x401 proof requirements in `WWW-Authenticate`. A protected route may already use that header for an existing HTTP authentication scheme, and combining multiple schemes — whether through comma-separated field values or duplicate header lines — is not consistently or well handled by common HTTP servers, proxies, client libraries, and middleware. Carrying x401 proof requirements in a dedicated `PROOF-REQUIRED` field avoids those interoperability gaps and lets x401 compose with any existing `WWW-Authenticate`-based authentication without contention.
+
+#### 402 for Payment
+
+A server that requires payment MUST use `402 Payment Required` and MUST NOT overload x401 to represent payment as proof.
+
+Payment metadata MAY be declared in a x401 payload for informational purposes when payment may also be required, but payment satisfaction itself remains governed by the payment protocol used with `402`.
+
+#### x401 Error for Failed Policy Satisfaction
+
+If an Agent presents a proof artifact that is structurally valid but does not satisfy the Verifier's policy, the Verifier SHOULD return a `PROOF-RESPONSE: <base64url-x401-error-object>` header. The x401 Error Object is the protocol-specific indication of failure for x401 exchanges. The HTTP response status remains independent and describes the overall response.
+
+Examples include:
+
+- credential from an untrusted issuer
+- credential does not satisfy predicates
+- expired or revoked credential
+- presentation is not bound as the request mode requires (wrong relying party, audience, or invoking origin)
+- nonce is not one the Verifier issued, or is expired or replayed
+- insufficient assurance level
+
+### Proof Header Fields
+
+The proof header fields carry x401 protocol objects. This specification uses "x401 proof requirement" for the overall route-gating declaration carried in `PROOF-REQUIRED`.
+
+#### Header Syntax
+
+Each x401 proof header field carries exactly one base64url-encoded UTF-8 JSON object. The header field name identifies the protocol leg, so x401 does not use an action keyword inside a shared carrier header.
+
+Header field names are shown in uppercase for consistency with the examples. As HTTP field names, they are case-insensitive.
+
+```text
+PROOF-REQUIRED: <base64url-json>
+PROOF-PRESENTATION: <base64url-json>
+PROOF-RESPONSE: <base64url-json>
+```
+
+The defined x401 proof header fields are:
+
+Header field | Direction | Decoded payload
+------------ | --------- | ---------------
+`PROOF-REQUIRED` | Verifier to Agent | [[ref: x401 Payload]]
+`PROOF-PRESENTATION` | Agent to Verifier | [[ref: VP Artifact]] or [[ref: x401 Token Object]]
+`PROOF-RESPONSE` | Verifier to Agent | x401 response information, including [[ref: x401 Error Object]]
+
+The encoded value MUST be base64url-encoded UTF-8 JSON using the URL and filename safe alphabet defined by RFC 4648 Section 5 without padding. The decoded value MUST be a single JSON object.
+
+When `PROOF-PRESENTATION` carries a VP Artifact, the request is a direct proof presentation. When it carries an x401 Token Object, the request is presenting a reusable proof-satisfaction token issued after prior verification.
+
+`PROOF-RESPONSE` is the Verifier-to-Agent response information channel for x401-specific results and diagnostics. This specification defines the x401 Error Object for failed proof presentation or token processing. Deployments MAY define additional response objects for accepted proof state, token metadata, or other x401-specific return information.
+
+A sender MUST NOT generate more than one field line with the same x401 proof header name in the same HTTP message. A sender MUST NOT combine multiple x401 protocol objects in a single proof header using commas or other list syntax. If a recipient receives multiple field lines for the same proof header, or receives a proof header value containing a comma-separated list of messages, it MUST treat that proof header as invalid.
+
+A response SHOULD NOT contain both `PROOF-REQUIRED` and `PROOF-RESPONSE` unless the response both reports verifier response information and intentionally advertises a fresh proof requirement for a subsequent attempt. A request SHOULD NOT contain more than one `PROOF-PRESENTATION` value.
+
+When browser-based JavaScript needs to read `PROOF-REQUIRED` or `PROOF-RESPONSE` from a cross-origin response, the response needs CORS exposure for those fields. When browser-based JavaScript sends `PROOF-PRESENTATION` cross-origin, the server needs to allow the `PROOF-PRESENTATION` request header through CORS preflight.
+
+### x401 Payload
+
+A x401 payload is a single JSON object encoded in the `PROOF-REQUIRED` header field.
+
+The payload SHOULD remain compact. Sensitive route state SHOULD be omitted, stored server-side, or carried only inside verifier-protected nonce state.
+
+#### Top-Level Members
+
+```json
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "presentation_requirements": {},
+  "oauth": {},
+  "trust_establishment": "https://...",
+  "request_id": "...",
+  "satisfied_requirements": [],
+  "payment": {}
+}
+```
+
+The top level of the x401 payload is itself the envelope: the native, standard Digital Credentials request is the `presentation_requirements` member, and the remaining x401-specific members — which are not yet expressible inside a native Digital Credentials request — sit alongside it so the Agent and Verifier can polyfill their use.
+
+#### Member Definitions
+
+Name | Definition
+---- | ----------
+`scheme` | REQUIRED. Value MUST be the string `"x401"`.
+`version` | REQUIRED. The x401 payload version.
+`presentation_requirements` | REQUIRED. The composed [[ref: Digital Credentials Request]]. See [Presentation Requirements](#presentation-requirements).
+`oauth` | REQUIRED. OAuth token exchange metadata for obtaining a reusable Verification Token. See [OAuth Members](#oauth-members).
+`trust_establishment` | OPTIONAL. HTTPS URL of a DIF Credential Trust Establishment document, as an acquisition and discovery hint. See [Trust Establishment](#trust-establishment).
+`request_id` | OPTIONAL. A stable verifier-defined identifier for the proof template, as an Agent-visible hint. See [Reusable Requirement Hints](#reusable-requirement-hints).
+`satisfied_requirements` | OPTIONAL. Stable verifier-defined identifiers for the reusable proof requirements this proof would satisfy, as an Agent-visible reuse hint. See [Reusable Requirement Hints](#reusable-requirement-hints).
+`return_uri` | OPTIONAL. An `https` URL added by a relaying intermediary (never by the Verifier) telling a remote handler where to deliver the presentation result. See [Relayed Delivery to a Remote Handler](#relayed-delivery-to-a-remote-handler).
+`payment` | OPTIONAL. Describes that payment is additionally required, without replacing `402` semantics.
+
+The credential requirement, the OpenID4VP `nonce`, and the request expiry all live inside the request in `presentation_requirements`; x401 does not duplicate them at the payload level. Of the payload-level members, only `presentation_requirements` and `oauth` are load-bearing; `trust_establishment`, `request_id`, and `satisfied_requirements` are optional hints and optimizations.
+
+### Presentation Requirements
+
+The `presentation_requirements` member carries the Verifier-composed [[ref: Digital Credentials Request]]. The Verifier authors it; in the RECOMMENDED signed mode it also signs the request and is its relying party (see [Verifier Binding](#verifier-binding)).
+
+#### General Structure
+
+```json
+{
+  "presentation_requirements": {
+    "requests": [
+      {
+        "protocol": "openid4vp-v1-signed",
+        "data": {
+          "request": "eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWF1dGh6LXJlcStqd3QifQ..."
+        }
+      }
+    ]
+  },
+  "oauth": {
+    "token_endpoint": "https://bank.example.com/oauth/token"
+  },
+  "trust_establishment": "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_requirements` is a `DigitalCredentialRequestOptions` value, usable directly as the `digital` member of `navigator.credentials.get()`. Each entry in `requests` is an OpenID4VP request for the DC API. The example below uses the RECOMMENDED signed form, whose JAR carries the OpenID4VP request the Verifier authored — RP identity and freshness live there, not in any x401-specific field. Decoded for readability, a typical JAR payload is:
+
+```json
+{
+  "response_type": "vp_token",
+  "response_mode": "dc_api",
+  "client_id": "x509_san_dns:bank.example.com",
+  "expected_origins": ["https://bank.example.com"],
+  "nonce": "uX7Vq3mZJH6MeN0qz2L7SQ",
+  "dcql_query": {
+    "credentials": [
+      {
+        "id": "financial_customer",
+        "format": "jwt_vc_json",
+        "meta": {
+          "type_values": ["FinancialCustomerCredential"]
+        },
+        "claims": [
+          {
+            "path": ["credentialSubject", "assurance_level"],
+            "values": ["VC-AL2", "VC-AL3"]
+          }
+        ]
+      }
+    ]
+  },
+  "client_metadata": {},
+  "exp": 1746557100
+}
+```
+
+The `presentation_requirements` member is a `DigitalCredentialRequestOptions` value, usable directly as the `digital` member of `navigator.credentials.get()`. The credential requirement (`dcql_query`), the OpenID4VP `nonce`, and the request expiry (`exp`) all live inside the request; x401 does not restate or duplicate them at the payload level, and adds no expiry member of its own.
+
+#### Request Members
+
+Name | Definition
+---- | ----------
+`requests` | REQUIRED. A non-empty array of Digital Credentials request entries. A Verifier MAY include more than one entry (for example, offering different credential formats) for a Wallet, handler, or remote service to select among. Every entry MUST be a valid OpenID4VP request for the DC API.
+`requests[].protocol` | REQUIRED. The DC API protocol identifier. For this version of x401 the value MUST be `"openid4vp-v1-signed"` (RECOMMENDED) or `"openid4vp-v1-unsigned"`. See [Verifier Binding](#verifier-binding) for the trade-off.
+`requests[].data` | REQUIRED. The protocol-specific request data. For `openid4vp-v1-signed`, an object carrying the signed OpenID4VP request (a JWT-Secured Authorization Request); for `openid4vp-v1-unsigned`, the OpenID4VP request parameters directly.
+
+### OAuth Members
+
+Name | Definition
+---- | ----------
+`token_endpoint` | REQUIRED. OAuth 2.0 token endpoint where the Agent can exchange a VP Artifact for a Verification Token.
+`audience` | OPTIONAL. OAuth token exchange `audience` value the Agent should request.
+`resource` | OPTIONAL. OAuth token exchange `resource` value the Agent should request.
+
+The x401 OAuth profile fixes `grant_type`, `subject_token_type`, and Bearer token usage. These values MUST NOT be repeated in the x401 payload.
+
+### Trust Establishment
+
+`trust_establishment` is an OPTIONAL acquisition and discovery hint. Its value is an HTTPS URL for a DIF Credential Trust Establishment document that describes the issuers, authorities, roles, activities, credential schemas, or credential types the Verifier approves for this proof requirement. It is not the mechanism that decides validity.
+
+Issuer enforcement is ultimately governed by the request, not by `trust_establishment`. Where the Verifier needs the Wallet to constrain acceptable issuers at presentation time, it expresses that with DCQL `trusted_authorities` inside the request in `presentation_requirements`. `trust_establishment` exists to help Agents and Wallets *discover* and *acquire* likely-acceptable credentials, and to convey richer ecosystem, role, or acquisition metadata than `trusted_authorities` carries; it MUST NOT enumerate approved issuers inline. The Verifier MUST enforce issuer trust during proof validation — against the `trusted_authorities` in the request and its own policy — and MUST NOT rely on the Agent's interpretation of the Issuer Trust List.
+
+### Reusable Requirement Hints
+
+`request_id` and `satisfied_requirements` are OPTIONAL, Agent-visible hints that support cross-route token reuse. They are not inputs to proof validation or token issuance — the Verifier determines what a proof satisfies from its own policy. See [Reuse Across Routes](#reuse-across-routes).
+
+Name | Definition
+---- | ----------
+`request_id` | OPTIONAL. A stable verifier-defined identifier for the proof template. It lets an Agent recognize that two routes ask for the same proof.
+`satisfied_requirements` | OPTIONAL. Stable verifier-defined identifiers for the reusable proof requirements this proof would satisfy, letting an Agent decide whether an existing Verification Token may apply to a later route.
+
+### Payload Example
+
+::: example x401 Payload Example
+```json
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "presentation_requirements": {
+    "requests": [
+      {
+        "protocol": "openid4vp-v1-signed",
+        "data": {
+          "request": "eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWF1dGh6LXJlcStqd3QifQ..."
+        }
+      }
+    ]
+  },
+  "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"
+  ]
+}
+```
+:::
+
+### Verifier State and Stateless Operation
+
+Because the Verifier authors, signs, and validates its own request, freshness, replay protection, and correlation between a returned presentation and the issued request are internal Verifier concerns. x401 places no requirements on how the Verifier composes the OpenID4VP `nonce`, recognizes a returned presentation as one it requested, or recovers route and policy context. The freshness and replay properties of the `nonce` are governed by OpenID4VP.
+
+::: note Stateless operation
+A Verifier MAY operate statelessly. Because the OpenID4VP `nonce` is the value echoed back and cryptographically bound in the returned presentation, a Verifier MAY make the `nonce` a verifier-protected, self-contained value that encodes the route, method, policy, and expiry it needs to validate the retry without server-side storage. How that value is constructed, whether one-time-use replay protection is enforced with a small shared cache, and how any response-encryption decryption key is managed are deployment decisions left to the implementer.
+:::
+
+### Credential Acquisition Guidance
+
+When a Verifier wants to disclose which issuers, authorities, roles, activities, credential schemas, or credential types can satisfy a proof requirement, it sets the `trust_establishment` member.
+
+Its value is an HTTPS URL pointing to an [[ref: Issuer Trust List]]. The Agent MAY use the referenced document to discover candidate credentials or credential issuers, and the Wallet MAY use it to help select credentials that are likely to satisfy the Verifier.
+
+If the referenced Issuer Trust List identifies OpenID4VCI Credential Issuer Identifiers, Agents resolve those issuer identifiers using the OpenID4VCI issuer metadata discovery rules. See OpenID4VCI Section 12.2.2: <https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html>.
+
+### Payment Object
+
+When payment may also be required, a x401 payload MAY declare the existence of that additional payment requirement. This is to help avoid situations where the user is not willing or able to pay, but does not find out about the payment requirement until after they have already disclosed their credential(s), resulting in needless sharing of identity information without achieving the outcome the user intended.
+
+The payment object is informational and orchestration-oriented only. It does not replace `402 Payment Required`.
+
+The presence of a `payment` member does not create a distinct x401 proof flow. The Agent completes the same proof steps described in the base flow. If the Verifier accepts the proof but payment remains unsatisfied, the Verifier uses `402 Payment Required` and the selected payment protocol to complete payment before granting access.
+
+#### Example
+
+```json
+{
+  "required": true,
+  "scheme_hint": "x402",
+  "notes": "Payment is required after proof is satisfied."
+}
+```
+
+::: warning payment hint warning
+There is good reason to include hints about payment requirements, but because it could result in replication of nearly everything 402-related protocols define, the payment hint has been constrained to a boolean to allow the community to drive how much payment requirement information to include.
+:::
+
+#### Members
+
+Name | Definition
+---- | ----------
+`required` | OPTIONAL. Boolean indicating whether payment is additionally required.
+`scheme_hint` | OPTIONAL. A hint naming the expected payment protocol.
+`notes` | OPTIONAL. Human-readable notes.
+
+If proof is accepted but payment is still unsatisfied, the Verifier responds with `402 Payment Required` using the payment protocol indicated by the verifier.
+
+## Obtaining a Presentation
+
+This leg defines how the Agent obtains a presentation for the Verifier-composed request at the payload's `presentation_requirements` member. The Verifier authored the request; the Agent does not compose it and is not, by default, its audience. The Agent's task is to get the request executed and to acquire the resulting [[ref: Presentation Result]].
+
+An Agent obtains a presentation by one of the following, all of which carry the same Verifier-composed request unchanged:
+
+1. **Native invocation.** In an environment with the Digital Credentials API, the Agent invokes the request directly:
+
+   ```js
+   const result = await navigator.credentials.get({ digital: payload.presentation_requirements });
+   // result => { protocol, data }
+   ```
+
+   A native platform credential handler MAY be used in place of the Web API where an equivalent mechanism exists.
+
+2. **Relay to a remote handler.** The Agent forwards the request to a remote handler — a web wallet or service that produces the presentation without invoking the Digital Credentials API itself — and the handler returns the result to a URL the Agent supplies. See [Relayed Delivery to a Remote Handler](#relayed-delivery-to-a-remote-handler).
+
+3. **Remote, out-of-band generation.** When the Agent's environment cannot invoke the request directly — for example, a consumer AI client without a credential handler — the request can be handed to a remote fulfillment surface (such as a verifier-hosted page) that invokes the Digital Credentials API in its own context and generates the presentation. The Agent then acquires the result and replays the protected route. See [Remote and Out-of-Band Fulfillment](#remote-and-out-of-band-fulfillment).
+
+In every case the resulting presentation is bound per the request's mode and transport — to the Verifier as relying party for a signed request, or to the invoking origin and the Verifier's `nonce` for an unsigned request (see [Verifier Binding](#verifier-binding)) — not to the Agent.
+
+### Composed Request Invariants
+
+The composed request is authored and signed by the Verifier. The Agent treats it as opaque:
+
+1. The Agent MUST NOT modify any entry in `presentation_requirements`. The request signature binds its contents, so any modification invalidates it.
+2. When `presentation_requirements.requests` contains more than one entry, the Agent MAY narrow them to entries whose `protocol` or credential formats the chosen Wallet or handler implements, and MAY pass the entries through unchanged; which entry is ultimately used is determined by the Wallet or handler matching the request against available credentials, not chosen up front by the Agent.
+3. The Agent MUST arrange to acquire the [[ref: Presentation Result]] returned for the request, whether it invokes the request itself, relays it, or acquires a remotely generated result.
+
+A Verifier composing `presentation_requirements`:
+
+1. MUST make each entry a valid OpenID4VP request for the Digital Credentials API, using `protocol: "openid4vp-v1-signed"` (RECOMMENDED) or `protocol: "openid4vp-v1-unsigned"`.
+2. SHOULD use a signed request and set its `client_id` and `expected_origins`. A signed request lets the Wallet authenticate the Verifier, binds the presentation's audience to the Verifier's identity, and lets the Verifier pre-authorize the invocation origin; see [Verifier Binding](#verifier-binding).
+3. MAY use an unsigned request when it needs the request fulfilled at an invocation origin it cannot declare in advance — for example, when the Agent invokes the request directly in its own context or relays it to an arbitrary surface. An unsigned request binds the presentation to the invoking origin and the Verifier's `nonce` rather than to a signed Verifier identity, with the trade-offs described in [Verifier Binding](#verifier-binding).
+4. MAY request response encryption (for example, a `dc_api.jwt` response mode with encryption keys in `client_metadata`) or omit it. Response encryption is OPTIONAL in x401.
+
+x401 does not restate the field-level rules for composing, signing, or invoking a Digital Credentials request; those are defined by the W3C Digital Credentials API and by OpenID4VP for the DC API. x401 requires only that `presentation_requirements` is a valid OpenID4VP request for the DC API; the Verifier validates whichever binding its chosen request mode provides.
+
+`trust_establishment` can help Agents discover acceptable issuers, but it never delegates verification behavior to the Agent, and it does not decide validity — the request's `dcql_query` and `trusted_authorities` do. When the referenced Issuer Trust List identifies OpenID4VCI issuers, Agents resolve those issuers using OpenID4VCI issuer metadata discovery.
+
+### Relayed Delivery to a Remote Handler
+
+Native invocation returns the presentation through the `navigator.credentials.get()` call, so it needs no return channel. When an intermediary — for example, an MCP tool or other Agent — instead hands the request to a **remote handler** (a web wallet or service that produces the presentation without invoking the Digital Credentials API itself), two things must be supplied that the Verifier cannot know: where the result is returned, and how a non-DC-API handler is expected to process a Digital Credentials request. The intermediary forwards the request unchanged and adds only the return channel.
+
+#### Return Channel
+
+An intermediary that relays the x401 payload to a remote handler MUST add a `return_uri` member to the payload it forwards. `return_uri` is an `https` URL the handler delivers the [[ref: Presentation Result]] to; it is supplied by the relaying intermediary, never by the Verifier, and SHOULD be unguessable, short-lived, single-use, and controlled by the intermediary. The handler returns the result by sending an HTTP `POST` of the `{ "protocol": ..., "data": ... }` Presentation Result to `return_uri`. The intermediary then packages that result into a VP Artifact (inline or as a [[ref: Presentation Reference]]) and retries the protected route.
+
+```json
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "presentation_requirements": { "requests": [ { "protocol": "openid4vp-v1-signed", "data": { "request": "eyJ..." } } ] },
+  "oauth": { "token_endpoint": "https://bank.example.com/oauth/token" },
+  "return_uri": "https://mcp.example/x401/return/9f1c2a"
+}
+```
+
+#### Handler Processing
+
+The intermediary passes `presentation_requirements` to the handler unchanged; the handler is not asked to disassemble it, nor is it told which entry to use. It evaluates the request the way the Digital Credentials API would and returns a presentation for whichever entry it can satisfy. A remote handler that does not invoke the Digital Credentials API:
+
+1. MUST consider the `requests[]` entries whose `protocol` and credential formats it implements, and among those, MUST attempt to satisfy each entry's `dcql_query` — including any `credential_sets` / `claim_sets` alternatives within it — against the credentials available to it, with Holder selection where applicable. Which entry is used is the *outcome* of this matching, not a prior choice; an entry is usable only if a held credential satisfies its query.
+2. For a satisfiable entry, MUST read the OpenID4VP request from its `data` — the claims of the signed request object for `openid4vp-v1-signed`, or the request parameters directly for `openid4vp-v1-unsigned` — and produce a presentation that satisfies that `dcql_query`, bound to its `nonce`. It honors `client_metadata` for accepted formats and any response-encryption key, and, for a signed request, binds the presentation's audience to the request's `client_id`.
+3. MUST treat the Digital Credentials API transport members as not applicable to relayed delivery: it does not return through `response_mode: dc_api`/`dc_api.jwt` (it returns to `return_uri` instead) and does not enforce `expected_origins` (there is no invoking Web origin).
+4. MUST NOT weaken or alter the `dcql_query` or `nonce`, and MUST deliver the resulting [[ref: Presentation Result]] to `return_uri`. If it can satisfy no entry, it returns no presentation and SHOULD signal that failure to the intermediary rather than returning a partial or substitute result.
+
+This matching, credential discovery, and Holder selection follow the same OpenID4VP and DCQL rules a Wallet applies under the Digital Credentials API; x401 does not redefine them.
+
+Because relayed delivery does not go through a Web origin, `expected_origins` is not enforced. A signed request still binds the presentation's audience to the Verifier through its `client_id`, so signed requests are RECOMMENDED for relayed delivery — they preserve Verifier audience binding across the relay, losing only origin pre-authorization. An unsigned request has no `client_id` and so binds only to the `nonce`. A Verifier that supports relayed delivery validates the returned presentation by its `nonce` and, for a signed request, its `client_id`, accepting that origin pre-authorization was not enforced — the weaker-binding case described in [Verifier Binding](#verifier-binding).
+
+#### Composing a Request for Both Native and Relayed Fulfillment
+
+A Verifier that may have its request fulfilled either natively — invoked through `navigator.credentials.get()` by a Wallet enforcing the Digital Credentials API — or by a remote handler that parses the request and generates a presentation manually MUST compose the request so it is self-contained and verifiable by a party with no prior relationship and no browser context. The governing test is: *could a Wallet that has never interacted with this Verifier verify the request and produce a correctly bound presentation from the request bytes alone?* A request composed only for the native path can silently fail this test even though a DC-API Wallet accepts it. To satisfy both paths, a Verifier:
+
+1. SHOULD use a signed request (`openid4vp-v1-signed`). It is the only request mode that carries any Verifier binding across a relay (audience via `client_id`), and it is equally valid natively. An unsigned request is fulfillable by a remote handler but binds only to the `nonce`; see [Verifier Binding](#verifier-binding).
+2. MUST make its identity and request-signing key resolvable from the request alone. The Verifier SHOULD embed its signing certificate chain in the request JWS `x5c` header, or use a `client_id` whose key material is publicly resolvable (for example a `did:` or `https:` scheme), so a handler with no prior relationship can verify the signature and confirm it matches `client_id` offline. A Verifier MUST NOT rely on a `client_id` scheme or key whose resolution depends on the invoking Web origin or on prior DC-API interaction, because neither exists on the relayed path.
+3. MUST carry every input a fulfiller needs inside the request object: the `nonce`, the `dcql_query` (including any `credential_sets` / `claim_sets` alternatives), the accepted formats and any response-encryption key in `client_metadata`, and the `exp`. A remote handler reads these directly from the request `data` — the signed request object's claims for a signed request — not from any API surface, so a value referenced only through the DC-API or a same-origin session is unavailable to it.
+4. SHOULD still set the Digital Credentials API transport members — `response_mode` (`dc_api` / `dc_api.jwt`) and `expected_origins` — for the native path, but MUST NOT make correct processing depend on them. A remote handler treats them as not applicable (it returns to `return_uri` and there is no invoking origin to pre-authorize), so a request whose only Verifier binding is `expected_origins` degrades to `nonce`-only when relayed.
+5. SHOULD, when response confidentiality through the intermediary or `return_uri` host is required, supply a response-encryption key in `client_metadata` rather than relying on the `dc_api.jwt` response mode. The encryption key is honored on both paths, independent of `response_mode`; the transport-bound encryption of `dc_api.jwt` is not used when the result is delivered to `return_uri`.
+6. SHOULD size `exp` to accommodate relay latency and Holder interaction, which take longer than a same-device interactive flow, and SHOULD rely on the freshness and uniqueness of the `nonce` for replay protection rather than on a tight `exp`; see [Verifier State and Stateless Operation](#verifier-state-and-stateless-operation).
+7. SHOULD use signature algorithms and credential formats an arbitrary Wallet can verify and produce, and SHOULD NOT over-constrain `client_metadata` to formats only a specific native Wallet implements.
+
+A request composed this way is fulfillable on either path with no change: the native Wallet enforces `expected_origins` and returns through the DC-API, while the remote handler ignores those transport members, verifies the Verifier from the embedded key material, and returns the same `{ protocol, data }` result to `return_uri`. In both cases the Verifier validates the returned presentation by its `nonce` and the binding its request mode provides.
+
+## Verifiable Presentation Delivery
+
+This phase of the protocol defines how the Agent packages the Wallet's presentation result and presents it back to the Verifier. The Agent either retries the protected route directly with a VP Artifact or uses that same VP Artifact in the OAuth token exchange described in the next leg.
+
+```http
+POST /accounts/applications HTTP/1.1
+Host: bank.example.com
+PROOF-PRESENTATION: <base64url-vp-artifact-json>
+```
+
+### VP Artifact
+
+After obtaining a [[ref: Presentation Result]], the Agent packages it as a VP Artifact for protected-route retry or OAuth token exchange. The VP Artifact carries the presentation result either inline or as a [[ref: Presentation Reference]].
+
+#### General Structure
+
+An inline VP Artifact carries the Digital Credentials API result `{ protocol, data }` directly:
+
+```json
+{
+  "request_id": "proof-template-financial-customer-v1",
+  "response": {
+    "protocol": "openid4vp-v1-signed",
+    "data": "<wallet-returned-presentation-result>"
+  }
+}
+```
+
+A by-reference VP Artifact carries a URL the Verifier dereferences to fetch the presentation result, for results that exceed header size limits or are generated at a remote location:
+
+```json
+{
+  "request_id": "proof-template-financial-customer-v1",
+  "presentation_uri": "https://bank.example.com/.well-known/x401/presentations/abc123",
+  "expires_at": "2026-05-06T18:50:00Z"
+}
+```
+
+#### Members
+
+Name | Definition
+---- | ----------
+`response` | REQUIRED unless `presentation_uri` is present. The [[ref: Presentation Result]] returned by the Wallet, as the `{ protocol, data }` object produced by the Digital Credentials API.
+`presentation_uri` | REQUIRED unless `response` is present. An HTTPS URL the Verifier dereferences with `GET` to fetch the [[ref: Presentation Result]]. The Verifier MUST issue a unique `presentation_uri` value for each presentation and MUST NOT reuse one across presentations. See [Presentation by Reference](#presentation-by-reference).
+`expires_at` | OPTIONAL. RFC 3339 time after which the `presentation_uri` is no longer valid.
+`request_id` | OPTIONAL. The x401 `request_id`, when present.
+`agent_id` | OPTIONAL. An [[ref: Agent Identifier]] for the HTTP caller, when the deployment binds the Agent to the retry. See [Agent Binding Options](#agent-binding-options).
+
+A VP Artifact MUST contain exactly one of `response` or `presentation_uri`.
+
+The Verifier MUST NOT treat the `request_id` or `agent_id` values inside the VP Artifact as authoritative by themselves. They are carried so the Verifier can correlate the retry. Correlation between the presentation and the issued request is established by the OpenID4VP `nonce` echoed inside the presentation result. The Verifier remains responsible for validating the presentation binding and, when it binds the Agent, authenticating the Agent Identifier.
+
+### Presentation by Reference
+
+A presentation result can be larger than an HTTP header field comfortably carries, and a remotely generated result may not be held by the Agent at all. For these cases the VP Artifact MAY carry a `presentation_uri` instead of an inline `response`. The Verifier dereferences the URL to obtain the same `{ protocol, data }` presentation result it would otherwise have received inline.
+
+When a VP Artifact carries `presentation_uri`:
+
+1. The `presentation_uri` MUST be an `https` URL.
+2. The Verifier MUST issue a unique `presentation_uri` for each presentation and MUST NOT reuse a URI value across presentations. Uniqueness per presentation is what lets the Verifier treat the reference as single-use and bind it to one retry.
+3. The Verifier fetches the presentation result with an HTTP `GET` and processes it exactly as if it had been supplied inline as `response`. The fetched presentation is self-authenticating — it is validated against the issued request's `nonce` and the binding its request mode provides, like any other — so a substituted or tampered result is rejected by normal proof validation without a separate integrity digest.
+4. The reference SHOULD be short-lived and scoped to the route and retry it serves.
+
+This same mechanism lets a remote fulfillment surface generate a presentation, publish it at a `presentation_uri`, and let the Agent replay the protected route with only the reference. See [Remote and Out-of-Band Fulfillment](#remote-and-out-of-band-fulfillment).
+
+### x401 Error Object
+
+When a Verifier reports that an x401 proof presentation failed or could not be processed, it returns a `PROOF-RESPONSE` header whose payload is a base64url-encoded x401 Error Object.
+
+#### General Structure
+
+```json
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "error": "invalid_presentation",
+  "error_description": "The presentation did not satisfy the route proof requirement.",
+  "request_id": "proof-template-financial-customer-v1"
+}
+```
+
+#### Members
+
+Name | Definition
+---- | ----------
+`scheme` | REQUIRED. Value MUST be the string `"x401"`.
+`version` | REQUIRED. The x401 error object version.
+`error` | REQUIRED. A verifier-defined error code. The value SHOULD be a short ASCII token suitable for logs and programmatic handling.
+`error_description` | OPTIONAL. Human-readable diagnostic text.
+`error_uri` | OPTIONAL. HTTPS URL identifying documentation for the error.
+`request_id` | OPTIONAL. The x401 `request_id`, when the error can be correlated to a proof template.
+
+The x401 Error Object describes the x401 proof branch only. The HTTP status code continues to describe the overall response.
+
+### x401 Token Object
+
+When an Agent has a Verification Token and the protected route already uses the `Authorization` request header for existing application authentication, the Agent can pass the Verification Token as an x401 Token Object in a `PROOF-PRESENTATION` header. This allows existing application credentials and x401 proof satisfaction to travel on the same request without overloading `Authorization`.
+
+#### General Structure
+
+```json
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "token_type": "Bearer",
+  "access_token": "<x401-verification-token>"
+}
+```
+
+#### Members
+
+Name | Definition
+---- | ----------
+`scheme` | REQUIRED. Value MUST be the string `"x401"`.
+`version` | REQUIRED. The x401 token object version.
+`token_type` | REQUIRED. The token type of the supplied Verification Token. For Verification Tokens defined by this specification, the value is `"Bearer"`.
+`access_token` | REQUIRED. The opaque or structured [[ref: Verification Token]] value issued to the [[ref: Agent]].
+
+The x401 Token Object carries proof satisfaction only. It does not replace the route's ordinary authorization credentials unless the deployment explicitly defines the Verification Token as an upgraded or replacement application token.
+
+### Route Retry Headers
+
+After receiving an x401 proof requirement and obtaining a presentation result, the Agent retries the protected route with either direct proof material or a reusable Verification Token.
+
+When retrying with proof material directly, the Agent uses `PROOF-PRESENTATION`:
+
+```http
+PROOF-PRESENTATION: <base64url-vp-artifact-json>
+```
+
+The `PROOF-PRESENTATION` value is the base64url-encoded UTF-8 JSON serialization of the VP Artifact, using the same no-padding encoding as the x401 payload. The VP Artifact carries the presentation result inline or as a [[ref: Presentation Reference]]; for large presentations the Agent SHOULD use the reference form to keep the header within server and intermediary size limits.
+
+When retrying with a [[ref: Verification Token]], the Agent either uses the route's normal `Authorization` request header or carries an x401 Token Object in `PROOF-PRESENTATION`.
+
+A deployment MAY issue a Verification Token that is also the route's ordinary application authorization credential, or it MAY upgrade the caller's existing application access token with x401-specific proof satisfaction metadata. In that case, the Agent sends the token using the normal token type for the route. For Verification Tokens defined by this specification, the token type is `Bearer`:
+
+```http
+Authorization: Bearer <verification-token-or-upgraded-application-token>
+```
+
+If the protected route already uses `Authorization` for existing application authentication and the x401 Verification Token is separate from that application credential, the Agent preserves the existing `Authorization` value and sends the x401 token separately:
+
+```http
+Authorization: Bearer <existing-application-token>
+PROOF-PRESENTATION: <base64url-x401-token-object>
+```
+
+A protected route MUST process the supplied `PROOF-PRESENTATION` value as a proof presentation or proof-token satisfaction attempt. If verification succeeds, the Verifier MAY return the protected resource directly.
+
+### Agent Processing Rules
+
+An Agent receiving an HTTP response with a `PROOF-REQUIRED` proof requirement:
+
+1. MUST treat the response as a proof requirement.
+2. MUST extract the `PROOF-REQUIRED` field value and base64url-decode it as a UTF-8 JSON [[ref: x401 Payload]].
+3. MUST validate the decoded payload structure and process the `proof` object.
+4. MUST treat `presentation_requirements` as the Verifier-composed [[ref: Digital Credentials Request]] and MUST NOT modify any of its entries.
+5. MUST obtain a [[ref: Presentation Result]] for `presentation_requirements` by invoking it through a native credential method, relaying it to a Wallet or remote service, or acquiring a remotely generated result.
+6. MAY select among multiple `presentation_requirements.requests` entries by protocol or supported credential format when more than one is present.
+7. MAY use `trust_establishment`, when present, to filter candidate credentials or guide acquisition.
+8. MUST NOT treat any Agent-side interpretation of the Issuer Trust List as proof of verifier acceptance.
+9. MUST package the presentation result as a VP Artifact, inline or as a [[ref: Presentation Reference]].
+10. MUST retry the same route that produced the x401 proof requirement with one of:
+    - a VP Artifact in a `PROOF-PRESENTATION` request header,
+    - a Verification Token carried as an x401 Token Object in a `PROOF-PRESENTATION` request header, or
+    - a Verification Token in the route's normal `Authorization` request header when the deployment specifies that the token is an upgraded or replacement application authorization credential.
+11. MUST NOT replace an existing application `Authorization` credential with an x401 Verification Token unless the deployment explicitly defines the returned token as valid for that route's ordinary authorization processing.
+12. MUST treat a `PROOF-RESPONSE` carrying an x401 Error Object as an x401 proof failure for the route-scoped proof attempt, regardless of the HTTP status code.
+
+### Verifier Processing Rules
+
+A Verifier implementing x401:
+
+1. MUST include `PROOF-REQUIRED: <base64url-x401-payload>` when proof is required or advertised.
+2. MUST include a valid base64url-encoded x401 payload in `PROOF-REQUIRED`.
+3. MUST use an HTTP status code appropriate for the overall response and MUST NOT rely on the status code alone to convey x401 proof state.
+4. MUST include a `presentation_requirements` whose entries are valid OpenID4VP requests for the DC API, using `openid4vp-v1-signed` (RECOMMENDED) or `openid4vp-v1-unsigned`.
+5. SHOULD use signed requests and set their `client_id` and `expected_origins`; when using unsigned requests, MUST account for the weaker binding described in [Verifier Binding](#verifier-binding).
+6. MUST include OAuth token exchange metadata in `oauth`.
+7. SHOULD provide `trust_establishment` when issuer approval policy is useful to disclose to Agents.
+8. MUST NOT enumerate verifier-approved issuers inline in the x401 payload.
+9. MUST validate presentations according to the proof validation rules in this specification and the credential format rules it relies upon, dereferencing a [[ref: Presentation Reference]] when one is supplied.
+10. MUST evaluate issuer trust, status, revocation, and policy constraints independently of any Agent-side interpretation of the Issuer Trust List.
+11. MUST accept a VP Artifact in a `PROOF-PRESENTATION` request header for protected-route retry, in both its inline and by-reference forms.
+12. MAY issue a Verification Token through the OAuth token endpoint after validating the presented VP Artifact.
+13. MUST validate Verification Tokens on protected-route retry according to token scope, audience, expiration, any Agent binding, and satisfied requirement metadata, whether the token arrives in `Authorization` or as an x401 Token Object in `PROOF-PRESENTATION`.
+14. MUST bind any Verification Token carried in `PROOF-PRESENTATION` to the existing application caller, credential, client, key, or Agent Identifier required by the protected route when an `Authorization` header is also present.
+15. SHOULD return `PROOF-RESPONSE: <base64url-x401-error-object>` if proof is presented but policy satisfaction fails or the presentation or token cannot be processed.
+16. MUST use `402 Payment Required` separately if payment is required and remains unsatisfied.
+
+### Proof Validation
+
+When a Verifier receives a VP Artifact directly on a protected-route retry or through the OAuth token endpoint, it MUST validate the presentation against the request it composed for the route. When the VP Artifact is a [[ref: Presentation Reference]], the Verifier first dereferences `presentation_uri` to obtain the presentation result, then validates that result exactly as if it had been supplied inline.
+
+The Verifier MUST:
+
+1. recover the route, method, and policy context for the request it composed, by whatever stateful or stateless means it uses;
+2. verify that the presentation proof is cryptographically protected according to the credential and presentation formats in use;
+3. verify the presentation's binding for the request's mode: for a signed request, that it is bound to the Verifier as relying party through the request signature, `client_id`, and `expected_origins`; for an unsigned request, that it is bound to the invoking origin the Verifier is willing to accept (see [Verifier Binding](#verifier-binding));
+4. verify that the presentation's OpenID4VP `nonce` is the value the Verifier issued for the request, applying its freshness and replay policy;
+5. verify that the credentials and disclosed claims satisfy the `dcql_query` carried in the request;
+6. verify issuer trust, credential status, revocation, expiration, assurance, and any additional route policy;
+7. when the deployment binds the Agent, determine and verify the [[ref: Agent Identifier]] for the HTTP caller and reject the retry if it cannot be bound; see [Agent Binding Options](#agent-binding-options).
+
+With a signed request the returned presentation is bound to the Verifier as relying party; with an unsigned request it is bound to the invoking origin and the Verifier's `nonce`, which the Verifier SHOULD reinforce as described in [Verifier Binding](#verifier-binding). In either case the presentation is not, by itself, bound to the Agent: Agent binding is OPTIONAL and, when used, is an additional check layered over this validation.
+
+## Access Token Acquisition
+
+This optional leg of the protocol defines the optional exchange of a verified VP Artifact for a reusable Verification Token. The Agent submits the VP Artifact to the OAuth token endpoint from the x401 payload using OAuth 2.0 Token Exchange, then retries protected routes with the returned token either as the route's normal authorization credential or as an x401 proof-satisfaction token object in `PROOF-PRESENTATION`.
+
+```http
+POST /oauth/token HTTP/1.1
+Host: bank.example.com
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
+subject_token_type=urn:x401:params:oauth:token-type:vp_artifact&
+subject_token=<base64url-vp-artifact-json>
+```
+
+### OAuth Token Exchange
+
+An Agent MAY exchange a VP Artifact for a [[ref: Verification Token]] at the OAuth token endpoint supplied in `oauth.token_endpoint`.
+
+The token request uses OAuth 2.0 Token Exchange. The Agent MUST use:
+
+- `grant_type=urn:ietf:params:oauth:grant-type:token-exchange`
+- `subject_token_type=urn:x401:params:oauth:token-type:vp_artifact`
+- `subject_token=<base64url-vp-artifact-json>`
+
+The Agent SHOULD include the `resource` or `audience` value from `oauth` when present. If neither value is present, the Agent MAY use the original protected resource URL as the OAuth `resource` value.
+
+```http
+POST /oauth/token HTTP/1.1
+Host: bank.example.com
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
+subject_token_type=urn:x401:params:oauth:token-type:vp_artifact&
+subject_token=<base64url-vp-artifact-json>&
+resource=https%3A%2F%2Fbank.example.com%2Faccounts%2Fapplications
+```
+
+The submitted VP Artifact MAY carry the presentation result inline or as a [[ref: Presentation Reference]]; when it is a reference, the token endpoint dereferences it as described in [Presentation by Reference](#presentation-by-reference). The token endpoint MAY require normal OAuth client authentication. If the deployment binds the Agent and client authentication is used, the authenticated OAuth client MUST bind to the same Agent Identifier the deployment requires for the retry.
+
+The token endpoint MUST process the submitted VP Artifact using the same proof validation rules that apply to direct protected-route retry. In particular, it MUST verify that:
+
+1. the presentation is cryptographically valid and bound per the request's mode — to the Verifier as relying party for a signed request, or to an acceptable invoking origin for an unsigned request;
+2. the credential material satisfies the `dcql_query` carried in the request for the requested resource;
+3. the presentation's OpenID4VP `nonce` is one the Verifier issued, applying its freshness and replay policy;
+4. when the deployment binds the Agent, the presentation and retry bind to the required Agent Identifier.
+
+If verification succeeds and the Verifier chooses token retry, the token endpoint returns an OAuth-compatible successful access token response:
+
+```http
+HTTP/1.1 200 OK
+Content-Type: application/json
+Cache-Control: no-store
+Pragma: no-cache
+```
+
+For Verification Tokens defined by this specification, the token endpoint MUST return `token_type` with the value `Bearer`.
+
+```json
+{
+  "access_token": "eyJhbGciOi...",
+  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
+  "token_type": "Bearer",
+  "expires_in": 300,
+  "scope": "accounts:open",
+  "x401": {
+    "agent_id": "did:web:agent.example",
+    "verifier_id": "https://bank.example.com",
+    "request_id": "proof-template-financial-customer-v1",
+    "satisfied_requirements": [
+      "urn:example:x401:satisfaction:financial-customer:v1"
+    ],
+    "resource": "https://bank.example.com/accounts/applications",
+    "method": "POST",
+    "expires_at": "2026-05-06T18:50:00Z"
+  }
+}
+```
+
+Name | Definition
+---- | ----------
+`access_token` | REQUIRED. The opaque or structured [[ref: Verification Token]] value issued to the [[ref: Agent]].
+`issued_token_type` | RECOMMENDED. Token type of the issued token. For Bearer access tokens, use `urn:ietf:params:oauth:token-type:access_token`.
+`token_type` | REQUIRED. The HTTP authorization scheme the Agent uses with the token. The value defined by this specification is `Bearer`.
+`expires_in` | RECOMMENDED. Lifetime of the token in seconds from the time the response is generated.
+`scope` | OPTIONAL. OAuth scope string representing access authorized by the token.
+`x401` | RECOMMENDED. Object containing x401-specific token metadata that helps the Agent and Verifier understand what proof requirements were satisfied.
+
+#### Verification Token Retry Placement
+
+A Verification Token can be placed in either `Authorization` or `PROOF-PRESENTATION`, depending on how the deployment composes x401 with existing application authorization.
+
+If the Verifier, authorization server, and protected application are integrated, the token endpoint MAY issue a token that is accepted as the route's normal application authorization credential. This can be a new token or an upgraded version of an existing application token that includes x401-specific proof satisfaction metadata. In that model, the Agent sends the returned token through the normal authorization mechanism for the route:
+
+```http
+Authorization: Bearer <verification-token-or-upgraded-application-token>
+```
+
+If the protected route already requires an application token in `Authorization`, and the x401 Verification Token is separate from that application token, the Agent SHOULD preserve the existing `Authorization` value and send the Verification Token as an x401 Token Object in `PROOF-PRESENTATION`:
+
+```http
+Authorization: Bearer <existing-application-token>
+PROOF-PRESENTATION: <base64url-x401-token-object>
+```
+
+When processing a `PROOF-PRESENTATION` value that carries an x401 Token Object, the Verifier MUST decode the x401 Token Object, validate the contained Verification Token, and evaluate whether the token satisfies the route's x401 proof requirement. If an `Authorization` header is also present, the Verifier MUST ensure that the application credential and the x401 Verification Token are bound to the same Agent Identifier, client, subject, proof-of-possession key, certificate, or other verifier-accepted caller binding for the route. A Verifier MUST reject a request that combines an application credential and x401 Verification Token that cannot be safely bound to the same accepted caller context.
+
+#### Verification Token Contents
+
+A [[ref: Verification Token]] records the Verifier's decision that a presentation satisfied an x401 proof requirement. It is not a credential, payment artifact, or new issuer attestation about the credential subject.
+
+A Verifier MAY issue a Verification Token after accepting a VP Artifact. The token:
+
+1. when the deployment binds the Agent, MUST be issued to the [[ref: Agent Identifier]] bound during the retry, and MUST NOT rely on the credential subject as the token holder identity unless the credential subject is also the Agent;
+2. MUST be scoped to the Verifier audience and to the route, policy, action, resource, or resource class for which proof was accepted;
+3. MUST expire, and SHOULD be short-lived;
+4. SHOULD include a unique token identifier and support replay detection and revocation;
+5. SHOULD identify the `request_id` and `satisfied_requirements` accepted by the Verifier;
+6. SHOULD identify the Verifier identifier, resource, method, and proof time used to issue the token.
+
+When a Verification Token is represented as a JWT, its exact claim set is deployment-specific. The token SHOULD include:
+
+- `iss` identifying the Verifier or authorization server;
+- `sub` identifying the Agent, when the deployment binds the Agent;
+- `aud` identifying the protected resource server or Verifier audience;
+- `exp`, `iat`, and `jti`;
+- `client_id` identifying the Agent when useful for OAuth infrastructure;
+- `scope`, `resource`, or method/action claims used for access decisions;
+- `x401_request_id`;
+- `x401_satisfied_requirements`;
+- `x401_query_hash` or a verifier-defined reference to the credential query that was satisfied.
+
+#### Reuse Across Routes
+
+OpenID4VP `state`, presentation `nonce`, and DCQL Credential Query `id` values are useful for request-response correlation, holder binding, or wallet-facing query selection inside a single presentation transaction. They are not, by themselves, stable semantic identifiers for cross-route token reuse.
+
+x401 uses `request_id` and `satisfied_requirements` for reusable proof semantics. A Verifier MAY accept a Verification Token issued for one route on another route only when:
+
+1. the token is valid for the Verifier audience and current protected resource;
+2. the token has not expired or been revoked;
+3. when the deployment binds the Agent, the token is issued to the current Agent Identifier;
+4. the token's accepted proof requirements cover the later route's `satisfied_requirements`;
+5. any freshness, status, assurance, and policy constraints still hold.
+
+Agents MAY use the `x401.satisfied_requirements` metadata returned with a Verification Token to decide whether to try the token on a later route. The Verifier remains authoritative and SHOULD return a new x401 proof requirement when the token is valid but does not satisfy the later route.
+
+## Examples
+
+### Example 1: Proof Requirement
+
+#### Initial Request
+
+```http
+POST /accounts/applications HTTP/1.1
+Host: bank.example.com
+```
+
+#### Response
+
+```http
+HTTP/1.1 401 Unauthorized
+PROOF-REQUIRED: <base64url-x401-payload>
+Cache-Control: no-store
+```
+
+Decoded x401 payload, shown for readability:
+
+```json
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "presentation_requirements": {
+    "requests": [
+      {
+        "protocol": "openid4vp-v1-signed",
+        "data": {
+          "request": "eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWF1dGh6LXJlcStqd3QifQ..."
+        }
+      }
+    ]
+  },
+  "oauth": {
+    "token_endpoint": "https://bank.example.com/oauth/token"
+  },
+  "trust_establishment": "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"
+  ]
+}
+```
+
+The signed OpenID4VP request inside `presentation_requirements.requests[0].data.request`, decoded for readability, is authored and signed by the Verifier:
+
+```json
+{
+  "response_type": "vp_token",
+  "response_mode": "dc_api",
+  "client_id": "x509_san_dns:bank.example.com",
+  "expected_origins": ["https://bank.example.com"],
+  "nonce": "uX7Vq3mZJH6MeN0qz2L7SQ",
+  "dcql_query": {
+    "credentials": [
+      {
+        "id": "financial_customer",
+        "format": "jwt_vc_json",
+        "meta": {
+          "type_values": ["FinancialCustomerCredential"]
+        },
+        "claims": [
+          {
+            "path": ["credentialSubject", "assurance_level"],
+            "values": ["VC-AL2", "VC-AL3"]
+          }
+        ]
+      }
+    ]
+  },
+  "exp": 1746557100
+}
+```
+
+#### Obtaining the Presentation
+
+The Agent invokes the Verifier-composed request directly through the Digital Credentials API, or relays it to a Wallet or remote service. The composed request is the `digital` member argument:
+
+```js
+const result = await navigator.credentials.get({ digital: payload.presentation_requirements });
+// result => { protocol: "openid4vp-v1-signed", data: { /* presentation result bound to the Verifier */ } }
+```
+
+#### Successful Retry With VP Artifact
+
+```http
+POST /accounts/applications HTTP/1.1
+Host: bank.example.com
+PROOF-PRESENTATION: <base64url-vp-artifact-json>
+```
+
+The decoded VP Artifact carries the presentation result inline:
+
+```json
+{
+  "request_id": "proof-template-financial-customer-v1",
+  "response": {
+    "protocol": "openid4vp-v1-signed",
+    "data": "<wallet-returned-presentation-result>"
+  }
+}
+```
+
+#### Successful Retry With a Presentation Reference
+
+When the presentation result is too large for a header field, or was generated at a remote location, the VP Artifact carries a reference the Verifier dereferences:
+
+```json
+{
+  "request_id": "proof-template-financial-customer-v1",
+  "presentation_uri": "https://bank.example.com/.well-known/x401/presentations/abc123",
+  "expires_at": "2026-05-06T18:50:00Z"
+}
+```
+
+#### Failed Retry With x401 Error
+
+```http
+HTTP/1.1 401 Unauthorized
+PROOF-RESPONSE: <base64url-x401-error-object>
+Cache-Control: no-store
+```
+
+The decoded x401 Error Object describes the failed proof presentation. The `401 Unauthorized` status in this example means the route was not completed because the x401 proof branch failed.
+
+### Example 2: OAuth Token Exchange
+
+After receiving the Wallet presentation result, the Agent may exchange the VP Artifact for a token.
+
+```http
+POST /oauth/token HTTP/1.1
+Host: bank.example.com
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
+subject_token_type=urn:x401:params:oauth:token-type:vp_artifact&
+subject_token=<base64url-vp-artifact-json>&
+resource=https%3A%2F%2Fbank.example.com%2Faccounts%2Fapplications
+```
+
+If verification succeeds, the token endpoint returns:
+
+```json
+{
+  "access_token": "eyJhbGciOi...",
+  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
+  "token_type": "Bearer",
+  "expires_in": 300,
+  "scope": "accounts:open",
+  "x401": {
+    "agent_id": "did:web:agent.example",
+    "verifier_id": "https://bank.example.com",
+    "request_id": "proof-template-financial-customer-v1",
+    "satisfied_requirements": [
+      "urn:example:x401:satisfaction:financial-customer:v1"
+    ],
+    "resource": "https://bank.example.com/accounts/applications",
+    "method": "POST"
+  }
+}
+```
+
+If the returned token is an upgraded or replacement application authorization credential, the Agent retries the original protected route with the token in `Authorization`:
+
+```http
+POST /accounts/applications HTTP/1.1
+Host: bank.example.com
+Authorization: Bearer eyJhbGciOi...
+```
+
+If the application already requires an existing `Authorization` token and the x401 Verification Token is separate, the Agent preserves the application token and carries the x401 Verification Token as an x401 Token Object in `PROOF-PRESENTATION`:
+
+```http
+POST /accounts/applications HTTP/1.1
+Host: bank.example.com
+Authorization: Bearer <existing-application-token>
+PROOF-PRESENTATION: <base64url-x401-token-object>
+```
+
+## Composable Agent and Entity Identification
+
+A returned presentation is already bound to the Verifier (for a signed request) or to the invoking origin and the Verifier's nonce (for an unsigned request); see [Verifier Binding](#verifier-binding). x401 does not, by default, require the presentation to be bound to the Agent, and it does not define a single global agent identity system. Deployments MAY layer additional mechanisms over x401 to authenticate the calling agent, bind an entity identity to the HTTP request, sender-constrain a Verification Token, or carry delegation evidence from a user, organization, workload, or upstream agent.
+
+These mechanisms compose cleanly with x401 when they:
+
+1. produce an authenticated caller identifier the Verifier can map to the route's accepted Agent Identifier policy;
+2. bind that identifier to the HTTP request being evaluated, including the method, target URI or authority, freshness values, and relevant x401 retry material;
+3. can be verified before or during x401 proof validation;
+4. do not alter the composed request in `presentation_requirements`, the VP Artifact, or the `402 Payment Required` boundary;
+5. allow the Verifier to reject mismatches between the authenticated caller, any VP Artifact `agent_id`, and any Verification Token holder identity.
+
+### Agent Binding Options
+
+Agent binding is OPTIONAL in x401. Some deployments — such as a consumer AI client surfacing a verification link to a user — need no agent binding at all; the proof is bound to the Verifier and that is sufficient. Others — such as service-to-service or enterprise deployments — want to additionally bind the proof and retry to the specific calling Agent. This specification does not select a single mechanism. The subsections below describe options that compose with x401; a deployment that binds the Agent picks one (or more) and defines the accepted [[ref: Agent Identifier]] schemes in its policy.
+
+When an Agent relays the request to a separate wallet, browser, device, or remote service, or acquires a remotely generated [[ref: Presentation Result]], the surface that obtains the result is not necessarily the Agent that retries the route. A deployment that binds the Agent in those topologies MUST choose a binding mechanism that survives the relay — for example, an HTTP-layer or token-layer caller authentication on the retry — rather than relying on the presentation result alone.
+
+### Web Bot Auth and HTTP Message Signatures
+
+Web Bot Auth is a natural option for adding request-bound identification to x401. A calling Agent can sign the initial protected-route request, the retry request carrying a VP Artifact or Verification Token, and the OAuth token exchange request using HTTP Message Signatures. The Agent can also use the `Signature-Agent` header to point the Verifier to an HTTP Message Signatures key directory.
+
+When layered over x401, a Web Bot Auth signature SHOULD cover the method and target, the authority or host, the `Signature-Agent` header when present, the `PROOF-PRESENTATION` header when retrying with direct proof or proof-token material, the `Authorization` header when retrying with application or upgraded token material, and `Content-Digest` when the request has a body. The signature SHOULD include short-lived freshness metadata such as `created`, `expires`, and a replay-resistant `nonce`.
+
+A Verifier MAY use the validated signing key, key directory authority, or derived service identity as the Agent Identifier, or as evidence that maps to an Agent Identifier. The Verifier MUST still validate the Wallet presentation binding for the request mode, the credential query satisfaction, issuer trust, token scope, and payment boundary. Web Bot Auth identifies the calling automation or service; it does not by itself prove the credential subject, satisfy the credential query, or prove end-user delegation.
+
+### OAuth Proof-of-Possession and Client Authentication
+
+Deployments that use the OAuth token exchange leg MAY require additional OAuth client authentication at `oauth.token_endpoint`. Mutual TLS client authentication and certificate-bound access tokens can bind the token request, and later token use, to a certificate controlled by the Agent. This works well when the Agent Identifier is a certificate-bound identifier, domain-bound client identifier, SPIFFE ID, or other identifier that the Verifier can map from the TLS client certificate.
+
+DPoP can bind OAuth token requests and resource requests to an Agent-controlled key at the application layer. Because this version of x401 defines Bearer Verification Tokens, a DPoP-bound Verification Token retry needs either a deployment-specific profile or a future x401 token retry profile that permits `token_type: DPoP` and the `DPoP` proof header. When a deployment binds the Agent and uses DPoP at the token endpoint, the endpoint MUST ensure the DPoP key maps to the Agent Identifier the deployment requires for the retry.
+
+### Workload Identity
+
+In service-to-service deployments, the Agent may be a workload rather than a user-facing application. The Agent Identifier can be derived from a workload identity mechanism such as a SPIFFE ID carried in an X.509-SVID or JWT-SVID, or from WIMSE work on workload identity tokens and HTTP Message Signatures. These mechanisms are useful for infrastructure agents, internal tools, and managed compute environments where the Verifier needs to know which deployed workload made the request.
+
+Workload identity proves the caller's operational identity. It does not prove that the caller holds the requested credential, that the credential subject is authorized, or that an end user delegated authority to the Agent. Those remain x401 proof validation and policy questions.
+
+### Agent Identifier Schemes and HTTP-Layer Binding
+
+In the composed-request model the presentation request never identifies the Agent: for a signed request the `client_id` identifies the Verifier as relying party, and an unsigned request has no `client_id` at all. A deployment that binds the Agent therefore does so at the HTTP or token layer rather than through the presentation request. The [[ref: Agent Identifier]] MAY be a DID, HTTPS origin, domain-bound client identifier, certificate-bound identifier, SPIFFE ID, or other verifier-approved scheme.
+
+The Verifier determines that the protected-route caller is the required Agent Identifier using a verifier-recognized mapping across the HTTP Message Signature identity, mutual TLS certificate, DPoP key, workload identity, or Verification Token holder identity used on the retry. Because the presentation is bound to the Verifier, this caller binding is what ties the proof to a specific Agent when a deployment requires it.
+
+### Delegation and Actor Evidence
+
+Some deployments need to know not only which Agent made the request, but who or what authorized that Agent to act. Delegation evidence can be carried as an additional credential, a credential disclosed through the request's `dcql_query`, an OAuth Token Exchange actor chain, a GNAP grant artifact, a Verifiable Intent credential, or another signed mandate or capability.
+
+Delegation evidence composes best when it is scoped, time-limited, replay-resistant, and bound to the Agent Identifier and requested resource or action. It does not replace caller authentication: the Verifier still needs to know which Agent is presenting the delegation evidence and whether that Agent is the one authorized by the evidence.
+
+## Consumer Client Compatibility
+
+::: note Experimental
+The mechanism in this section is an early experiment in adapting x401 to consumer AI clients and other body-only consumers of HTTP responses. The core x401 protocol — as defined in the preceding sections — is the standard, straightforward way to convey proof requirements: a Verifier returns a `PROOF-REQUIRED` header, and the Agent reads, decodes, and acts on it. The pattern described below is offered as a compatibility supplement for content-bearing responses where header-driven discovery is not viable, and the community is invited to contribute proposals, examples, and reference implementations that improve how x401 reaches these clients.
+:::
+
+x401 is fundamentally an HTTP header protocol. A conforming Verifier signals proof requirements through `PROOF-REQUIRED`, and a conforming Agent processes that header. There is, however, a meaningful class of consumers that today cannot reliably access HTTP response headers on a successful (`2xx`) response with a body. A Verifier that wants its gating requirements to reach those consumers — most notably consumer-facing AI assistants — MAY emit a body-embedded form of the same x401 payload in addition to whatever it carries in `PROOF-REQUIRED`.
+
+### Motivation
+
+Several common client classes do not surface `PROOF-REQUIRED` on a successful response with a body:
+
+- Consumer-facing AI assistants from major platforms typically fetch web content through summarization or browsing tools that surface the response body to the model but drop, hide, or do not propagate the HTTP headers of `2xx` responses. As a result, a proof requirement carried only in `PROOF-REQUIRED` on a successful HTML response will not reach the model.
+- HTML documents rendered in a browser do not expose response headers to inline content unless application code reads them through JavaScript and re-injects them into the DOM.
+- Archival, syndication, and feed-rendering tools often store or render the body without preserving headers.
+
+A Verifier that wants its gating requirements to be discoverable by these consumer AI flows or other body-only clients SHOULD strongly consider embedding the proof requirement in the response body using the form defined below, in addition to setting `PROOF-REQUIRED` on the same response.
+
+### Embedded Proof Requirements in HTML Content
+
+On a non-`401` HTML response, the Verifier MAY emit each advertised x401 proof requirement as a single HTML `<data>` element placed in the document body at, near, or wrapping the content to which the requirement applies. The element:
+
+1. MUST use the tag name `data`.
+2. MUST set the `value` attribute to the MIME-type expression `application/json;x401=proof-required`. The `x401` parameter identifies the embedded carrier and signals the role of the element's text content.
+3. MUST set the `hidden` attribute so the element is not visually rendered.
+4. MUST contain a single JSON object as its text content. The JSON object MUST be a valid x401 payload as defined in [x401 Payload](#x401-payload), and MUST include a `$schema` member whose value is the JSON Schema URL for the x401 request object, `https://x401.id/spec/schemas/request.json`. The `$schema` member is an informational marker that allows AI scrapers, content processors, and validators that retain only the JSON object to recognize it as an x401 proof requirement without prior knowledge of the surrounding HTML carrier.
+
+```html
+<data value="application/json;x401=proof-required" hidden>{
+  "$schema": "https://x401.id/spec/schemas/request.json",
+  "scheme": "x401",
+  "version": "0.2.0",
+  "presentation_requirements": {
+    "requests": [
+      {
+        "protocol": "openid4vp-v1-signed",
+        "data": {
+          "request": "eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWF1dGh6LXJlcStqd3QifQ..."
+        }
+      }
+    ]
+  },
+  "oauth": {
+    "token_endpoint": "https://bank.example.com/oauth/token"
+  }
+}</data>
+```
+
+Unlike the `PROOF-REQUIRED` header value, the embedded form is the unencoded JSON object. The `<data>` element is already a text container, and the `$schema` member is intended to be directly readable by content processors that retain the object.
+
+### Placement and Scope
+
+A `<data>` element placed at the document level applies to the page as a whole and SHOULD be used as a body-side mirror of the route-scoped `PROOF-REQUIRED` header so that header-blind clients can still discover the requirement. A response MAY include multiple `<data value="application/json;x401=proof-required" hidden>` elements when a page surfaces multiple advertised requirements; each element MUST be a complete, independent x401 payload that can be processed without reference to the others.
+
+The embedded form does not extend `PROOF-REQUIRED` semantics. The header continues to carry the route-scoped requirement for the entire response. A `<data>` element is a body-side disclosure intended for clients that cannot consume the header.
+
+### Processing Expectations
+
+A client that processes embedded `<data>` elements:
+
+1. MUST treat the parsed JSON object as an x401 payload subject to the same structural validation and composed-request processing defined elsewhere in this specification.
+2. SHOULD treat the embedded requirement as a disclosure of gating intent for the surrounding content and SHOULD complete the protocol by requesting the appropriate protected resource through normal x401 header-driven mechanisms.
+
+A Verifier that emits embedded `<data>` elements MUST still enforce proof on the protected resource through the normal `PROOF-REQUIRED` / `PROOF-PRESENTATION` exchange. Embedding a requirement in HTML is informational disclosure and does not by itself grant access.
+
+The JSON Schema for the embedded request object is included in [Appendix C: x401 Request Object JSON Schema](#appendix-c-x401-request-object-json-schema).
+
+### Remote and Out-of-Band Fulfillment
+
+::: note Informative
+This subsection describes, without adding new normative requirements, how the building blocks defined above let an Agent obtain a presentation when its own environment cannot invoke the Digital Credentials API — the common case for consumer AI clients. It uses only mechanisms already defined in this specification: the composed `presentation_requirements`, the [[ref: Presentation Reference]] form of the VP Artifact, and the existing retry. The community is invited to contribute concrete fulfillment and resume patterns.
+:::
+
+A consumer AI client may be unable to call `navigator.credentials.get()` itself. Because the composed request is signed and bound to the Verifier rather than to whoever invokes it, the request can be invoked somewhere else and the result returned to the Agent for replay. A common shape is:
+
+1. The Agent receives the x401 proof requirement and cannot invoke `presentation_requirements` directly.
+2. The Agent surfaces a fulfillment URL — for example, a verifier-hosted page — to the user. Hosting the page on a verifier-controlled origin lets the page's origin match the `expected_origins` of a signed request; an unsigned request avoids the `expected_origins` constraint at the cost described in [Verifier Binding](#verifier-binding).
+3. The page invokes `navigator.credentials.get({ digital: request })` in its own browser context, on a real user activation, and obtains the presentation result.
+4. The page makes the result available for the route retry — for example, by posting it to the Verifier, which holds it at a `presentation_uri`, or by returning a short-lived reference.
+5. The Agent resumes: it acquires the result or its reference and retries the protected route with a VP Artifact carrying the inline result or a [[ref: Presentation Reference]].
+
+How the Agent learns that fulfillment is complete and acquires the result or reference — polling a status endpoint, a user-pasted completion code, or a continuation URL — is a deployment choice. None of these resume mechanisms change the wire format defined by this specification; they all converge on the same protected-route retry. Because the presentation is bound to the Verifier, the surface that invokes the request does not need to be the Agent, and the Agent does not need to read the presentation it relays.
+
+## Security Considerations
+
+### Replay Prevention
+
+The freshness and replay properties of a presentation derive from the OpenID4VP `nonce` the Verifier places in the signed request. Verifiers SHOULD use fresh nonce values and short request expiries and SHOULD reject stale or replayed proofs. How a Verifier recognizes a returned nonce as one it issued, and whether it enforces strict one-time use with shared replay state, are deployment decisions; see [Verifier State and Stateless Operation](#verifier-state-and-stateless-operation).
+
+### Verifier Binding
+
+x401 binds a presentation to the Verifier in one of two ways, depending on the request mode the Verifier chose.
+
+**Signed requests (`openid4vp-v1-signed`, RECOMMENDED).** The request signature and `client_id` let the Wallet authenticate the Verifier and bind the presentation's audience to the Verifier's identity, and `expected_origins` lets the Verifier pre-authorize the origin(s) from which the request may be invoked. This resists relay and phishing: a Wallet will not produce a presentation for the Verifier's request unless it is invoked from an origin the Verifier authorized, so an attacker cannot harvest a presentation for the Verifier from an arbitrary origin. The cost is that the Verifier must know the invocation origin in advance — which is why, when the Agent's own origin is not known, the request is invoked from a verifier-controlled fulfillment origin (see [Remote and Out-of-Band Fulfillment](#remote-and-out-of-band-fulfillment)).
+
+**Unsigned requests (`openid4vp-v1-unsigned`).** There is no signature and no `client_id`; the Wallet uses the invoking origin as the relying-party identity and binds the presentation to that origin and the Verifier's `nonce`. This lets the request be fulfilled at an origin the Verifier did not declare — the case signed requests cannot serve — at a real cost: the Wallet cannot authenticate the Verifier, and the Verifier cannot pre-authorize the invocation origin. A malicious page or relay that obtains the request can invoke it from its own origin in front of a different holder and relay the resulting presentation back, so a Verifier that accepts an unsigned presentation on the strength of the `nonce` alone is exposed to credential harvesting and relay. A Verifier that uses unsigned requests therefore relies on the freshness and uniqueness of its `nonce` for replay protection and SHOULD compensate for the missing origin pre-authorization — for example by binding the proof to an authenticated Agent (see [Agent Binding Options](#agent-binding-options)), by constraining the observed invocation origin, or by trusting the delivery channel.
+
+**Relayed delivery.** When the request is fulfilled by a remote handler that does not invoke the Digital Credentials API (see [Relayed Delivery to a Remote Handler](#relayed-delivery-to-a-remote-handler)), there is no invoking Web origin, so `expected_origins` is not enforced regardless of request mode. A *signed* request still binds the presentation's audience to the Verifier through its `client_id`, so relayed delivery of a signed request preserves Verifier audience binding and loses only origin pre-authorization — strictly stronger than unsigned. A *unsigned* request relayed this way has no `client_id` and falls back to `nonce`-only binding. Either way the Verifier SHOULD compensate for the absent origin pre-authorization as it would for an unsigned request.
+
+In all modes the Verifier MUST validate the binding its request mode and transport provide and MUST reject a presentation it cannot bind to the request it issued. The `nonce` provides freshness and correlation throughout; it does not, by itself, authenticate the Verifier or constrain the invocation origin.
+
+### Agent Binding
+
+Agent binding is OPTIONAL. The presentation is bound to the Verifier, not to the Agent, so a deployment that does not bind the Agent still has a presentation it can trust. A deployment that additionally wants to tie the proof and retry to a specific Agent layers an HTTP-layer or token-layer caller authentication over x401; see [Agent Binding Options](#agent-binding-options). When a deployment binds the Agent, it MUST reject a retry whose caller cannot be bound to the required [[ref: Agent Identifier]]. Because the surface that invokes the request may differ from the Agent that retries the route, a binding mechanism that depends only on the presentation result is insufficient in relay and remote-fulfillment topologies.
+
+### Presentation by Reference
+
+A `presentation_uri` is a capability-style reference: possession of the URL is enough to retrieve the presentation. The Verifier MUST issue a unique URI per presentation, and SHOULD make it `https`, unguessable, short-lived, single-use, and scoped to the route and retry it serves; the URL SHOULD be treated as sensitive because it can leak through logs, history, and intermediaries. Because the Verifier issues these references, it SHOULD dereference only URIs it recognizes as its own, which also guards against being pointed at arbitrary locations; it SHOULD bound the response size and time of the fetch. A reference that is reused, expired, or unrecognized MUST be rejected. Integrity and authenticity of the fetched bytes do not depend on a separate digest: the presentation is validated against the issued request's `nonce` and the binding its request mode provides, so a substituted or tampered result fails normal proof validation.
+
+### Issuer Trust
+
+Acquisition hints MUST NOT be treated as sufficient trust material. Verifiers MUST apply their own trusted issuer policy and validation logic.
+
+When a x401 payload includes `trust_establishment`, that URL identifies the DIF Credential Trust Establishment document for the proof requirement. The document is an acquisition and discovery hint; it does not decide validity. Issuer constraints that must hold at presentation time belong in the request's DCQL `trusted_authorities`, and the Verifier MUST independently validate that presented credentials were issued by parties approved under that request and its own issuer policy. The Verifier MUST NOT rely on the Agent's interpretation of the Issuer Trust List.
+
+### Proof Presentation and Token Retry
+
+Verifiers SHOULD prefer Verification Token retry in multi-step flows to avoid repeatedly transmitting large VP Artifacts. Verifiers that accept direct VP retry SHOULD consider header size limits and SHOULD use compact or referenced proof formats where possible.
+
+Responses carrying fresh `PROOF-REQUIRED` challenge material or `PROOF-RESPONSE` diagnostics SHOULD use `Cache-Control: no-store` unless the deployment has explicitly made the x401 payload safe to cache. Responses whose selected representation varies based on a `PROOF-PRESENTATION` request header SHOULD use `Vary: PROOF-PRESENTATION` or stronger cache controls.
+
+The x401 payload is visible to the Agent and to intermediaries that can observe decrypted HTTP traffic. A Verifier that encodes state in the request `nonce` to operate statelessly SHOULD protect that state with a signature, MAC, or authenticated encryption so it cannot be forged or read.
+
+### Verification Token Scope
+
+Verification Tokens SHOULD be short-lived, revocable, and scoped to the accepted x401 proof requirement. When a deployment binds the Agent, a Verifier that issues a token MUST identify the Agent as the token holder and MUST NOT treat the credential subject as the token holder unless the credential subject is also the Agent.
+
+### Payment Separation
+
+Implementations MUST keep proof and payment semantics separate. A proof artifact MUST NOT be treated as payment, and payment satisfaction MUST NOT be treated as proof satisfaction.
+
+## Privacy Considerations
+
+### Data Minimization
+
+Verifiers SHOULD request the minimum attributes or predicates necessary for access control.
+
+### Selective Disclosure
+
+Implementations SHOULD prefer credential formats and proof methods that support selective disclosure or predicate proofs where available.
+
+### Correlation Risk
+
+Repeated use of the same credential or issuer across multiple routes may introduce correlation risk. Implementers SHOULD consider verifier-specific or minimally identifying proof mechanisms where available.
+
+## IANA Considerations
+
+This draft does not yet request any IANA registrations.
+
+## Conformance
+
+A conforming x401 Verifier:
+
+- includes `PROOF-REQUIRED: <base64url-x401-payload>` when proof is required or advertised
+- treats the HTTP status code as the overall response status, not as the x401 protocol carrier
+- returns a valid base64url-encoded x401 payload in `PROOF-REQUIRED`
+- includes a composed Digital Credentials request at `presentation_requirements` whose every entry is a valid OpenID4VP request for the DC API, using `openid4vp-v1-signed` (RECOMMENDED) or `openid4vp-v1-unsigned`
+- for signed requests, sets the `client_id` and `expected_origins` that make the Verifier the relying party; for unsigned requests, accounts for the weaker binding per [Verifier Binding](#verifier-binding)
+- includes an OAuth token endpoint for VP Artifact token exchange
+- validates presentations for the binding the request mode provides, credential query satisfaction, nonce freshness, issuer trust, status, revocation, and route policy
+- accepts VP Artifacts in `PROOF-PRESENTATION: <base64url-vp-artifact-json>` in both inline and by-reference forms, dereferencing a Presentation Reference when supplied
+- accepts Verification Tokens as x401 Token Objects in `PROOF-PRESENTATION: <base64url-x401-token-object>` when x401 proof satisfaction is separate from existing application authorization
+- binds x401 Verification Tokens to the same caller context as any existing application authorization credential present on the request
+- returns `PROOF-RESPONSE: <base64url-x401-error-object>` when reporting x401 proof presentation or token errors
+- optionally includes a DIF Credential Trust Establishment URL for issuer trust and acquisition guidance
+- keeps payment separate under `402 Payment Required`
+
+A conforming x401 Agent:
+
+- recognizes `PROOF-REQUIRED`
+- decodes and processes the x401 payload from the `PROOF-REQUIRED` field value
+- treats `presentation_requirements` as the Verifier-composed Digital Credentials request and does not modify it
+- obtains a presentation result for `presentation_requirements` by invoking it through a native credential method, relaying it to a Wallet or remote service, or acquiring a remotely generated result
+- packages the presentation result as a VP Artifact, inline or as a Presentation Reference
+- retries the same protected route that produced the x401 proof requirement with `PROOF-PRESENTATION` carrying a VP Artifact, `PROOF-PRESENTATION` carrying an x401 Token Object, or a deployment-defined upgraded `Authorization` token
+- preserves existing application `Authorization` credentials when carrying a separate x401 Verification Token as an x401 Token Object in `PROOF-PRESENTATION`
+- recognizes x401 Error Objects in `PROOF-RESPONSE` as x401 proof failures regardless of the HTTP status code
+- treats Issuer Trust List interpretation as advisory until the Verifier validates the presentation
+- supports separate handling of `402 Payment Required`
+
+## Open Questions & Future Additions
+
+The items below are questions intentionally left open at the time of the initial release of this specification. The community is invited to contribute concrete proposals, start discussions, provide examples, create interop profiles, add test vectors, and submit reference implementations so future versions of x401 can turn the right patterns into a robust protocol that accounts for all necessary concerns.
+
+### Machine Payments and 402
+
+How should x401 compose with machine-payment protocols that use `402 Payment Required`? Future work should define recommended sequencing for proof-first, payment-first, and parallel proof/payment flows while preserving the current boundary that x401 handles proof and `402` handles payment.
+
+Open design questions include how a payment artifact should be bound to the x401 route, method, request nonce, any Agent Identifier, and payment quote; whether a `402` response should reference the same proof context as the earlier x401 response; how proof freshness and payment settlement freshness interact; and how protocols such as x402, AP2, ACP, or UCP should carry or reference x401 proof satisfaction without redefining it.
+
+### Fully Autonomous Delegation
+
+How can a Holder fully delegate identity or proof capability to an Agent so the Agent can satisfy x401 proof requirements without per-request human or Wallet interaction? The current working assumption is that this could be addressed by Verifiable Intent or a similar signed delegation artifact that gives an Agent Identifier bounded authority to act within a user-approved scope.
+
+Future work should specify how such a delegation is created, presented, constrained, revoked, audited, and bound to the Agent's request-signing key. It should also answer whether delegated proof is represented as a credential requested by DCQL, as a companion artifact to the VP Artifact, as OAuth or GNAP delegation state, or as a separate profile layered above x401.
+
+### Adding Agent Authentication
+
+When is agent binding necessary on top of x401? The base protocol binds the returned presentation to the Verifier as relying party and makes Agent binding OPTIONAL; see [Agent Binding Options](#agent-binding-options). Some deployments need no Agent binding at all; others may bind pairwise, ephemeral, enterprise-local, or token-bound Agent Identifiers, or require Web Bot Auth, HTTP Message Signatures, mutual TLS, DPoP, SPIFFE, WIMSE, DID-based authentication, or another caller-authentication profile.
+
+Future work should define when Agent binding is mandatory, how a Verifier advertises acceptable caller-authentication mechanisms in or near the x401 proof requirement, which status codes and headers are used when caller authentication is missing, and how mismatches are reported across HTTP caller identity, VP Artifact `agent_id`, Verification Token holder identity, and delegation evidence.
+
+## References
+
+### Normative
+
+- [RFC 9110: HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110)
+- [RFC 2119: Key words for use in RFCs to Indicate Requirement Levels](https://datatracker.ietf.org/doc/html/rfc2119)
+- [RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words](https://datatracker.ietf.org/doc/html/rfc8174)
+- [RFC 4648: The Base16, Base32, and Base64 Data Encodings](https://datatracker.ietf.org/doc/html/rfc4648)
+- [RFC 6749: The OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749)
+- [RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://datatracker.ietf.org/doc/html/rfc6750)
+- [RFC 7519: JSON Web Token](https://datatracker.ietf.org/doc/html/rfc7519)
+- [RFC 8414: OAuth 2.0 Authorization Server Metadata](https://datatracker.ietf.org/doc/html/rfc8414)
+- [RFC 8693: OAuth 2.0 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693)
+- [RFC 9101: OAuth 2.0 JWT-Secured Authorization Request (JAR)](https://datatracker.ietf.org/doc/html/rfc9101)
+- [OpenID for Verifiable Presentations 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0-final.html), including its profile for use over the W3C Digital Credentials API
+- [OpenID for Verifiable Credential Issuance 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html)
+- [W3C Digital Credentials API](https://www.w3.org/TR/digital-credentials/)
+- [DIF Credential Trust Establishment 1.0](https://identity.foundation/credential-trust-establishment/)
+
+### Informative
+
+- [RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens](https://datatracker.ietf.org/doc/html/rfc8705)
+- [RFC 9421: HTTP Message Signatures](https://datatracker.ietf.org/doc/html/rfc9421)
+- [RFC 9449: OAuth 2.0 Demonstrating Proof of Possession](https://datatracker.ietf.org/doc/html/rfc9449)
+- [RFC 9635: Grant Negotiation and Authorization Protocol](https://datatracker.ietf.org/doc/html/rfc9635)
+- [W3C Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/)
+- [Web Bot Auth Architecture](https://datatracker.ietf.org/doc/html/draft-meunier-web-bot-auth-architecture)
+- [HTTP Message Signatures Directory](https://datatracker.ietf.org/doc/html/draft-meunier-http-message-signatures-directory)
+- [WIMSE Workload-to-Workload Authentication with HTTP Signatures](https://datatracker.ietf.org/doc/html/draft-ietf-wimse-http-signature)
+- [SPIFFE X.509-SVID](https://spiffe.io/docs/latest/spiffe-specs/x509-svid/)
+- [SPIFFE JWT-SVID](https://spiffe.io/docs/latest/spiffe-specs/jwt-svid/)
+- [Verifiable Intent Specification Overview](https://verifiableintent.dev/spec/)
+
+## Appendix A: Minimal Payload
+
+::: example Minimal x401 Payload
+```json
+{
+  "scheme": "x401",
+  "version": "0.2.0",
+  "presentation_requirements": {
+    "requests": [
+      {
+        "protocol": "openid4vp-v1-signed",
+        "data": {
+          "request": "eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWF1dGh6LXJlcStqd3QifQ..."
+        }
+      }
+    ]
+  },
+  "oauth": {
+    "token_endpoint": "https://bank.example.com/oauth/token"
+  }
+}
+```
+
+The example uses the RECOMMENDED signed form; the OpenID4VP request inside `presentation_requirements` carries the credential query (`dcql_query`), the `nonce`, and — for a signed request — the `client_id` and `expected_origins`. The JSON object is carried in the `PROOF-REQUIRED` header as:
+
+```http
+PROOF-REQUIRED: <base64url-minimal-x401-payload>
+```
+:::
+
+## Appendix B: Design Summary
+
+x401 is best understood as:
+
+- an HTTP route proof requirement protocol
+- carrying a composed, Verifier-authored Digital Credentials request at `presentation_requirements` rather than a decomposed set of values for the Agent to assemble
+- making the Verifier the relying party through a signed request (RECOMMENDED), bound via the request signature, `client_id`, and `expected_origins`, or allowing an unsigned request bound to the invoking origin and nonce when the invocation origin cannot be declared in advance
+- letting the Agent execute the request natively, relay it to a wallet or remote service, or acquire a remotely generated result and replay the route
+- reserving the top level of the payload, alongside the native request, for x401-specific values not yet expressible inside a native Digital Credentials request
+- carrying the presentation result inline or by reference on retry
+- treating VP response encryption and Agent binding as OPTIONAL
+- allowing caller authentication, request signing, workload identity, and delegation evidence to layer over the protected-route request
+- optionally exchanging verified VP Artifacts for OAuth access tokens
+- optionally pointing to OpenID4VCI issuance sources
+- remaining orthogonal to payment protocols
+- composing with `402 Payment Required` rather than absorbing it
+
+## Appendix C: x401 Request Object JSON Schema
+
+The JSON Schema below describes the x401 proof requirement payload. The same schema applies whether the payload is carried as a base64url-encoded value in the `PROOF-REQUIRED` header or embedded in HTML inside a `<data value="application/json;x401=proof-required" hidden>` element. The schema is published at the URL referenced by the `$schema` member of an embedded `<data>` element: `https://x401.id/spec/schemas/request.json`.
+
+```json
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://x401.id/spec/schemas/request.json",
+  "title": "x401 Proof Requirement Payload",
+  "description": "Schema for an x401 proof requirement payload as defined by the x401 specification.",
+  "type": "object",
+  "required": ["scheme", "version", "presentation_requirements", "oauth"],
+  "properties": {
+    "$schema": {
+      "type": "string",
+      "format": "uri",
+      "description": "Optional informational marker. When the payload is embedded in HTML as a <data> element, this SHOULD be set to https://x401.id/spec/schemas/request.json so that content processors can recognize the object as an x401 proof requirement."
+    },
+    "scheme": {
+      "type": "string",
+      "const": "x401",
+      "description": "MUST be the string \"x401\"."
+    },
+    "version": {
+      "type": "string",
+      "description": "The x401 payload version."
+    },
+    "presentation_requirements": {
+      "type": "object",
+      "required": ["requests"],
+      "description": "The composed Digital Credentials request (a DigitalCredentialRequestOptions value), usable as the digital member of navigator.credentials.get().",
+      "properties": {
+        "requests": {
+          "type": "array",
+          "minItems": 1,
+          "description": "Digital Credentials request entries. Every entry MUST be a valid OpenID4VP request for the DC API.",
+          "items": {
+            "type": "object",
+            "required": ["protocol", "data"],
+            "properties": {
+              "protocol": {
+                "type": "string",
+                "enum": ["openid4vp-v1-signed", "openid4vp-v1-unsigned"],
+                "description": "The DC API protocol identifier. openid4vp-v1-signed is RECOMMENDED; openid4vp-v1-unsigned is permitted. See Verifier Binding."
+              },
+              "data": {
+                "type": "object",
+                "description": "Protocol-specific request data. For openid4vp-v1-signed, an object carrying the signed OpenID4VP request (e.g. { \"request\": \"<JWT>\" }); for openid4vp-v1-unsigned, the OpenID4VP request parameters directly.",
+                "properties": {
+                  "request": {
+                    "type": "string",
+                    "description": "The signed OpenID4VP request (a JWT-Secured Authorization Request); present for openid4vp-v1-signed."
+                  }
+                }
+              }
+            }
+          }
+        }
+      }
+    },
+    "oauth": {
+      "type": "object",
+      "required": ["token_endpoint"],
+      "properties": {
+        "token_endpoint": {
+          "type": "string",
+          "format": "uri",
+          "description": "OAuth 2.0 token endpoint where the Agent can exchange a VP Artifact for a Verification Token."
+        },
+        "audience": {
+          "type": "string",
+          "description": "Optional OAuth token exchange audience value the Agent should request."
+        },
+        "resource": {
+          "type": "string",
+          "format": "uri",
+          "description": "Optional OAuth token exchange resource value the Agent should request."
+        }
+      },
+      "additionalProperties": false
+    },
+    "trust_establishment": {
+      "type": "string",
+      "format": "uri",
+      "description": "Optional acquisition and discovery hint: HTTPS URL for a DIF Credential Trust Establishment document. Issuer enforcement is governed by the signed request (DCQL trusted_authorities), not by this member."
+    },
+    "request_id": {
+      "type": "string",
+      "description": "Optional Agent-visible hint: a stable verifier-defined identifier for the proof template."
+    },
+    "satisfied_requirements": {
+      "type": "array",
+      "items": { "type": "string" },
+      "description": "Optional Agent-visible reuse hint: stable verifier-defined identifiers for the reusable proof requirements this proof would satisfy."
+    },
+    "return_uri": {
+      "type": "string",
+      "format": "uri",
+      "description": "Optional. Added by a relaying intermediary (never by the Verifier) to tell a remote handler where to POST the presentation result. See Relayed Delivery to a Remote Handler."
+    },
+    "payment": {
+      "type": "object",
+      "description": "Informational hint that payment is additionally required. Does not replace 402 Payment Required.",
+      "properties": {
+        "required": {
+          "type": "boolean",
+          "description": "Whether payment is additionally required."
+        },
+        "scheme_hint": {
+          "type": "string",
+          "description": "Hint naming the expected payment protocol."
+        },
+        "notes": {
+          "type": "string",
+          "description": "Human-readable notes."
+        }
+      },
+      "additionalProperties": false
+    }
+  },
+  "additionalProperties": false
+}
+```
diff --git a/src/agent.ts b/src/agent.ts
index 1894942..0afcb80 100644
--- a/src/agent.ts
+++ b/src/agent.ts
@@ -6,11 +6,15 @@ import {
   X401_VERSION,
 } from "./constants.ts";
 import { decodeProofHeader, encodeJson } from "./encoding.ts";
-import { parseX401ErrorObject, parseX401Payload } from "./validate.ts";
+import {
+  parseX401ErrorObject,
+  parseX401Payload,
+  X401ValidationError,
+} from "./validate.ts";
 import type {
-  DCQLQuery,
-  JsonObject,
-  JsonValue,
+  DigitalCredentialRequest,
+  PresentationResult,
+  TokenExchangeRequest,
   TokenExchangeResponse,
   VPArtifact,
   X401ErrorObject,
@@ -103,44 +107,70 @@ function decodeHtmlEntities(value: string): string {
     .replace(/&amp;/g, "&");
 }
 
-export function getNonce(payload: X401Payload): string {
-  return payload.proof.challenge.value;
+/**
+ * Returns the Verifier-composed Digital Credentials request, usable directly as the
+ * `digital` member of `navigator.credentials.get()`. x401 treats it as opaque; the
+ * Agent MUST NOT modify it.
+ */
+export function getDigitalCredentialRequest(
+  payload: X401Payload,
+): DigitalCredentialRequest {
+  return payload.presentation_requirements;
 }
 
-export function getCredentialQuery(
+/**
+ * Returns a copy of the payload with `return_uri` added, for an intermediary relaying the
+ * request to a remote handler that POSTs the presentation result back. Only a relaying
+ * intermediary sets this — never the Verifier. The URL must be https.
+ */
+export function addReturnUri(
   payload: X401Payload,
-): { scope: string } | { dcql_query: DCQLQuery } {
-  if (payload.proof.scope !== undefined) {
-    return { scope: payload.proof.scope };
+  returnUri: string,
+): X401Payload {
+  if (!returnUri.startsWith("https://")) {
+    throw new X401ValidationError("return_uri must be an https URL.");
   }
-  return { dcql_query: payload.proof.dcql_query as DCQLQuery };
+  return { ...payload, return_uri: returnUri };
 }
 
 interface BuildVPArtifactInput {
-  /** The decoded x401 payload that produced this presentation. */
-  payload: X401Payload;
-  /** Agent Identifier (the OpenID4VP client_id used with the wallet). */
-  agentId: string;
-  /** Wallet-returned presentation material. Opaque to x401 (string or object). */
-  vpToken: JsonValue;
-  /** OpenID4VP presentation submission metadata returned by the wallet, when applicable. */
-  presentationSubmission?: JsonObject;
-  /** Agent-generated correlation state returned by the wallet, when applicable. */
-  state?: string;
+  /** The `{ protocol, data }` presentation result returned by the Wallet. */
+  response: PresentationResult;
+  /** Stable verifier-defined identifier for the proof template, when correlating. */
+  requestId?: string;
+  /** Agent Identifier, when the deployment binds the Agent to the retry. */
+  agentId?: string;
 }
 
+/** Packages an inline presentation result as a VP Artifact for protected-route retry. */
 export function buildVPArtifact(input: BuildVPArtifactInput): VPArtifact {
   return {
-    agent_id: input.agentId,
-    challenge: input.payload.proof.challenge.value,
-    vp_token: input.vpToken,
-    ...(input.payload.proof.request_id !== undefined && {
-      request_id: input.payload.proof.request_id,
-    }),
-    ...(input.presentationSubmission !== undefined && {
-      presentation_submission: input.presentationSubmission,
-    }),
-    ...(input.state !== undefined && { state: input.state }),
+    response: input.response,
+    ...(input.requestId !== undefined && { request_id: input.requestId }),
+    ...(input.agentId !== undefined && { agent_id: input.agentId }),
+  };
+}
+
+interface BuildVPArtifactReferenceInput {
+  /** HTTPS URL the Verifier dereferences to fetch the presentation result. */
+  presentationUri: string;
+  /** RFC 3339 time after which the reference is no longer valid. */
+  expiresAt?: string;
+  /** Stable verifier-defined identifier for the proof template, when correlating. */
+  requestId?: string;
+  /** Agent Identifier, when the deployment binds the Agent to the retry. */
+  agentId?: string;
+}
+
+/** Packages a by-reference presentation as a VP Artifact for protected-route retry. */
+export function buildVPArtifactReference(
+  input: BuildVPArtifactReferenceInput,
+): VPArtifact {
+  return {
+    presentation_uri: input.presentationUri,
+    ...(input.expiresAt !== undefined && { expires_at: input.expiresAt }),
+    ...(input.requestId !== undefined && { request_id: input.requestId }),
+    ...(input.agentId !== undefined && { agent_id: input.agentId }),
   };
 }
 
@@ -162,9 +192,9 @@ export function encodeTokenObject(token: X401TokenObject): string {
 }
 
 interface TokenExchangeOptions {
-  /** OAuth `resource` value to request (from proof.oauth.resource or the protected URL). */
+  /** OAuth `resource` value to request (from oauth.resource or the protected URL). */
   resource?: string;
-  /** OAuth `audience` value to request (from proof.oauth.audience). */
+  /** OAuth `audience` value to request (from oauth.audience). */
   audience?: string;
 }
 
@@ -172,15 +202,16 @@ export function buildTokenExchangeForm(
   artifact: VPArtifact,
   options: TokenExchangeOptions = {},
 ): URLSearchParams {
+  const request: TokenExchangeRequest = {
+    grant_type: TOKEN_EXCHANGE_GRANT_TYPE,
+    subject_token_type: VP_ARTIFACT_SUBJECT_TOKEN_TYPE,
+    subject_token: encodeVPArtifact(artifact),
+    ...(options.resource !== undefined && { resource: options.resource }),
+    ...(options.audience !== undefined && { audience: options.audience }),
+  };
   const form = new URLSearchParams();
-  form.set("grant_type", TOKEN_EXCHANGE_GRANT_TYPE);
-  form.set("subject_token_type", VP_ARTIFACT_SUBJECT_TOKEN_TYPE);
-  form.set("subject_token", encodeVPArtifact(artifact));
-  if (options.resource !== undefined) {
-    form.set("resource", options.resource);
-  }
-  if (options.audience !== undefined) {
-    form.set("audience", options.audience);
+  for (const [key, value] of Object.entries(request)) {
+    form.set(key, value);
   }
   return form;
 }
diff --git a/src/challenge.ts b/src/challenge.ts
deleted file mode 100644
index 88457cb..0000000
--- a/src/challenge.ts
+++ /dev/null
@@ -1,159 +0,0 @@
-import {
-  base64urlDecode,
-  base64urlEncode,
-  uint8ArrayToBase64Url,
-} from "@owf/identity-common";
-
-import type { Encryptor } from "./encryptor.ts";
-import type { JsonObject, VerifierChallenge } from "./types.ts";
-
-const PREFIX = "x401";
-const RANDOM_BYTES = 16;
-
-export interface CreateChallengeInput {
-  /** Verifier identifier (e.g. HTTPS origin or DID). Encoded into the challenge value and sealed into the nonce. */
-  verifierId: string;
-  /** Route/resource the challenge is bound to. */
-  resource: string;
-  /** HTTP method the challenge is bound to. */
-  method: string;
-  /** Encryptor used to encrypt the challenge state into the nonce segment. */
-  encryptor: Encryptor;
-  /** Challenge lifetime in seconds. */
-  ttlSeconds: number;
-  /** Override the current time (testing). */
-  now?: Date;
-  /** Additional verifier-defined context bound into the challenge (policy id, agent rules, retry mechanisms, etc.). */
-  context?: JsonObject;
-}
-
-export async function createChallenge(
-  input: CreateChallengeInput,
-): Promise<VerifierChallenge> {
-  const now = input.now ?? new Date();
-  const expiresAt = new Date(now.getTime() + input.ttlSeconds * 1000);
-  const rnd = uint8ArrayToBase64Url(
-    crypto.getRandomValues(new Uint8Array(RANDOM_BYTES)),
-  );
-  const claims: JsonObject = {
-    vid: input.verifierId,
-    rnd,
-    resource: input.resource,
-    method: input.method.toUpperCase(),
-    exp: Math.floor(expiresAt.getTime() / 1000),
-    ...(input.context !== undefined && { context: input.context }),
-  };
-  const nonce = await input.encryptor.encrypt(claims);
-  return {
-    value: `${PREFIX}:${base64urlEncode(input.verifierId)}:${nonce}`,
-    expires_at: expiresAt.toISOString(),
-  };
-}
-
-function parseChallengeValue(value: string): {
-  verifierId: string;
-  nonce: string;
-} {
-  const first = value.indexOf(":");
-  const second = value.indexOf(":", first + 1);
-  if (first < 0 || second < 0 || value.slice(0, first) !== PREFIX) {
-    throw new Error("x401: malformed Verifier Challenge value.");
-  }
-  return {
-    verifierId: base64urlDecode(value.slice(first + 1, second)),
-    nonce: value.slice(second + 1),
-  };
-}
-
-export type VerifyChallengeResult =
-  | {
-      ok: true;
-      verifierId: string;
-      resource: string;
-      method: string;
-      expiresAt: string;
-      claims: JsonObject;
-    }
-  | { ok: false; reason: string };
-
-export interface VerifyChallengeInput {
-  /** The returned challenge value (from the VP Artifact or token-exchange request). */
-  value: string;
-  /** The same encryptor used to create the challenge. */
-  encryptor: Encryptor;
-  /** Reject the challenge unless its sealed verifier identifier equals this value. */
-  expectedVerifierId?: string;
-  /** Reject the challenge unless its sealed resource equals this value. */
-  expectedResource?: string;
-  /** Reject the challenge unless its sealed method equals this value (case-insensitive). */
-  expectedMethod?: string;
-  /** Override the current time (testing). */
-  now?: Date;
-}
-
-export async function verifyChallenge(
-  input: VerifyChallengeInput,
-): Promise<VerifyChallengeResult> {
-  let parsed: { verifierId: string; nonce: string };
-  try {
-    parsed = parseChallengeValue(input.value);
-  } catch (error) {
-    return { ok: false, reason: (error as Error).message };
-  }
-
-  let claims: JsonObject;
-  try {
-    claims = await input.encryptor.decrypt(parsed.nonce);
-  } catch (error) {
-    return { ok: false, reason: (error as Error).message };
-  }
-
-  const vid = typeof claims.vid === "string" ? claims.vid : undefined;
-  const resource =
-    typeof claims.resource === "string" ? claims.resource : undefined;
-  const method = typeof claims.method === "string" ? claims.method : undefined;
-  const exp = typeof claims.exp === "number" ? claims.exp : undefined;
-  if (
-    vid === undefined ||
-    resource === undefined ||
-    method === undefined ||
-    exp === undefined
-  ) {
-    return { ok: false, reason: "protected challenge state is incomplete" };
-  }
-  if (vid !== parsed.verifierId) {
-    return { ok: false, reason: "verifier identifier mismatch" };
-  }
-  if (
-    input.expectedVerifierId !== undefined &&
-    vid !== input.expectedVerifierId
-  ) {
-    return { ok: false, reason: "verifier identifier mismatch" };
-  }
-
-  const now = input.now ?? new Date();
-  if (now.getTime() / 1000 > exp) {
-    return { ok: false, reason: "challenge expired" };
-  }
-  if (
-    input.expectedResource !== undefined &&
-    resource !== input.expectedResource
-  ) {
-    return { ok: false, reason: "resource mismatch" };
-  }
-  if (
-    input.expectedMethod !== undefined &&
-    method !== input.expectedMethod.toUpperCase()
-  ) {
-    return { ok: false, reason: "method mismatch" };
-  }
-
-  return {
-    ok: true,
-    verifierId: vid,
-    resource,
-    method,
-    expiresAt: new Date(exp * 1000).toISOString(),
-    claims,
-  };
-}
diff --git a/src/constants.ts b/src/constants.ts
index b479540..10f139d 100644
--- a/src/constants.ts
+++ b/src/constants.ts
@@ -1,8 +1,15 @@
 export const X401_SCHEME = "x401" as const;
 
-export const X401_VERSION = "0.1.0" as const;
-
-export const PRESENTATION_PROTOCOL = "openid4vp" as const;
+export const X401_VERSION = "0.2.0" as const;
+
+/**
+ * W3C Digital Credentials API protocol identifiers for an entry in
+ * `presentation_requirements.requests`. `SIGNED` is RECOMMENDED.
+ */
+export const DC_API_PROTOCOL = {
+  SIGNED: "openid4vp-v1-signed",
+  UNSIGNED: "openid4vp-v1-unsigned",
+} as const;
 
 export const HEADER = {
   PROOF_REQUIRED: "PROOF-REQUIRED",
@@ -20,5 +27,6 @@ export const TOKEN_EXCHANGE_GRANT_TYPE =
 export const VP_ARTIFACT_SUBJECT_TOKEN_TYPE =
   "urn:x401:params:oauth:token-type:vp_artifact";
 
+/** RECOMMENDED `issued_token_type` value for a Bearer Verification Token (RFC 8693). */
 export const ACCESS_TOKEN_TYPE =
   "urn:ietf:params:oauth:token-type:access_token";
diff --git a/src/encryptor.ts b/src/encryptor.ts
deleted file mode 100644
index a98bb8c..0000000
--- a/src/encryptor.ts
+++ /dev/null
@@ -1,101 +0,0 @@
-import {
-  base64UrlToUint8Array,
-  concatBytes,
-  stringToBytes,
-  uint8ArrayToBase64Url,
-} from "@owf/identity-common";
-
-import type { JsonObject } from "./types.ts";
-
-const VERSION = 1;
-const IV_BYTES = 12;
-
-export interface EncryptorOptions {
-  /** Secret key material. A string is UTF-8 encoded before key derivation. */
-  key: string | Uint8Array;
-  /** Domain-separation label mixed into key derivation and bound as additional authenticated data. */
-  purpose?: string;
-}
-
-export interface Encryptor {
-  /** Encrypt and authenticate a claims object into a single base64url token. */
-  encrypt(claims: JsonObject): Promise<string>;
-  /** Authenticate and decrypt a token back into its claims. Throws if authentication fails. */
-  decrypt(token: string): Promise<JsonObject>;
-}
-
-function bytes(value: Uint8Array): Uint8Array<ArrayBuffer> {
-  return new Uint8Array(value);
-}
-
-async function deriveKey(
-  material: Uint8Array<ArrayBuffer>,
-  purpose: string,
-): Promise<CryptoKey> {
-  const base = await crypto.subtle.importKey("raw", material, "HKDF", false, [
-    "deriveKey",
-  ]);
-  return crypto.subtle.deriveKey(
-    {
-      name: "HKDF",
-      hash: "SHA-256",
-      salt: bytes(stringToBytes("x401-encryptor")),
-      info: bytes(stringToBytes(purpose)),
-    },
-    base,
-    { name: "AES-GCM", length: 256 },
-    false,
-    ["encrypt", "decrypt"],
-  );
-}
-
-export function createEncryptor(options: EncryptorOptions): Encryptor {
-  const purpose = options.purpose ?? "x401";
-  const material = bytes(
-    typeof options.key === "string" ? stringToBytes(options.key) : options.key,
-  );
-  const aad = bytes(stringToBytes(`x401-encryptor.v${VERSION}.${purpose}`));
-  let keyPromise: Promise<CryptoKey> | null = null;
-  const getKey = (): Promise<CryptoKey> =>
-    (keyPromise ??= deriveKey(material, purpose));
-
-  return {
-    async encrypt(claims: JsonObject): Promise<string> {
-      const key = await getKey();
-      const iv = crypto.getRandomValues(new Uint8Array(IV_BYTES));
-      const ciphertext = new Uint8Array(
-        await crypto.subtle.encrypt(
-          { name: "AES-GCM", iv, additionalData: aad },
-          key,
-          bytes(stringToBytes(JSON.stringify(claims))),
-        ),
-      );
-      return uint8ArrayToBase64Url(
-        concatBytes(new Uint8Array([VERSION]), iv, ciphertext),
-      );
-    },
-
-    async decrypt(token: string): Promise<JsonObject> {
-      const raw = base64UrlToUint8Array(token);
-      if (raw.length < 1 + IV_BYTES + 1 || raw[0] !== VERSION) {
-        throw new Error("x401 encryptor: malformed token.");
-      }
-      const key = await getKey();
-      const iv = bytes(raw.subarray(1, 1 + IV_BYTES));
-      const ciphertext = bytes(raw.subarray(1 + IV_BYTES));
-      let plaintext: ArrayBuffer;
-      try {
-        plaintext = await crypto.subtle.decrypt(
-          { name: "AES-GCM", iv, additionalData: aad },
-          key,
-          ciphertext,
-        );
-      } catch {
-        throw new Error("x401 encryptor: authentication failed.");
-      }
-      return JSON.parse(
-        new TextDecoder().decode(new Uint8Array(plaintext)),
-      ) as JsonObject;
-    },
-  };
-}
diff --git a/src/index.ts b/src/index.ts
index fadd274..fb0d969 100644
--- a/src/index.ts
+++ b/src/index.ts
@@ -1,13 +1,11 @@
 export * as agent from "./agent.ts";
 export * as verifier from "./verifier.ts";
 
-export { createEncryptor } from "./encryptor.ts";
-export type { Encryptor, EncryptorOptions } from "./encryptor.ts";
-
 export { X401ValidationError } from "./validate.ts";
 
 export {
   ACCESS_TOKEN_TYPE,
+  DC_API_PROTOCOL,
   HEADER,
   TOKEN_EXCHANGE_GRANT_TYPE,
   VP_ARTIFACT_SUBJECT_TOKEN_TYPE,
@@ -15,16 +13,16 @@ export {
 } from "./constants.ts";
 
 export type {
-  DCQLQuery,
-  IssuersRef,
+  DCApiProtocol,
+  DigitalCredentialRequest,
+  DigitalCredentialRequestEntry,
   JsonObject,
   JsonValue,
   OAuthMetadata,
   PaymentObject,
-  ProofObject,
+  PresentationResult,
   TokenExchangeRequest,
   TokenExchangeResponse,
-  VerifierChallenge,
   VPArtifact,
   X401ErrorObject,
   X401Payload,
diff --git a/src/types.ts b/src/types.ts
index aaf561a..8b48e2f 100644
--- a/src/types.ts
+++ b/src/types.ts
@@ -1,5 +1,5 @@
 import type {
-  PRESENTATION_PROTOCOL,
+  DC_API_PROTOCOL,
   TOKEN_EXCHANGE_GRANT_TYPE,
   VP_ARTIFACT_SUBJECT_TOKEN_TYPE,
   X401_SCHEME,
@@ -12,39 +12,41 @@ export type JsonValue =
   | { [key: string]: JsonValue };
 export type JsonObject = { [key: string]: JsonValue };
 
-/** A DCQL query. x401 treats it as an opaque OpenID4VP credential query object. */
-export type DCQLQuery = JsonObject;
+/** Digital Credentials API protocol identifier for a request entry. */
+export type DCApiProtocol =
+  (typeof DC_API_PROTOCOL)[keyof typeof DC_API_PROTOCOL];
 
-/** The Verifier Challenge object carried in `proof.challenge`. */
-export interface VerifierChallenge {
-  /** The exact value the Agent MUST use as the OpenID4VP `nonce`. */
-  value: string;
-  /** RFC 3339 timestamp after which the Verifier rejects the challenge. */
-  expires_at: string;
+/**
+ * One entry of a composed Digital Credentials request. `data` carries the
+ * protocol-specific request (the signed JAR for `openid4vp-v1-signed`, or the
+ * OpenID4VP parameters directly for `openid4vp-v1-unsigned`); x401 treats it as opaque.
+ */
+export interface DigitalCredentialRequestEntry {
+  protocol: DCApiProtocol;
+  data: JsonObject;
 }
 
-/** OAuth token-exchange metadata carried in `proof.oauth`. */
-export interface OAuthMetadata {
-  token_endpoint: string;
-  audience?: string;
-  resource?: string;
+/**
+ * The Verifier-composed Digital Credentials request carried in `presentation_requirements`.
+ * A `DigitalCredentialRequestOptions` value, usable directly as the `digital` member of
+ * `navigator.credentials.get()`.
+ */
+export interface DigitalCredentialRequest {
+  requests: DigitalCredentialRequestEntry[];
 }
 
-/** Reference to a DIF Credential Trust Establishment document. */
-export interface IssuersRef {
-  trust_establishment_url: string;
+/** The `{ protocol, data }` result a Wallet returns through the Digital Credentials API. */
+export interface PresentationResult {
+  protocol: string;
+  /** Wallet-returned presentation material. Opaque to x401. */
+  data: JsonValue;
 }
 
-/** The `proof` object of an x401 payload. Contains exactly one of `dcql_query` or `scope`. */
-export interface ProofObject {
-  presentation_protocol: typeof PRESENTATION_PROTOCOL;
-  dcql_query?: DCQLQuery;
-  scope?: string;
-  challenge: VerifierChallenge;
-  oauth: OAuthMetadata;
-  issuers?: IssuersRef;
-  request_id?: string;
-  satisfied_requirements?: string[];
+/** OAuth token-exchange metadata carried in `oauth`. */
+export interface OAuthMetadata {
+  token_endpoint: string;
+  audience?: string;
+  resource?: string;
 }
 
 /** Informational payment hint. Does not replace 402 Payment Required semantics. */
@@ -54,23 +56,43 @@ export interface PaymentObject {
   notes?: string;
 }
 
-/** The x401 payload carried (base64url-encoded) in the PROOF-REQUIRED header. */
+/** The flat x401 payload carried (base64url-encoded) in the PROOF-REQUIRED header. */
 export interface X401Payload {
   scheme: typeof X401_SCHEME;
   version: string;
-  proof: ProofObject;
+  /** The composed Digital Credentials request. Required. */
+  presentation_requirements: DigitalCredentialRequest;
+  /** OAuth token-exchange metadata. Required. */
+  oauth: OAuthMetadata;
+  /** HTTPS URL of a DIF Credential Trust Establishment document. Optional hint. */
+  trust_establishment?: string;
+  /** Stable verifier-defined identifier for the proof template. Optional hint. */
+  request_id?: string;
+  /** Stable identifiers for reusable proof requirements this proof would satisfy. Optional hint. */
+  satisfied_requirements?: string[];
+  /**
+   * HTTPS URL a remote handler POSTs the presentation result to. Added by a relaying
+   * intermediary (never by the Verifier) when relaying to a remote handler.
+   */
+  return_uri?: string;
   payment?: PaymentObject;
 }
 
-/** The VP Artifact carried (base64url-encoded) in PROOF-PRESENTATION for a direct retry. */
+/**
+ * The VP Artifact carried (base64url-encoded) in PROOF-PRESENTATION for a direct retry.
+ * Carries the presentation result inline (`response`) or by reference (`presentation_uri`);
+ * exactly one MUST be present.
+ */
 export interface VPArtifact {
-  agent_id: string;
-  challenge: string;
+  /** Inline presentation result. Mutually exclusive with `presentation_uri`. */
+  response?: PresentationResult;
+  /** HTTPS URL the Verifier dereferences to fetch the presentation result. */
+  presentation_uri?: string;
+  /** RFC 3339 time after which `presentation_uri` is no longer valid. */
+  expires_at?: string;
   request_id?: string;
-  /** Verifiable presentation material returned by the Wallet. Opaque to x401. */
-  vp_token: JsonValue;
-  presentation_submission?: JsonObject;
-  state?: string;
+  /** Optional Agent Identifier, when the deployment binds the Agent to the retry. */
+  agent_id?: string;
 }
 
 /** A reusable proof-satisfaction token carried in PROOF-PRESENTATION. */
@@ -89,7 +111,6 @@ export interface X401ErrorObject {
   error_description?: string;
   error_uri?: string;
   request_id?: string;
-  challenge?: string;
 }
 
 /** OAuth 2.0 Token Exchange response that returns an x401 Verification Token. */
diff --git a/src/validate.ts b/src/validate.ts
index 462a7f3..34af383 100644
--- a/src/validate.ts
+++ b/src/validate.ts
@@ -1,4 +1,4 @@
-import { PRESENTATION_PROTOCOL, X401_SCHEME } from "./constants.ts";
+import { DC_API_PROTOCOL, X401_SCHEME } from "./constants.ts";
 import type {
   JsonObject,
   VPArtifact,
@@ -22,6 +22,8 @@ function isString(value: unknown): value is string {
   return typeof value === "string";
 }
 
+const DC_API_PROTOCOLS: readonly string[] = Object.values(DC_API_PROTOCOL);
+
 export function parseX401Payload(value: unknown): X401Payload {
   if (!isObject(value)) {
     throw new X401ValidationError("x401 payload must be a JSON object.");
@@ -32,41 +34,43 @@ export function parseX401Payload(value: unknown): X401Payload {
   if (!isString(value.version)) {
     throw new X401ValidationError('x401 payload "version" is required.');
   }
-  const proof = value.proof;
-  if (!isObject(proof)) {
-    throw new X401ValidationError('x401 payload "proof" object is required.');
-  }
-  if (proof.presentation_protocol !== PRESENTATION_PROTOCOL) {
-    throw new X401ValidationError(
-      'proof.presentation_protocol must be "openid4vp".',
-    );
-  }
-  const hasDcql = proof.dcql_query !== undefined;
-  const hasScope = proof.scope !== undefined;
-  if (hasDcql === hasScope) {
-    throw new X401ValidationError(
-      "proof must contain exactly one of dcql_query or scope.",
-    );
-  }
-  if (hasScope && !isString(proof.scope)) {
-    throw new X401ValidationError("proof.scope must be a string.");
-  }
-  if (hasDcql && !isObject(proof.dcql_query)) {
-    throw new X401ValidationError("proof.dcql_query must be an object.");
-  }
-  const challenge = proof.challenge;
+  const pr = value.presentation_requirements;
   if (
-    !isObject(challenge) ||
-    !isString(challenge.value) ||
-    !isString(challenge.expires_at)
+    !isObject(pr) ||
+    !Array.isArray(pr.requests) ||
+    pr.requests.length === 0
   ) {
     throw new X401ValidationError(
-      "proof.challenge.value and proof.challenge.expires_at are required.",
+      "presentation_requirements.requests must be a non-empty array.",
     );
   }
-  const oauth = proof.oauth;
+  for (const entry of pr.requests) {
+    if (!isObject(entry)) {
+      throw new X401ValidationError(
+        "each presentation_requirements.requests entry must be an object.",
+      );
+    }
+    if (
+      !isString(entry.protocol) ||
+      !DC_API_PROTOCOLS.includes(entry.protocol)
+    ) {
+      throw new X401ValidationError(
+        `request protocol must be one of ${DC_API_PROTOCOLS.join(", ")}.`,
+      );
+    }
+    if (!isObject(entry.data)) {
+      throw new X401ValidationError("request data must be an object.");
+    }
+  }
+  const oauth = value.oauth;
   if (!isObject(oauth) || !isString(oauth.token_endpoint)) {
-    throw new X401ValidationError("proof.oauth.token_endpoint is required.");
+    throw new X401ValidationError("oauth.token_endpoint is required.");
+  }
+  if (
+    value.return_uri !== undefined &&
+    (!isString(value.return_uri) || !value.return_uri.startsWith("https://"))
+  ) {
+    throw new X401ValidationError("return_uri must be an https URL.");
   }
   return value as unknown as X401Payload;
 }
@@ -75,14 +79,33 @@ export function parseVPArtifact(value: unknown): VPArtifact {
   if (!isObject(value)) {
     throw new X401ValidationError("VP Artifact must be a JSON object.");
   }
-  if (!isString(value.agent_id)) {
-    throw new X401ValidationError("VP Artifact agent_id is required.");
+  const hasResponse = value.response !== undefined;
+  const hasUri = value.presentation_uri !== undefined;
+  if (hasResponse === hasUri) {
+    throw new X401ValidationError(
+      "VP Artifact must contain exactly one of response or presentation_uri.",
+    );
   }
-  if (!isString(value.challenge)) {
-    throw new X401ValidationError("VP Artifact challenge is required.");
+  if (hasResponse) {
+    const response = value.response;
+    if (
+      !isObject(response) ||
+      !isString(response.protocol) ||
+      response.data === undefined
+    ) {
+      throw new X401ValidationError(
+        "VP Artifact response must be a { protocol, data } object.",
+      );
+    }
   }
-  if (value.vp_token === undefined || value.vp_token === null) {
-    throw new X401ValidationError("VP Artifact vp_token is required.");
+  if (
+    hasUri &&
+    (!isString(value.presentation_uri) ||
+      !value.presentation_uri.startsWith("https://"))
+  ) {
+    throw new X401ValidationError(
+      "VP Artifact presentation_uri must be an https URL.",
+    );
   }
   return value as unknown as VPArtifact;
 }
@@ -94,6 +117,9 @@ export function parseX401TokenObject(value: unknown): X401TokenObject {
   if (value.scheme !== X401_SCHEME) {
     throw new X401ValidationError('x401 Token Object "scheme" must be "x401".');
   }
+  if (!isString(value.version)) {
+    throw new X401ValidationError('x401 Token Object "version" is required.');
+  }
   if (value.token_type !== "Bearer") {
     throw new X401ValidationError(
       'x401 Token Object "token_type" must be "Bearer".',
@@ -114,6 +140,9 @@ export function parseX401ErrorObject(value: unknown): X401ErrorObject {
   if (value.scheme !== X401_SCHEME) {
     throw new X401ValidationError('x401 Error Object "scheme" must be "x401".');
   }
+  if (!isString(value.version)) {
+    throw new X401ValidationError('x401 Error Object "version" is required.');
+  }
   if (!isString(value.error)) {
     throw new X401ValidationError("x401 Error Object error code is required.");
   }
diff --git a/src/verifier.ts b/src/verifier.ts
index ba10e24..92d31e4 100644
--- a/src/verifier.ts
+++ b/src/verifier.ts
@@ -1,6 +1,6 @@
 import {
+  DC_API_PROTOCOL,
   EMBEDDED_DATA_VALUE,
-  PRESENTATION_PROTOCOL,
   REQUEST_SCHEMA_URL,
   TOKEN_EXCHANGE_GRANT_TYPE,
   VP_ARTIFACT_SUBJECT_TOKEN_TYPE,
@@ -14,67 +14,61 @@ import {
   X401ValidationError,
 } from "./validate.ts";
 import type {
-  DCQLQuery,
-  IssuersRef,
+  DigitalCredentialRequest,
   OAuthMetadata,
   PaymentObject,
-  VerifierChallenge,
   VPArtifact,
   X401ErrorObject,
   X401Payload,
   X401TokenObject,
 } from "./types.ts";
 
-export { createChallenge, verifyChallenge } from "./challenge.ts";
-export type { VerifyChallengeResult } from "./challenge.ts";
+const DC_API_PROTOCOLS: readonly string[] = Object.values(DC_API_PROTOCOL);
 
-interface BuildPayloadProof {
-  /** Verifier Challenge, typically from {@link createChallenge}. */
-  challenge: VerifierChallenge;
+interface BuildPayloadInput {
+  /**
+   * The Verifier-composed Digital Credentials request (a `DigitalCredentialRequestOptions`
+   * value). The caller authors and, for signed requests, signs it; x401 carries it opaque.
+   */
+  presentationRequirements: DigitalCredentialRequest;
   /** OAuth token-exchange metadata for the Agent. */
   oauth: OAuthMetadata;
-  /** DCQL Credential Query Requirement. Provide exactly one of `dcql_query` or `scope`. */
-  dcql_query?: DCQLQuery;
-  /** OpenID4VP scope Credential Query Requirement. Provide exactly one of `dcql_query` or `scope`. */
-  scope?: string;
-  /** Reference to an Issuer Trust List (DIF Credential Trust Establishment document). */
-  issuers?: IssuersRef;
-  /** Stable verifier-defined identifier for the proof template. */
-  request_id?: string;
-  /** Reusable proof-requirement identifiers marked satisfied if this proof is fulfilled. */
-  satisfied_requirements?: string[];
-}
-
-interface BuildPayloadInput {
-  proof: BuildPayloadProof;
+  /** HTTPS URL of a DIF Credential Trust Establishment document. Optional hint. */
+  trustEstablishment?: string;
+  /** Stable verifier-defined identifier for the proof template. Optional hint. */
+  requestId?: string;
+  /** Reusable proof-requirement identifiers this proof would satisfy. Optional hint. */
+  satisfiedRequirements?: string[];
   /** Informational payment hint. Does not replace 402 Payment Required. */
   payment?: PaymentObject;
 }
 
 export function buildPayload(input: BuildPayloadInput): X401Payload {
-  const { proof } = input;
-  const hasDcql = proof.dcql_query !== undefined;
-  const hasScope = proof.scope !== undefined;
-  if (hasDcql === hasScope) {
+  const requests = input.presentationRequirements.requests;
+  if (!Array.isArray(requests) || requests.length === 0) {
     throw new X401ValidationError(
-      "proof must contain exactly one of dcql_query or scope.",
+      "presentation_requirements.requests must be a non-empty array.",
     );
   }
+  for (const entry of requests) {
+    if (!DC_API_PROTOCOLS.includes(entry.protocol)) {
+      throw new X401ValidationError(
+        `request protocol must be one of ${DC_API_PROTOCOLS.join(", ")}.`,
+      );
+    }
+  }
   return {
     scheme: X401_SCHEME,
     version: X401_VERSION,
-    proof: {
-      presentation_protocol: PRESENTATION_PROTOCOL,
-      challenge: proof.challenge,
-      oauth: proof.oauth,
-      ...(proof.dcql_query !== undefined && { dcql_query: proof.dcql_query }),
-      ...(proof.scope !== undefined && { scope: proof.scope }),
-      ...(proof.issuers !== undefined && { issuers: proof.issuers }),
-      ...(proof.request_id !== undefined && { request_id: proof.request_id }),
-      ...(proof.satisfied_requirements !== undefined && {
-        satisfied_requirements: proof.satisfied_requirements,
-      }),
-    },
+    presentation_requirements: input.presentationRequirements,
+    oauth: input.oauth,
+    ...(input.trustEstablishment !== undefined && {
+      trust_establishment: input.trustEstablishment,
+    }),
+    ...(input.requestId !== undefined && { request_id: input.requestId }),
+    ...(input.satisfiedRequirements !== undefined && {
+      satisfied_requirements: input.satisfiedRequirements,
+    }),
     ...(input.payment !== undefined && { payment: input.payment }),
   };
 }
@@ -92,13 +86,10 @@ export function embedHtmlData(payload: X401Payload): string {
   return `<data value="${EMBEDDED_DATA_VALUE}" hidden>${escapeHtml(json)}</data>`;
 }
 
+// Escape only `&` and `<`; leaving quotes and `>` keeps the embedded text directly
+// readable as JSON, which the spec requires of the `<data>` content.
 function escapeHtml(value: string): string {
-  return value
-    .replace(/&/g, "&amp;")
-    .replace(/</g, "&lt;")
-    .replace(/>/g, "&gt;")
-    .replace(/"/g, "&quot;")
-    .replace(/'/g, "&#039;");
+  return value.replace(/&/g, "&amp;").replace(/</g, "&lt;");
 }
 
 export function decodeVPArtifact(headerValue: string): VPArtifact {
@@ -150,10 +141,8 @@ interface BuildErrorInput {
   error_description?: string;
   /** HTTPS URL identifying documentation for the error. */
   error_uri?: string;
-  /** The proof.request_id, when the error correlates to a proof template. */
+  /** The request_id, when the error correlates to a proof template. */
   request_id?: string;
-  /** The Verifier Challenge value, when the error can be safely correlated to a challenge. */
-  challenge?: string;
 }
 
 export function buildErrorObject(input: BuildErrorInput): X401ErrorObject {
@@ -166,7 +155,6 @@ export function buildErrorObject(input: BuildErrorInput): X401ErrorObject {
     }),
     ...(input.error_uri !== undefined && { error_uri: input.error_uri }),
     ...(input.request_id !== undefined && { request_id: input.request_id }),
-    ...(input.challenge !== undefined && { challenge: input.challenge }),
   };
 }
 
diff --git a/tests/spec-fixtures.test.ts b/tests/spec-fixtures.test.ts
new file mode 100644
index 0000000..b8e8e28
--- /dev/null
+++ b/tests/spec-fixtures.test.ts
@@ -0,0 +1,92 @@
+import assert from "node:assert/strict";
+import { readdirSync, readFileSync } from "node:fs";
+import { dirname, join } from "node:path";
+import test from "node:test";
+import { fileURLToPath } from "node:url";
+
+import { agent, verifier } from "../src/index.ts";
+import { parseX401Payload } from "../src/validate.ts";
+
+const FIXTURES = join(
+  dirname(fileURLToPath(import.meta.url)),
+  "..",
+  "spec",
+  "fixtures",
+);
+
+function fixture(name: string): unknown {
+  return JSON.parse(readFileSync(join(FIXTURES, name), "utf8"));
+}
+
+function names(re: RegExp): string[] {
+  return readdirSync(FIXTURES)
+    .filter((n) => re.test(n))
+    .sort();
+}
+
+function hasRequests(p: unknown): boolean {
+  const pr = (p as { presentation_requirements?: { requests?: unknown[] } })
+    .presentation_requirements;
+  return Array.isArray(pr?.requests) && pr.requests.length > 0;
+}
+
+test("complete spec payload fixtures parse and survive an encode round-trip", () => {
+  const complete = names(/^payload-\d+\.json$/).filter((n) =>
+    hasRequests(fixture(n)),
+  );
+  assert.ok(complete.length >= 1);
+  for (const name of complete) {
+    const payload = parseX401Payload(fixture(name));
+    const decoded = agent.decodePayload(verifier.encodePayload(payload));
+    assert.deepEqual(decoded, payload, name);
+  }
+});
+
+test("the spec envelope skeleton is rejected by the parser", () => {
+  const skeletons = names(/^payload-\d+\.json$/).filter(
+    (n) => !hasRequests(fixture(n)),
+  );
+  for (const name of skeletons) {
+    assert.throws(() => parseX401Payload(fixture(name)), name);
+  }
+});
+
+test("spec VP Artifact fixtures (inline and by-reference) decode and round-trip", () => {
+  const arts = names(/^vp-artifact-\d+\.json$/);
+  assert.ok(
+    arts.length >= 2,
+    "expected inline and by-reference VP artifact fixtures",
+  );
+  let sawInline = false;
+  let sawReference = false;
+  for (const name of arts) {
+    const raw = fixture(name) as Record<string, unknown>;
+    if (raw["response"] !== undefined) sawInline = true;
+    if (raw["presentation_uri"] !== undefined) sawReference = true;
+    const decoded = verifier.decodeVPArtifact(
+      agent.encodeVPArtifact(raw as never),
+    );
+    assert.deepEqual(decoded, raw, name);
+  }
+  assert.ok(sawInline, "no inline VP artifact fixture found");
+  assert.ok(sawReference, "no by-reference VP artifact fixture found");
+});
+
+test("spec error object fixture decodes through PROOF-RESPONSE", () => {
+  const raw = fixture("error-object.json") as Record<string, unknown>;
+  const decoded = agent.decodeErrorObject(
+    verifier.encodeErrorObject(raw as never),
+  );
+  assert.equal(decoded.error, raw["error"]);
+  assert.equal(decoded.version, "0.2.0");
+  assert.equal("challenge" in decoded, false);
+});
+
+test("spec token object fixture decodes through PROOF-PRESENTATION", () => {
+  const raw = fixture("token-object.json") as Record<string, unknown>;
+  const decoded = verifier.decodeTokenObject(
+    agent.encodeTokenObject(raw as never),
+  );
+  assert.equal(decoded.token_type, "Bearer");
+  assert.equal(decoded.access_token, raw["access_token"]);
+});
diff --git a/tests/spec-schema.test.ts b/tests/spec-schema.test.ts
new file mode 100644
index 0000000..96ecc86
--- /dev/null
+++ b/tests/spec-schema.test.ts
@@ -0,0 +1,125 @@
+import assert from "node:assert/strict";
+import { readdirSync, readFileSync } from "node:fs";
+import { dirname, join } from "node:path";
+import test from "node:test";
+import { fileURLToPath } from "node:url";
+
+import Ajv2020 from "ajv/dist/2020.js";
+import addFormats from "ajv-formats";
+
+import { verifier } from "../src/index.ts";
+
+const FIXTURES = join(
+  dirname(fileURLToPath(import.meta.url)),
+  "..",
+  "spec",
+  "fixtures",
+);
+
+function fixture(name: string): unknown {
+  return JSON.parse(readFileSync(join(FIXTURES, name), "utf8"));
+}
+
+function payloadFixtureNames(): string[] {
+  return readdirSync(FIXTURES)
+    .filter((n) => /^payload-\d+\.json$/.test(n))
+    .sort();
+}
+
+/** A "complete" payload example carries at least one request entry; the spec also
+ * shows an envelope skeleton (empty objects) that is illustrative, not valid. */
+function isComplete(p: unknown): boolean {
+  const pr = (p as { presentation_requirements?: { requests?: unknown[] } })
+    .presentation_requirements;
+  return Array.isArray(pr?.requests) && pr.requests.length > 0;
+}
+
+const ajv = addFormats(new Ajv2020({ allErrors: true }));
+const validate = ajv.compile(fixture("request.schema.json"));
+
+test("every complete spec payload example validates against Appendix C schema", () => {
+  const complete = payloadFixtureNames().filter((n) => isComplete(fixture(n)));
+  assert.ok(
+    complete.length >= 1,
+    "expected at least one complete payload fixture",
+  );
+  for (const name of complete) {
+    const ok = validate(fixture(name));
+    assert.ok(ok, `${name} failed schema: ${ajv.errorsText(validate.errors)}`);
+  }
+});
+
+test("the spec envelope skeleton is not a complete payload (sanity check on the schema)", () => {
+  const skeletons = payloadFixtureNames().filter(
+    (n) => !isComplete(fixture(n)),
+  );
+  for (const name of skeletons) {
+    assert.equal(
+      validate(fixture(name)),
+      false,
+      `${name} unexpectedly validated`,
+    );
+  }
+});
+
+test("payloads produced by verifier.buildPayload validate against the schema", () => {
+  const signed = verifier.buildPayload({
+    presentationRequirements: {
+      requests: [
+        { protocol: "openid4vp-v1-signed", data: { request: "eyJ..." } },
+      ],
+    },
+    oauth: { token_endpoint: "https://bank.example.com/oauth/token" },
+    trustEstablishment: "https://bank.example.com/.well-known/x401/trust/v1",
+    requestId: "proof-template-v1",
+    satisfiedRequirements: ["urn:example:x401:satisfaction:v1"],
+  });
+  assert.ok(validate(signed), `signed: ${ajv.errorsText(validate.errors)}`);
+
+  const unsigned = verifier.buildPayload({
+    presentationRequirements: {
+      requests: [{ protocol: "openid4vp-v1-unsigned", data: { nonce: "abc" } }],
+    },
+    oauth: { token_endpoint: "https://bank.example.com/oauth/token" },
+  });
+  assert.ok(validate(unsigned), `unsigned: ${ajv.errorsText(validate.errors)}`);
+});
+
+test("schema rejects structurally invalid payloads", () => {
+  const base = {
+    scheme: "x401",
+    version: "0.2.0",
+    presentation_requirements: {
+      requests: [{ protocol: "openid4vp-v1-signed", data: {} }],
+    },
+    oauth: { token_endpoint: "https://bank.example.com/oauth/token" },
+  };
+  // missing oauth
+  assert.equal(
+    validate({
+      scheme: "x401",
+      version: "0.2.0",
+      presentation_requirements: {
+        requests: [{ protocol: "openid4vp-v1-signed", data: {} }],
+      },
+    }),
+    false,
+  );
+  // bad protocol enum
+  assert.equal(
+    validate({
+      ...base,
+      presentation_requirements: {
+        requests: [{ protocol: "openid4vp-signed", data: {} }],
+      },
+    }),
+    false,
+  );
+  // empty requests
+  assert.equal(
+    validate({ ...base, presentation_requirements: { requests: [] } }),
+    false,
+  );
+  // leftover 0.1.0 proof wrapper (additionalProperties: false)
+  assert.equal(validate({ ...base, proof: {} }), false);
+});
diff --git a/tests/x401.test.ts b/tests/x401.test.ts
index fbf9f32..494082d 100644
--- a/tests/x401.test.ts
+++ b/tests/x401.test.ts
@@ -4,105 +4,143 @@ import test from "node:test";
 import {
   agent,
   verifier,
-  createEncryptor,
+  ACCESS_TOKEN_TYPE,
   HEADER,
   TOKEN_EXCHANGE_GRANT_TYPE,
   VP_ARTIFACT_SUBJECT_TOKEN_TYPE,
   X401ValidationError,
 } from "../src/index.ts";
+import type { DigitalCredentialRequest } from "../src/index.ts";
 
-const VERIFIER_ID = "https://research.example.com";
-const RESOURCE = "https://research.example.com/papers/medical-study-123";
 const TOKEN_ENDPOINT = "https://research.example.com/oauth/token";
+const RESOURCE = "https://research.example.com/papers/medical-study-123";
 
-function newEncryptor() {
-  return createEncryptor({
-    key: "test-key-long-enough-for-hkdf-derivation",
-    purpose: "x401-demo",
-  });
-}
-
-async function buildRequirement(encryptor = newEncryptor()) {
-  const challenge = await verifier.createChallenge({
-    verifierId: VERIFIER_ID,
-    resource: RESOURCE,
-    method: "GET",
-    encryptor,
-    ttlSeconds: 600,
-  });
-  const payload = verifier.buildPayload({
-    proof: {
-      challenge,
-      oauth: { token_endpoint: TOKEN_ENDPOINT },
-      scope: "urn:proof:params:scope:verifiable-credentials:basic",
-      request_id: "proof-template-age-over-21-v1",
-      satisfied_requirements: ["urn:example:x401:satisfaction:age-over-21:v1"],
+const SIGNED_REQUEST: DigitalCredentialRequest = {
+  requests: [
+    {
+      protocol: "openid4vp-v1-signed",
+      data: { request: "eyJhbGciOiJFUzI1NiJ9.signed-jar" },
     },
+  ],
+};
+
+function buildRequirement() {
+  return verifier.buildPayload({
+    presentationRequirements: SIGNED_REQUEST,
+    oauth: { token_endpoint: TOKEN_ENDPOINT },
+    trustEstablishment:
+      "https://research.example.com/.well-known/x401/trust/v1",
+    requestId: "proof-template-age-over-21-v1",
+    satisfiedRequirements: ["urn:example:x401:satisfaction:age-over-21:v1"],
   });
-  return { payload, challenge, encryptor };
 }
 
-test("challenge value matches the spec schema pattern (dotless nonce segment)", async () => {
-  const { challenge } = await buildRequirement();
-  assert.match(challenge.value, /^x401:[A-Za-z0-9_-]+:[A-Za-z0-9_-]+$/);
+test("buildPayload emits a flat 0.2.0 payload with presentation_requirements", () => {
+  const payload = buildRequirement();
+  assert.equal(payload.version, "0.2.0");
+  assert.equal(
+    payload.presentation_requirements.requests[0]?.protocol,
+    "openid4vp-v1-signed",
+  );
+  assert.equal(payload.oauth.token_endpoint, TOKEN_ENDPOINT);
+  // No 0.1.0 proof wrapper.
+  assert.equal("proof" in payload, false);
+});
+
+test("buildPayload rejects an empty requests array", () => {
+  assert.throws(
+    () =>
+      verifier.buildPayload({
+        presentationRequirements: { requests: [] },
+        oauth: { token_endpoint: TOKEN_ENDPOINT },
+      }),
+    X401ValidationError,
+  );
 });
 
-test("buildPayload rejects both dcql_query and scope", () => {
+test("buildPayload rejects an unknown DC API protocol", () => {
   assert.throws(
     () =>
       verifier.buildPayload({
-        proof: {
-          challenge: {
-            value: "x401:a:b",
-            expires_at: new Date().toISOString(),
-          },
-          oauth: { token_endpoint: TOKEN_ENDPOINT },
-          scope: "s",
-          dcql_query: { credentials: [] },
+        presentationRequirements: {
+          requests: [{ protocol: "openid4vp-signed" as never, data: {} }],
         },
+        oauth: { token_endpoint: TOKEN_ENDPOINT },
       }),
     X401ValidationError,
   );
 });
 
-test("agent decodes the PROOF-REQUIRED header into a validated payload", async () => {
-  const { payload } = await buildRequirement();
-  const headerValue = verifier.encodePayload(payload);
+test("agent decodes the PROOF-REQUIRED header and exposes the composed request", () => {
+  const payload = buildRequirement();
   const detected = agent.detectProofRequirement({
-    headers: { [HEADER.PROOF_REQUIRED]: headerValue },
+    headers: { [HEADER.PROOF_REQUIRED]: verifier.encodePayload(payload) },
   });
   assert.ok(detected);
   assert.equal(detected.source, "header");
-  assert.equal(detected.payload.proof.presentation_protocol, "openid4vp");
-  assert.deepEqual(agent.getCredentialQuery(detected.payload), {
-    scope: "urn:proof:params:scope:verifiable-credentials:basic",
-  });
-  assert.equal(agent.getNonce(detected.payload), payload.proof.challenge.value);
-});
-
-test("agent detects the embedded <data> requirement when the header is absent", async () => {
-  const { payload } = await buildRequirement();
-  const body = `<html><body><data value="application/json;x401=proof-required" hidden>${embed(
-    payload,
-  )}</data></body></html>`;
-  const detected = agent.detectProofRequirement({ headers: {}, body });
-  assert.ok(detected);
-  assert.equal(detected.source, "embedded");
-  assert.equal(
-    detected.payload.proof.challenge.value,
-    payload.proof.challenge.value,
+  assert.deepEqual(
+    agent.getDigitalCredentialRequest(detected.payload),
+    SIGNED_REQUEST,
   );
 });
 
-test("embedHtmlData round-trips through the agent detector", async () => {
-  const { payload } = await buildRequirement();
+test("agent detects the embedded <data> requirement and it round-trips", () => {
+  const payload = buildRequirement();
   const detected = agent.detectProofRequirement({
     body: verifier.embedHtmlData(payload),
   });
   assert.ok(detected);
-  assert.equal(
-    detected.payload.proof.request_id,
-    "proof-template-age-over-21-v1",
+  assert.equal(detected.source, "embedded");
+  assert.equal(detected.payload.request_id, "proof-template-age-over-21-v1");
+});
+
+test("addReturnUri attaches an https return_uri that survives a round-trip", () => {
+  const payload = buildRequirement();
+  assert.equal("return_uri" in payload, false); // verifier never sets it
+  const relayed = agent.addReturnUri(
+    payload,
+    "https://mcp.example/x401/return/9f1c2a",
+  );
+  assert.equal(relayed.return_uri, "https://mcp.example/x401/return/9f1c2a");
+  const decoded = agent.decodePayload(verifier.encodePayload(relayed));
+  assert.equal(decoded.return_uri, "https://mcp.example/x401/return/9f1c2a");
+});
+
+test("addReturnUri rejects a non-https return_uri", () => {
+  assert.throws(
+    () => agent.addReturnUri(buildRequirement(), "http://mcp.example/return"),
+    X401ValidationError,
+  );
+});
+
+test("parseX401Payload rejects a non-https return_uri", () => {
+  const bad = Buffer.from(
+    JSON.stringify({
+      scheme: "x401",
+      version: "0.2.0",
+      presentation_requirements: {
+        requests: [{ protocol: "openid4vp-v1-signed", data: {} }],
+      },
+      oauth: { token_endpoint: "https://bank.example.com/oauth/token" },
+      return_uri: "http://mcp.example/return",
+    }),
+  ).toString("base64url");
+  assert.throws(() => agent.decodePayload(bad), X401ValidationError);
+});
+
+test("parseX401Payload rejects a leftover 0.1.0 proof wrapper", () => {
+  assert.throws(
+    () =>
+      agent.decodePayload(
+        Buffer.from(
+          JSON.stringify({
+            scheme: "x401",
+            version: "0.1.0",
+            proof: { presentation_protocol: "openid4vp" },
+          }),
+        ).toString("base64url"),
+      ),
+    X401ValidationError,
   );
 });
 
@@ -110,113 +148,67 @@ test("a comma-list proof header value is rejected as invalid", () => {
   assert.throws(() => agent.decodePayload("AAAA,BBBB"), X401ValidationError);
 });
 
-test("full direct-retry round trip: payload -> artifact -> verify challenge", async () => {
-  const { payload, encryptor } = await buildRequirement();
-  const headerValue = verifier.encodePayload(payload);
-
-  const detected = agent.detectProofRequirement({
-    headers: { [HEADER.PROOF_REQUIRED]: headerValue },
-  });
-  assert.ok(detected);
-  const vpToken = "eyJ...wallet-returned-sd-jwt-vc";
+test("inline VP Artifact round-trips through PROOF-PRESENTATION", () => {
+  const payload = buildRequirement();
   const artifact = agent.buildVPArtifact({
-    payload: detected.payload,
-    agentId: "did:web:agent.example",
-    vpToken,
+    response: {
+      protocol: "openid4vp-v1-signed",
+      data: "<wallet-returned-presentation-result>",
+    },
+    requestId: payload.request_id,
   });
-  const presentationHeader = agent.encodeVPArtifact(artifact);
-
-  const decoded = verifier.decodeVPArtifact(presentationHeader);
-  assert.equal(decoded.agent_id, "did:web:agent.example");
-  assert.equal(decoded.challenge, payload.proof.challenge.value);
+  const decoded = verifier.decodeVPArtifact(agent.encodeVPArtifact(artifact));
+  assert.equal(decoded.response?.protocol, "openid4vp-v1-signed");
+  assert.equal(decoded.presentation_uri, undefined);
   assert.equal(decoded.request_id, "proof-template-age-over-21-v1");
-  assert.equal(decoded.vp_token, vpToken);
-
-  const result = await verifier.verifyChallenge({
-    value: decoded.challenge,
-    encryptor,
-    expectedVerifierId: VERIFIER_ID,
-    expectedResource: RESOURCE,
-    expectedMethod: "GET",
-  });
-  assert.ok(result.ok);
-  if (result.ok) {
-    assert.equal(result.verifierId, VERIFIER_ID);
-    assert.equal(result.resource, RESOURCE);
-    assert.equal(result.method, "GET");
-  }
-});
-
-test("verifyChallenge rejects a tampered nonce", async () => {
-  const { challenge, encryptor } = await buildRequirement();
-  const tampered = `${challenge.value.slice(0, -2)}xx`;
-  const result = await verifier.verifyChallenge({ value: tampered, encryptor });
-  assert.equal(result.ok, false);
 });
 
-test("verifyChallenge rejects a swapped (unauthenticated) verifier-id segment", async () => {
-  const { challenge, encryptor } = await buildRequirement();
-  const [, , nonce] = challenge.value.split(":");
-  const forgedVid = Buffer.from("https://evil.example.com").toString(
-    "base64url",
+test("by-reference VP Artifact round-trips through PROOF-PRESENTATION", () => {
+  const artifact = agent.buildVPArtifactReference({
+    presentationUri:
+      "https://research.example.com/.well-known/x401/presentations/abc",
+    expiresAt: "2026-05-06T18:50:00Z",
+    agentId: "did:web:agent.example",
+  });
+  const decoded = verifier.decodeVPArtifact(agent.encodeVPArtifact(artifact));
+  assert.equal(
+    decoded.presentation_uri,
+    "https://research.example.com/.well-known/x401/presentations/abc",
   );
-  const forged = `x401:${forgedVid}:${nonce}`;
-  const result = await verifier.verifyChallenge({ value: forged, encryptor });
-  assert.equal(result.ok, false);
-  if (!result.ok) assert.equal(result.reason, "verifier identifier mismatch");
+  assert.equal(decoded.response, undefined);
+  assert.equal(decoded.agent_id, "did:web:agent.example");
 });
 
-test("verifyChallenge rejects a challenge sealed by a different encryptor", async () => {
-  const { challenge } = await buildRequirement();
-  const other = createEncryptor({
-    key: "a-different-secret-key-entirely",
-    purpose: "x401-demo",
-  });
-  const result = await verifier.verifyChallenge({
-    value: challenge.value,
-    encryptor: other,
-  });
-  assert.equal(result.ok, false);
+test("VP Artifact with neither response nor presentation_uri is rejected", () => {
+  assert.throws(
+    () =>
+      verifier.decodeVPArtifact(
+        Buffer.from(JSON.stringify({})).toString("base64url"),
+      ),
+    X401ValidationError,
+  );
 });
 
-test("verifyChallenge rejects an expired challenge", async () => {
-  const encryptor = newEncryptor();
-  const challenge = await verifier.createChallenge({
-    verifierId: VERIFIER_ID,
-    resource: RESOURCE,
-    method: "GET",
-    encryptor,
-    ttlSeconds: 60,
-    now: new Date(Date.now() - 120_000),
-  });
-  const result = await verifier.verifyChallenge({
-    value: challenge.value,
-    encryptor,
-  });
-  assert.equal(result.ok, false);
-  if (!result.ok) assert.equal(result.reason, "challenge expired");
+test("VP Artifact with a non-https presentation_uri is rejected", () => {
+  const insecure = Buffer.from(
+    JSON.stringify({ presentation_uri: "http://example.com/p/1" }),
+  ).toString("base64url");
+  assert.throws(() => verifier.decodeVPArtifact(insecure), X401ValidationError);
 });
 
-test("verifyChallenge rejects a route mismatch", async () => {
-  const { challenge, encryptor } = await buildRequirement();
-  const result = await verifier.verifyChallenge({
-    value: challenge.value,
-    encryptor,
-    expectedResource: "https://research.example.com/other",
-  });
-  assert.equal(result.ok, false);
+test("VP Artifact with both response and presentation_uri is rejected", () => {
+  const both = Buffer.from(
+    JSON.stringify({
+      response: { protocol: "openid4vp-v1-signed", data: "x" },
+      presentation_uri: "https://example.com/p/1",
+    }),
+  ).toString("base64url");
+  assert.throws(() => verifier.decodeVPArtifact(both), X401ValidationError);
 });
 
-test("token-exchange request build and verifier parse agree on fixed parameters", async () => {
-  const { payload } = await buildRequirement();
-  const detected = agent.detectProofRequirement({
-    headers: { [HEADER.PROOF_REQUIRED]: verifier.encodePayload(payload) },
-  });
-  assert.ok(detected);
+test("token-exchange request build and verifier parse agree on fixed parameters", () => {
   const artifact = agent.buildVPArtifact({
-    payload: detected.payload,
-    agentId: "did:web:agent.example",
-    vpToken: "opaque",
+    response: { protocol: "openid4vp-v1-signed", data: "opaque" },
   });
   const form = agent.buildTokenExchangeForm(artifact, { resource: RESOURCE });
   assert.equal(form.get("grant_type"), TOKEN_EXCHANGE_GRANT_TYPE);
@@ -225,7 +217,21 @@ test("token-exchange request build and verifier parse agree on fixed parameters"
   const parsed = verifier.parseTokenExchange(form);
   assert.equal(parsed.resource, RESOURCE);
   const reDecoded = verifier.decodeVPArtifact(parsed.subject_token);
-  assert.equal(reDecoded.agent_id, "did:web:agent.example");
+  assert.equal(reDecoded.response?.data, "opaque");
+});
+
+test("token-exchange response carrying ACCESS_TOKEN_TYPE parses", () => {
+  assert.equal(
+    ACCESS_TOKEN_TYPE,
+    "urn:ietf:params:oauth:token-type:access_token",
+  );
+  const parsed = agent.parseTokenExchangeResponse({
+    access_token: "verification-token",
+    token_type: "Bearer",
+    issued_token_type: ACCESS_TOKEN_TYPE,
+  });
+  assert.equal(parsed.issued_token_type, ACCESS_TOKEN_TYPE);
+  assert.equal(parsed.token_type, "Bearer");
 });
 
 test("parseTokenExchange rejects a wrong grant_type", () => {
@@ -240,29 +246,55 @@ test("parseTokenExchange rejects a wrong grant_type", () => {
 });
 
 test("token object round-trips through PROOF-PRESENTATION", () => {
-  const header = agent.encodeTokenObject(
-    agent.buildTokenObject("verification-token-123"),
+  const decoded = verifier.decodeTokenObject(
+    agent.encodeTokenObject(agent.buildTokenObject("verification-token-123")),
   );
-  const decoded = verifier.decodeTokenObject(header);
   assert.equal(decoded.token_type, "Bearer");
   assert.equal(decoded.access_token, "verification-token-123");
 });
 
-test("error object round-trips through PROOF-RESPONSE", () => {
-  const encoded = verifier.encodeErrorObject(
-    verifier.buildErrorObject({
-      error: "invalid_presentation",
-      error_description: "nope",
-    }),
+test("token object without a version is rejected", () => {
+  const noVersion = Buffer.from(
+    JSON.stringify({ scheme: "x401", token_type: "Bearer", access_token: "x" }),
+  ).toString("base64url");
+  assert.throws(
+    () => verifier.decodeTokenObject(noVersion),
+    X401ValidationError,
+  );
+});
+
+test("error object without a version is rejected", () => {
+  const noVersion = Buffer.from(
+    JSON.stringify({ scheme: "x401", error: "invalid_presentation" }),
+  ).toString("base64url");
+  assert.throws(() => agent.decodeErrorObject(noVersion), X401ValidationError);
+});
+
+test("embedHtmlData content is directly parseable JSON (quotes not entity-escaped)", () => {
+  const payload = buildRequirement();
+  const html = verifier.embedHtmlData(payload);
+  const inner = html.replace(/^<data[^>]*>/, "").replace(/<\/data>$/, "");
+  assert.equal(inner.includes("&quot;"), false);
+  const parsed = JSON.parse(inner);
+  assert.equal(parsed.$schema, "https://x401.id/spec/schemas/request.json");
+  assert.equal(parsed.scheme, "x401");
+  assert.deepEqual(
+    parsed.presentation_requirements,
+    payload.presentation_requirements,
+  );
+});
+
+test("error object round-trips through PROOF-RESPONSE without a challenge field", () => {
+  const decoded = agent.decodeErrorObject(
+    verifier.encodeErrorObject(
+      verifier.buildErrorObject({
+        error: "invalid_presentation",
+        error_description: "nope",
+        request_id: "proof-template-age-over-21-v1",
+      }),
+    ),
   );
-  const decoded = agent.decodeErrorObject(encoded);
   assert.equal(decoded.error, "invalid_presentation");
   assert.equal(decoded.scheme, "x401");
+  assert.equal("challenge" in decoded, false);
 });
-
-function embed(payload: unknown): string {
-  return JSON.stringify(payload)
-    .replace(/&/g, "&amp;")
-    .replace(/</g, "&lt;")
-    .replace(/>/g, "&gt;");
-}
diff --git a/yarn.lock b/yarn.lock
index 1a221f5..ba36e90 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -219,6 +219,13 @@ acorn@^8.16.0:
   resolved "https://registry.yarnpkg.com/acorn/-/acorn-8.16.0.tgz#4ce79c89be40afe7afe8f3adb902a1f1ce9ac08a"
   integrity sha512-UVJyE9MttOsBQIDKw1skb9nAwQuR5wuGD3+82K6JgJlm/Y+KI92oNsMNGZCYdDsVtRHSak0pcV5Dno5+4jh9sw==
 
+ajv-formats@^3.0.1:
+  version "3.0.1"
+  resolved "https://registry.yarnpkg.com/ajv-formats/-/ajv-formats-3.0.1.tgz#3d5dc762bca17679c3c2ea7e90ad6b7532309578"
+  integrity sha512-8iUql50EUR+uUcdRQ3HDqa6EVyo3docL8g5WJ3FNcWmu62IbkGUue/pEyLBW8VGKKucTPgqeks4fIU1DA4yowQ==
+  dependencies:
+    ajv "^8.0.0"
+
 ajv@^6.14.0:
   version "6.15.0"
   resolved "https://registry.yarnpkg.com/ajv/-/ajv-6.15.0.tgz#07e982c74626167aa7a2495c53817892d7139492"
@@ -229,6 +236,16 @@ ajv@^6.14.0:
     json-schema-traverse "^0.4.1"
     uri-js "^4.2.2"
 
+ajv@^8.0.0, ajv@^8.20.0:
+  version "8.20.0"
+  resolved "https://registry.yarnpkg.com/ajv/-/ajv-8.20.0.tgz#304b3636add88ba7d936760dd50ece006dea95f9"
+  integrity sha512-Thbli+OlOj+iMPYFBVBfJ3OmCAnaSyNn4M1vz9T6Gka5Jt9ba/HIR56joy65tY6kx/FCF5VXNB819Y7/GUrBGA==
+  dependencies:
+    fast-deep-equal "^3.1.3"
+    fast-uri "^3.0.1"
+    json-schema-traverse "^1.0.0"
+    require-from-string "^2.0.2"
+
 balanced-match@^4.0.2:
   version "4.0.4"
   resolved "https://registry.yarnpkg.com/balanced-match/-/balanced-match-4.0.4.tgz#bfb10662feed8196a2c62e7c68e17720c274179a"
@@ -386,6 +403,11 @@ fast-levenshtein@^2.0.6:
   resolved "https://registry.yarnpkg.com/fast-levenshtein/-/fast-levenshtein-2.0.6.tgz#3d8a5c66883a16a30ca8643e851f19baa7797917"
   integrity sha512-DCXu6Ifhqcks7TZKY3Hxp3y6qphY5SJZmrWMDrKcERSOXWQdMhU9Ig/PYrzyw/ul9jOIyh0N4M0tbC5hodg8dw==
 
+fast-uri@^3.0.1:
+  version "3.1.2"
+  resolved "https://registry.yarnpkg.com/fast-uri/-/fast-uri-3.1.2.tgz#8af3d4fc9d3e71b11572cc2673b514a7d1a8c8ec"
+  integrity sha512-rVjf7ArG3LTk+FS6Yw81V1DLuZl1bRbNrev6Tmd/9RaroeeRRJhAt7jg/6YFxbvAQXUCavSoZhPPj6oOx+5KjQ==
+
 fdir@^6.5.0:
   version "6.5.0"
   resolved "https://registry.yarnpkg.com/fdir/-/fdir-6.5.0.tgz#ed2ab967a331ade62f18d077dae192684d50d350"
@@ -478,6 +500,11 @@ json-schema-traverse@^0.4.1:
   resolved "https://registry.yarnpkg.com/json-schema-traverse/-/json-schema-traverse-0.4.1.tgz#69f6a87d9513ab8bb8fe63bdb0979c448e684660"
   integrity sha512-xbbCH5dCYU5T8LcEhhuh7HJ88HXuW3qsI3Y0zOZFKfZEHcpWiHU/Jxzk629Brsab/mMiHQti9wMP+845RPe3Vg==
 
+json-schema-traverse@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.yarnpkg.com/json-schema-traverse/-/json-schema-traverse-1.0.0.tgz#ae7bcb3656ab77a73ba5c49bf654f38e6b6860e2"
+  integrity sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==
+
 json-stable-stringify-without-jsonify@^1.0.1:
   version "1.0.1"
   resolved "https://registry.yarnpkg.com/json-stable-stringify-without-jsonify/-/json-stable-stringify-without-jsonify-1.0.1.tgz#9db7b59496ad3f3cfef30a75142d2d930ad72651"
@@ -610,6 +637,11 @@ punycode@^2.1.0:
   resolved "https://registry.yarnpkg.com/punycode/-/punycode-2.3.1.tgz#027422e2faec0b25e1549c3e1bd8309b9133b6e5"
   integrity sha512-vYt7UD1U9Wg6138shLtLOvdAu+8DsC/ilFtEVHcH+wydcSpNE20AfSOduf6MkRFahL5FY7X1oU7nKVZFtfq8Fg==
 
+require-from-string@^2.0.2:
+  version "2.0.2"
+  resolved "https://registry.yarnpkg.com/require-from-string/-/require-from-string-2.0.2.tgz#89a7fdd938261267318eafe14f9c32e598c36909"
+  integrity sha512-Xf0nWe6RseziFMu+Ap9biiUbmplq6S9/p+7w7YXP/JBHhrUDDUhwa+vANyubuqfZWTveU//DYVGsDG7RKL/vEw==
+
 sade@^1.8.1:
   version "1.8.1"
   resolved "https://registry.yarnpkg.com/sade/-/sade-1.8.1.tgz#0a78e81d658d394887be57d2a409bf703a3b2701"