C2PA Multi-Asset Hashes: How to Review Several Bound Assets

Preserve the exact multi-part file and validator output

Save the file before opening it in a C2PA-compatible validator. Record its source, retrieval time, filename, size, validator name and version, active manifest label, and complete output. This worksheet is an operational method proposed here, not a C2PA reporting format. Do not re-export the file or replace it with a screenshot before the first validation.

Find the assertion labelled c2pa.hash.multi-asset. Copy the parts array in its reported order and keep each location, hashAssertion, and optional value tied to the same entry. The specification says this assertion changes how hard binding is handled but is not itself a hard binding. It must not appear in a cloud data assertion, and C2PA recommends avoiding it with a compressed manifest while compatibility remains unevaluated. Record what the validator reports rather than inferring the software that created the structure.

The review has one narrow question: do the listed parts locate and bind the sections of this exact file as reported? It does not decide whether a caption, person, place, date, or depicted event is true.

Check every location and the full byte range

C2PA 2.2 requires every part, including the primary part, to appear as a part-hash-map object in parts. A location uses either byteOffset with length, or bmffBox. For a bmffBox location, the part is the payload of that box and excludes the box header. Copy the locator exactly; do not convert a box path into guessed byte offsets.

The parts must follow their order in the file. Together they must be contiguous, non-overlapping, and cover every byte of the asset. Build a simple range table for byte-based entries: part number, start, length, calculated end, and next start. A gap, overlap, reversed order, or uncovered tail is a structural finding. If the validator does not expose enough detail to calculate coverage, mark coverage as unverified and preserve the full output.

Treat every copy as a separate target. Validate each copy independently, and do not use one copy's results to fill fields missing from another.

Follow each part to its hash assertion

Each hashAssertion is a hashed URI to that part's hash assertion. C2PA requires the referenced assertion to be a standard hard binding type, such as c2pa.hash.data, with .part and any multiple-instance identifier appended to its label. The suffix distinguishes part bindings from the standard hard binding for the whole asset and permits multiple part assertions in one manifest.

Record the literal URI, resolved assertion label, hash algorithm and result only when the validator exposes them. Keep the overall asset hard-binding result in a separate row. A passing whole-file binding does not replace a failed or unreported part result, and a passing part does not establish the status of the other parts.

The optional boolean defaults to false when absent. An optional part may be removed by a workflow without a trusted signer while integrity for the remaining file is still desired. Record whether optional was present and its value. Do not reinterpret an absent part as harmless unless the assertion marks it optional and the validator reports the remaining checks.

If a part has its own C2PA Manifest that is not self-contained in that part, the specification recommends storing that manifest in the asset's Manifest Store and referencing it with a componentOf ingredient. Record such a reference only when it appears in the inspected output.

Report integrity without authenticating the event

A pass supports a limited statement: this validator found the declared part layout and applicable part hashes consistent for this file. A failure should stay attached to the exact part, locator, URI, code or message, and file copy. It does not by itself identify who changed the file, when a change occurred, or whether the represented event was fabricated.

If you also analyze the preserved file with DeepFakeCheck, keep that probabilistic result outside the C2PA table and link it to the exact copy. Automated analysis can produce false positives on authentic media and false negatives on synthetic or altered media. Keep its probabilistic result separate from the C2PA validator result.

Finish with the saved file, complete validator output, part-range table, resolved hash references, optional-part status, separate whole-asset result, original publication check, and the reviewer's decision.

Sources

• C2PA, “C2PA Technical Specification, Multi-Asset Hash”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_multi_asset_hash