A C2PA manifest is the technical record that connects a digital asset to signed information about its provenance. It can describe how the asset was created, which tools or systems handled it, what actions were recorded, and which other assets contributed to the result. The manifest is designed so that protected statements and their association with the asset can be checked for tampering.
The preferred non-technical term for a C2PA manifest is a Content Credential. An asset can carry more than one manifest, so C2PA also defines a larger container called the C2PA Manifest Store. A single manifest is one Content Credential; the Manifest Store represents the collection of Content Credentials associated with the asset.[1]
The hierarchy at a glance
Term | Meaning |
|---|---|
C2PA manifest | One verifiable provenance unit containing assertions, a claim, and a claim signature. |
Content Credential | The preferred non-technical term for a C2PA manifest. |
C2PA Manifest Store | The container holding one or more manifests associated with an asset. |
Active manifest | The current validation entry point: normally the last manifest in the Manifest Store. |
Ingredient | An asset or piece of data that contributed to the current asset or its history. |
Claim generator | The hardware or software component that creates the claim and claim signature. |
Signer | The holder of the private key and signing credential used to sign the claim. |
The distinction between the claim generator and the signer is easy to miss. A camera, editing application, or cloud service may act as the claim generator, but it signs on behalf of the entity represented by the signing credential. The same organization may control both, but the concepts are not identical.
Why C2PA uses manifests
Ordinary metadata can describe a file, but it often offers no dependable way to determine whether the metadata was changed or who was responsible for it. A field saying that an image came from a particular camera or was edited by a particular application can be copied, deleted, or rewritten like any other unprotected data.
A C2PA manifest adds a cryptographic structure around provenance information. It connects statements about the asset, hashes of those statements, a binding to the asset content, and a digitally signed claim. A validator can therefore check whether the signed claim still matches the assertions it references and whether the relevant content binding still matches the asset being examined.
This does not make every statement objectively true. It makes the protected record tamper-evident and identifies the signer responsible for the created assertions. Trust in the resulting provenance still depends on the signer, the security of the workflow, and the context in which the credential is being evaluated.[1]
What is inside a C2PA manifest?
Every current standard or update manifest contains three core structural components: an assertion store, one claim, and one claim signature. A standard manifest also contains exactly one hard-binding assertion that connects it to the protected content.[3][4]
1. The assertion store
Assertions carry the substantive provenance information. Depending on the asset and workflow, they can describe creation or editing actions, software or hardware involved, AI use, source ingredients, selected metadata, thumbnails, identity or attestation information, external references, and content bindings.
The assertion store is the part of the manifest where those assertion objects are collected. The claim does not simply say, in general terms, that the store is trusted. It identifies the assertions being claimed and protects their integrity through cryptographic references. Assertions referenced by the claim must be present in the same manifest unless the specification defines an external-storage mechanism for the data involved.[2]
C2PA distinguishes between created assertions and gathered assertions. Created assertions are made by the claim generator and attributed to the signer. Gathered assertions originate elsewhere in the workflow; the claim protects them against modification, but they are not attributed to the signer in the same way. This allows a signing system to preserve a device attestation or other externally supplied statement without pretending that the signing application originated it.
2. The claim
The claim is the organizing statement for the manifest. It identifies the claim generator, records the specification version used by that generator, refers to the claim signature, and contains hashed references to the assertions being claimed. It can also declare that assertions were redacted from earlier ingredient manifests.
A hashed reference contains both a location and a cryptographic hash. During validation, the referenced assertion is located, hashed again, and compared with the value recorded in the claim. If the assertion changed after signing, the comparison fails even if the modified assertion still appears plausible to a human reader.[2]
3. The claim signature
The claim signature is the digital signature produced over the serialized claim. The signer uses a private key to create it, and the associated signing credential allows a validator to evaluate who controlled that key and whether the credential satisfies the validator’s trust rules.
It is more precise to say that C2PA signs the claim than to say that it directly signs every byte inside the manifest. The signature protects the claim; the claim protects its referenced assertions through hashes; and a hard-binding assertion connects the signed structure to the asset content. These are related checks, but they are not one undifferentiated “valid” flag.
4. The content binding
A content binding associates a manifest with the content it describes. In a standard manifest, the required hard binding uses cryptographic hashes calculated according to the asset format and binding method. If covered content changes without a corresponding new manifest, the binding should no longer validate.
Soft bindings, such as fingerprints or invisible-watermark identifiers, can help rediscover provenance after a manifest is separated from the asset. They are optional discovery mechanisms and do not replace the required hard binding in a standard manifest.
How the parts work together
A simplified creation sequence looks like this:
- The claim generator determines the asset representation that will be signed.
- It creates or gathers the assertions needed for the provenance record.
- It constructs a claim containing hashed references to those assertions.
- The signer’s private key is used to create the claim signature.
- The completed manifest is placed in a Manifest Store, which is embedded in the asset or stored externally.
- The finished output is validated so that the signature, assertion hashes, and content binding can be checked together.
The order matters. A content-changing operation performed after the hard binding is calculated can invalidate the credential. Production systems therefore need to treat signing as part of the finalization pipeline, not as metadata that can be added at any arbitrary point.
The Manifest Store carries more than one moment in time
C2PA serializes its core structures in a JUMBF-compatible container. The outer container is the Manifest Store, and it contains one or more individual manifest structures. Each manifest contains the data created when its claim was issued, including its assertion store, claim, and claim signature. The last manifest in the store is the active manifest.[3]
The Manifest Store should not be pictured as a simple revision list in which every record is merely an earlier version of the same file. It may contain the active manifest for the current asset, manifests inherited from source ingredients, manifests for components used in a composition, or a chain of update manifests that extend an earlier content-bound record.
The active manifest
The active manifest is the current entry point for validation and presentation. If it is a standard manifest, it contains the hard binding used to validate the current asset. If it is an update manifest, the validator follows its required parent relationship until it reaches the standard manifest whose hard binding applies to the unchanged content.
Calling a manifest “active” does not mean that it contains every fact about the asset. It means that validation begins there. Earlier or contributing provenance can be reached through the relationships recorded in ingredient assertions.
Ingredients turn provenance into a graph
An ingredient is an asset or piece of data that contributed to the current asset or to the process that produced it. C2PA 2.4 defines three principal relationship values for current ingredient assertions:[5]
Relationship | How to read it |
|---|---|
parentOf | The ingredient is the parent or earlier rendition from which the current asset was derived. |
componentOf | The ingredient is one component placed into or composed into the current asset. |
inputTo | The ingredient was used as an input to a computational process that created or modified the current asset. |
These relationships make provenance a graph rather than a single timeline. A finished advertisement might be derived from an earlier photograph, contain a separately designed logo, and use a prompt or reference image as input to a generative process. Each branch can have provenance of its own.
When an ingredient has an existing Manifest Store, a C2PA-aware claim generator validates the relevant ingredient manifests and normally copies them into the new asset’s Manifest Store, subject to the specification’s rules and user or configuration choices. The new ingredient assertion then points to the copied manifest and its claim signature. This preserves a traversable record even after the finished asset is separated from the original authoring environment.[5]
Standard manifests and update manifests
C2PA 2.4 uses two main current manifest types. The difference is not about whether one is more authoritative. It is about whether the protected content changed.[4]
Characteristic | Standard manifest | Update manifest |
|---|---|---|
When used | When issuing provenance for a particular asset representation. | When adding permitted provenance information without changing content covered by the existing binding. |
Hard binding | Contains exactly one supported hard-binding assertion. | Does not contain a new hard-binding assertion. |
Required relationship | May contain ingredients appropriate to the workflow. | Contains exactly one parentOf ingredient pointing to the manifest being updated. |
Typical examples | Capture, crop, compositing, transcoding, generated output, edited document. | Publication, opening, metadata edit, declared redaction, or later status information allowed by the specification. |
Content-changing edits | Represented with a new standard manifest and new binding. | Not permitted to be represented as an update-only event. |
Standard manifests
A standard manifest binds provenance to an asset representation. If an image is cropped, a video is transcoded, or a document is edited in a way that changes protected content, the resulting asset ordinarily needs a new standard manifest with a new hard binding. Standard manifests can appear as the active manifest of the current asset or as ingredient manifests preserved from contributing assets.
Update manifests
An update manifest extends provenance without rebinding unchanged content. It contains exactly one parentOf ingredient that points to the manifest being updated. Update manifests may record only the limited actions and assertion types allowed for that purpose; they cannot be used to disguise a pixel, audio, video, or document-content edit as a metadata-only event.
If several update manifests occur in succession, validation follows the parentOf chain back to the first applicable standard manifest and uses that manifest’s hard binding to check the content.
Standard and update manifests can also be compressed for storage. Compression changes the encoding, not the semantic type: after decompression, the record is still interpreted as either a standard manifest or an update manifest.
Embedded and external Manifest Stores
A Manifest Store can be embedded directly in the asset or kept externally. C2PA defines format-specific embedding methods for many image, video, audio, document, font, HTML, and text formats. Embedding keeps the credential with the file, but it is not always technically possible, practical, or appropriate.
An external Manifest Store is stored separately, typically in a manifest repository, and served using the application/c2pa media type. A consumer may discover it through a supported reference such as an HTTP Link header, an XMP provenance URI, a format-specific reference, or a nearby .c2pa resource.[6]
Discovery is not proof of association. A validator that retrieves an external store must still verify the relevant content binding. If the binding does not match, the validator cannot safely assume that the located manifest belongs to the asset. External storage also introduces an availability dependency: a correctly issued manifest is of limited use if it cannot be found or retrieved when needed.
A practical manifest history
Consider a news photograph moving through a C2PA-aware workflow.
Stage 1: Capture
A camera creates the original photograph and issues a standard manifest. The manifest contains a hard binding to the captured file, a creation action, selected information about the capture system, and a claim signature. At this point, the capture manifest is the active manifest.
Stage 2: Editing
An editor crops the photograph and adjusts its exposure. Because the exported image is a different asset representation, the editing application creates a new standard manifest. The new manifest binds to the edited output, records the relevant actions, and identifies the captured photograph as a parent ingredient. The validated capture manifest can be copied into the new Manifest Store as ingredient provenance.
Stage 3: Publication
A publisher later records a publication event without changing the protected image content. The publishing system can issue an update manifest whose required parentOf ingredient points to the editing manifest. The update becomes active, while the editing manifest remains the source of the applicable hard binding.
Stage 4: Verification
A validator begins with the active update manifest, checks its claim and signature, follows the parent relationship to the editing manifest, validates the edited image against that manifest’s hard binding, and can then traverse the ingredient relationship back to the capture record. The history is a sequence of separately signed statements, not one mutable log that every participant edits in place.
Can an existing manifest be edited?
A signed manifest cannot be silently edited while retaining the same valid cryptographic relationships. Changing an assertion causes its hash to differ from the value recorded in the claim. Changing the claim breaks its signature. Changing protected content breaks the hard binding.
Operationally, provenance is extended by issuing a new standard or update manifest rather than rewriting an earlier signed claim. C2PA also provides declared redaction mechanisms for cases where information from an ingredient manifest must be withheld. The later record declares the redaction instead of presenting the altered earlier manifest as though nothing had been removed.
Does every edit create a new manifest?
No. A new manifest appears only when a C2PA-capable claim generator issues one. An asset can be edited by software that does not support C2PA, or a platform can remove its embedded Manifest Store. In those cases, an earlier credential may become unavailable or fail to bind to the current representation, and no replacement history is automatically created.
C2PA can therefore preserve a detailed recorded history without guaranteeing that the history is complete. The absence of a recorded action is not proof that the action never occurred.
What a manifest can and cannot establish
When the relevant checks succeed, a manifest can provide evidence that:
- a particular claim was signed using a particular signing credential;
- the assertions referenced by that claim have not changed since signing;
- the protected asset content matches the applicable hard binding;
- particular actions, ingredients, metadata, or disclosures were asserted; and
- the recorded relationships connect the asset to particular earlier or contributing manifests.
A manifest does not independently prove:
- that every assertion is factually accurate;
- that the depicted event happened as represented;
- that the signer was honest or the originating system was secure;
- that the recorded history is complete;
- that unsigned content is false; or
- that the asset satisfies a particular law, platform policy, or business rule.
C2PA is designed to make provenance records verifiable and tamper-evident, not to make universal judgments that content is true, trustworthy, or compliant. Those judgments require additional evidence and a policy for interpreting the signals.[1]
The simplest mental model
Assertions contain the provenance statements.
The claim identifies and hashes the assertions being signed.
The claim signature protects the claim and ties it to a signing credential.
The hard binding connects a standard manifest to the protected asset content.
The manifest combines those elements into one signed provenance record.
The Manifest Store holds one or more related manifests.
The active manifest is the current entry point for validation.
Ingredients connect the current asset to earlier, component, or computational-input provenance.
Together, these structures allow digital content to carry a signed and tamper-evident account of how it reached its current state, while preserving the distinction between what is cryptographically supported, what a signer asserted, and what remains a matter of external trust or interpretation.
Sources and notes
All technical references below point to the official C2PA 2.4 specification. The article uses source notes only for exact structural or normative claims.
[1] C2PA Technical Specification 2.4, section 1.2, “Scope,”and section 2.3, “Core Aspects of C2PA.”
[2] C2PA Technical Specification 2.4, section 6.6, “Assertion Store,”and section 10, “Claims.”
[4] C2PA Technical Specification 2.4, section 11.2, “Types of Manifests.”
[5] C2PA Technical Specification 2.4, section 18.16, “Ingredient.”
[6] C2PA Technical Specification 2.4, section 11.4, “External Manifests,”and section 11.5, “Embedding a Reference to an external Manifest.”