pub fn verify_embedded_hash(dr: &DataRef) -> Result<(), AcdpError>Expand description
Verify a DataRef’s declared embedded.content_hash against its
embedded payload. Does nothing if the ref has no embedded, or if
embedded.content_hash is absent.
RFC-ACDP-0002 §6.6 (“Check 8”) scopes the publish-time integrity
obligation to embedded.content_hash only: when present, it MUST
match the SHA-256 of the decoded embedded.content bytes — that is
this function’s entire job. The DataRef-root content_hash (§6.1)
carries no publish-time obligation for embedded refs; §6.6 explicitly
says a registry “MAY additionally verify” it, but this function
deliberately does not, so as to accept every context whose only
obligation is the required one. Root-checking used to also be
exercised here — reverted (see CHANGELOG.md) after it was found to
reject the spec’s own canonical examples/mixed-data-refs/ example
(root and embedded hashes legitimately differ there): a registry
exercising the root-check MAY is spec-permitted, but doing so
unconditionally, with no way to opt out, made this crate reject
spec-conformant publishes that the minimum required check accepts.
Consumers verify the root field after fetching location-form data
(§6.5, acdp-client) — that check lives entirely there and is
unaffected by this function, which only ever runs for embedded refs.
A mismatch is a data-reference-level integrity failure
(AcdpError::DataRefHashMismatch, wire code data_ref_hash_mismatch)
— the embedded bytes diverged from a producer-declared hash, but the
body’s own content_hash / signature are unaffected. It is NOT the
body-level AcdpError::HashMismatch (RFC-ACDP-0007 §5, data-ref-007).