C2PA Collection Data Hashes: How to Verify a Set of Files

Preserve the collection before validation

Save the collection in the form you received it before opening or reorganizing any member. Record the source, retrieval time, manifest location, directory layout, file names, and a stable identifier for the copy under review. If the collection arrived as an archive, keep the received archive and the extracted working copy as separate items. This evidence log is an operating recommendation from this article, not a reporting format required by C2PA.

Use a C2PA-compatible validator and save its complete output with the collection. Record the tool and version. Check whether the validator finds the members listed by the c2pa.hash.collection.data assertion and obtains the recorded hash for each one. Preserve member-level output so the record identifies the URI, algorithm, and availability of each listed file.

Do not rename, move, normalize, or re-export members before the first check. Those actions can change the path or bytes being tested. If you need a working copy, give it another identifier and validate it separately.

Read the URI list as the declared scope

C2PA 2.2 uses a collection data hash assertion when a manifest refers to a collection of assets. Its label is c2pa.hash.collection.data. The uris array associates each relative URI with a hash. The assertion also carries one alg value, so the listed content items use the same cryptographic hash algorithm. Optional member fields can include byte size, media type, and data-type information.

Copy the URI list exactly as the validator reports it. The specification treats each URI as relative to the manifest location, whether the manifest is local, in a container, or in the cloud. A claim generator must validate or sanitize these references so . and .. do not appear as URI path elements. If either element appears in the material you review, record the reference and stop until its intended location is clarified. Do not silently resolve a suspicious path and then describe it as valid.

The list is the assertion's declared scope. C2PA does not require every file in a hierarchy to be included. That flexibility means an unlisted file can be added without invalidating the listed bindings. Record both the members named in the assertion and any other files you observed, but do not claim that the hash assertion covers an unlisted file.

Check required fields and every file hash

The schema defines uris and alg for the collection, and each member entry contains uri and hash. Check that these fields are present. If one is absent, mark the record incomplete and preserve the validator's actual message instead of inventing a status.

Each listed file is hashed individually with the algorithm in alg, and the result is stored with that file's URI. Recalculate the hash over all bytes of the member, from the first byte to the last, with no exceptions, then compare it with the entry's hash. Record match, mismatch, or unavailable in your review table using the validator's actual wording.

Build a review table with the collection identifier, manifest location, algorithm, URI, observed file identifier, optional declared size or media type, computed status, and exact result code. Mark fields as unreported when the tool does not expose them. This makes a second review possible without filling gaps by inference.

Keep integrity separate from file meaning

A complete set of matches supports a limited observation. The validator found the listed members, and their full-file bytes matched the hashes recorded in this assertion. It does not show that the collection includes every relevant file, that the signer is trustworthy, that metadata is accurate, or that events described inside the files happened. Those questions require other C2PA checks and independent evidence.

A mismatch, invalid URI, malformed entry, or missing listed file shows that this copy did not pass the specified collection binding check. The result does not identify who changed the collection, when it changed, whether an omission was deliberate, or whether a document, image, audio recording, or video tells the truth. Preserve the received copy and compare another copy only after validating it under its own identifier.

If you use DeepFakeCheck for a separate probabilistic media signal, keep that output outside the C2PA record and link it to the exact file analyzed. Automated analysis 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 authenticate the collection or repair a hash failure.

Leave a review another person can repeat

Store the original collection, manifest, validator version, full output, URI table, and any external-source checks together. Another reviewer should be able to locate the same manifest, follow the same relative URIs, and reproduce each comparison. If a tool hides member-level output, record that limitation instead of converting an aggregate badge into several assumed matches.

Check claims about the files through their original publishers, stated dates and locations, accountable organizations, and independent evidence about the subject. The collection data hash answers which declared files matched a cryptographic record. It does not answer whether the collection is complete or whether its contents are true.

Sources

• C2PA, "C2PA Technical Specification: Collection Data Hash": https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_collection_data_hash