Cross-Issuer ZKP Federation for Post-Quantum Agentic Payment Credentials
draft-hopley-x402-federation-zkp-00

Independent Submission                                         C. Hopley
Internet-Draft                                                   AlgoVoi
Intended status: Informational                              June 4, 2026
Expires: December 6, 2026

Cross-Issuer ZKP Federation for Post-Quantum Agentic Payment Credentials
                  draft-hopley-x402-federation-zkp-00

Abstract

   This document defines a protocol for composing independently-issued
   post-quantum ZKP credentials from different issuers into a single
   federation token, without requiring a shared trust root between
   issuers.

   Each credential is a Falcon-1024 (NIST FIPS 206) or ML-DSA-65 (NIST
   FIPS 204) signed Bulletproofs range proof asserting that an agent's
   trust score meets a threshold.  A federation validator independently
   verifies each credential against its issuer's public key, then
   computes a composite commitment binding all verified proofs.

   The resulting federation token is signed by the validator alone.  No
   issuer needs to know about the others.  This solves the cross-issuer
   attestation composition problem in agentic payment networks.

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.

1.1.

   Agentic payment networks are converging on a multi-issuer credential
   landscape.  An agent may hold credentials from:

   A gateway that requires proof of compliance with N issuers faces a
   composition problem: how does it accept a single credential that
   proves all N conditions are met, without requiring:

   The naive solution -- accept N separate credentials and verify each
   -- works but has two drawbacks:

   This document specifies a federation composition protocol that:

1.2.

   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 signs PQC credentials (ATB hub, identity provider,
   etc.).  Each issuer has an independent Falcon-1024 or ML-DSA-65 key
   pair.  Issuers have no knowledge of each other.

   An entity that holds the public keys of N trusted issuers and
   composes their credentials into a single federation token.  The
   validator may be the payment gateway itself, or a separate service
   trusted by the gateway.

   A short-lived HMAC-SHA256-signed token produced by the federation
   validator, containing the composite commitment and issuer list.

   A SHA-256 hash binding the Pedersen commitments from all N input
   credentials together with a per-composition nonce.

2.

   The agent presents two or more PQC credentials (each from an
   independent issuer) to the federation validator.  The validator
   verifies each, composes the commitments, and returns a federation
   token.  The agent then uses this token on the gateway.

   The gateway only needs to: 1.  Verify the HMAC on the federation
   token. 2.  Verify expiry. 3.  Check spend cap.

   No Falcon-1024 verification happens on the gateway hot path.

3.

   Each credential presented to the federation validator MUST conform to
   {{CREDENTIALBINDING}} S.2 (ATB Phase 2,

   ).

   Specifically: -

   MUST be

   or

   . -

   MUST decode to exactly 32 bytes (compressed Ristretto255). -

   MUST decode to 200-900 bytes (64-bit Bulletproofs range proof). -

   MUST be a DID present in the validator's

   registry. - The credential MUST not be expired.

   The validator MUST independently verify each credential's Falcon-1024
   signature before proceeding to composition.

4.

   The federation validator maintains a mapping:

   Each issuer's public key is obtained from their

   endpoint:

   The validator MUST NOT accept credentials from issuers not in its
   registry.  This is the sole trust boundary: the validator trusts
   specific issuer keys, but issuers do not need to trust each other.

5.

5.1.

5.2.

   For each credential

   , extract the Pedersen commitment:

   Sample a per-composition nonce:

   Compute the composite commitment:

   where:

   The domain label provides separation from other SHA-256 uses.  The
   nonce ensures the composite commitment is unique per composition
   event, preventing an adversary from reusing a subset of credentials
   with different partners to produce a matching composite.

5.3.

   The federation token's

   MUST be set to:

   This ensures the federation token never outlives any of its input
   credentials.

5.4.

   The validator constructs the following payload:

   Applies JCS canonicalization {{RFC8785}} to produce

   .

   Computes the HMAC tag:

   Assembles the federation token envelope:

   Base64url-encodes the envelope JSON as the federation token string.

6.

   The gateway receiving

   (after the initial session exchange):

   The gateway does NOT re-verify Falcon-1024 signatures on the hot
   path.  That work was done once by the federation validator.

7.

7.1.

   Issuers A and B have independent key pairs.  The validator's only
   relationship to each issuer is possession of their public keys.
   Issuers do not need to communicate with each other or with the
   validator beyond publishing their public keys.

7.2.

   Each credential in the composition is independently verifiable by any
   party holding the issuer's public key.  The composite token does not
   obscure this: the

   field in the token payload lists all issuers and their kids, allowing
   retrospective audit.

7.3.

   The composite commitment

   binds the federation token to the exact set of Pedersen commitments
   from the input credentials.  An adversary who replaces one credential
   with a different one will produce a different

   and the HMAC will not verify.

   The per-composition nonce prevents a partial-credential-set replay:
   an adversary cannot use commitment_A from one composition event and
   commitment_B from another to produce a valid composite.

7.4.

   The ZKP range proof in each input credential asserts

   without revealing the exact score.  The composite commitment is
   derived from Pedersen commitment bytes, not from scores.  The gateway
   learns only that

   .

7.5.

   All per-credential signing uses Falcon-1024 (NIST FIPS 206) or ML-
   DSA-65 (NIST FIPS 204).  The composite token uses HMAC-SHA256, which
   is quantum- resistant under the birthday-bound model (Grover's
   algorithm reduces effective security from 256 to 128 bits -- still
   adequate).

7.6.

   If the validator's HMAC key is compromised, an adversary can forge
   federation tokens.  Operators SHOULD rotate the validator key
   regularly and revoke outstanding tokens on rotation by advancing the
   token's

   .

8.

8.1.

   An HMAC-based federation token is verifiable by any instance holding
   the validator secret.  In multi-instance deployments the secret MUST
   be shared across instances (e.g. via a secrets manager), not per-
   instance.

8.2.

   Operators SHOULD configure

   to require cross-issuer evidence.  A value of 1 provides single-
   issuer mode -- useful for testing but does not demonstrate cross-
   issuer composition.

8.3.

   The protocol permits two credentials from the same issuer.  The
   composite commitment is still computed correctly and the HMAC
   verifies.  However, the "no shared trust root" property holds
   trivially in this case.  Operators that require distinct issuers
   SHOULD enforce issuer-DID uniqueness in the validator configuration.

8.4.

   Full Bulletproofs range proof verification (step 10 of
   {{CREDENTIALBINDING}} S.4) requires calling the ATB ZKP service.  The
   federation validator package performs structural validation of proof
   fields without the Rust service.  Operators requiring cryptographic
   range proof verification SHOULD configure

   and the

   environment variable.

9.

   The composition pattern in this document is novel in the agentic
   payments context.  It draws on:

10.

   This document has no IANA actions.

Appendix A.

A.1.

A.2.

Author's Address

   Christopher Hopley
   AlgoVoi

   Email: hello@algovoi.co.uk