Problem
HTTP Shape 1 can prove that the executed request body matches the signed invocation. Pure JSON-RPC Shape 2 currently verifies the bundle from _meta, but it does not send the actual JSON-RPC params as the /verify binding body. That is fine if we say it clearly. It is dangerous if users think Shape 2 has the same execution-integrity guarantee as Shape 1.
What to do
Choose one contract and make the code, tests, and docs match it:
- implement Shape 2 params/body binding parity, or
- explicitly scope Shape 2 to provenance verification only for the first pilot wedge
Acceptance criteria
- one written decision exists in the docs
- helper package behavior matches that decision
- tests prove the chosen behavior
- README and builder docs do not imply stronger guarantees than the code provides
Out of scope
- plugin work
- new transports
- broad standards positioning
Problem
HTTP Shape 1 can prove that the executed request body matches the signed invocation. Pure JSON-RPC Shape 2 currently verifies the bundle from
_meta, but it does not send the actual JSON-RPC params as the/verifybinding body. That is fine if we say it clearly. It is dangerous if users think Shape 2 has the same execution-integrity guarantee as Shape 1.What to do
Choose one contract and make the code, tests, and docs match it:
Acceptance criteria
Out of scope