C2PA ZIP Manifests: Reviewing EPUB and Office File Integrity

Start with an unchanged copy

Save the exact EPUB, DOCX, XLSX, or other ZIP-based file before opening it. Record its source, acquisition time, filename, validator name, and version. Keep the complete validator output; a single green badge cannot show which ZIP check ran.

The narrow question is whether the ZIP container and the C2PA Manifest Store satisfy the specification's integrity checks. That result does not establish that the text, image, author, date, or event described by the document is true.

Check the ZIP container before the manifest

C2PA 2.2 describes a ZIP-based embedding path. A validator checks the file hashes and the ZIP Central Directory hash, then verifies that the Manifest Store is in the expected location. Record each result separately: file hash, Central Directory hash, placement, and any exact status code.

Do not replace a missing or unreadable field with a pass. If the tool cannot read the Central Directory or cannot locate the Manifest Store, preserve that output and mark the stage as unresolved. A failed container check means the recorded bytes do not satisfy that technical check; it does not identify who changed them or why.

Verify placement and signing as different stages

Once the ZIP structure is readable, confirm that the Manifest Store is placed where the ZIP profile allows it. Then review the C2PA claim and signature results. A correctly placed store can still contain an invalid signature or an invalid assertion. Conversely, a signature result cannot repair a damaged ZIP container.

Make one row per stage with the file digest, Central Directory result, store location, claim status, signature status, validator version, and unresolved fields. When comparing a download with a publisher's retained copy, hash both copies independently and report only observed differences.

Before reporting a result, note the archive format and the validator profile used. EPUB and Office packages may contain many members, so record which member or byte range the tool covered. If a publisher provides a detached manifest or a second download, do not merge their records: retain separate hashes, timestamps, and outputs. A later successful run can show that the current copy passes; it cannot rewrite an earlier failure. This distinction helps reviewers explain a broken package without assigning intent.

The review should also capture the archive member list, the byte range covered by the profile, and whether the file was re-saved by an editor. If a detached manifest or a second download is available, keep it as a separate artifact with its own digest and acquisition time. A later pass describes the current copy only; it does not erase an earlier failure. This record lets another reviewer reproduce the check and challenge a narrow technical result without turning it into an accusation. Do not infer a file conversion, malicious edit, or publication motive from a status code. Keep the review factual and fully reproducible for every reviewer. Ask the publisher for the original package and compare the two byte streams when that is possible.

Keep integrity separate from document meaning

A matching ZIP or manifest hash supports a claim about bytes and references. It does not verify the accuracy of a quotation, spreadsheet value, image caption, or represented event. A mismatch does not prove that the document is fabricated; it says the validator found a technical disagreement with the recorded value. A useful log also records archive member names, embedded or external references, and whether an office application re-saved the file before testing. Preserve the original bytes and any re-saved copy as separate artifacts so another reviewer can reproduce the comparison.

If you use DeepFakeCheck text detection, keep its probabilistic signal in a separate section. Automated detection can produce false positives on authentic writing and false negatives on generated or edited text. It does not validate ZIP hashes or issue C2PA status codes.

Sources

• C2PA, “C2PA Technical Specification — Embedding manifests into ZIP-based formats”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_embedding_manifests_into_zip_based_formats