Independent Submission C. Hopley Internet-Draft AlgoVoi Intended status: Informational June 4, 2026 Expires: December 6, 2026 Post-Quantum Credential Binding for x402 Agentic Payment Authorization draft-hopley-x402-pqc-credential-binding-00 Abstract This document defines how Falcon-1024 (NIST FIPS 206 / FN-DSA) and ML-DSA-65 (NIST FIPS 204) credentials bind to x402 agentic payment authorization. It specifies the credential envelope format, the JCS canonicalization discipline applied to signed payloads, the gateway verification procedure, and the session token binding that replaces per-request API key authentication for credentialed agents. This is the first Internet-Draft in the agentic payments space to anchor credential binding to the NIST post-quantum cryptography standards (FIPS 203/204/206). 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/. 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 December 6, 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. 1. The x402 payment protocol {{x402}} enables HTTP-native micropayments between autonomous agents and API providers. As agent deployments scale, two problems emerge: This document addresses both by defining a credential binding scheme where: 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]. An entity that evaluates an agent and signs a credential asserting the result. The reference implementation is the AlgoVoi Agent Trust Bench. The x402 payment gateway that accepts credentials and issues session tokens. An autonomous software system presenting credentials to a gateway in exchange for payment-authorization session tokens. A Falcon-1024-signed credential asserting that an agent passed adversarial evaluation. Phase 1 contains a plaintext score; Phase 2 replaces the score with a Bulletproofs range proof (zero-knowledge). 2. A PQC credential is a JSON object serialised to UTF-8 and encoded as base64url (without padding). The structure is: 2.1. MUST be one of: The algorithm is the RECOMMENDED choice. It provides 1,024-bit classical security, 256-bit post-quantum security, and compact signatures (~1,280 bytes). 2.2. A 16-character lowercase hex string derived as: The gateway MUST verify that the in the envelope matches the of the issuer's public key in its trusted-key registry before proceeding to signature verification. 2.3. A JSON object. Required fields for ATB Phase 2 credentials: The field MUST decode to exactly 32 bytes (a compressed Ristretto255 point). The field MUST decode to 200-900 bytes (a 64-bit Bulletproofs range proof over Ristretto255). 2.4. Base64url-encoded detached signature over the JCS-canonical form of the field. The signer applies RFC 8785 {{RFC8785}} canonicalization to the object, then signs the resulting UTF-8 bytes. For , the signature is a Falcon-1024 detached signature (NIST FIPS 206, PQClean format, ~1,280 bytes, base64url). 3. The issuer: The issuer MUST NOT include the field in the payload before signing. The and envelope fields MUST NOT be signed. 4. The gateway receiving : A gateway SHOULD implement an LRU cache keyed by to avoid re-running Falcon verification for repeated presentations within the cache TTL. The cache TTL MUST NOT exceed the credential's . 5. On successful credential verification, the gateway issues a session token: Response: The session token is a JWT {{RFC7519}} signed with the gateway's HMAC key. Its claims include , , (in micro-USD), , and . Subsequent requests carry only: No API key or tenant header is required for the session duration. 5.1. The gateway tracks cumulative spend per in-process. On each successful payment, is incremented. If , the gateway MUST reject the request with HTTP 402. 6. Implementations SHOULD prefer Falcon-1024 for its signature compactness in HTTP header contexts. 7. 7.1. An adversary with a cryptographically-relevant quantum computer can break Ed25519 and ES256 signatures using Shor's algorithm. All credentials using these algorithms are vulnerable to retrospective forgery once such a machine exists. Issuers SHOULD migrate to Falcon-1024 or ML-DSA-65 before quantum computers reach this capability threshold. 7.2. Phase 2 ATB credentials include a Bulletproofs range proof rather than a plaintext score. The range proof attests that without revealing the exact score. Gateways MUST NOT attempt to reconstruct scores from commitment values. 7.3. The in each session token is a random 128-bit value generated at issuance. Gateways MUST track issued values and reject replayed tokens. The credential in Phase 1 activation flows prevents replay at the license-activation layer. 7.4. Issuers SHOULD rotate Falcon-1024 keys at least annually. The field allows gateways to maintain a key registry and identify credentials by key version without revoking the full issuer DID. 8. This document has no IANA actions. Appendix A. A.1. A.2. Author's Address Christopher Hopley AlgoVoi Email: hello@algovoi.co.uk