C2PA Assertion Hashed URIs: Reviewing Missing and Mismatched Assertions

Preserve the file and the complete validator output

Save the exact file before opening it in a C2PA-compatible validator. Record the source URL or local path, filename, acquisition time, validator name, and validator version. Keep the complete output beside the file. This log format is an editorial method for repeatable review; C2PA does not require reviewers to use this particular worksheet.

Limit the question before reading the result: does each assertion reference in this claim resolve inside the same C2PA Manifest, and does the assertion data match the hash recorded by the claim? That question concerns the internal integrity of a provenance record. It does not establish whether a caption, speaker, location, capture time, or depicted event is accurate.

Give the claim and every assertion a short local identifier. Copy technical labels and status codes exactly. A color badge or a single pass/fail headline can hide whether the validator found a missing reference, an outside-manifest reference, invalid data, or a hash mismatch.

Resolve each hashed URI before checking its hash

C2PA 2.2 says the entries in a claim's created_assertions and gathered_assertions fields are hashed_uri structures. Version 1 claims use the assertions field. Assertions gathered from another source remain part of the claim and go through the same validation algorithm. Review each entry rather than sampling one result.

First check whether the URI is listed as a redacted assertion. A claim cannot redact an assertion in its own manifest. For assertions that are not redacted, resolve the url field and preserve the resolved location. The reference must point to a self#jumbf location within the same C2PA Manifest. If it points outside that manifest, the specification uses assertion.outsideManifest. If the URI cannot be resolved and its data retrieved, it uses assertion.missing.

Keep those outcomes separate. assertion.outsideManifest means the reference crosses the permitted manifest boundary. assertion.missing means the validator could not resolve and retrieve the referenced data. Neither code, by itself, explains who changed a file or why the record is in that state.

Also record an assertion present in the assertion store but absent from the claim's assertion arrays. C2PA assigns assertion.undeclared to that condition. Do not silently add the assertion to your notes as though the claim had declared it.

Determine the algorithm and compare the JUMBF hash

After the URI resolves, follow the specification's algorithm-determination procedure. Record the algorithm the validator used and any failure code it returned. Then compute or have the validator compute the assertion hash using the JUMBF-box hashing procedure cited by C2PA, and compare it with the hash field in the hashed_uri.

A mismatch is recorded as assertion.hashedURI.mismatch. A match is recorded as assertion.hashedURI.match. Preserve the case-sensitive code, the assertion label, the resolved URI, the algorithm, and the value or digest identifier shown by the tool. If the tool hides one of these fields, mark it as not displayed; do not infer it from a success badge.

The hash comparison answers a narrow question: whether the computed assertion data agrees with the value the claim recorded under the selected algorithm. A matching hash does not make every statement inside the assertion true. A mismatch also does not prove that the media is synthetic or that the event shown is false.

Keep data-format failures in their own row

C2PA applies further checks after reference and hash handling. If a standard assertion is not well-formed CBOR, the claim receives assertion.cbor.invalid. Non-conforming JSON produces assertion.json.invalid. Record these separately from assertion.missing and assertion.hashedURI.mismatch; they describe different stages of validation.

A useful review table has one row per assertion and columns for claim identifier, array name, assertion label, URI, redaction status, resolved location, algorithm, hash result, data-format result, and unresolved question. When comparing two copies, complete the table independently for each file. A blank cell means the validator did not display or find the value during that run, not that the value never existed.

When a result is incomplete, preserve the file and rerun it with a documented validator version. Compare the publisher's retained original or another independently obtained copy when available. Report only the observed difference. The C2PA status code does not supply motive, authorship, or a real-world explanation.

Separate provenance integrity from detection and fact-checking

If you submit the saved file to DeepFakeCheck, keep its probabilistic risk signal in a separate section. DeepFakeCheck does not resolve C2PA assertion URIs, validate JUMBF hashes, or issue C2PA status codes. Automated detection can produce false positives on authentic material and false negatives on synthetic or altered material.

A high-risk signal supports further review; a low-risk signal does not repair a missing assertion or authenticate the file. Likewise, assertion.hashedURI.match supports the recorded assertion-integrity result but does not confirm the scene, caption, speaker, or publication context. Verify those claims through the original publication and independent sources.

Close the record with the exact file, validator and version, per-assertion table, full output, external-source findings, detector output if used, unresolved questions, and the action taken. Another reviewer should be able to repeat the URI and hash checks without turning a technical integrity result into a verdict about the depicted event.

Sources

• C2PA, “C2PA Technical Specification — Validate the Assertions”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_validate_the_assertions