[Bug]: Checkout JWT algorithm constraint forces dual keys under WBA (and conflicts with normative Security & Privacy guidance)

[igrigorik]

Two normative passages in AP2 v0.2 prescribe inconsistent requirements for the same threat (rainbow-table inversion of checkout_hash). Converging on entropy-based formulation in security and privacy doc would eliminate composition cost being paid by integrators today, with no loss of security.

Context

Web Bot Auth (draft-meunier-web-bot-auth-architecture) is being adopted as the HTTP transport identity layer across agentic commerce. Its deployed convention is Ed25519.

A merchant composing AP2 with Web Bot Auth at the transport layer is therefore currently required to hold two keypairs in two different algorithms for a single role: Ed25519 for HTTP transport identity, and ECDSA for the merchant Checkout JWT. The second constraint comes from specification.md "Payment Mandate (lines 155–157)", which forbids deterministic signature schemes (e.g. Ed25519) for the Checkout JWT on the basis of rainbow-table defense.

However, AP2's own security_and_privacy_considerations.md "Rainbow Table Attacks (lines 140–148)" permits deterministic schemes, including Ed25519, provided the JWT payload carries a salt of sufficient entropy. The two normative passages are at odds. The S&P document's entropy-based formulation is the more accurate articulation of the underlying security property: what defeats rainbow-table inversion of checkout_hash is unpredictable JWT bytes per session — the source of the unpredictability (signature or payload) is incidental.

Application protocols already provide this entropy structurally. As one concrete example, UCP requires every Checkout to carry a unique, unguessable per-session checkout id. AP2's own §Checkout Mandate states that when used with UCP, checkout_jwt MUST be a UCP Checkout. By composition, every UCP+AP2 checkout_jwt already contains a high-entropy per-session identifier, making hash(checkout_jwt) unpredictable regardless of signature algorithm. Yet integrators are still required by specification.md to hold a second key in a second algorithm to satisfy the algorithm-class proxy of a property they already provide.

Current text...

specification.md §Payment Mandate (lines 155–157):

"The Payment Mandate is bound to a particular Checkout using the cryptographic hash of the Checkout JWT. To prevent rainbow table attacks, the Checkout JWT MUST be signed using a digital signature scheme (e.g., ECDSA) and not a deterministic signature (e.g., Ed25519)."

security_and_privacy_considerations.md §Rainbow Table Attacks (lines 140–148):

"Digests in SD-JWTs (for Payment and Checkout Mandates as well as Constraints) MUST include a salt with sufficient entropy to prevent guessing the plaintext. See RFC9901 Section 9.1.

The checkout_hash makes use of the entropy already included in the JWT signature to prevent guessing the Checkout contents. If a signing algorithm (e.g. deterministic signature scheme such as Ed25519) is used that does not include this then a salt of sufficient entropy MUST be present in the Checkout."

---

Recommendation

Replace specification.md lines 153–157 with text aligned to the S&P document.

Suggested replacement:

"The Payment Mandate is bound to a particular Checkout using the cryptographic hash of the Checkout JWT. To prevent rainbow-table attacks on checkout_hash, the Checkout JWT MUST contain sufficient entropy to make its serialized bytes unpredictable per session. This requirement is satisfied by either (a) signing with a non-deterministic signature scheme (e.g., ECDSA), or (b) including a high-entropy claim in the JWT payload (e.g., a jti per RFC 7519 §4.1.7, or an application-protocol-defined session identifier of equivalent entropy). Implementations using a deterministic signature scheme (e.g., Ed25519) MUST ensure the payload satisfies (b)."

This change:

• Resolves the contradiction between spec and S&P docs: both describe the same property.
• Preserves all current ECDSA-using implementations unchanged — they satisfy clause (a) as-is.
• Removes the algorithm-class constraint that acted as a proxy for the entropy property, eliminating the forced multi-key cost for AP2+WBA integrators.

---

Issue #250 proposes adding an open-enum signature_algorithm field to AP2 mandates to enable PQ migration (ML-DSA-65, Falcon-1024), driven by HKMA / EU DORA / NIST IR 8547 requirements. That proposal's mechanism — making signature algorithm an explicit per-mandate choice — would resolve the contradiction surfaced here as a side effect. The two proposals reinforce each other: both want algorithm flexibility for legitimate but different reasons, and both are blocked in different ways by the same specification.md paragraph.

[GarethCOliver]

Yeah, we are probably being overly restrictive and 'clever' relying on the signing algorithm to provide the entropy (so we didn't have to care about the contents). Getting it from the payload is reasonable and the update to the text makes sense to me. Given we have officially moved further iterations of this to FIDO, we should aim to change this as part of the agentic payments work group. I think we are happy enough to make a breaking change and simply mandate (b). It's a reasonable expectations and easy enough for Checkout's to achieve (and simpler is generally better and less error prone).

Tagged this for reference.

Regarding alg enum: Why is the standard JWT 'alg' header not sufficient?

There is, generically, a need for for to negotiate acceptable signatures, but that's a different problem.

[igrigorik]

@GarethCOliver (b)-only would simplify things -- aligned. The result would be something like...

"The Payment Mandate is bound to a particular Checkout using the cryptographic hash of the Checkout JWT. To prevent rainbow-table attacks on checkout_hash, the Checkout JWT payload MUST contain a high-entropy claim that makes its serialized bytes unpredictable per session. This requirement is satisfied by including a unique unpredictable claim such as a jti per RFC 7519 §4.1.7 or an application-protocol-defined session identifier of equivalent entropy. This requirement applies regardless of the signature algorithm used."

Looks about right?

LMK how I can help land this. Is there a FIDO repo (couldn't find it) where we can bring this as a PR?

[chopmob-cloud]

@GarethCOliver @igrigorik: bringing context from AP2 #250 (the open-enum signature_algorithm proposal cross-referenced in the OP) and from the Ed25519 + RFC 9421 reference verifier shipped to PyPI and npm earlier today.

On the entropy reformulation. @igrigorik's suggested replacement text is the right shape. The Ed25519-with-entropy-in-payload pattern is already shipping in production under exactly that property. AlgoVoi's compliance-receipt I-D (draft-hopley-x402-compliance-receipt, IETF Independent Submission, Informational) signs categorical verdicts (ALLOW / REFER / DENY) over content-addressed binding fields that carry per-receipt unpredictability regardless of signature algorithm. Reference implementation: algovoi-substrate on PyPI and npm, Apache 2.0. The pattern works in deployment today.

On @GarethCOliver's JWT 'alg' question. Standard JWT 'alg' (RFC 7515 §4.1.1) is sufficient for identifying the algorithm used on a given signature. It is not sufficient for the three extensibility properties AP2 needs:

1. RFC 7518 does not register ML-DSA, Falcon-1024, or any post-quantum signature scheme. The IANA JOSE registry has multi-year process latency. NIST IR 8547 and EU DORA require PQ migration paths that do not wait on JWT-alg registration.

2. Composite or hybrid signatures (e.g. Ed25519 + ML-DSA-65 over the same canonical bytes during the PQ migration window) have no native form under JWT 'alg'. The header carries one value per signature, not a class declaration over the mandate.

3. AP2 mandates need to declare issuer policy about the algorithm class the mandate is anchored under, so verifiers can filter on policy before parsing any individual JWT envelope. JWT 'alg' answers "what algorithm produced this signature." signature_algorithm in Proposal: Post-Quantum Extension to AP2 (ML-DSA-65 / FIPS 204) #250 answers "what algorithm class is this mandate sealed under." The two are orthogonal.

signature_algorithm as an open enum (strings, not a closed integer table) addresses all three without requiring IANA process latency for each new PQ scheme.

On Ed25519 under RFC 9421 + WBA. algovoi-rfc9421-verifier@0.2.1 (Apache 2.0, Python and TypeScript on PyPI and npm) verifies RFC 9421 HTTP Message Signatures with RFC 9530 Content-Digest. Cross-validated against the Envoys envoys-rfc9421 and Hippo hippo-rfc9421 external fixture sets: 7 of 7 verifiable vectors PASS. The verifier exercises the Ed25519 + payload-entropy property that the proposed reformulation legitimises.

On the FIDO question. No direct visibility into where the Agentic Payments WG is hosting deliverables. Happy to coordinate against whichever venue lands the resolution.

-- AlgoVoi (chopmob-cloud)

---

AlgoVoi (chopmob-cloud) -- Acquisition enquiries: https://docs.algovoi.co.uk/acquisition