Agent Delegation Receipts

2.1. Requirements language

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 [BCP14] when, and only when, they appear in all capitals, as shown here.¶

2.2. Definitions

Delegation Receipt: A signed authorization object produced before an agent acts. It binds a scope, boundaries, a validity window, and a hash of the operator's stated instructions to the authorizing key's signature.¶

Grant Layer Authority: The standing delegation: who may do what, within which bounds, for how long. Permissions established at authorization time, defining what an agent is allowed to do in principle. In OAuth deployments this is typically the authorization server's grant, expressed as scopes or rich authorization requests [RFC9396].¶

Execution Layer Evidence: A verifiable, non-repudiable record generated when a specific action is taken, proving the execution was covered by a Grant Layer Authority. A Delegation Receipt is Execution Layer Evidence for the grant it chains to.¶

Receipt Body: The JSON object that is canonicalized and signed to produce a Delegation Receipt. It contains every field listed in Section 4 except the signature values themselves.¶

User (Principal): The human principal whose authority is being delegated. The User's private key is the signing authority for root Delegation Receipts.¶

Operator: The party that builds and deploys the agent. The Operator delivers instructions to the agent at runtime and is bound by the instruction hash committed in the receipt.¶

Agent: The AI system taking actions on behalf of the User. In deployments that enforce this specification, the Agent presents a valid Delegation Receipt before executing an action.¶

Orchestrator: In a multi-agent delegation, the agent (or its controlling key) that issues a sub-receipt to a downstream agent. The Orchestrator signs the sub-receipt.¶

Scope: The set of operations an agent is authorized to perform, expressed either as free text (advisory) or as a structured scopeSchema (machine-enforceable). See Section 8.¶

Boundaries: Prohibitions embedded in a Delegation Receipt that survive any later operator instruction. Boundaries MUST NOT be waived by the Operator.¶

Instruction Hash (instructionsHash): The SHA-256 digest of the Operator's stated instructions at delegation time, after text normalization (Section 4.2). Recomputing it at execution time detects operator instruction drift.¶

Time Window (timeWindow): The validity interval of the receipt, as an object with "start" and "end" ISO 8601 timestamps.¶

Sub-Receipt: A Delegation Receipt issued by an Orchestrator to a downstream agent. It carries "parentReceiptId" in its signed body; its "signerPublicKey" MUST match the parent's "delegateeKey" (holder binding, Section 8.7).¶

Delegation Chain: A root receipt plus zero or more sub-receipts linked by parentReceiptId, each hop narrowing scope. The root is at depth 0. A chain of length zero -- a root receipt with no sub-receipts -- is a complete delegation, called a terminal delegation (Section 8.8), not a degenerate case.¶

Revocation Registry: An append-only store of signed revocation records, consulted before execution. Revocations are permanent.¶

Verifier: The component that checks a receipt (signature, revocation, time window, scope, instruction hash, and chain integrity) before an action executes.¶

2.3. Relationship to Existing Work

This section maps this document's terms to neighboring specifications where the mapping is clean, and states plainly where this draft deliberately differs. Claims about peer specifications that were not verified against the peer's own published text are marked (unverified).¶

AP2 (Google Agent Payments Protocol). AP2's "mandate" is the closest conceptual relative of this document's Delegation Receipt: a signed, user-authorized record of what an agent may do. AP2 expresses mandates as SD-JWT verifiable credentials and chains them for delegation (open mandates signed by the user, closed mandates signed by the agent). This draft adopts "mandate" as an accepted synonym for a Delegation Receipt where the payment context applies. The deliberate difference: AP2 is scoped to payments and commerce and produces pre-transaction authorization evidence. This draft's receipt is a general-purpose authorization and audit artifact that covers arbitrary agent actions, and deployments pair it with a signed log of what was actually done. (AP2 chain details summarized from third-party technical write-ups; the AP2 specification text itself was not directly reviewed for this draft: unverified.)¶

PACT (Decagon Personal Agent Consent & Trust Protocol). PACT defines businesses issuing signed delegation tokens to personal agents over OAuth 2.0 and A2A, with a signed receipt on every reply. PACT's per-reply receipt is a compact JWS carrying grant, user, agent, brand, scopes-used, and action claims. This draft's JWS profile (Section 6) is intentionally compatible in shape with that approach: a compact JWS over a JSON claim set. The deliberate difference: PACT is a consent protocol between a customer, a personal agent, and a business, with short-lived tokens (delegation tokens valid at most an hour, request JWTs at most five minutes). This draft covers user-to-operator delegation with longer windows and adds the pre-execution gate, scope attenuation across agent-to-agent hops, and cascade revocation, which PACT's published material does not define (PACT claim names and lifetimes summarized from an independent spec teardown; the normative PACT text was not directly reviewed: unverified).¶

ERC-8004 ("Trustless Agents"). ERC-8004 defines three on-chain registries: Identity (ERC-721 based agent identifiers), Reputation (feedback signals), and Validation (third-party verification of work). This draft uses "registry" in the same spirit for its revocation registry (Section 9), but the two are different layers: ERC-8004 standardizes who an agent is and what others say about it; this draft standardizes what a specific key authorized a specific agent to do. They are complementary, not overlapping.¶

UCAN (User Controlled Authorization Networks). UCANs are capability tokens (JWTs binding issuer to audience) with "prf" proof chains and attenuation semantics: each delegation may only narrow the capabilities of its parent. This draft's delegation chain and scope attenuation rules (Section 8) follow the same principle, and this document uses "attenuation" in UCAN's sense. The deliberate difference: UCAN is a general capability-token format; this draft adds the receipt-as-audit-trail (instruction pinning, signed action log, revocation registry), which UCAN does not define. (UCAN field details summarized from secondary write-ups; the UCAN specification has been stale since March 2024: unverified.)¶

W3C Verifiable Credentials. AP2's mandates are expressed as SD-JWT VCs. This draft does not use the VC data model: a Delegation Receipt is a JWS (or COSE) over a fixed claim set, not a credential with selective disclosure. Deployments that need selective disclosure should use AP2's mandate format for the payment portions of a workflow and this draft's receipt for the general authorization record.¶

IETF drafts. Two individual drafts cover adjacent ground: draft-liu-agent-operation-authorization (verifiable human delegation of specific operations to AI agents) and draft-mishra-oauth-agent-grants (Delegated Agent Authorization Protocol: persistent agent identity, multi-agent delegation, tamper-evident audit). Both are cited informatively; neither was reviewed in full for this revision (unverified).¶

OAuth 2.0. This document does not compete with the authorization server for the initial human consent event. Where an authorization server (AS) is in the loop, its consent record is the attributable authorization for the first hop. The receipt chain covers what the AS does not see: downstream delegation hops, offline execution, and multi-agent chains with no common AS. The receipt is Execution Layer Evidence (Section 2.4) for a Grant Layer Authority that may originate at an AS; the two compose rather than overlap. A principal-signed root adds one thing an AS consent record does not: proof that the human principal, and not the operator, authorized the delegation, and only when the authorizing key meets the custody requirements of Section 4.6.¶

What this draft does NOT claim: wire-format interoperability with any of the above. No adapter between this draft's receipt format and AP2, PACT, UCAN, or agent-passport Action Receipts has been built or verified. Terminology alignment is not interoperability, and this document does not present it as such.¶

2.4. What a receipt proves

A Delegation Receipt is Execution Layer Evidence [CHEN-AGENT-USE-CASES] for a Grant Layer Authority: it proves that a specific execution was covered by the grant's terms. A verifier checking a receipt answers one question: was this action within the scope, boundaries, and validity window the authorizing key signed, under the instructions committed at issuance? The verifier MUST NOT re-adjudicate the principal's intent per action; intent was settled when the grant was made.¶

Coverage and parameters are proved by different fields, and both are required for the full claim:¶

• Coverage: "scope" / "scopeSchema", "boundaries", and "timeWindow" prove the execution fell inside the grant.¶

• Parameters: "instructionsHash" pins the concrete operator instructions committed at issuance; recomputation at execution time detects drift (Section 4.2).¶

A receipt that proves coverage but whose instructions cannot be reconciled with what was delivered proves an authorized envelope around an unverified action. Deployments that need per-action approval semantics MUST NOT read them into this document: the receipt proves the execution was covered, not that the principal reviewed each action.¶

4.1. Design

A Delegation Receipt is a JSON object [RFC8259]. The receipt body is the set of fields defined in Sections 4.2 and 4.3. The signature values defined in Section 4.4 are attached to the receipt but are NEVER part of the signed body: the JWS or COSE signature is computed over the canonicalized body alone.¶

Every field name below is REQUIRED to appear exactly as written (case-sensitive). The top-level body field set defined in Sections 4.2 and 4.3 is CLOSED. Issuers MUST NOT emit unknown top-level body fields. A verifier that encounters an unknown top-level body field MUST reject the receipt and MUST NOT silently ignore the field or produce an allow: an unrecognized field could be a restriction on authority, and ignoring it would be indistinguishable from widening what was authorized. The reference implementation reports this condition as UNKNOWN_BODY_FIELD with the offending field names appended.¶

The defined extension point is the "metadata" object (Section 4.3). Verifiers MUST ignore unknown fields inside "metadata"; their presence or absence does not change the verification decision. The "metadata" object is part of the signed body (JCS-canonicalized with the rest), so extensions placed there are authenticated but never interpreted.¶

A verifier MUST verify the signature over the exact received signing input. It MUST NOT strip unknown fields, re-canonicalize, and verify against the modified bytes: a receipt whose bytes do not match the canonical form of its recognized fields is rejected.¶

Field types: "string", "boolean", "object", "array of string", "ISO 8601" (a string in RFC 3339 / ISO 8601 UTC form, e.g. "2026-10-09T12:00:00.000Z"), "hex64" (64 lowercase hex characters, a SHA-256 digest), and "JWK" (a JSON Web Key object [RFC7517]).¶

4.2. Required fields

delegationId

(string, REQUIRED): An opaque identifier assigned at issuance. The reference implementation uses the form "auth-<unix-milliseconds>-<5 lowercase hex chars>" with a CSPRNG-backed suffix. It is NOT a hash of the body (this changed from -08, when it was a hash of the body). Verifiers MUST treat it as opaque.¶

issuedAt

(ISO 8601, REQUIRED): The issuance timestamp as asserted by the issuer. This is a claim, not a trusted timestamp; see Section 11 on timestamp limits.¶

scope

(string, REQUIRED): Human-readable description of what the agent is authorized to do (e.g. "read calendar events and draft meeting summaries"). Free-text scope is advisory: it is NOT machine-enforced. Machine enforcement requires "scopeSchema" (Section 4.3). A receipt with only text scope MUST NOT be presented as cryptographically scope-enforced.¶

boundaries

(string, REQUIRED): Human-readable prohibitions the agent MUST NOT violate regardless of operator instruction (e.g. "never send email without explicit confirmation"). Like "scope", this field is advisory text unless mirrored in "scopeSchema"'s deniedActions.¶

timeWindow

(object, REQUIRED): Validity interval with two REQUIRED string members: "start" and "end", both ISO 8601. An action at time T is temporally valid only if start <= T <= end. For a sub-receipt, the child window MUST be contained within the parent window (child.start >= parent.start AND child.end <= parent.end); issuance MUST fail otherwise.¶

operatorInstructions

(string, REQUIRED): The Operator's stated instructions at delegation time, in plaintext.¶

instructionsHash

(hex64, REQUIRED): SHA-256 over the normalized form of "operatorInstructions". Normalization: trim leading/trailing whitespace, lowercase, collapse internal whitespace runs to single spaces, remove commas, remove sentence-final periods, remove straight and curly quote characters, and sort detected key-value pairs alphabetically by key. (This normalization is lossy by design: it detects semantic drift, not byte edits. When the claimed instructions are supplied, verifiers MUST apply the identical normalization before comparing.)¶

signerPublicKey

(JWK, REQUIRED): The public key corresponding to the signing key, as a JWK containing exactly the members "kty", "crv", "x", and "y". The -12 profiles use "kty": "EC", "crv": "P-256". The JWK MUST NOT contain private material. Verifiers MUST confirm the key's "crv" matches the signature algorithm before verifying.¶

4.3. Optional fields

agentId

(string, OPTIONAL): Identifier of the agent being authorized.¶

metadata

(object, OPTIONAL): Arbitrary JSON metadata, stored and signed as-is. This is the defined extension point for fields this document does not define: verifiers MUST ignore the contents of "metadata" for authorization decisions (see Section 4.1), so adding e.g. "metadata.displayLabel" preserves the verification decision. Implementations MUST NOT put secrets here; the body is signed, not encrypted.¶

toolSchemaHash

(hex64, OPTIONAL): SHA-256 of the canonical tool schema the receipt was issued against. When present, verifiers detect tool-schema substitution.¶

trustedSources

(array of string, OPTIONAL): Instruction sources permitted to influence agent behavior, e.g. "user", "system_prompt", "verified_tool". When present, actions driven by an instruction source not in the list MUST be denied.¶

toolOutputHash

(hex64, OPTIONAL): SHA-256 of the expected tool output that triggers the action. When present, verifiers detect tampered tool outputs.¶

programHash

(hex64, OPTIONAL): SHA-256 of the agent program or code the receipt authorizes. When present, verifiers detect code substitution. The hash construction (what bytes are hashed) is deployment-defined; the issuer and verifier MUST use the same construction for the check to be meaningful.¶

revocationRequired

(boolean, OPTIONAL): When true, the receipt REQUIRES a live revocation-registry check. Verifiers operating without registry access MUST deny such receipts (fail closed). See Section 9.4.¶

oneTimeUse

(boolean, OPTIONAL): When true, the receipt authorizes at most one action globally. Enforcement requires a durable, shared consumption store; without one, verifiers MUST deny (fail closed). See Section 9.5.¶

parentReceiptId

(string, OPTIONAL): Present only on sub-receipts. The identifier of the parent receipt. Its presence marks the receipt as a sub-receipt and triggers chain checks (Section 8.7, Section 10).¶

delegateeKey

(JWK, OPTIONAL): The public key of the delegatee -- the party authorized to hold this receipt and mint sub-receipts under it. Same JWK constraints as "signerPublicKey" (Section 4.2): exactly the members "kty", "crv", "x", and "y"; no private material. Present on any receipt under which sub-receipts may be issued. A receipt that carries no "delegateeKey" is terminal: no sub-receipt may be issued under it (Sections 8.7, 8.8).¶

authorityStateCommitment

(hex64, OPTIONAL): SHA-256 commitment over the authority state (roles, groups, entitlements, attributes) at issuance. When present, verifiers can detect authority-state drift.¶

reauthPolicy

(object, OPTIONAL): Re-authorization policy, stored as-is, with OPTIONAL members "secondsBeforeExpiry" (number), "trustScoreBelow" (number), and "onAuthorityStateDrift" (string, "block" or "reauth").¶

scopeSchema

(object, OPTIONAL): Machine-readable structured scope (Section 8.1). When present, it is the enforced scope; the text "scope" field remains advisory.¶

nonce

(string, OPTIONAL): When present on a oneTimeUse receipt, the consumption key is "<receiptId>:<nonce>" instead of the receiptId alone, allowing the same receiptId to be consumed once per nonce.¶

4.4. Attached and derived values

These values travel with the receipt but are NOT part of the signed body and MUST be excluded from canonicalization and signing input.¶

Signature: In the -12 profiles the signature is the JWS (Section 6) or COSE_Sign1 (Section 7) object itself; there is no separate "signature" field inside the body. (Pre-11 implementations attached a "signature" field holding lowercase hex of the DER-encoded ECDSA signature over UTF-8(JSON.stringify(body)); that format is deprecated by this document, precisely because its signing input was not canonical.)¶

orchestratorSignature: DEPRECATED as of -15. The holder-binding rule (Sections 4.3, 8.7) subsumes it: the parent-child link is now bound by the parent's "delegateeKey" matching the child's "signerPublicKey", with "parentReceiptId" in the signed child body. Issuers conforming to this revision MUST NOT emit "orchestratorSignature". Verifiers MUST NOT require it and MUST NOT treat its presence as satisfying holder binding. It remains parseable so pre-15 receipts stay readable for audit; it carries no authorization meaning under this revision.¶

revoked

(boolean): An implementation-local annotation set from the revocation registry. It is not signed and not transmitted.¶

receiptId

(hex64, derived): The profile-neutral identifier of the issued artifact, binding body and signature together: the lowercase-hex SHA-256 digest of the bytes of the issued signed artifact, as computed by the active profile (JWS: Section 6.6; COSE: Section 7). (Before -11 it was the SHA-256 hex of JSON.stringify(body + signature); the definition changed with the -11 wire format.)¶

4.5. The scopeSchema object

When present, "scopeSchema" is an object with:¶

• version (string, default "1.0"): Schema version.¶

• allowedActions (array, REQUIRED): Each entry is an object with REQUIRED "operation" (string) and "resource" (string), and OPTIONAL "constraints" (object). Entries support wildcards (Section 8.2).¶

• deniedActions (array, default []): Same entry shape. Denied entries are evaluated FIRST; denial takes precedence over allowance. An issuer that explicitly allows an action class in "allowedActions" SHOULD omit the corresponding default boundary from "deniedActions": keeping both would silently deny an action the same signed receipt allows.¶

• maxDuration (string, OPTIONAL, e.g. "4h"): Carried for policy use. NOTE: the reference implementation stores but does not enforce maxDuration; verifiers MUST NOT claim enforcement of it.¶

• manifestHash (hex64, OPTIONAL): SHA-256 binding a tool server's capability manifest, so server/manifest divergence is detectable.¶

4.6. Authorizing key requirements

A Delegation Receipt's non-repudiation claim (Section 11.1) holds only if the authorizing key is under the human principal's sole control. For a root receipt to carry that claim, the authorizing key MUST satisfy all of the following:¶

• Non-exportable: the private key MUST NOT be extractable from the store that holds it, by the principal, the operator, or anyone else.¶

• Gated on user verification: each signing operation MUST require an explicit user-verification gesture (for example, a biometric check or PIN entry on a platform authenticator). Cached, standing, or pre-authorized signing sessions MUST NOT satisfy this requirement.¶

• Sole control: no party other than the human principal holds a copy of, or signing access to, the private key.¶

A signing ceremony the agent can complete without the human -- a click-through dialog, a pre-approved auto-signing rule, a standing delegation the agent invokes on its own -- is not a human grant. A receipt produced under such a ceremony MUST NOT be presented as non-repudiable evidence of the human principal's authorization; it is operator-asserted evidence at best, and deployments MUST label it as such where the distinction matters.¶

How these properties are achieved is deployment-defined and out of scope (Section 15). FIDO2 / WebAuthn platform authenticators [WebAuthn] are RECOMMENDED as the mechanism: they provide non-exportable keys gated on user verification as a commodity.¶

The receipt format itself cannot prove key custody from the receipt bytes alone. Custody is attested by the deployment, not proven by the format. A verifier that needs the non-repudiation claim MUST obtain the custody attestation through a channel outside the receipt before treating the receipt as the human principal's act.¶

6.1. Protected header

The JWS Protected Header MUST contain "alg" (Section 6.5) and SHOULD contain "typ" with the value "drp-receipt" (where "drp" abbreviates "delegation receipt"). It MAY contain "kid" to identify the signing key. No other header parameters are defined by this document; verifiers MUST ignore unrecognized parameters except as required by RFC 7515 ("crit" handling).¶

6.2. Payload

The payload is the exact byte string produced by Section 5. It is a JSON object and nothing else. Verifiers MUST parse the payload, confirm it is an object, and validate every field per Section 4 before applying any authorization logic.¶

6.3. Compact serialization

The standard form is the JWS Compact Serialization [RFC7515]:¶

BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)

For ECDSA signatures the JWS Signature value is the raw fixed-length concatenation R || S (64 bytes for P-256), base64url encoded per [RFC7518] Section 3.4. DER-encoded signatures MUST be rejected: they are the pre-11 format and are not valid -12 JWS.¶

6.4. Detached serialization

When the receipt body travels separately from its signature (e.g. the body is already stored under its receiptId), the JWS MAY use the detached form with an unencoded payload [RFC7797]: the Protected Header MUST contain "b64": false and "crit": ["b64"], and the signing input is¶

ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || JWS Payload)

with the payload bytes used raw. The compact transmission form is then header..signature (empty payload segment), and the verifier supplies the payload bytes out of band. The payload bytes supplied MUST be byte-identical to the JCS form; any deviation fails verification.¶

6.5. Algorithm registry

• ES256 (ECDSA P-256 with SHA-256, [RFC7518]): REQUIRED. This is the only algorithm the reference implementation issues and verifies. All conforming implementations MUST support ES256 for verification and SHOULD use it for issuance.¶

• ES384, ES512 ([RFC7518]): OPTIONAL.¶

• EdDSA (Ed25519, [RFC8037]): OPTIONAL. (Reference-implementation test vectors cover Ed25519; second-implementation interop evidence is P-256 only.)¶

• RS256, PS256 ([RFC7518]): OPTIONAL, NOT RECOMMENDED for new deployments (larger keys and signatures for no benefit here).¶

• "none": PROHIBITED. Verifiers MUST reject unsecured JWS.¶

No other "alg" values are defined by this document.¶

6.6. Receipt identifier

The "receiptId" of a receipt is the lowercase hex SHA-256 digest of the ASCII bytes of its JWS Compact Serialization. For the detached form, the digest is computed over the bytes a compact serialization of the same receipt would contain: the ASCII of the protected-header segment, a period, BASE64URL(JCS body bytes), a period, and the signature segment. The receiptId binds the issued artifact (body plus signature); the same body signed by two keys yields two receiptIds.¶

Issuers MUST follow this computation order, which admits no circularity: (1) assemble the body fields (Sections 4.2, 4.3); the "receiptId" is not yet defined and plays no part; (2) canonicalize the body per Section 5 and sign the profile signing input ([RFC7515] Section 5.1), producing the signature; (3) assemble the JWS Compact Serialization (Section 6.3); (4) compute the "receiptId" as the SHA-256 hex digest of the ASCII bytes of that serialization. No step consumes a value produced by a later step.¶

8.1. Structured scopes

A "scopeSchema" (Section 4.5) is the machine-enforceable scope. An action is described as { operation, resource, constraints? }. To test an action against a schema: first check "deniedActions"; if any entry matches, the action is denied. Then check "allowedActions"; if any entry matches (and its constraints hold), the action is allowed. Otherwise the action is denied. Default-deny: anything not listed is not permitted.¶

8.2. Wildcard matching

Operation patterns: "*" matches any operation; otherwise exact string equality is required.¶

Resource patterns: "*" matches anything. A pattern containing "*" is a glob: the "*" segments match any character sequence, anchored at both ends (e.g. "files/*" matches "files/report.pdf" but not "files"; "*.company.com" matches "mail.company.com"). Non-wildcard patterns require exact equality.¶

8.3. Constraints

An "allowedActions" entry MAY carry "constraints", an object mapping parameter names to limits. Two limit forms are defined: a number (the action's parameter value MUST NOT exceed it, e.g. { "maxEvents": 10 }), and a wildcard string pattern (a string parameter MUST match it, e.g. { "sender": "*.company.com" }). Parameters absent from the action are skipped. A constraint violation denies the action.¶

8.4. Text scope is advisory

The "scope" and "boundaries" string fields, and any keyword-overlap heuristic over them, are advisory signals for observability only. They MUST NOT gate allow/deny decisions. Real scope enforcement REQUIRES a "scopeSchema".¶

8.5. Attenuation rules

When both the parent and child receipts carry "scopeSchema" and an Orchestrator issues a sub-receipt, the child scope MUST be a strict proper subset of the parent scope. The check operates on literal "operation::resource" keys (exact string comparison; wildcard patterns are compared as literal strings, not expanded):¶

1. Every entry in the child's "allowedActions" MUST have its "operation::resource" key present in the parent's "allowedActions". An agent MUST NOT grant what it was not given.¶

2. The child MUST have strictly fewer "allowedActions" entries than the parent. Equal scope is rejected: delegation MUST narrow.¶

3. Every entry in the parent's "deniedActions" MUST be present in the child's "deniedActions" with constraints equal or broader: the child's denial MUST cover at least the authority the parent's denial covered (a denial pattern in the child MUST match every string the parent's pattern matched, and a numeric denial bound in the child MUST NOT be smaller than the parent's). A child MAY add denials but MUST NOT drop or narrow any.¶

4. For each constraint key in a parent entry for an "operation::resource" key, the child entry for the same key MUST carry that constraint key with a value authorizing no more than the parent's: a numeric limit in the child MUST NOT exceed the parent's value, and a wildcard pattern in the child MUST NOT match strings the parent's pattern does not match. Dropping or renaming a parent constraint key is a violation: for constraints, fewer keys means more authority. Profiles MAY define narrowing for other constraint value forms.¶

Violation MUST abort issuance; the reference implementation raises a scope-attenuation error before signing. Attenuation is checked at issuance AND re-checked by verifiers walking the chain.¶

Note: because the comparison is on literal keys, a child entry "read::calendar/events" is NOT covered by a parent entry "read::calendar/*". Wildcard-aware subset reasoning is out of scope for -12; deployments needing it must carry the identical pattern string down the chain.¶

8.6. Depth limit

The root receipt is at depth 0; each delegation hop adds 1. A delegation that would place a receipt at depth >= maxDepth MUST be rejected before signing. The default maxDepth is 3, so a default chain holds the root (depth 0) and at most two delegation levels (depths 1 and 2). Verifiers walking a chain MUST deny with CHAIN_DEPTH_EXCEEDED when the walked depth is greater than or equal to their configured maximum (default 3). maxDepth is a deployment parameter, not a receipt field: the receipt carries "parentReceiptId" links, and depth is counted by walking them.¶

8.7. Sub-receipt issuance

Issuing a sub-receipt MUST follow this sequence:¶

1. Holder binding: if the parent body carries no "delegateeKey", the parent is terminal and issuance MUST fail. Otherwise the issuer's signing key MUST be the key named in the parent's "delegateeKey" (compared as [RFC7638] SHA-256 thumbprints); issuance MUST fail on mismatch. The child body MUST carry "parentReceiptId" and its own "signerPublicKey", which is the key just matched.¶

2. Resolve the parent's scope ("scopeSchema" if present, else the text "scope" field; structured scope is REQUIRED for machine-checked attenuation).¶

3. Verify the child scope against Section 8.5 when both receipts carry "scopeSchema" (otherwise the text-scope advisory rules of Section 8.4 apply) and the child timeWindow against the parent window (Section 4.2).¶

4. Build the child body including "parentReceiptId", sign it per the active profile (Section 6 or 7).¶

5. Compute the child "receiptId" (Sections 6.6, 7). No further binding artifact is needed: the parent-child link is established by the child's "parentReceiptId" in the signed body together with the holder-binding key match of step 1. Issuers conforming to this revision MUST NOT emit "orchestratorSignature" (Section 4.4).¶

Schema parity across delegation hops: sub-receipt issuance without "scopeSchema" MUST fail unless the parent receipt also carries no "scopeSchema", in which case only the text-scope advisory rules of Section 8.4 apply and the sub-receipt MUST NOT be presented as cryptographically scope-enforced (Section 4.2). Verifiers walking the chain MUST enforce this parity; a parity failure denies the action.¶

Verifiers MUST check, for any receipt carrying "parentReceiptId": the parent's signature is valid; the parent body carries a "delegateeKey" (a parent without one is terminal, and any child presented under it MUST be denied); the sub-receipt's "signerPublicKey" matches the parent's "delegateeKey" ([RFC7638] SHA-256 thumbprint comparison); the child window is contained in the parent window; the child scope attenuates per Section 8.5 when both receipts carry "scopeSchema" (otherwise the text-scope advisory rules of Section 8.4 apply); and no ancestor is revoked (Section 9.3). Any failure denies the action.¶

Cross-format chains: a sub-receipt presented under a parent expressed in a receipt format with no delegateeKey concept MUST be denied. Holder binding cannot be evaluated across formats, so the chain cannot be verified.¶

Receipts carry no wire version marker, so a pre-15 receipt and a receipt that is terminal by intent are indistinguishable on the wire; both are terminal, and issuance of a sub-receipt under either MUST fail. There is no grandfathering of pre-15 chains.¶

A parallel key-binding mechanism appears in [WEI-AIC-JWT] as "da.agent_key_binding.key_hash", where the verifier requires the presenting key to match the bound hash before accepting the token. The mechanisms differ in key representation (SPKI hash there, [RFC7638] thumbprint here) and in that this document applies the check at every delegation hop.¶

8.8. Terminal delegation

A delegation terminates at the delegate when the authorizing party intends no further sub-delegation. A receipt with no sub-receipts is a complete, verifiable delegation on its own: verifiers apply Sections 4-7 and 9 without chain walking.¶

Cryptographic termination: a receipt that carries no "delegateeKey" (Section 4.3) is terminal. Issuance of a sub-receipt under a terminal receipt MUST fail (Section 8.7). Deployments that intend a delegation to be non-delegable SHOULD omit "delegateeKey" rather than relying on policy alone.¶

9.1. Registry model

Revocation state lives in a Revocation Registry: an append-only store mapping receiptIds to signed revocation records. The registry is consulted by verifiers before execution (after signature verification). The registry interface is two operations: "check(receiptId)" returning { revoked, reason?, revokedAt? }, and "revoke(receiptId, { reason?, revokedAt? })" creating a signed record. Revocation is permanent: the registry MUST NOT provide un-revocation, and "revoke" on an already-revoked receiptId MUST fail.¶

This document defines the record format and check semantics. How revocation records are distributed to verifiers (the revocation distribution protocol) is explicitly out of scope (Section 15); deployments without a distribution story have an unsolved window between revocation and enforcement, and MUST say so.¶

9.2. Revocation record

A revocation record contains: "receiptHash" (the receiptId), "reason" (string), "revokedAt" (Unix milliseconds), "revokedBy" (the revoker's public JWK), and a signature over the record by the revoker's key (a JWS in -12 deployments). Records MUST be signature-verified before import into a registry; records with invalid signatures MUST be skipped and reported. The "revokedAt" time in the signed revocation record establishes the authoritative revocation time: actions taken before it remain valid; actions attempted after it MUST fail.¶

9.3. Cascade revocation

Revoking any receipt in a delegation chain denies all of its descendants. Verifiers enforce the cascade live at check time: when checking a sub-receipt, the verifier walks every ancestor via "parentReceiptId" links and consults the registry for each; any revoked ancestor denies the child with ANCESTOR_REVOKED. This holds regardless of which API created the revocation: a parent revoked through any path still denies its children at the gate. A registry or chain manager MAY also eagerly mark descendants revoked (breadth-first traversal), but eager marking is an optimization; the gate's ancestor walk is the normative enforcement.¶

9.4. Offline behavior

A verifier without registry access (offline mode) MUST NOT treat "unknown" as "not revoked". The rule is fail-closed: any receipt with "revocationRequired": true is denied immediately (REVOCATION_CHECK_REQUIRED), and any walked ancestor carrying "revocationRequired": true denies the whole subtree (ANCESTOR_REVOCATION_CHECK_REQUIRED). Receipts without the flag are checked against whatever registry state is locally available; a deployment that cannot reach its registry SHOULD treat the gap as a declared risk, not as silent approval.¶

9.5. One-time-use receipts

A receipt with "oneTimeUse": true authorizes at most one action globally. Consumption MUST be attempted only after every other check has passed, so a consumption slot is never burned on a receipt that would be denied for another reason. Enforcement requires a durable, shared consumption store: without one, the verifier MUST deny with CONSUMPTION_STORE_REQUIRED (fail closed), because an in-memory or per-instance store cannot guarantee global uniqueness. An already consumed receipt is denied with RECEIPT_ALREADY_CONSUMED. The consumption key is the receiptId, or "<receiptId>:<nonce>" when the receipt carries "nonce".¶

11.1. Threat model

Compromised operator instructions. An attacker who alters the instructions delivered to the agent produces an instruction hash mismatch at Check 5. They cannot forge a passing hash without the User's private key.¶

Scope widening by the operator. The signed scope and, when the receipt carries it, the signed program hash always win over unsigned operator log metadata; disagreement denies the action (SCOPE_METADATA_MISMATCH / PROGRAM_METADATA_MISMATCH). An operator who can write to the log cannot widen scope without invalidating the receipt signature.¶

Revoked credential reuse. The registry check (Check 2) and the ancestor walk (Check 14) deny revoked receipts and their descendants. Revocation records are signed and permanent.¶

Prompt injection via untrusted channels. "trustedSources" (Check 11) lets the User restrict which input channels may drive behavior; actions from unlisted sources are denied. This controls which channels can act, not whether a trusted channel carries a malicious payload.¶

Code and tool substitution. "toolSchemaHash" (Check 8), "toolOutputHash" (Check 10), and the program hash (Check 6, when present) bind the receipt to the exact tools and code it was issued against.¶

Replay. One-time-use receipts (Section 9.5) give at-most-once semantics when backed by a durable store. The gate additionally blocks concurrent duplicate checks on the same receipt hash. Beyond that, receipts are bearer instruments: possession plus a valid signature authorizes, and general replay protection across deployments is out of scope.¶

Non-repudiation. Under the EUF-CMA unforgeability of ECDSA P-256, a valid receipt on the log is non-repudiable evidence that the key holder authorized the body content. This is evidence, not prevention.¶

Rogue operator root. The non-repudiation claim above is about the key holder, not necessarily the human principal. An operator who holds (or can invoke) the authorizing key can sign a well-formed root receipt the human never saw. Section 4.6 states the key-custody properties under which the key holder and the human principal coincide; without them, a valid signature proves only that whoever held the key signed.¶

11.2. Limitations

What receipts cannot do, stated without hedging:¶

• No control over malicious operators. The verifier is same-process software in the reference implementation. An operator who controls the runtime can simply not call it. The receipt is an audit and attribution layer for honest deployments: it makes misbehavior provable, not impossible. Any claim that this protocol "sits outside the agent runtime" or constrains a malicious operator is false for the reference implementation.¶

• Revocation distribution is unsolved. The registry model (Section 9) defines records and check semantics, not distribution. Until a distribution protocol exists, there is a window between revocation and enforcement that this document does not close.¶

• Timestamps are presence-checked, not verified. Where the implementation touches RFC 3161 timestamp tokens, it confirms only that the token bytes contain the entry digest. It does NOT verify the TSA's signature or certificate chain; a forged token embedding the digest would pass. Full TSA signature verification is out of scope. The word "verified" MUST NOT appear next to RFC 3161 or TSA claims without this qualification.¶

• No hardware attestation. TEE and model-state features in the reference implementation are software-computed, self-attested measurements for audit and tamper-evidence in honest deployments, not hardware-rooted attestation. Hardware guarantees require real TEE hardware and are not provided.¶

• Text scope is not enforced. Free-text "scope" and "boundaries" are advisory. Only "scopeSchema" is machine-enforced.¶

• Instruction-drift check can be skipped. If the caller does not supply the operator's claimed instructions, Check 5 is skipped with a warning; drift is then unverified for that call.¶

• Guided scope discovery auto-approves. The one-call guided delegation flow approves the full observed scope with no human review unless a review hook is supplied. It is observation, not authorization.¶

• Key management is the deployer's problem. Generation, storage, rotation, and custody are out of scope (Section 15). A compromised signing key voids every guarantee in this document. Section 4.6 now specifies the properties the authorizing key MUST have for the non-repudiation claim to hold; the mechanisms that achieve those properties remain the deployer's problem.¶

• Key-to-user binding is out-of-band. The "signerPublicKey" carried in the signed body is self-asserted: a valid signature proves the key holder authorized the body, not that the key holder is the claimed User. Verifiers MUST obtain the authorizing public key through a trusted out-of-band channel or equivalent trust anchor (for example a pinned key directory, an account-bound key ceremony, or a key commitment recorded in the append-only log) and MUST confirm the receipt's "signerPublicKey" matches it before relying on the receipt. A receipt whose signer key is not anchored to the claimed User proves nothing about that User's authorization.¶

• Bearer semantics. Apart from one-time-use with a durable store, a valid receipt presented twice is valid twice.¶

16.1. Normative References

[BCP14]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", Best Current Practice 14, BCP 14, RFC 2119, RFC 8174, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7517]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Key (JWK)", RFC 7517, May 2015, <https://www.rfc-editor.org/rfc/rfc7517>.

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, May 2015, <https://www.rfc-editor.org/rfc/rfc7518>.

[RFC7797]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS) Unencoded Payload Option", RFC 7797, February 2016, <https://www.rfc-editor.org/rfc/rfc7797>.

[RFC8037]

Ligur, I. and Y. Sheffer, "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, January 2017, <https://www.rfc-editor.org/rfc/rfc8037>.

[RFC8259]

Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8785]

Rondinelli, E. and S. Miller, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "Rich Authorization Requests (RAR)", RFC 9396, February 2024, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.

16.2. Informative References

[AP2]

Google, "Google Agent Payments Protocol (AP2): signed mandates for agent payments, expressed as SD-JWT verifiable credentials with delegation chains".

[PACT]

Decagon, "Personal Agent Consent & Trust Protocol (PACT)", October 2026.

[ERC-8004]

Ethereum, "ERC-8004: Trustless Agents", <https://eips.ethereum.org/EIPS/eip-8004>.

[UCAN]

UCAN Working Group, "User Controlled Authorization Networks (UCAN): capability tokens with proof chains and attenuation", <https://github.com/ucan-wg/spec>.

[W3C-VC]

W3C, "Verifiable Credentials Data Model", W3C Recommendation.

[WebAuthn]

W3C, "Web Authentication: An API for accessing Public Key Credentials Level 2", W3C Recommendation, April 2021.

[AGENT-PASSPORT]

agent-passport-system, "Action Receipts v1.1".

[DAAP]

Mishra, "Delegated Agent Authorization Protocol (DAAP)", Work in Progress, Internet-Draft, draft-mishra-oauth-agent-grants, <https://datatracker.ietf.org/doc/html/draft-mishra-oauth-agent-grants>.

[LIU-AUTH]

Liu, "Agent Operation Authorization", Work in Progress, Internet-Draft, draft-liu-agent-operation-authorization, <https://datatracker.ietf.org/doc/html/draft-liu-agent-operation-authorization>.

[CHEN-AGENT-USE-CASES]

Chen, M., Chen, J., Yao, J., Jiang, Y., Liu, C.P., and X. Liu, "Agent Authorization use cases and gap analysis", Work in Progress, Internet-Draft, draft-chen-oauth-agent-authz-use-cases, October 2026, <https://datatracker.ietf.org/doc/html/draft-chen-oauth-agent-authz-use-cases>.

[WEI-AIC-JWT]

Wei, J., "AI Agent Identity Certificate (AIC) JSON Web Token Profile", Work in Progress, Internet-Draft, draft-wei-aic-jwt, October 2026, <https://datatracker.ietf.org/doc/html/draft-wei-aic-jwt>.

[AGENTLEDGER]

Chengyue2025, "agentledger: tamper-evident evidence ledger for AI agents", Independent Python implementation of this draft; interop feedback filed as INTEROP-15, October 2026, <https://github.com/Chengyue2025/agentledger>.

[EU2122]

Klassen, B.N., "EU2122 V1.0 Standard: Content Profile for AI Output Verification Receipts", Content profile for verification receipts; cites this draft informatively, Work in Progress, Internet-Draft, draft-klassen-eu2122-content-profile, October 2026, <https://datatracker.ietf.org/doc/draft-klassen-eu2122-content-profile/>.

[INTEROP-15]

Chengyue2025, "Interop feedback from an independent implementation", authproof-sdk issue 15: three specification ambiguities found while implementing draft -12, plus an interop corpus exchange offer, October 2026, <https://github.com/Commonguy25/authproof-sdk/issues/15>.

[RFC3161]

Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001, <https://www.rfc-editor.org/rfc/rfc3161>.

[RFC6962]

Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013, <https://www.rfc-editor.org/rfc/rfc6962>.

A.1. The receipt (presentation form)

{
  "delegationId": "auth-1790000000000-a1b2c",
  "issuedAt": "2026-10-09T12:00:00.000Z",
  "scope": "read calendar events and draft meeting summaries",
  "boundaries": "never send email without explicit confirmation; never delete calendar events",
  "timeWindow": {
    "start": "2026-10-09T12:00:00.000Z",
    "end": "2026-10-09T13:00:00.000Z"
  },
  "operatorInstructions": "Read today's calendar events and draft a summary for the 2pm standup.",
  "instructionsHash": "c730de758e586e19a81098fa1cd40721162da9817fa7f7e651524a27c93ee4fb",
  "signerPublicKey": {
    "kty": "EC",
    "crv": "P-256",
    "x": "8bwgL5U3l0I7nkbcTJRcjzTeV0n6Wzcgm-KStQwbHEo",
    "y": "7SMrWmxPetYwa0LvAX4tpGA1OkEVBtkvhqh_oLh3-28"
  },
  "agentId": "calendar-agent-01",
  "metadata": {
    "session": "demo-001"
  },
  "trustedSources": [
    "user",
    "system_prompt"
  ],
  "scopeSchema": {
    "allowedActions": [
      {
        "operation": "read",
        "resource": "calendar/events"
      },
      {
        "constraints": {
          "maxEvents": 10
        },
        "operation": "write",
        "resource": "calendar/drafts"
      }
    ],
    "deniedActions": [
      {
        "operation": "delete",
        "resource": "calendar/events"
      }
    ],
    "version": "1.0"
  }
}

The "instructionsHash" is SHA-256 over the normalized instructions ("read today's calendar events and draft a summary for the 2pm standup." lowercased, punctuation-stripped per Section 4.2).¶

A.2. JCS canonical form

Canonicalized per RFC 8785 (keys sorted, no whitespace). This exact byte string is the JWS payload:¶

{"agentId":"calendar-agent-01","boundaries":"never send email without explicit confirmation; never delete calendar events","delegationId":"auth-1790000000000-a1b2c","instructionsHash":"c730de758e586e19a81098fa1cd40721162da9817fa7f7e651524a27c93ee4fb","issuedAt":"2026-10-09T12:00:00.000Z","metadata":{"session":"demo-001"},"operatorInstructions":"Read today's calendar events and draft a summary for the 2pm standup.","scope":"read calendar events and draft meeting summaries","scopeSchema":{"allowedActions":[{"operation":"read","resource":"calendar/events"},{"constraints":{"maxEvents":10},"operation":"write","resource":"calendar/drafts"}],"deniedActions":[{"operation":"delete","resource":"calendar/events"}],"version":"1.0"},"signerPublicKey":{"crv":"P-256","kty":"EC","x":"8bwgL5U3l0I7nkbcTJRcjzTeV0n6Wzcgm-KStQwbHEo","y":"7SMrWmxPetYwa0LvAX4tpGA1OkEVBtkvhqh_oLh3-28"},"timeWindow":{"end":"2026-10-09T13:00:00.000Z","start":"2026-10-09T12:00:00.000Z"},"trustedSources":["user","system_prompt"]}

Note the key ordering ("agentId" before "boundaries", "end" before "start" inside "timeWindow"): byte order follows UTF-16 code unit sorting, not the presentation order of Section A.1.¶

A.3. JWS compact serialization (ES256)

Protected header: {"alg":"ES256","typ":"drp-receipt"}, base64url: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRycC1yZWNlaXB0In0¶

The full compact serialization (header.payload.signature), EXAMPLE:¶

eyJhbGciOiJFUzI1NiIsInR5cCI6ImRycC1yZWNlaXB0In0.eyJhZ2VudElkIjoiY2FsZW5kYXItYWdlbnQtMDEiLCJib3VuZGFyaWVzIjoibmV2ZXIgc2VuZCBlbWFpbCB3aXRob3V0IGV4cGxpY2l0IGNvbmZpcm1hdGlvbjsgbmV2ZXIgZGVsZXRlIGNhbGVuZGFyIGV2ZW50cyIsImRlbGVnYXRpb25JZCI6ImF1dGgtMTc5MDAwMDAwMDAwMC1hMWIyYyIsImluc3RydWN0aW9uc0hhc2giOiJjNzMwZGU3NThlNTg2ZTE5YTgxMDk4ZmExY2Q0MDcyMTE2MmRhOTgxN2ZhN2Y3ZTY1MTUyNGEyN2M5M2VlNGZiIiwiaXNzdWVkQXQiOiIyMDI2LTEwLTA5VDEyOjAwOjAwLjAwMFoiLCJtZXRhZGF0YSI6eyJzZXNzaW9uIjoiZGVtby0wMDEifSwib3BlcmF0b3JJbnN0cnVjdGlvbnMiOiJSZWFkIHRvZGF5J3MgY2FsZW5kYXIgZXZlbnRzIGFuZCBkcmFmdCBhIHN1bW1hcnkgZm9yIHRoZSAycG0gc3RhbmR1cC4iLCJzY29wZSI6InJlYWQgY2FsZW5kYXIgZXZlbnRzIGFuZCBkcmFmdCBtZWV0aW5nIHN1bW1hcmllcyIsInNjb3BlU2NoZW1hIjp7ImFsbG93ZWRBY3Rpb25zIjpbeyJvcGVyYXRpb24iOiJyZWFkIiwicmVzb3VyY2UiOiJjYWxlbmRhci9ldmVudHMifSx7ImNvbnN0cmFpbnRzIjp7Im1heEV2ZW50cyI6MTB9LCJvcGVyYXRpb24iOiJ3cml0ZSIsInJlc291cmNlIjoiY2FsZW5kYXIvZHJhZnRzIn1dLCJkZW5pZWRBY3Rpb25zIjpbeyJvcGVyYXRpb24iOiJkZWxldGUiLCJyZXNvdXJjZSI6ImNhbGVuZGFyL2V2ZW50cyJ9XSwidmVyc2lvbiI6IjEuMCJ9LCJzaWduZXJQdWJsaWNLZXkiOnsiY3J2IjoiUC0yNTYiLCJrdHkiOiJFQyIsIngiOiI4YndnTDVVM2wwSTdua2JjVEpSY2p6VGVWMG42V3pjZ20tS1N0UXdiSEVvIiwieSI6IjdTTXJXbXhQZXRZd2EwTHZBWDR0cEdBMU9rRVZCdGt2aHFoX29MaDMtMjgifSwidGltZVdpbmRvdyI6eyJlbmQiOiIyMDI2LTEwLTA5VDEzOjAwOjAwLjAwMFoiLCJzdGFydCI6IjIwMjYtMTAtMDlUMTI6MDA6MDAuMDAwWiJ9LCJ0cnVzdGVkU291cmNlcyI6WyJ1c2VyIiwic3lzdGVtX3Byb21wdCJdfQ.x-25GCeZP17YIXVxETe10cwsg2_Qui7X412Ubx0q64H4uq6jta8f1n4O9bqOeFLaVArHCgwv--_TuscMJwttlw

The signature is the raw 64-byte R||S concatenation required by Section 6.3 (RFC 7518 Section 3.4). The receiptId is the SHA-256 hex of the ASCII bytes of that string:¶

061cef91d98ef21ad9ba2550f1d71b8e16717c97e008282d6a10523a7a838199

A.4. Detached form (RFC 7797)

With header {"alg":"ES256","b64":false,"crit":["b64"]} and the same JCS bytes supplied out of band, the transmitted form is header..signature (EXAMPLE):¶

eyJhbGciOiJFUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..T_iG4gR4ms4pMp5RXGz7NNieNQkF_9oBwEYCFZWZ7Kig_WWUaLlFhvWS_wvpw3-B8HQww7dq1KiLgaDRkitvUw

A.5. Example key (DO NOT USE)

Public JWK:¶

{
  "kty": "EC",
  "crv": "P-256",
  "x": "8bwgL5U3l0I7nkbcTJRcjzTeV0n6Wzcgm-KStQwbHEo",
  "y": "7SMrWmxPetYwa0LvAX4tpGA1OkEVBtkvhqh_oLh3-28"
}

The corresponding private "d" value (published so the example is reproducible; throwaway): nvTRYETQC0GN4fA2Q8Fe9am6PG8xlfXqXsjvs1eeaZw.¶

To re-verify: base64url-decode the payload segment, confirm it is byte-identical to the JCS form in Section A.2, then verify the ES256 signature over ASCII(headerSegment || "." || payloadSegment) with the public JWK above, using the raw 64-byte R||S form per RFC 7518 Section 3.4.¶