C2PA Active Manifests: How to Locate Embedded and Remote Credentials

Preserve the asset and its retrieval context

Save the exact asset before starting the review. Record the file name, source URL or local path, retrieval time, media type, and validator name and version. If the asset came through HTTP, preserve the response headers as well as the downloaded bytes. A later copy may have different headers, metadata, or embedded data, so its result cannot replace the result for the first copy. This recordkeeping is an operational method proposed here, not a procedure required by C2PA.

The narrow question is whether a validator can locate the C2PA Manifest Store associated with this asset and then confirm the match. Finding a store is an intermediate technical result. It does not establish who created the depicted event, when it happened, or whether a caption is accurate.

Start with the standard embedded location

C2PA 2.2 says the last C2PA Manifest superbox in the C2PA Manifest Store is the active manifest. The validator first looks for a Manifest Store embedded at the standard location for that asset format. Record whether an embedded store was found and how many stores were present.

For most assets, multiple embedded Manifest Stores make all of them invalid, and validation proceeds as if none were located. PDF incremental updates are a specific exception: a PDF may contain stores in different update sections, but more than one store inside the same update section remains invalid. Preserve the update section and count reported by the validator instead of reducing the result to a generic “credentials found” label.

When the asset was retrieved through HTTP, the validator may inspect the response's Link header before downloading the entire asset. The specification notes that this is useful for large or streamed assets. Keep the original header because the remote reference depends on both the retrieval context and the file bytes.

Follow remote references in a recorded order

If no embedded store is available, C2PA defines several places to check. For an HTTP retrieval, inspect a Link header whose relation is c2pa-manifest. The target may be a normal HTTP or HTTPS URI. A link can also refer to an embedded Manifest Store through a JUMBF URI fragment; references to a specific child manifest are not permitted, and a validator ignores the child-label part.

Next, inspect XMP stored in the asset's standard location outside the C2PA Manifest. A dcterms:provenance key can provide the URI for the active manifest. For a font containing a C2PA table, a non-zero activeManifestUriLength points to the URI to use. If those routes do not locate a store, the validator should try the same path or URI with a .c2pa filename extension and may search other suitable locations.

Write one row for each attempt: location type, exact reference, retrieval result, HTTP status when applicable, and validator message. If a remote location was documented but is missing or unavailable, including an offline case, C2PA uses manifest.inaccessible. Do not rewrite that outcome as “no credentials ever existed.” It reports that the documented store could not be obtained in this review context.

Confirm that the located store matches the asset

A located Manifest Store still needs a match check. C2PA directs the validator to use the hard-binding assertion in the active manifest to test whether the store belongs with the asset and whether the asset changed without manifest updates. Preserve the full hard-binding result rather than marking location alone as success.

If the hard binding does not match, the specification says the validator cannot know from that result whether the asset was modified or the wrong Manifest Store was located. It treats the result as a non-matching hard binding and rejects the manifest. The exact failure code depends on the binding type: assertion.dataHash.mismatch, assertion.boxesHash.mismatch, assertion.collectionHash.mismatch, or assertion.bmffHash.mismatch. Record the code actually returned; do not infer a cause that the code does not provide.

Keep the location evidence, active-manifest identifier, hard-binding type, complete validator output, and exact file identifier together. That bundle lets another reviewer distinguish a missing remote store from a located but non-matching store.

Keep provenance, detection, and event checks separate

A successful location and matching hard binding support a limited statement: the validator found a Manifest Store and obtained the recorded match result for this asset copy. They do not independently verify the caption, speaker, capture time, place, or event shown. Check those claims against the original publication and independent evidence.

If you also submit the preserved file to DeepFakeCheck, keep its probabilistic risk signal in a separate part of the record. Automated detection can produce false positives on authentic media and false negatives on synthetic or manipulated media. A high-risk result supports further review. The probabilistic signal and a C2PA provenance credential are separate evidence mechanisms, and neither proves the depicted event.

Finish with the exact asset identifier, retrieval context, each location attempted, the reference used, accessibility result, active-manifest identifier, hard-binding status, unresolved questions, and the action taken. The next reviewer should be able to repeat the search without guessing which copy or remote response you examined.

Sources

• C2PA, “C2PA Technical Specification, Locating the Active Manifest”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_locating_the_active_manifest