test(conformance): portable vectors for the RFC 8785 requirement

[lywinged]

What this is not

§3.2.2 requires an RFC 8785-conformant canonicalizer and names json.dumps(sort_keys=True) as insufficient. tests/test_sign.py already covers that, with four literal-byte known-answer tests over _canonical_bytes. I swapped the canonicalizer for each ad-hoc form in turn to check, and every one of them fails those tests. This PR is not reporting a hole in them and does not replace them.

I mention it because my first read of this was that the requirement was untested, and that was wrong — I had not read test_sign.py before concluding it.

What it adds

1. Portability. A known-answer test over a private function runs only from Python, in this package. ROADMAP.md targets Go, Rust and TypeScript verification libraries for v1.0, and none of them can run test_sign.py. These three fixtures are signed Trust Records: another implementation runs them against its own verifier and finds out whether its canonicalizer agrees.

That matters because no existing record in the repository can tell. Every example is ASCII-only with schema-fixed keys, and on such records every serializer produces identical bytes — so an implementation built on ad-hoc sorting verifies all of them correctly.

2. One vector separates key ordering, which nothing here currently does.

test_jcs_distinguishes_unicode_key_order_from_json_dumps compares {"z": 1, "\U0001f600": 2}. Under RFC 8785's UTF-16 code-unit sort and under Python's code-point sort, that object serializes in the same order — the test's own docstring notes it ("order matches here") — so what it actually detects is the ensure_ascii escaping, which it hardcodes on the comparison side:

>>> obj = {"z": 1, "\U0001f600": 2}
>>> rfc8785.dumps(obj) == json.dumps(obj, sort_keys=True, separators=(",",":"), ensure_ascii=False).encode()
True          # a code-point sorter emitting raw UTF-8 passes this test

Vector 03 uses two keys sharing a zk prefix and differing only after it, where the orderings genuinely disagree:

# Escapes throughout, so nothing depends on how your terminal renders it.
>>> obj = {"zk\U0001f600": 1, "zk\uFFFD": 2}   # U+1F600 is D83D DE00 in UTF-16
>>> rfc8785.dumps(obj)
b'{"zk\xf0\x9f\x98\x80":1,"zk\xef\xbf\xbd":2}'    # D83D < FFFD
>>> json.dumps(obj, sort_keys=True, separators=(",",":"), ensure_ascii=False).encode()
b'{"zk\xef\xbf\xbd":2,"zk\xf0\x9f\x98\x80":1}'    # 0xFFFD < 0x1F600

cnf.jwk is the one schema object open to additional members, which RFC 7517 permits, so this is expressible in a schema-valid record.

The ladder

Ad-hoc form	Fails on
json.dumps(o, sort_keys=True)	any record
… separators=(",", ":")	01, 02, 03
… separators=(",", ":"), ensure_ascii=False	03 only

Each fixture declares diverges_under; the test recomputes it rather than trusting it, and separately asserts the set as a whole still kills every rung — so a vector that quietly stopped discriminating fails rather than passing while documenting a distinction it no longer makes.

Deliberately no number-formatting vector

RFC 8785's IEEE 754 serialization is the other divergence §3.2.2 warns about, and it is unreachable inside a schema-valid record: no field in schema/trace-claim.json is typed number, and integers below 2^53 serialize identically everywhere. test_number_divergence_is_still_unreachable pins that and fails the day a numeric field is added, at which point the right response is a vector here rather than an edit to the test.

Verification

• 114 tests pass (105 before, plus 9)
• ruff check src tests examples clean; verified on Python 3.11 and 3.14
• gen_boundary_vectors.py regenerates the set byte-for-byte; only public JWKs appear in the files
• Every fixture is schema-valid and verifies through verify_record, so none can pass or fail for an unrelated reason
• No normative text, schema, or record field changed. Test material only.
• DCO signed

[github-actions]

❔ Contributor Check: UNKNOWN

Check	Result
Profile	UNKNOWN
Credential	LOW
Overall	UNKNOWN

Automated check by AgenTrust Contributor Check.

[imran-siddique]

Good reasoning, and the honest note that test_sign.py already covers the requirement from Python is why this is worth having: the gap is portability, not coverage. Signed fixtures a Go, Rust or TypeScript verifier can run against its own canonicalizer are exactly what the v1.0 roadmap needs, and no existing ASCII-only example can distinguish a conformant canonicalizer from ad-hoc sorting.