Conformance vectors for binding_hash (JCS + SHA-256)

[mcguinness]

Summary

Add byte-identical conformance test vectors for the denial-binding binding_hash construction, so an independently implemented PDP and Access Request Service have a pass/fail target instead of a prose-only specification.

Background

binding-token-integrity pins the hashed denial-binding form by recomputation over a JCS (RFC 8785) serialized JSON object plus SHA-256. That is correct, but prose-pinned canonicalization is exactly where independently implemented parties quietly diverge (the field set, nesting, and how binding_context_members selects the hashed context members).

Raised in PR #532 review, where a reviewer offered to contribute vectors already validated byte-for-byte across TypeScript, Python, and Go.

Scope

Vectors for:

• Single-item binding_hash: base64url(SHA-256(JCS({"subject": <Subject>, "resource": <Resource>, "action": <Action>, "context": <authz-relevant Context>}))), with subject.properties.act removed.
• Bulk binding_hash: the {"subject": <Subject>, "items": [{"resource": <Resource>, "action": <Action>}, ...], "context": <authz-relevant Context>} form, preserving bound item order.
• binding_context_members selection: which context members feed the hash (the subtlest part, and the one most worth a vector).
• Edge cases: absent vs null members, number canonicalization, array ordering, and an empty authorization-relevant context.

Where

An interop test-vectors location, or a draft appendix. TBD.

Depends on

Freezing the binding_hash field object (currently specified in binding-token-integrity); tracks PR #532.

[aeoess]

Following up on the vectors offer. I've built a first set of byte-identical conformance vectors for the denial-binding binding_hash construction. Before opening a PR, I'd like your read on where they should live and on the points where I did not want to guess at the profile's intent.

I built them against main at 620a233. I also checked PR #532: it changes the surrounding Authorization-Relevant Context wording, but not the hash object, the selected fields, subject.properties.act removal, JCS/RFC 8785, SHA-256, or base64url without padding.

The current set has:

• 35 positive cases covering both single and bulk forms, context-member selection, absent versus null, act removal, literal member names, item and array ordering, nested values, number canonicalization, and string canonicalization (control-character escaping, quote and backslash, forward slash left unescaped, empty strings and keys, non-BMP characters, and NFC versus NFD).
• 8 rejection cases covering malformed or unsupported input, including non-finite numbers, duplicate JSON object members, a lone surrogate, a machinery member named in binding_context_members, and type violations of binding_context_members and context.

Each case is computed independently in TypeScript, Python, and Go. I also re-canonicalized the raw inputs with Sigstore's rfc8785 implementation, which shares no code with those three. All 35 positive cases produce the same canonical bytes and hash across all four paths.

There are four points I left open, carried as proposed cases with both readings and both digests rather than settled:

1. Empty authorization-relevant Context. Should the preimage include "context": {}, or omit context entirely? The construction literal includes the key, which points toward {}, but the "only Subject, Resource, and Action bind" wording could be read the other way.
2. Absent binding_context_members versus []. The profile distinguishes an absent claim from a present-but-empty one, but does not say whether they produce the same hash input. I kept them separate.
3. Duplicate names in binding_context_members, for example ["mfa", "mfa"]. Should implementations deduplicate because the claim describes a set, or reject it as malformed?
4. The integer boundary at 2^53. 2^53 - 1 is covered as the largest safe integer. At 2^53, strict I-JSON handling and more permissive implementations diverge, so I left that as an explicit boundary question rather than declaring one behavior conformant.

The artifact itself is one self-contained JSON file with raw inputs, expected canonical strings, and expected hashes, reproducible with any RFC 8785 implementation. Would you prefer it as a draft appendix, under an interop test-vectors directory, or attached here first?

I've kept the generator and the three language runners separate for now. Happy to contribute those too, but I did not want to invent a repository structure before you chose the shape.

[aeoess]

The vectors are public now so they can be reviewed while the final location is still open:
https://github.com/aeoess/authzen-556-vectors

This is the same set described above: 35 normative cases, 8 rejection cases, and the unresolved points carried separately as proposed cases with both candidate preimages and hashes. vectors.json is self-contained and can be checked with any RFC 8785 implementation.

The TypeScript, Python, and Go runners, plus the independent-library check, are included only as verification tooling.

Happy to move the artifact into a draft appendix or interop test-vectors directory once you decide where it should live. I would keep the proposed cases non-normative until the open questions above are resolved.