R3: define r3_s256 as the hash of the exact served bytes, not RFC 8785 canonical JSON

[dickhardt]

Summary

draft-hardt-aauth-r3 computes r3_s256 over the RFC 8785 canonical JSON serialization of the R3 document. Propose changing it to the SHA-256 of the exact bytes the resource serves at r3_uri (base64url, unpadded).

Where the spec says canonical JSON

• §Content Addressing: "computed as the SHA-256 hash of the canonical JSON serialization ([@!RFC8785]) of the R3 document, base64url-encoded without padding."
• §R3 Processing → AS Processing, step 3: "Compute the SHA-256 hash of the fetched document using canonical JSON serialization ([@!RFC8785]) and compare it to r3_s256."

Problem

Canonicalization is an extra, error-prone step on both sides: the resource serializes the document, and the AS/MM must re-serialize it identically (RFC 8785 — key ordering, number formatting, unicode normalization) before hashing. Any mismatch breaks verification. It buys nothing here, because the R3 document is fetched as-is over HTTPS — the verifier already holds the exact bytes.

Proposal

Define r3_s256 = BASE64URL(SHA-256(served-bytes)), where served-bytes are the exact response body the resource returns at r3_uri:

• The resource stringifies the document once, serves those bytes verbatim, and sets r3_s256 to their hash.
• The AS/MM hash the raw response body they receive and compare. No canonicalization step.

Rationale

• Simpler; removes a whole class of canonicalization-mismatch bugs.
• Content-addressing still holds: the hash identifies the exact served document.
• Matches the working reference implementation (notes.aauth.dev) and the deployed person.hello.coop behavior.

Sections to update

• §Content Addressing — replace the RFC 8785 definition with the served-bytes hash.
• §AS Processing, step 3 — hash the raw fetched body.
• §R3 Document — keep "served over HTTPS, AS-signature-gated"; add that the resource MUST serve the exact bytes it hashed.