C2PA Claims: How to Review Location and Structural Failures

Preserve the file and the validator output

Save the exact file before opening it in a C2PA validator. Record its source URL or local path, retrieval time, file identifier, validator name and version, current manifest label, and complete output. If another reviewer cannot identify the same bytes and validator version, a later result cannot reliably reproduce the first review. This record sheet is an operational method proposed here, not a reporting format required by C2PA.

Keep the question narrow: did the validator locate one permitted claim box, parse its structure, and resolve the references required by that claim? This stage precedes the cryptographic validation of the claim signature and the validation of assertion contents. A structurally acceptable claim does not prove that a caption, identity, date, place, or depicted event is true. A structural failure does not prove that those claims are false.

Locate exactly one claim box

After locating the current manifest, C2PA 2.2 directs the validator to find its claim JUMBF Superbox. A version 2 claim uses the label c2pa.claim.v2; an older claim uses c2pa.claim. Both use the JUMBF type UUID 6332636C-0011-0010-8000-00AA00389B71, also written as c2cl. Record the label and UUID reported by the tool instead of inferring a version from the file name.

The current manifest may contain only one such box. If the validator finds more than one, the manifest is rejected with claim.multiple. Preserve the count and the exact code. Do not reduce the result to a generic red badge, because the count distinguishes this condition from a missing, inaccessible, or malformed claim. If the tool does not expose the box count, mark it as not reported and retain the complete output for a second validator run.

This location check is separate from locating the active manifest. The active-manifest step identifies which manifest is current; this step identifies the claim inside that manifest. Keep both identifiers in the review record so another person can tell which object produced the failure.

Check CBOR and the required fields

The claim contents must be well-formed CBOR. C2PA points to RFC 8949 Appendix C for that check. Invalid CBOR produces claim.cbor.invalid. Preserve that exact result rather than guessing whether transport, editing, or a generator caused the malformed bytes. The code identifies the failed structural check, not the history of the failure.

For a c2pa.claim.v2 object, the specification lists required fields. The validator must reject the claim with claim.malformed if one is absent. The same code applies when claim_generator_info lacks its required name. Record the missing field if the validator reports it. If the output gives only claim.malformed, do not invent a field name; keep the unresolved item for inspection with a tool that exposes field-level detail.

An icon inside the generator information is a reference and must be validated under the specification's reference rules. This does not turn the icon, tool name, or version into proof that every provenance statement is correct. It only adds another specific reference check to the claim review.

Resolve the signature and assertion references

Read the claim's signature field and resolve its URI to the COSE signature. The signature must be embedded in the same manifest. If the URI points outside that C2PA Manifest box rather than to a permitted self#jumbf location, the claim is rejected. Record the literal URI, resolution result, and returned code before moving to cryptographic signature validation. This article stops at the location and structure boundary; it does not substitute for checking the signature value, certificate chain, time-stamp, or revocation status.

Report a bounded result

Build one table with the exact file identifier, manifest label, claim label, claim-box count, CBOR result, required-field result, signature URI, validator code, validator version, and unresolved questions. Attach the complete output. This makes it possible to distinguish claim.multiple, claim.cbor.invalid, and claim.malformed from later signature or assertion failures.

If you also analyze the preserved asset with DeepFakeCheck, keep that probabilistic risk signal outside the C2PA structure table. Automated detection can produce false positives on authentic media and false negatives on synthetic or altered media. DeepFakeCheck does not locate a claim box or issue the C2PA failure codes described here.

A passing structure review supports only a limited statement: the inspected current manifest contained a claim that passed these location and structure checks in that validator run. A failure identifies a concrete technical condition to investigate. Verify the publisher, caption, people, date, place, and event with the original source and independent evidence.

Sources

• C2PA, “C2PA Technical Specification, Locating and Validating the Claim”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_locating_and_validating_the_claim