R3 hash verification: add explicit "no canonicalization, hash bytes as served" guidance

[rohanharikr]

The R3 spec currently mandates RFC 8785 canonical JSON serialization for the hash:

"computed as the SHA-256 hash of the canonical JSON serialization ([@!RFC8785]) of the R3 document" (§ R3 hash)
"Compute the SHA-256 hash of the fetched document using canonical JSON serialization ([@!RFC8785])" (§ R3 fetch verification)

Suggestion: remove the canonicalization requirement. Hash the bytes the resource serves, not a re-canonicalized form.

Rationale:

• Canonicalization adds an implementation dependency (RFC 8785 libraries, edge cases) that's hard to get right.
• The resource is the authoritative source of bytes — its serialization IS the document.
• Pattern: serialize once at the RS, persist those bytes, serve them verbatim. Verifier hashes received bytes directly.

Practical implications:

• Replace "canonical JSON serialization" with "the bytes returned by the resource"
• Add implementer guidance: serialize once, store, serve verbatim — re-serialization between hash computation and serving will break the chain
• RSes that build R3 documents on the fly need to persist serialized bytes (e.g. KV) rather than re-build/re-serialize per request

[jagmarques]

There is a real tension here, but I think the spec should keep canonicalization and instead tighten the implementation guidance.

The "hash bytes as served" pattern works as long as the bytes are produced exactly once and never re-serialized. In practice it breaks in three places:

1. Any HTTP intermediary that decompresses, re-compresses, or alters Content-Encoding will change the served bytes without changing the document. CDNs, reverse proxies, and even some logging middleware do this.
2. JSON libraries with non-deterministic key ordering or different float-formatting between encode and re-encode will silently break verification on the verifier side if it ever round-trips. It does, eventually, somewhere in a multi-team deployment.
3. RS implementations that build R3 documents from a database row do not have authoritative bytes; they have a record. They have to canonicalize at construction time anyway.

RFC 8785 was written specifically to solve "two implementations, same JSON value, different bytes". Dropping it pushes the canonicalization burden into operations, where it gets handled inconsistently.

A middle path that I think actually matches the proposal's intent: keep RFC 8785 as the canonical form, but add a normative requirement that the RS persists the canonical bytes at issuance time (along with the signature), and serves those exact bytes on subsequent fetches. The verifier hashes received bytes directly, with no re-canonicalization. The canonicalization happens once, in one place, with one library, at the moment the document is signed.

That gives you the implementation simplicity the proposal wants ("verifier hashes received bytes") without losing the interoperability guarantee that RFC 8785 buys you. The only thing the spec needs to add is that the RS must not re-build or re-serialize the document between hash computation and serving, which is what the proposal already says.

Worth checking if anyone is hitting RFC 8785 edge cases in practice (BigInt, unpaired surrogates, -0 vs 0, locale-dependent number formatting in older Java/Go libs) before pulling it. If yes, narrowing the JSON profile is more useful than removing canonicalization.