The execution-action-binding v1 vector set merged in #627 cannot distinguish a conformant RFC 8785 canonicalizer from one that sorts by code point. Measured on the merged file.
The measurement
docs/spec/execution-action-binding-v1-vectors.json contains six vectors. Using the rfc8785 package as an oracle:
- no character above U+FFFF appears anywhere in the file;
- for all six vectors,
rfc8785.dumps(preimage) is byte-identical to json.dumps(preimage, sort_keys=True, separators=(',',':'), ensure_ascii=False).
So an implementation that sorts member names by Unicode code point, rather than by UTF-16 code unit as RFC 8785 Section 3.2.3 requires, reproduces every expected digest in the set and passes.
EAB-002-nonascii-sha256 uses 工具 (U+5DE5, U+5177). That exercises multibyte UTF-8 encoding, which is worth having, and it is entirely inside the BMP, where the two orderings agree.
Why the two orderings diverge, and where
RFC 8785 sorts by UTF-16 code unit. For characters above U+FFFF, UTF-16 encodes a surrogate pair beginning in D800-DBFF, which sorts below BMP characters in E000-FFFF. Sorting by code point puts them above. So the sets disagree only when a preimage carries both a supplementary-plane member name and a BMP member name in that range.
What to add
One vector whose preimage has two member names chosen so the two rules produce different orderings, with the expected JCS bytes and digest fixed in the file as the existing six are. A conformant implementation reproduces it; a code-point sorter does not.
The binding contract's fields are fixed at domain, version, agent_id, action_type, action_scope, action_timestamp, all ASCII, so the discriminating case has to come from member names inside a value that is itself an object, or the vector set should state plainly that ordering is not exercised because the preimage shape makes it unreachable. Either answer is fine; the current position of appearing to test it while not testing it is the one to avoid.
Not specific to this repository
The same measurement holds in agentrust-io/trace-spec: 23 of the 24 delegation-link vectors are sub-BMP, so the corpus is satisfied by a correct canonicalizer and an incorrect one alike. Raised there on trace-spec#231 on 10 September. Recording it here so the two are not solved twice or, worse, once.
Related: #588, #627, agentrust-io/trace-spec#231.
The execution-action-binding v1 vector set merged in #627 cannot distinguish a conformant RFC 8785 canonicalizer from one that sorts by code point. Measured on the merged file.
The measurement
docs/spec/execution-action-binding-v1-vectors.jsoncontains six vectors. Using therfc8785package as an oracle:rfc8785.dumps(preimage)is byte-identical tojson.dumps(preimage, sort_keys=True, separators=(',',':'), ensure_ascii=False).So an implementation that sorts member names by Unicode code point, rather than by UTF-16 code unit as RFC 8785 Section 3.2.3 requires, reproduces every expected digest in the set and passes.
EAB-002-nonascii-sha256uses工具(U+5DE5, U+5177). That exercises multibyte UTF-8 encoding, which is worth having, and it is entirely inside the BMP, where the two orderings agree.Why the two orderings diverge, and where
RFC 8785 sorts by UTF-16 code unit. For characters above U+FFFF, UTF-16 encodes a surrogate pair beginning in
D800-DBFF, which sorts below BMP characters inE000-FFFF. Sorting by code point puts them above. So the sets disagree only when a preimage carries both a supplementary-plane member name and a BMP member name in that range.What to add
One vector whose preimage has two member names chosen so the two rules produce different orderings, with the expected JCS bytes and digest fixed in the file as the existing six are. A conformant implementation reproduces it; a code-point sorter does not.
The binding contract's fields are fixed at
domain,version,agent_id,action_type,action_scope,action_timestamp, all ASCII, so the discriminating case has to come from member names inside a value that is itself an object, or the vector set should state plainly that ordering is not exercised because the preimage shape makes it unreachable. Either answer is fine; the current position of appearing to test it while not testing it is the one to avoid.Not specific to this repository
The same measurement holds in
agentrust-io/trace-spec: 23 of the 24 delegation-link vectors are sub-BMP, so the corpus is satisfied by a correct canonicalizer and an incorrect one alike. Raised there on trace-spec#231 on 10 September. Recording it here so the two are not solved twice or, worse, once.Related: #588, #627, agentrust-io/trace-spec#231.