[Proposal]: versioned delegate-SD-JWT chain golden vectors + a CI drift canary against the reference

[vishkaty]

Summary

Offering a versioned golden-vector set for the delegate SD-JWT chain layer (the ~~ wire format mandates travel on), plus a standing CI cross-check against this repo that works as a drift canary while the chain layer tracks a moving draft.

This picks up the conformance-vectors thread from Discussion #262 and complements #265, which covers open_mandate_hash / JCS canonicalization — the layer below. These vectors cover the chain layer above it: disclosure hashing, _sd/sd_hash linkage, hop composition on the ~~ wire, and nested merchant_authorization binding.

What exists today

A vector set keyed to exact revisions (inventory and change policy: docs/ap2-vectors.md):

Layer	Pinned revision
Delegate SD-JWT chain draft	draft-gco-oauth-delegate-sd-jwt-00
AP2 reference	this repo @ e1ea56d
Frozen standards	RFC 9901, RFC 8785, RFC 7515

• Valid checkout-mandate and payment-mandate chains, plus a nested-binding set whose three negatives are syntactically valid and caught only by binding verification (hash mismatch, missing nested authorization, tampered terms) — the pair-invariant idea from [Proposal] v0 conformance vectors for open_mandate_hash derivation (cross-impl validated) #265 applied one layer up.
• Two-way cross-verified: an independently written verifier (built from the RFCs, no shared code with this repo) accepts reference-minted chains byte-for-byte, and the reference verifier accepts chains minted by the independent implementation, including constraint and schema checks.

The canary offer

Our CI reinstalls this repo at the pin on every run and byte-compares chain computation (disclosure digests per RFC 9901 §5.1, sd_hash, canonical chain segments) against the independent implementation. In practice that means: when the draft or this repo's chain machinery moves, the divergence surfaces immediately as a byte diff keyed to a commit.

If useful, happy to:

1. publish a new keyed vector set for each draft/reference revision (existing sets never mutate, so implementers can diff behavior across revisions);
2. report any observed divergence here as a small issue keyed to the commit that introduced it;
3. contribute the cross-check as an optional workflow in this repo, if you'd rather run the canary yourselves.

No action needed on your side for (1) and (2) — this is mostly a "this exists, use it if it helps" note, and I'd rather align with however you're planning official conformance vectors than run ahead of it.