Independent Submission V. Research Internet-Draft Vauban Research Intended status: Informational 25 May 2026 Expires: 26 November 2026 x402 Delegation Binding for Agentic HTTP Pipelines draft-vauban-x402-delegation-binding-01 Abstract Agent-to-agent HTTP payment pipelines built on x402 V2 require a mechanism to bind a DelegationGrant receipt to the identity of the delegatee agent that will consume it. Existing x402 DelegationGrant fields (as defined in [LIFECYCLE-FSM]) constrain spend scope and expiry but do not cryptographically bind the grant to an agent identity token recognised by A2A or MCP agent protocol layers. Without this binding, a grant issued to one agent can be replayed by another agent with different authority bounds, enabling undetected privilege escalation in automated payment pipelines. This document defines a delegation binding extension for x402 V2 DelegationGrant receipts. The extension introduces a delegate_pseudonym field derived from the agent's identity via the JCS canonical preimage discipline ([RFC8785]), a structured set of spend-cap and scope fields, and a delegation_nonce that enables nullifier consumption on revocation. The binding is cross-validated against 18 bounded-spend vectors in five language runtimes ([X402-2432]). Integration notes are provided for A2A Composable Trust Evidence Format ([A2A-CTEF]) and MCP agent protocol surfaces ([VAUBAN-DEMO]). This document is the fourth companion in the Vauban Pay normative quartet: format ([STARK-RECEIPTS]), lifecycle FSM ([LIFECYCLE-FSM]), and delegation binding (this document); the algebra companion draft-vauban-x402-vpsf-algebra is in preparation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Research Expires 26 November 2026 [Page 1] Internet-Draft x402-delegation-binding May 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Agent Credential Gap . . . . . . . . . . . . . . . . 3 1.2. The Binding Solution . . . . . . . . . . . . . . . . . . 4 1.3. Relationship to Companion Documents . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Delegation Binding Format . . . . . . . . . . . . . . . . . . 6 4.1. Binding Fields . . . . . . . . . . . . . . . . . . . . . 6 4.2. felt252 Decimal Encoding . . . . . . . . . . . . . . . . 8 4.3. u256 Decimal Encoding . . . . . . . . . . . . . . . . . . 8 5. Agent Identity Binding . . . . . . . . . . . . . . . . . . . 8 5.1. Pseudonym Derivation . . . . . . . . . . . . . . . . . . 8 5.2. Nullifier Consumption Discipline . . . . . . . . . . . . 9 5.3. Revocation Propagation . . . . . . . . . . . . . . . . . 10 5.4. Chain Depth Enforcement . . . . . . . . . . . . . . . . . 10 6. A2A Integration Notes . . . . . . . . . . . . . . . . . . . . 11 7. MCP Agent Protocol Notes . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8.1. Agent Identity Spoofing . . . . . . . . . . . . . . . . . 13 8.2. Spend Cap Inflation . . . . . . . . . . . . . . . . . . . 13 8.3. Nullifier Replay . . . . . . . . . . . . . . . . . . . . 13 8.4. Chain Depth Attack . . . . . . . . . . . . . . . . . . . 14 8.5. Cross-Format Confusion . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 Research Expires 26 November 2026 [Page 2] Internet-Draft x402-delegation-binding May 2026 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Worked Example: MCP Agent Delegation Cycle . . . . . 16 A.1. Step 1: Grant Issuance . . . . . . . . . . . . . . . . . 16 A.2. Step 2: PaymentIntent Binding . . . . . . . . . . . . . . 17 A.3. Step 3: Facilitator Verification . . . . . . . . . . . . 18 Appendix B. Error Token Reference . . . . . . . . . . . . . . . 18 Known Adopters and Reference Implementations . . . . . . . . . . 20 Primary Maintainer . . . . . . . . . . . . . . . . . . . . . . 20 Reference Implementation Matrix . . . . . . . . . . . . . . . . 20 Adoption Process . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction 1.1. The Agent Credential Gap The x402 protocol ([X402-V2]) DelegationGrant state defined in [LIFECYCLE-FSM] enables a principal to pre-authorise an agent to spawn PaymentIntents within a scoped set of constraints. The FSM defines the side-channel role of DelegationGrant, its scope enforcement requirements, and its linkage to downstream PaymentIntents via the JCS canonical preimage discipline ([RFC8785]). However, neither the FSM nor the receipt format extension ([STARK-RECEIPTS]) specifies how the DelegationGrant is cryptographically bound to the identity of the delegatee agent. The delegatee field in the FSM is defined as "address or pseudonym of the agent receiving authority"; it is a free-form string. A facilitator verifying a PaymentIntent that claims to operate under a DelegationGrant has no normative mechanism to confirm that the presenting agent is the intended delegatee, beyond comparing an unverified string. This creates the agent credential gap: the delegation chain is semantically correct but identity-unbound. In agentic HTTP pipelines where multiple autonomous agents share a session, this gap enables grant-capture attacks. Agent A is granted authority over a merchant set with a given spend cap. Agent B, operating in the same pipeline with different authority bounds, intercepts the DelegationGrant receipt and presents it as its own credential. The facilitator, comparing only the free-form delegatee string, cannot distinguish the impersonation. Research Expires 26 November 2026 [Page 3] Internet-Draft x402-delegation-binding May 2026 1.2. The Binding Solution This document closes the agent credential gap by introducing a delegation binding layer above the FSM DelegationGrant field set. The binding is achieved via three mechanisms operating in concert: 1. A delegate_pseudonym field derived from the agent's identity via the shared JCS canonical preimage discipline ([RFC8785]). The pseudonym is a felt252-sized opaque value; it does not reveal the underlying agent identity to observers of the receipt. 2. A delegation_nonce field committed at grant issuance. The nonce is consumed on first use within its chain depth and marked in a nullifier store. Replay of the grant by a different agent identity produces a nonce mismatch that the facilitator can detect without contacting the issuing principal. 3. A max_chain_length field that bounds privilege escalation through transitive delegation. A grant with max_chain_length: 1 cannot be sub-delegated; any attempt to use it as the basis for a further DelegationGrant is rejected with DelegationDepthExceeded. Together these mechanisms establish what this document calls Composable Trust Evidence for the delegation surface: the grant is cryptographically scoped to one agent identity, one nullifier epoch, and one depth bound, without requiring the facilitator to maintain a per-agent identity registry or contact the issuing principal at verification time. 1.3. Relationship to Companion Documents This document is the fourth companion in the Vauban Pay normative quartet: * [STARK-RECEIPTS] defines the receipt format, including the JCS canonical preimage discipline shared by all variants and the action_ref work-receipt binding. * [LIFECYCLE-FSM] defines the four-state payment lifecycle FSM, including the DelegationGrant side-channel state, its required fields, and its transition rules. * This document extends the DelegationGrant state with identity binding and spend-cap fields. It does not restate FSM transition rules; those are normative in [LIFECYCLE-FSM]. Research Expires 26 November 2026 [Page 4] Internet-Draft x402-delegation-binding May 2026 * A fourth companion, draft-vauban-x402-vpsf-algebra (in preparation), defines the claim-algebraic composition operators over the four PaymentClaim states. Implementations that adopt this extension MUST also implement the FSM ([LIFECYCLE-FSM]) and the canonical preimage discipline ([STARK-RECEIPTS] Section 5). This document adds fields and binding semantics; it does not substitute for either companion. This document is an Independent Submission. It is not the product of an IETF Working Group. It is published for community review and to establish a stable reference for implementors. 2. 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology Agent Identity: A stable identifier for an autonomous software agent operating in an agentic HTTP pipeline. For A2A pipelines, the Agent Identity is typically a DID (did:web, did:key, or similar scheme). For MCP pipelines, it is a server URI or a capability token issued at registration time. This document does not mandate any specific identity scheme; it requires only that the identity resolves to a deterministic byte string that can be fed to the JCS canonical preimage construction. Delegation Grant: A side-channel Payment Claim (as defined in [LIFECYCLE-FSM] Section 3.4) that authorises a delegatee agent to spawn PaymentIntents on behalf of a principal delegator, subject to spend-cap and scope constraints. In this document, "DelegationGrant" refers to the extended form defined in Section 4, which adds identity binding fields to the FSM base fields. Bounded Authority: The property of a DelegationGrant that restricts the delegatee's ability to issue payments to a defined ceiling (cap per transaction, cap per period), a defined merchant set, a defined currency set, and a defined chain depth. Bounded authority is the normative goal of the delegation binding extension. Composable Trust Evidence: A receipt or receipt chain from which a Research Expires 26 November 2026 [Page 5] Internet-Draft x402-delegation-binding May 2026 verifier can independently reconstruct and check the authority of every agent in the delegation chain, without contacting the issuing principal or a central registry. Composable Trust Evidence is the property that this extension enables for DelegationGrant receipts in A2A and MCP pipelines. delegate_pseudonym: A felt252-sized opaque value derived from the Agent Identity via the JCS canonical preimage discipline. The pseudonym binds the DelegationGrant to the delegatee identity without revealing the identity to observers of the grant receipt. delegation_nonce: A felt252-sized unique anti-replay token committed at grant issuance. The nonce is consumed on first verification and marked in the facilitator's nullifier store. A second verification of the same DelegationGrant with the same nonce is rejected as a replay, even if the presenting agent identity matches. 4. Delegation Binding Format A DelegationGrant implementing this extension carries the base fields required by [LIFECYCLE-FSM] Section 3.4 plus the binding fields defined in this section. Fields from [LIFECYCLE-FSM] are not restated here; implementations MUST satisfy both sets of field requirements. 4.1. Binding Fields The following fields MUST be present in a DelegationGrant that implements this extension: +==================+========+===========+=================================+ |Field |Type |Constraint |Description | +==================+========+===========+=================================+ |delegate_pseudonym|string |felt252 |Opaque identity commitment | | | |decimal |derived from Agent Identity. See| | | |encoding |Section 5.1. | +------------------+--------+-----------+---------------------------------+ |cap_per_tx |string |u256 |Maximum amount, in the smallest | | | |decimal |indivisible unit of the grant's | | | |encoding |currency, for any single | | | | |PaymentIntent spawned under this | | | | |grant. MUST be a non-negative | | | | |integer decimal string. | +------------------+--------+-----------+---------------------------------+ |cap_per_period |string |u256 |Maximum aggregate amount, in the | | | |decimal |smallest indivisible unit of the | | | |encoding |grant's currency, across all | Research Expires 26 November 2026 [Page 6] Internet-Draft x402-delegation-binding May 2026 | | | |PaymentIntents spawned under this| | | | |grant within period_seconds. | | | | |MUST be a non-negative integer | | | | |decimal string. | +------------------+--------+-----------+---------------------------------+ |period_seconds |integer |1..31536000|Duration of the spend-cap | | | |inclusive |accounting period in seconds. | | | | |MUST be at least 1 and at most | | | | |31536000 (365 days). | +------------------+--------+-----------+---------------------------------+ |allowed_merchants |string[]|URN pattern|Ordered list of merchant | | | | |identifiers within which the | | | | |delegatee may spawn | | | | |PaymentIntents. Each entry MUST | | | | |match the pattern | | | | |urn:x402:merchant:[a-z0-9-]{1,63}| | | | |or be an on-chain address in the | | | | |receipt format's canonical | | | | |address encoding. An empty list | | | | |MUST be interpreted as "no | | | | |merchant allowed" (fully-closed | | | | |grant). | +------------------+--------+-----------+---------------------------------+ |allowed_currencies|string[]|URN pattern|Ordered list of currency | | | | |identifiers the delegatee may | | | | |use. Each entry MUST match | | | | |urn:x402:currency:[A-Z]{2,12} or | | | | |be a standard token ticker per | | | | |the facilitator's supported asset| | | | |list. An empty list MUST be | | | | |interpreted as "no currency | | | | |allowed". | +------------------+--------+-----------+---------------------------------+ |delegation_nonce |string |felt252 |Anti-replay token committed at | | | |decimal |issuance. See Section 5.2. | | | |encoding | | +------------------+--------+-----------+---------------------------------+ |max_chain_length |integer |1..32 |Maximum number of delegation hops| | | |inclusive |permitted in a chain rooted at | | | | |this grant. A value of 1 means | | | | |the grant is terminal (cannot be | | | | |sub-delegated). MUST NOT exceed | | | | |32. | +------------------+--------+-----------+---------------------------------+ Table 1 Research Expires 26 November 2026 [Page 7] Internet-Draft x402-delegation-binding May 2026 All string fields MUST be Unicode Normalization Form C (NFC) before JCS canonicalisation ([RFC8785]). Float values for integer-typed fields MUST be rejected before canonicalisation. 4.2. felt252 Decimal Encoding The delegate_pseudonym and delegation_nonce fields are felt252 field elements encoded as unsigned decimal strings. The Starknet felt252 field prime is: P = 2^251 + 17 * 2^192 + 1 Implementations MUST reject values that are not valid decimal representations of integers in the range [0, P-1]. Negative values and values >= P MUST be rejected before canonicalisation. Implementations MUST NOT use hexadecimal or base64 encoding for felt252 fields; the decimal string representation is the sole canonical form for cross-implementation digest consistency. 4.3. u256 Decimal Encoding The cap_per_tx and cap_per_period fields are u256 values encoded as unsigned decimal strings. Implementations MUST reject negative values and values exceeding 2^256 - 1. Implementations MUST NOT use hexadecimal encoding for u256 fields. The decimal string representation is the sole canonical form. 5. Agent Identity Binding 5.1. Pseudonym Derivation The delegate_pseudonym is derived from the Agent Identity string using the following deterministic construction: 1. Encode the Agent Identity as a UTF-8 NFC byte string. 2. Compute raw = SHA-256(UTF-8(NFC(agent_identity))). 3. Interpret raw as an unsigned 256-bit big-endian integer. 4. Compute pseudonym_int = raw mod P where P is the felt252 prime defined in Section 4.2. 5. Encode pseudonym_int as an unsigned decimal string. This is the delegate_pseudonym. Research Expires 26 November 2026 [Page 8] Internet-Draft x402-delegation-binding May 2026 The pseudonym is a deterministic function of the Agent Identity. Two presentations of the same DelegationGrant by the same agent produce the same pseudonym. A different agent identity produces a different pseudonym with probability 1 - 2^-251 (negligible collision probability). The derivation does not reveal the Agent Identity to observers of the receipt; the pseudonym is a one-way commitment. Facilitators verifying a PaymentIntent under a DelegationGrant MUST: 1. Compute the pseudonym of the presenting agent using the construction above. 2. Compare the computed pseudonym against the delegate_pseudonym in the retained DelegationGrant. Comparison MUST be constant-time to prevent timing side-channels. 3. Reject the PaymentIntent with AgentIdentityMismatch if the pseudonyms do not match. 5.2. Nullifier Consumption Discipline The delegation_nonce is generated at grant issuance by the issuing principal using a cryptographically secure random number generator. The nonce MUST be in the felt252 range defined in Section 4.2. On first verification of a DelegationGrant, the facilitator MUST: 1. Verify that the delegation_nonce is not present in its nullifier store. 2. Insert the delegation_nonce into the nullifier store keyed by (delegation_nonce, max_chain_length). 3. Accept the grant for the verification scope. On any subsequent presentation of the same delegation_nonce, the facilitator MUST: 1. Detect the nonce in the nullifier store. 2. Reject the presentation with DelegationNonceReplay. This discipline prevents an adversary who has captured a DelegationGrant receipt from replaying it against a different agent session after the intended delegatee has consumed the grant. Research Expires 26 November 2026 [Page 9] Internet-Draft x402-delegation-binding May 2026 5.3. Revocation Propagation When a principal revokes a DelegationGrant, the revocation MUST be propagated to all facilitators that have stored the grant in their active grant registries. Revocation is signalled by inserting the delegation_nonce into the facilitator's nullifier store with a revoked marker before the first legitimate consumption. A facilitator that receives a PaymentIntent citing a revoked DelegationGrant MUST reject the PaymentIntent with GrantRevoked. Revocation propagation over an unreliable channel creates a time window during which a legitimately issued PaymentIntent spawned before the revocation signal arrives may be either accepted or rejected depending on propagation latency. Implementations MUST: * Accept PaymentIntents whose issued_at timestamp (per [LIFECYCLE-FSM] Section 3.1) predates the revocation signal by at most the maxTimeoutSeconds window declared in the payment requirements. * Reject PaymentIntents whose issued_at is after the revocation signal timestamp, regardless of propagation latency. This rule bounds the revocation window without requiring synchronous coordination between the issuing principal and all active facilitators. 5.4. Chain Depth Enforcement A DelegationGrant with max_chain_length: N may spawn a sub-delegation only if N > 1. The sub-delegation MUST carry max_chain_length: N-1. A sub-delegation MUST also carry a new delegation_nonce generated by the sub-delegating agent; it MUST NOT reuse the parent nonce. A facilitator verifying a sub-delegation chain MUST: 1. Reconstruct the chain from its retained grant manifests. 2. Verify that the sum of hops from the root grant to the current grant does not exceed the root grant's max_chain_length. 3. Reject with DelegationDepthExceeded if the chain length constraint is violated. Research Expires 26 November 2026 [Page 10] Internet-Draft x402-delegation-binding May 2026 The default max_chain_length for new DelegationGrants is 1 (terminal, no sub-delegation). Implementations that do not support sub- delegation MUST reject any DelegationGrant with max_chain_length greater than 1 during grant acceptance, not at PaymentIntent submission time. 6. A2A Integration Notes A2A pipelines that implement the Composable Trust Evidence Format ([A2A-CTEF]) MAY use the DelegationGrant binding defined in this document as the authority row within a Composable Trust Evidence envelope. The delegation binding serves as the authority evidence column, complementing the payment evidence column provided by the action_ref and payment_hash fields in [STARK-RECEIPTS]. In an A2A Composable Trust Evidence envelope, the binding between the agent identity evidence and the payment settlement evidence is established by the shared payment_hash and action_ref pair, as defined in [STARK-RECEIPTS] Section 6. The delegate_pseudonym in the DelegationGrant provides the additional link to the specific agent that consumed the grant; a verifier can confirm that the agent that submitted the payment (identified by agent_id in the action_ref preimage per [STARK-RECEIPTS] Section 5.3) is the same agent that was granted authority (identified by delegate_pseudonym in the DelegationGrant). The cross-verification is: SHA-256(UTF-8(NFC(action_ref_preimage.agent_id))) mod P == DelegationGrant.delegate_pseudonym A verifier that can perform this check independently confirms the full delegation binding without contacting any external registry. This is the Composable Trust Evidence property for the delegation surface. The allowed_merchants and allowed_currencies fields in the DelegationGrant carry the same semantic as the scope constraints in a Composable Trust Evidence authority row: they define the set of actions the agent is authorised to perform. A2A implementations MAY map these fields directly to their authority row schema. The discussion thread at [A2A-CTEF] established the requirement for this cross-verification during the x402 coalition review of the Axis 4 composite trust-query ([X402-2440]). Research Expires 26 November 2026 [Page 11] Internet-Draft x402-delegation-binding May 2026 7. MCP Agent Protocol Notes Model Context Protocol (MCP) servers that expose x402 payment tools to language model agents can use the delegation binding defined in this document to scope each agent session's payment authority. The Vauban Pay MCP server ([VAUBAN-DEMO]) implements the request_delegation_grant tool, which constructs a DelegationGrant with the binding fields defined in Section 4 and returns the JCS- canonical hash for use as the grant's content digest. In an MCP payment cycle, the delegation binding operates as follows: 1. The MCP server receives an agent session registration carrying the agent's identity token (a URI or capability string issued at connection time). 2. The server computes the delegate_pseudonym from the agent identity token using the derivation in Section 5.1. 3. The server issues a DelegationGrant embedding the pseudonym and the session's spend caps, serialises the grant using JCS ([RFC8785]), and returns the JCS hash to the agent as the grant reference. 4. When the agent submits a make_payment call, the server reconstructs the grant from the retained manifest, computes the presenting agent's pseudonym, and compares it against the stored delegate_pseudonym before accepting the PaymentIntent. 5. The delegation_nonce is consumed on the first make_payment call within the session epoch; a second call within the same epoch is rejected with DelegationNonceReplay unless a new grant with a fresh nonce is issued. MCP server implementations MUST NOT expose the Agent Identity string in the PAYMENT-RESPONSE or in any receipt body. The delegate_pseudonym is the only identity-derived value that appears in wire-format objects subject to this extension. 8. Security Considerations Research Expires 26 November 2026 [Page 12] Internet-Draft x402-delegation-binding May 2026 8.1. Agent Identity Spoofing An adversary that knows the target agent's identity string can precompute the expected delegate_pseudonym and attempt to construct a forged DelegationGrant with a matching pseudonym. The pseudonym construction uses SHA-256, which is collision-resistant under currently known attacks. Implementations MUST combine pseudonym verification with delegation_nonce consumption: a correct pseudonym does not suffice if the nonce has already been consumed. Additional mitigation: principals issuing DelegationGrants SHOULD sign the grant object with their own signing key (per the signature mechanism of the selected receipt format) before transmitting it to the delegatee. A signed grant cannot be forged without the principal's private key, even if the adversary knows the target pseudonym. 8.2. Spend Cap Inflation An adversary with write access to the grant receipt (for example, a compromised MCP server session) may attempt to inflate the cap_per_tx or cap_per_period fields before presenting the grant to the facilitator. Because the grant is JCS-hashed at issuance, any modification of these fields changes the grant's content digest. A facilitator that verifies the presented grant's JCS hash against the digest it stored at grant registration will detect the inflation. Facilitators MUST store the JCS hash of each registered DelegationGrant at registration time and MUST re-verify the hash on every grant presentation. A grant whose current JCS hash does not match the stored hash MUST be rejected with GrantHashMismatch. 8.3. Nullifier Replay The delegation_nonce consumption discipline defined in Section 5.2 prevents replay of a captured DelegationGrant receipt. The nullifier store MUST be durable: a facilitator restart that loses its nullifier store creates a replay window. Implementations MUST persist the nullifier store to durable storage before acknowledging grant consumption to the delegatee. For high-availability deployments with multiple facilitator instances, the nullifier store MUST be shared (for example, via a distributed key-value store with strong consistency guarantees). Implementations using eventually-consistent stores MUST use optimistic locking to prevent race-condition-based nonce bypass. Research Expires 26 November 2026 [Page 13] Internet-Draft x402-delegation-binding May 2026 8.4. Chain Depth Attack An adversary may attempt to construct a sub-delegation chain that exceeds the root grant's max_chain_length by presenting each hop to a different facilitator that has not retained the chain history. Facilitators MUST verify the full chain depth against the root grant, not just the immediate parent grant. Chain reconstruction ([LIFECYCLE-FSM] Section 4.3) MUST be applied to the full chain before accepting any PaymentIntent. Implementations that cannot reconstruct the full chain from retained manifests MUST reject the PaymentIntent with ChainNotReconstructable rather than accepting it with partial chain verification. 8.5. Cross-Format Confusion The delegate_pseudonym derivation defined in Section 5.1 uses SHA-256 and the felt252 prime. A verifier that applies the same derivation to a different identity scheme (for example, a DID that resolves to a different key) or a different prime may compute a pseudonym that coincidentally matches a legitimate grant. Implementations MUST use the derivation as defined in Section 5.1 without variation; a pseudonym computed under a modified derivation is not compatible with this extension. Facilitators supporting multiple receipt formats MUST apply the pseudonym derivation in Section 5.1 uniformly across formats. Format-specific pseudonym constructions that diverge from Section 5.1 MUST be treated as incompatible and MUST NOT be cross-verified against grants issued under this extension. 9. IANA Considerations This document introduces no new IANA registrations. The delegate_pseudonym, cap_per_tx, cap_per_period, period_seconds, allowed_merchants, allowed_currencies, delegation_nonce, and max_chain_length fields are defined as extension fields within the DelegationGrant structure of the x402 V2 protocol ([X402-V2]). If the x402 Foundation TSC establishes a DelegationGrant field registry as an extension of the x402 Receipt Format registry defined in [STARK-RECEIPTS] Section 9, the fields in this document SHOULD be submitted for registration. New error tokens introduced by this extension (AgentIdentityMismatch, DelegationNonceReplay, GrantRevoked, GrantHashMismatch, ChainNotReconstructable) are used in the X-Receipt-Reject-Reason header defined in [STARK-RECEIPTS] Section 5.2. These tokens extend the error taxonomy of [STARK-RECEIPTS] without requiring a new Research Expires 26 November 2026 [Page 14] Internet-Draft x402-delegation-binding May 2026 registry; they follow the same naming convention and MUST be treated as unknown tokens by verifiers that have not implemented this extension. 10. Acknowledgments The 18-vector bounded-spend conformance matrix in [X402-2432] was produced as part of the x402 Linux Foundation coalition cross- validation exercise. The cross-runtime byte-identical results across five language implementations (Python, TypeScript, Go, Java, Rust) established the feasibility of the JCS canonical preimage discipline as a binding mechanism for delegation receipts, and directly motivated the field set defined in Section 4. The Composable Trust Evidence Format discussion ([A2A-CTEF]) and the composite trust-query work in [X402-2440] shaped the A2A integration notes in Section 6. In particular, the cross-verification construction in Section 6 (mapping action_ref_preimage.agent_id to delegate_pseudonym via shared SHA-256 and felt252 reduction) is grounded in the editorial alignment reached in the [X402-2440] review. 11. References 11.1. Normative References [LIFECYCLE-FSM] "x402 V2 Payment Lifecycle Finite State Machine", Work in Progress, Internet-Draft, draft-vauban-x402-lifecycle-fsm- 00, n.d., . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . Research Expires 26 November 2026 [Page 15] Internet-Draft x402-delegation-binding May 2026 [STARK-RECEIPTS] "x402 STARK Receipt Format Extension", Work in Progress, Internet-Draft, draft-vauban-x402-stark-receipts-01, n.d., . 11.2. Informative References [A2A-CTEF] "A2A Composable Trust Evidence Format (kenneives, x402 coalition thread)", n.d., . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [VAUBAN-DEMO] "Vauban Pay reference demo and MCP server (Starknet Sepolia)", n.d., . [X402-2326] "x402 shared canonicalisation discipline (coalition discussion thread)", n.d., . [X402-2432] "Bounded-spend authorization sample: 18-vector cross- runtime conformance matrix", n.d., . [X402-2440] "Composite trust-query normative layer (Axis 4)", n.d., . [X402-V2] "x402 Linux Foundation V2 Working Group", n.d., . Appendix A. Worked Example: MCP Agent Delegation Cycle The following example illustrates a complete MCP agent delegation cycle under this extension. A.1. Step 1: Grant Issuance The MCP server registers an agent session with identity string did:web:agent-42.mcp.example.com. The server computes: Research Expires 26 November 2026 [Page 16] Internet-Draft x402-delegation-binding May 2026 pseudonym_raw = SHA-256(UTF-8(NFC("did:web:agent-42.mcp.example.com"))) = <32-byte SHA-256 digest> pseudonym_int = pseudonym_raw_as_big_endian_integer mod P delegate_pseudonym = decimal_string(pseudonym_int) The server issues the following DelegationGrant object (JCS key order shown for clarity): { "allowed_currencies": ["urn:x402:currency:USDC"], "allowed_merchants": ["urn:x402:merchant:api-example"], "cap_per_period": "10000000", "cap_per_tx": "500000", "delegate_pseudonym": "", "delegatee": "did:web:agent-42.mcp.example.com", "delegator": "did:web:principal.example.com", "delegation_nonce": "", "expires_at": 1780000000, "max_chain_length": 1, "period_seconds": 86400, "scope": ["payment:usdc", "merchant:api-example"] } The server serialises this object via JCS ([RFC8785]) and computes the grant content digest: grant_hash = SHA-256(UTF- 8(JCS(grant_object))). The grant_hash is returned to the agent as its DelegationGrant reference. A.2. Step 2: PaymentIntent Binding When the agent submits a make_payment call, the server: 1. Retrieves the stored DelegationGrant by grant_hash. 2. Verifies cap_per_tx: the requested amount is within the per- transaction ceiling. 3. Verifies allowed_merchants: the target merchant is in the list. 4. Verifies allowed_currencies: the payment currency is permitted. 5. Computes the presenting agent's pseudonym and compares it against delegate_pseudonym (constant-time comparison). 6. Checks the delegation_nonce against the nullifier store. 7. If all checks pass, builds the PaymentIntent carrying the grant_hash as its DelegationGrant reference. Research Expires 26 November 2026 [Page 17] Internet-Draft x402-delegation-binding May 2026 A.3. Step 3: Facilitator Verification The facilitator receiving the PaymentIntent: 1. Extracts the grant_hash from the PaymentIntent. 2. Looks up the retained DelegationGrant manifest by grant_hash. 3. Re-hashes the manifest via JCS and confirms the digest matches grant_hash (detects any field inflation). 4. Verifies the presenting agent's delegate_pseudonym matches the retained value. 5. Verifies the delegation_nonce is not in the nullifier store. 6. Accepts or rejects the PaymentIntent based on all scope and cap checks. Appendix B. Error Token Reference The following error tokens extend the X-Receipt-Reject-Reason taxonomy of [STARK-RECEIPTS] Section 5.2 for delegation binding failures: Research Expires 26 November 2026 [Page 18] Internet-Draft x402-delegation-binding May 2026 +=========================+========+===============================+ | Token | HTTP | Description | | | Status | | +=========================+========+===============================+ | AgentIdentityMismatch | 403 | The presenting agent's | | | | pseudonym does not match | | | | delegate_pseudonym in the | | | | retained DelegationGrant. | +-------------------------+--------+-------------------------------+ | DelegationNonceReplay | 409 | The delegation_nonce has | | | | already been consumed. The | | | | grant cannot be replayed. | +-------------------------+--------+-------------------------------+ | GrantRevoked | 410 | The DelegationGrant has been | | | | explicitly revoked by the | | | | issuing principal. | +-------------------------+--------+-------------------------------+ | GrantHashMismatch | 422 | The JCS hash of the presented | | | | DelegationGrant does not | | | | match the stored digest. | | | | Possible cap inflation or | | | | field tampering. | +-------------------------+--------+-------------------------------+ | ChainNotReconstructable | 422 | The facilitator cannot | | | | reconstruct the full | | | | delegation chain from | | | | retained manifests. The | | | | PaymentIntent is rejected | | | | pending chain availability. | +-------------------------+--------+-------------------------------+ | DelegationDepthExceeded | 422 | The delegation chain exceeds | | | | the root grant's | | | | max_chain_length. | +-------------------------+--------+-------------------------------+ | GrantExpired | 410 | The DelegationGrant | | | | expires_at has elapsed. | | | | Expired grants do not | | | | authorise new PaymentIntents | | | | (per [LIFECYCLE-FSM] | | | | Section 3.6). | +-------------------------+--------+-------------------------------+ Table 2 Research Expires 26 November 2026 [Page 19] Internet-Draft x402-delegation-binding May 2026 Known Adopters and Reference Implementations This appendix documents reference implementations and adopters of this specification confirmed at the time of publication. The list is informational and will be updated in subsequent revisions as additional implementations are reported. Primary Maintainer Vauban Pay (https://pay.vauban.tech) maintains the reference delegation binding specification, the published conformance vectors (https://github.com/vauban-org/x402-stark-receipts-conformance), and the reference implementations listed below. The bounded-spend- authorization vector set demonstrates the DelegationGrant + SettlementReceipt pair under the six-element Claim sextuplet shape with the seven fiscal_authority qualification fields mapped to cryptographic primitives. Reference Implementation Matrix The conformance vector suite maintains an 8-implementation reference matrix across Python, JavaScript, Go, Java, Rust, PHP, Ruby, and C#. The first five are validated byte-for-byte against upstream JCS RFC 8785 libraries ; the last three are published as pure-stdlib reference runners pending CI execution. Detailed validation status is documented in _attestations/2026-05-25-vauban-8-impl-extended.md in the conformance vectors repository. The published Vauban Pay packages across 3 ecosystems : vauban-x402- jcs-conformance@0.1.0, vauban-x402-canonical@0.1.0, vauban- x402-wire@0.1.0 on crates.io ; vauban-x402-stark-receipt@0.1.0 on PyPI ; @vauban-pay/substrate@0.1.0 on npm. Adoption Process Implementers SHOULD notify the IETF contact at research@vauban.tech when adopting this specification in production. Adoption notifications include the agent identity binding mechanism implemented (DID method, key type), the DelegationGrant chain enforcement strategy, the revocation publication endpoint, and the contact for follow-on coordination. Reported adopters will be listed in the next revision of this appendix following a verification step against the conformance vector matrix. Author's Address Vauban Research Vauban Research Research Expires 26 November 2026 [Page 20] Internet-Draft x402-delegation-binding May 2026 Email: research@vauban.tech URI: https://pay.vauban.tech Research Expires 26 November 2026 [Page 21]