C2PA Data Hash Assertions: How to Review Asset Binding

Preserve the file that produced the result

Save the exact media file before opening it in a validator. Record its source page, download time, filename, size, and a file hash if your existing workflow already calculates one. If a platform provides an original and converted copies, label each copy and identify the one under review. This evidence log is an operational method proposed here; it is not a record format required by C2PA.

Use a C2PA-compatible validator and note the tool name and version. Keep the complete output with the saved file. A badge or a shortened status cannot show which assertion was checked, which byte ranges were excluded, or which copy produced the result. Do not convert, re-export, or rewrite metadata in the evidence copy before validation. Those operations create a different review target.

Write the question beside the record: does the data hash assertion bind the inspected bytes as the validator reports? Keep that question separate from who published the media, whether the caption is accurate, and whether the depicted event occurred.

Read the assertion and its exclusions

C2PA 2.2 assigns the label c2pa.hash.data to a data hash assertion. The specification says the assertion stores a cryptographic hash for a specified range of asset bytes. The hash value is required. An alg field may name the hash algorithm; when it is absent, the validator takes the algorithm from the enclosing structure. There is no default algorithm when neither location supplies one.

The assertion may also contain exclusions. Each exclusion has a start position and length. The specification requires these ranges to appear in increasing start order and forbids overlap. An exclusion must begin and end within the same logical unit and cannot overlap that unit's header or length field, except for free-box or padding data. C2PA limits the excluded content to the C2PA Manifest Store or asset metadata such as EXIF or IPTC.

Copy only the fields the validator exposes: assertion label, algorithm, hash status, and each reported exclusion start and length. Mark an absent field as not displayed. Do not infer byte offsets from another copy. The specification also marks the old url field as deprecated and says claim generators must not add it.

C2PA states that a data hash assertion cannot appear in a cloud data assertion and cannot be used with a compressed manifest. Record such a validation message verbatim if the tool reports it. Avoid guessing which application created the structure or why it is malformed.

Interpret a match or mismatch narrowly

A matching result supports one bounded observation: the validator computed the relevant hash over the included bytes and matched the value declared by the assertion. It does not establish that every metadata field is accurate, that the signer is trustworthy, or that a caption about a real event is correct. Excluded ranges need their own review because they were outside that hash calculation.

A mismatch means the computed value did not match the declared value for this file and assertion. Preserve the exact failure code or message and the inspected file. The mismatch alone does not identify which byte changed, who changed it, when it changed, or whether the media depicts a fabricated event. Compare another copy only after assigning it a separate identifier and validating it independently.

Keep unknowns visible. If the tool does not expose exclusions, algorithm selection, or a complete status, write that the field was not displayed. A precise incomplete record is more useful than a completed table filled with assumptions.

Keep media detection and event checks separate

A saved image, video, audio file, or text can be submitted to DeepFakeCheck for a probabilistic risk signal. Store that output separately from the C2PA validator record and link it to the exact analyzed copy. Use a C2PA-compatible validator for the c2pa.hash.data review, and keep the DeepFakeCheck output in a separate record.

Automated analysis can produce false positives that flag authentic material and false negatives that miss synthetic or altered material. A high-risk result supports further review. A low-risk result does not authenticate the file, repair a hash mismatch, or confirm the depicted event.

Check the real-world claim through the original publication, the account or organization presenting the media, the stated date and place, and independent evidence about the event. Finish the review with the file identifier, validator and version, assertion fields, exclusions, complete status, detector output if used, external-source findings, and the decision taken.

Sources

• C2PA, “C2PA Technical Specification — Data Hash”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_data_hash