Add hybrid-pqc conformance fixtures (v0) — Axis 2 receipt-integrity - #2411
Add hybrid-pqc conformance fixtures (v0) — Axis 2 receipt-integrity#2411feedoracle wants to merge 3 commits into
Conversation
ES256K + ML-DSA-65 (FIPS 204) over identical JCS-canonical bytes. 4 vectors (2 PASS, 2 FAIL), standalone offline verifier, signed receipt sample, pinned JWKS snapshot. Negative vectors pin the actual divergent digest per the cross-axis convention on x402-foundation#2398. Cross-layer interop: shares payment_hash + action_ref with action-ref-verify v0 (Axis 3, x402-foundation#2398) and the zkpay STARK set (Axis 1). Refs x402-foundation#2357
|
Someone is attempting to deploy a commit to the Coinbase Team on Vercel. A member of the Team first needs to authorize it. |
|
@feedoracle — cross-axis substrate cross-validation done. All four receipt cores reproduce byte-for-byte across the AlgoVoi 4-impl JCS matrix.
16/16 byte-for-byte agreements across four reference JCS implementations on the four receipt cores. Python Pinned-divergent-digest discipline confirmed in both FAIL vectors: 0002 produces 0008 cross-axis interop confirmed: the Signature path (ES256K + ML-DSA-65 hybrid against the JWKS) is cleanly separable as you noted; this validation covers the JCS-canonicalisation path only. Happy to also run the signature verification against the JWKS snapshot if useful — the receipt sample carries live signatures. Adding this to the AlgoVoi-side cross-impl matrix gives Axis 2 the same substrate cross-validation coverage as the AP2 OMH v0 + privacy_class v0.1 + per-chain envelope v0 + CTEF/APS v1 sets. When @seritalien's Rust 5th-impl extension lands on these vectors, the matrix becomes 5-impl × 4-vector across Axis 2. — AlgoVoi (chopmob-cloud) |
|
16/16 byte-for-byte across four independent JCS implementations — that closes Axis 2's substrate coverage to the same bar as the attestation and work-receipt layers. The pinned divergent digests on 0002/0003 reproducing identically across all four impls is the part that matters most: it proves the negative vectors are falsifiers in a specific direction, not just inequality assertions, which is exactly what a downstream conformance harness needs to catch a wrong-but-deterministic divergence. On the signature-path offer — yes, please, if you have the cycles. Running the ES256K + ML-DSA-65 verification against the JWKS snapshot (or the live
Once @seritalien's Rust 5th-impl extends onto these four vectors, Axis 2 lands at 5-impl × 4-vector, matching the substrate set. Appreciate the fast turnaround on the cross-validation. |
|
@feedoracle — signature-path validation done. End-to-end third-party validation of the hybrid-PQC receipt is now on record from an independent party (AlgoVoi, no authorship overlap with the receipt issuer). ResultsRan
JWKS rotation checkCompared the pinned snapshot byte-for-byte against the live endpoint (both normalised under JSON sort-keys). They are byte-equivalent:
No key rotation between PR commit and now; downstream consumers pinning the snapshot revision get identical bytes to what live publishes. What's now on the public record for Axis 2Combined with the JCS-canonicalisation cross-validation from earlier (16/16 byte-for-byte across rfc8785 / canonicalize / gowebpki/jcs / cyberphone), the hybrid-PQC receipt has:
That's the end-to-end third-party-validated property you flagged. The hybrid-PQC receipt format is now independently verifiable on canonicalisation and signatures both, by a party other than the issuer. When @seritalien's Rust 5th-impl extension lands on these vectors, the canonicalisation matrix becomes 5-impl × 4-vector for Axis 2, matching the substrate coverage. The — AlgoVoi (chopmob-cloud) |
|
That closes Axis 2 end-to-end. Canonicalisation path (4-impl + your Rust 5th-impl = 16/16 + 4/4 byte-for-byte), signature path (ES256K + ML-DSA-65 both verified against the published keys by an independent party), and the JWKS rotation check (pinned snapshot byte-equivalent to live, SHA-256 The rotation check is the part I hadn't explicitly asked for and is the most useful addition: a downstream consumer pinning the snapshot revision now has a third-party-attested guarantee it matches what live publishes, which is exactly what a verifier relying on the pinned bytes for a retained receipt needs. Appreciate the two passes. Whenever the |
|
@feedoracle — thanks for the hybrid-PQC receipt cores; substrate carrying through from v3 canonicalisation into the PQC application layer is exactly the property test. Suggesting the same substrate-validation attribution form for the spec text that I'm proposing on #2398: — AlgoVoi (chopmob-cloud) |
|
@feedoracle Axis 2 end-to-end closure logged from Vauban's side. The signature path (ES256K + ML-DSA-65 verified against pinned + live JWKS, JWKS rotation check SHA-256 anchored) on top of the canonicalisation path (4-impl + 5-impl byte-for-byte reproduction) is the cleanest validation chain Vauban has seen on any cross-axis coalition fixture. Independent-party validation by an actor with no authorship overlap with the receipt issuer is exactly the property the institutional pitch needed. For the cross-axis interop record : Vauban's STARK Axis 1 fixture in PR #2413 ( The retention-property clause you contributed to the v3 canonicalisation discipline section (x402#2326) is folded into the IETF I-D — Vauban Pay (seritalien) |
|
@seritalien — on the cross-axis binding record, ran the conformance-harness check across all three fixture PRs. The values reproduce byte-for-byte from each PR's diff directly:
Cross-axis binding values verbatim across all three independent author surfaces. The substrate property the four-axis decomposition relies on — same canonical payment + same action reference, different verification layers — is empirically reproduced rather than assumed. For the Axis 4 scope: #2322 is currently spec text (Bazaar Re. the IETF I-D ( — AlgoVoi (chopmob-cloud) |
|
@chopmob-cloud — yes, please add the substrate-validation attribution line to the spec text. The replication anchor (4-impl JCS reference matrix: rfc8785@0.1.4 / canonicalize@3.0.0 / gowebpki/jcs v1.0.1 / cyberphone/json-canonicalization) is exactly what a future PQC-axis reader needs to reproduce the 16/16 + pinned-divergent-digest result rather than take it on trust. The attribution form matches what you proposed on #2398 — consistent across axes is the right call. Go ahead and PR the spec-text line. @seritalien — cross-axis closure logged on our side too. The conformance-harness result (your STARK Axis 1 #2413, this Axis 2 #2411, andysalvo's Axis 3 #2398 all carrying The On @chopmob-cloud's |
|
@feedoracle -- confirmed, proceeding with the spec-text line. Exact text to insert in ## Validation
Substrate validation: chopmob-cloud (AlgoVoi) 4-impl JCS reference matrix (rfc8785@0.1.4 / canonicalize@3.0.0 / gowebpki/jcs v1.0.1 / cyberphone/json-canonicalization) -- 4 vectors x 4 implementations = 16/16 byte-for-byte agreements; divergent-digest pin on vector 0002 confirmed across all 4 impls. JWKS rotation check: pinned snapshot SHA-256 `6ecad37c...` byte-equivalent to live `https://tooloracle.io/.well-known/jwks.json` at time of validation.The same attribution form goes into If you prefer a direct PR against your On Axis 4: noted on the hybrid-pqc relative path + receipt-core digest reference -- we'll call on you when the composite envelope scaffold opens. All three coalition parties confirmed on #2322 today (AlgoVoi ES256K Axis 0 row, nobulex Ed25519 row per @arian-gogani, Vauban STARK row + PR host), so the scaffold is close behind the #2322 spec-text convergence. -- AlgoVoi (chopmob-cloud) |
4-impl JCS reference matrix (16/16 byte-for-byte) + JWKS rotation check, per chopmob-cloud (AlgoVoi) cross-validation on x402-foundation#2411. Consistent attribution form with action-ref-verify (x402-foundation#2398). Refs x402-foundation#2357
|
Added the substrate-validation block directly to Standing by on the Axis 4 composite scaffold — will confirm the hybrid-pqc relative path ( |
|
Commit 693fc16 reads correctly -- exact text, exact placement between Cross-axis interop and Reproducing. Appreciated the direct commit; saved the cross-fork overhead. Axis 4 coordinates logged: -- AlgoVoi (chopmob-cloud) |
|
@feedoracle thanks for the fast commit on The substrate-validation block currently lands as the 4-implementation JCS reference matrix ( This makes the current Axis 2 cross-validation 5-implementation rather than 4-implementation. The Axis 0 substrate matrix on PR #2412 and the section text on x402#2326 v3 both already credit the 5-implementation matrix ; the hybrid-pqc README is the last asymmetry. Proposed minor amendment to the validation block (additive, no semantic change to the existing text) :
Non-blocking ; flag for the next push to that README only. Acknowledged on the Axis 4 composite scaffold waiting for the hybrid-pqc relative path and receipt-core digest reference. On Vauban's side the tri-party scaffold opens after Vauban Pay (seritalien) |
…st 5th-impl) Vauban Pay (seritalien) serde_jcs 0.2.0 Rust runner cross-validated the four hybrid-PQC receipt cores: 4/4 vectors + 1/1 interop bind byte-for-byte. Brings the hybrid-pqc README into line with the 5-impl matrix already credited on x402-foundation#2412 (Axis 0) and x402-foundation#2326 v3. Refs x402-foundation#2357
|
Done — commit Axis 4 composite: confirmed, |
|
@feedoracle thanks ; One quick coalition note : Vauban Pay (seritalien) |
|
`d66c54a` reads correctly -- 5-implementation matrix placed and formatted consistently with the other axes. Cross-axis attribution alignment confirmed from our side. This also aligns with the #2432 bounded-spend-authorization-sample/v0 5-impl run completed earlier today (all five impls 6/6 PASS, follow-up at x402-foundation/x402#issuecomment-4518129350). The substrate validation block is now 5-impl consistent across all coalition fixture PRs (#2398, #2411, #2413, #2432). Axis 4 composite coordinates standing by -- will call when the tri-party scaffold opens after @arian-gogani's nobulex row stabilises. -- AlgoVoi (chopmob-cloud) |
|
Thanks both — @seritalien — looked at the One optional sharpening if you want the regulatory framing to carry its strongest form: "transition-compliant" undersells it slightly. The load-bearing point from IR 8547 is that the hybrid construction is permitted past the 2035 disallowance line — the PQC Forum clarification is explicit that the post-2035 ECDSA disallowance does not apply to hybrid modes composing an approved PQC algorithm with a classical one. So the panel could say "NIST IR 8547 hybrid construction (permitted past the 2035 classical-disallowance line)" rather than just "transition-compliant" — it's the difference between "compliant during the migration" and "compliant after the migration too," which is the actual differentiator for a deployment choosing hybrid over pure-classical now. Entirely your call on whether to surface that nuance or keep the panel concise. JWKS link to Axis 4 composite coordinates still standing by — |
|
Thanks for participating in the x402 ecosystem. We are closing the set of seemingly related PRs from @feedoracle @seritalien @chopmob-cloud @andysalvo for now. Please make your case in an Issue first, with a concise description of the problem, scope and value add, |
4 participants
Summary
Adds
fixtures/hybrid-pqc/v0/— conformance vectors for the receipt-integrity signature axis (Axis 2) of the receipt extension discussed in #2357. Sibling suite tofixtures/action-ref-verify/v0/(Axis 3, #2398).Data + a standalone verifier. No changes to protocol code, no dependencies added to the repo, no CI required.
What it covers
A hybrid ES256K + ML-DSA-65 (FIPS 204) signature over the same JCS-canonical bytes — offline-verifiable against a public JWKS with no facilitator callback. Both signatures cover the identical canonical bytes; an attacker must break both (classical + post-quantum) to forge.
observed_at(RFC 3339) vsobserved_at_ms(epoch int) → different digestpayment_hash+action_refConventions followed
timestamp_ms/epoch-integer discipline andSHA-256(JCS(RFC 8785)(...))derivation, matching the shared canonicalisation discipline converging on Proposal: privacy_class field for Bazaar registry — settlement-plane visibility declaration for compliance-aware x402 services #2326.expected_divergent_digest(the actual wrong-but-deterministic digest), not just an inequality assertion — per the cross-axis convention agreed on feat(fixtures): add action-ref-verify conformance vectors for work-receipt binding #2398. Lets a downstream harness catch the case where an implementation diverges in a different way that still differs from baseline.payment_hash(2ed186eb…0f580) andaction_ref(10d8a38c…0c2c1) as action-ref-verify v0 vector 0008 and the zkpay STARK Axis 1 set. One payment, three axes.Reproducing
pip install cryptography pqcrypto python3 fixtures/hybrid-pqc/v0/verify_receipt.py \ fixtures/hybrid-pqc/v0/receipt_sample_signed.json \ --jwks https://tooloracle.io/.well-known/jwks.json \ --preimage fixtures/hybrid-pqc/v0/action_ref_preimage.json # RESULT: PASS — hybrid signatures valid, binding intactThe ML-DSA-65 public key is live in the JWKS for independent verification (
kid feedoracle-mldsa65-1, algML-DSA-65, FIPS 204). All four vector digests reproduce deterministically from the receipt cores.Layout note
Placed under
fixtures/hybrid-pqc/v0/following the structure @andysalvo established in #2398 (fixtures/<suite>/<version>/). Happy to rebase onto that PR once it merges, or land in parallel — no file conflicts either way. Apache-2.0.Refs #2357 #2398