Problem
Current HTTP request binding compares JCS(actual body) with JCS(invocation.args). That is acceptable for the JSON golden path, but long-term it forces the verifier to handle the full request body and makes privacy/size tradeoffs harder. A signed digest gives the same binding property with a cleaner contract.
What to do
Design the next request-binding contract around a digest:
- compute
sha256(jcs(body)) for JSON bodies
- carry the digest in the signed invocation payload or a clearly versioned binding field
- verify digest equality at the tool boundary
- preserve the existing equality mode until migration is explicit
Acceptance criteria
- written design explains migration from JCS equality to digest binding
- test vectors cover matching digest, mismatched digest, reordered JSON keys, and invalid body
- docs explain privacy/size benefits and JSON-only limitations
- no existing HTTP golden-path behavior is broken without a versioned migration decision
Out of scope
- supporting arbitrary binary body canonicalization
- changing the first pilot wedge before it is stable
- removing current equality binding without migration
Problem
Current HTTP request binding compares JCS(actual body) with JCS(invocation.args). That is acceptable for the JSON golden path, but long-term it forces the verifier to handle the full request body and makes privacy/size tradeoffs harder. A signed digest gives the same binding property with a cleaner contract.
What to do
Design the next request-binding contract around a digest:
sha256(jcs(body))for JSON bodiesAcceptance criteria
Out of scope