Wiki · Concept · Last reviewed August 12, 2026

C2PA Manifest Store

A C2PA Manifest Store is the collection of signed C2PA Manifests associated with a digital asset. Its last manifest is active; referenced earlier manifests can preserve ingredient lineage. The store makes provenance tamper-evident and inspectable, but it does not prove that the asset or its claims are true.

Category: media provenance / manifest architecture Published: July 10, 2026 Modified: August 12, 2026 Last reviewed: August 12, 2026 Tags: C2PA, Content Credentials, manifest store, JUMBF, active manifest, ingredient lineage, provenance

Definition

A C2PA Manifest Store is the specification-defined collection of one or more C2PA Manifests associated with an asset. It may be embedded in the asset or stored externally. Each manifest carries a signed claim about a particular state or provenance event; the store groups the active manifest with any earlier manifests needed to interpret ingredient history.

C2PA calls a single manifest a Content Credential in non-technical language and says the manifest store represents the Content Credentials of an asset. The store is not the on-screen badge, a trust list, or a manifest repository. Those are respectively a user-interface signal, a certificate-trust input, and an optional storage or recovery service.

This is narrower than content provenance as an editorial and social practice. A validator can use the store to identify signed assertions, test content bindings, follow referenced ingredients, and report failures. It cannot infer that an unsigned asset is false or that a signed assertion is factually correct.

Snapshot

Structure

In the normative binary representation, the outer store is a JUMBF superbox labeled c2pa. It contains one or more manifest superboxes and may also contain extension boxes whose types C2PA does not define. Mere presence inside the wrapper does not make an extension or an unreferenced manifest authoritative.

Every C2PA Manifest contains an assertion store with at least one assertion, one claim, and one claim signature. Assertions are statements about such matters as actions, ingredients, metadata, identity, content source, or cryptographic bindings. The claim references its assertions by hashed URI, and the claim signature signs the claim. Cryptographic authority therefore comes from each signed claim and its verified references—not from the wrapper or a badge alone.

The active manifest is required to be last in the store. Earlier manifests do not automatically form a chronological chain merely because of their position: lineage is established through ingredient references, and C2PA tells validators to ignore additional manifests that are not reached through those references.

Manifest Types and Roles

Type and role should be kept separate. Under C2PA 2.4, a standard manifest contains exactly one hard binding to the asset's content. An update manifest adds permitted provenance information when the covered digital content has not changed; it carries no new hard binding and instead links through exactly one parentOf ingredient assertion to the manifest being updated. Standard and update manifests may also be compressed without changing their semantic type.

Historical time-stamp manifests are deprecated. C2PA 2.4 says claim generators must not write them and manifest consumers must not read them; current workflows use time-stamp assertions, including in update manifests. Preservation systems should therefore retain the original bytes while reporting that the old construct is outside the current processing path.

Active manifest is a positional role: it is the last manifest in the store. Ingredient manifest is a graph role: it is a manifest referenced by an ingredient assertion. A standard manifest can occupy either role, and an update manifest can point to a standard or earlier update manifest.

When an imported ingredient has its own store, a claim generator normally copies its manifests into the new asset's store. For an ingredient with provenance, the current c2pa.ingredient.v3 form can hash-reference both its active manifest and claim signature and records the claim generator's validation results. That supports efficient validation and redaction-aware lineage; it does not prove that every component used in production was declared.

Embedding and Discovery

A validator first looks in the format-specific location for an embedded store. If none is found, C2PA defines an ordered search by reference: an HTTP Link header using rel=c2pa-manifest, an XMP dcterms:provenance URI, a font C2PA table, and then a same-path or same-URI .c2pa sidecar. A validator may search additional locations, but once it locates a store it proceeds with that store rather than combining every candidate.

The IANA registries list both the c2pa-manifest link relation and the application/c2pa media type. C2PA 2.4 also specifies embedding or reference mechanisms for HTML, structured text, unstructured text, PDFs, ZIP-based documents, images, audio, video, fonts, and live-media workflows; the exact byte location and binding method remain format-specific. PDFs with incremental updates are a special case: they may contain multiple stores, but no more than one may appear in an individual update section.

Embedded stores travel with files only through workflows that preserve or deliberately re-sign them. Screenshots, metadata stripping, transcoding, and ordinary platform processing can remove them. Remote repositories and soft bindings can improve recovery, but introduce availability, tracking, access-control, and link-resolution dependencies. If a documented remote store is unavailable, the specified result is manifest.inaccessible, not “fake” or “authentic.”

Validation

Validation begins by locating the store and selecting its last manifest as active. A validator then checks required structure, assertion references, ingredient relationships, the claim signature, time-stamp and revocation evidence, and the asset's content binding. It returns success, informational, and failure codes for the active manifest and every ingredient manifest reachable through ingredient assertions; unrelated extra manifests in the store are ignored.

If the active record is a standard manifest, its hard binding is checked against the covered asset bytes or regions. If the active record is an update manifest, the validator follows its parentOf chain until it reaches the standard manifest that supplies the binding. Thus “the active manifest contains the hard binding” is not always correct.

C2PA 2.4 defines a hierarchy of results:

These states answer cryptographic and conformance questions. They do not establish the truth of a scene, fairness of a caption, completeness of the declared workflow, consent of a depicted person, or lawfulness of the content.

Redaction

A signed assertion cannot simply be edited in place. C2PA redaction is a defined operation applied when an asset is used as an ingredient: the copied ingredient manifest may omit an entire assertion or replace its content with the specified redaction marker, while the new claim records the assertion's URI in redacted_assertions. The label remains available so a consumer can know the category of information removed.

Redaction is constrained. Actions assertions cannot be redacted, and an update manifest cannot redact the hard binding that applies to the current asset. When content bytes have not changed, the specification recommends an update manifest to document the redaction; the c2pa.ingredient.v3 claim-signature reference supports validation of a redacted ingredient lineage.

This is selective disclosure, not guaranteed erasure. Earlier copies, caches, repositories, soft-binding lookups, or recipients may still hold the unredacted manifest. A privacy process must therefore address retention and access at every store location, not merely add a redaction record to a later asset.

Current Context

As of August 12, 2026, C2PA 2.4 is the latest specification set shown on the official site. Published in April 2026, it added HTML and structured-text embedding, extended existing live-video rules to dynamically packaged content, and introduced AI Disclosure and repository-receipt assertions. The specification set also retains the unstructured-text embedding method introduced in version 2.3.

Version 2.4 also introduced Content Credentials JSON, or crJSON. Despite its convenient JSON-LD form, the crJSON specification is explicit that it is a derived, potentially non-lossless view for profile evaluation, interoperability testing, and validation reporting. It is not an input format, an independently verifiable credential, or a replacement for the original JUMBF store and asset.

The new assertions remain signed statements, not automatic guarantees. A repository receipt can support an ingestion claim but not permanent availability. An AI Disclosure assertion can carry machine-readable model and oversight information, but its presence does not independently audit the named model, training rights, human review, or downstream use.

Governance and Safety

For newsrooms, courts, archives, campaigns, platforms, and public agencies, a manifest store should be treated as one evidence layer within a documented verification process. The governance task is to preserve the raw evidence, validate it reproducibly, interpret each assertion at the right confidence level, and show uncertainty without turning provenance into a reputation score.

Limits

C2PA's security model aims to expose unauthorized modification of signed provenance and covered content. It expressly does not prevent complete removal of manifests. Manifest repositories and soft bindings can help recover stripped credentials, but they add new privacy and security trade-offs.

The disciplined reading is therefore specific: which store was located, which manifest was active, which referenced lineage was available, which bytes were bound, which signatures and credentials validated, what was redacted, what was not declared, and what still requires external corroboration?

Review Record

Source Discipline

Normative implementation claims should cite the numbered C2PA specification version and section. C2PA's implementation, security, harms, and user-experience documents are primary sources for intended practice and identified risks, but they are informative guidance rather than independent audits of deployed products. Current registry claims should cite IANA.

Do not collapse the manifest store into trust lists, identity assertions, source-type vocabulary, watermarking, moderation, or fact-checking. Name the evidence layer and the actor making the assertion. “The manifest says a model was used” is narrower than “a model was used,” and neither establishes consent, legality, quality, or truth.

Preserve distinctions among absent, inaccessible, malformed, well-formed, invalid, valid, trusted, and valid asset. The specVersion field in claim-generator information is informational; C2PA security guidance says validators should apply current security-relevant checks and disclose the validation version. A crJSON export is a reporting view, so material findings should be reproduced against the original asset and manifest store.

Spiralist Reading

Spiralism reads the manifest store as the archive hidden inside the artifact. A public sees an image, clip, document, or badge. Underneath it may be a chain of claims: capture, edit, import, redaction, export, signature, ingredient, and warning.

The danger is badge collapse. The store can become a symbol that says "trust me" when it should say "inspect me." The right practice is to ask what was signed, what was missing, what was redacted, and what still needs human corroboration.

The manifest store is most valuable when it keeps provenance contestable: a graph that can be preserved, independently parsed, and challenged—not an authority token that closes inquiry.

Open Questions

Sources

Return to Wiki