Content Provenance for AI-Generated Media - C2PA, Watermarking, and Machine-Readable Marking

First Published: 2026-08-12
Last Updated: 2026-08-12

Two requirements arrive at almost every team that touches generated media, and they are not the same requirement. The first is outbound: when your system produces an image, a video, or an audio clip, you have to be able to say that it did. The second is inbound: when a file arrives from somewhere else, you want to know what it is and where it came from before you publish it, index it, or feed it to a model.

Content provenance is the technology that answers both, and the Coalition for Content Provenance and Authenticity (C2PA) is where the interoperable version of it lives. Its specification defines a signed, tamper-evident record that travels with an asset and says who did what to it. In non-technical writing that record is called a Content Credential.

The reason to write about it carefully rather than enthusiastically is that the most common summary of what it does is wrong. "Put Content Credentials on it and people can tell whether it is real" is not what the specification claims, and the C2PA says so in its own words in more than one document. A valid credential is a verified statement about who signed what. It is not a verdict on whether the content is true, and its absence is not evidence of anything at all. Building a product on the wrong reading of that sentence produces a system that confidently mislabels honest content and confidently blesses dishonest content.

Everything in this article was checked against the primary specification documents on 2026-08-09. The technical specification is at version 2.4, whose version history entry is headed 2.4 - April 2026; the preceding release is 2.3 - December 2025. Field names, assertion labels, status codes, and normative sentences below were copied from those documents rather than written from memory. Section 1.4 records exactly which document is at which version, because they are not all at the same one, and that turns out to matter.

1. Introduction
2. What Provenance Can and Cannot Tell You
3. Inside a Content Credential
4. Marking Generated Media in a Machine-Readable Way
5. The Two-Layer Strategy
6. Why Credentials Fall Off, and Designing for It
7. The Signing-Verification Asymmetry
8. Certificates, Revocation, and Blast Radius
9. Where to Put Each Step
10. Designing an Ingestion Policy
11. What This Does Not Solve
12. Failure Modes
13. Frequently Asked Questions
14. Summary
15. References

1. Introduction

1.1 The two decisions this article is about

Strip away the vocabulary and there are three placement decisions and one policy decision to make.

The placement decisions are where you sign, where you preserve, and where you verify. Signing belongs at the moment of creation, inside the process that actually produced the pixels or the samples. Preservation belongs in every tool that touches the asset afterward, because a transformation that does not carry the record forward silently ends the chain. Verification belongs at ingestion, at the boundary where content from outside your control becomes content you are responsible for.

The policy decision is what your system does with each of the outcomes verification can produce. There are more than two. A file can arrive with no credential, with a credential that fails validation, with a credential that validates but is signed by someone you have never heard of, or with a credential that validates and is signed by a party on a trust list you accept. Those four cases deserve four different behaviors, and collapsing them into "has credential" versus "does not have credential" is the single most consequential design mistake in this area.

1.2 Who this is for

This is for engineers and product owners building systems that either produce generated media or accept media from outside. It assumes you know what a digital signature and a certificate chain are. It does not assume you have read the C2PA specification, and it does not assume you have decided to adopt anything yet.

1.3 What this covers, and what it does not

In scope: what a Content Credential asserts and what it does not, the structure of a manifest, the machine-readable vocabulary for marking generated media, the two-layer binding strategy, why credentials get stripped and how the specification expects you to survive that, the current asymmetry between the signing side and the verification side, the operational risk that certificate revocation creates, and how to write an ingestion policy.

Out of scope, deliberately:

Regulatory analysis. Transparency obligations are one of the forces pushing adoption forward, but this article is about the specification and the engineering, and no rule from any jurisdiction is load-bearing in anything below.
Any claim about detecting generated content. No technique here tells you whether a file was generated by a model. Section 11 explains why that is a different problem with a different shape, and why the two are constantly confused.
Procedures for removing, forging, or bypassing credentials. Stripping is discussed as a fact of the distribution environment that your design has to survive, never as a method.
Cloud-specific implementation. Where the signing credential lives and how the generation step itself is constrained are platform topics with their own treatment; see Responsible-AI Guardrails Architecture on AWS and AI Agent Defense in Depth Model (AIDDM) for that side.
Numbers I did not measure. No pricing, no detection rates, no performance figures. Where counts appear, in section 7, they are counts of records in a published C2PA file, and the file, the retrieval date, and the inclusion criteria are all stated.

1.4 Which documents this article transcribes, and at which version

The C2PA publishes a technical specification plus a set of guidance and informative documents, and they do not move in lockstep. Knowing which version you are reading is part of using them correctly, and it is the same discipline the OpenTelemetry GenAI Semantic Conventions Implementation Guide applies to a different moving specification.

* You can sort the table by clicking on the column name.

Document	Version used here	Normative	Note
Content Credentials : C2PA Technical Specification	2.4	Yes	Version history entry is headed `2.4 - April 2026`
C2PA Soft Binding API	2.4	Yes	Its embedded OpenAPI document declares `info.version` of `2.3.0`
Content Credentials JSON (crJSON)	2.4	Yes	New in 2.4; a derived view, explicitly not independently verifiable
C2PA Security Considerations	2.4	No	States of itself that its content is non-normative and a work in progress
C2PA Harms Modelling	2.4	No	Source of the strongest statements about what provenance does not mean
Guidance for Artificial Intelligence and Machine Learning	2.3	No	Not yet reissued under 2.4
Explainer, Guidance for Implementers, User Experience Guidance	2.2	No	Two releases behind the technical specification
Attestations	1.4	Yes	Furthest behind of the technical documents

Two things follow from that table. First, downloadable PDF bundles are published up to 2.3; the 2.4 documents are served as HTML, and the download menu on the 2.4 pages still offers the 2.3 PDFs. If your team standardized on the PDF, you are reading 2.3. Second, the informative documents that tell implementers how to apply the specification are two releases behind the specification itself, so when guidance and specification disagree, the specification is newer.

2. What Provenance Can and Cannot Tell You

This section comes second on purpose. Every practical decision later in the article depends on getting this one right, and every widely repeated misconception about Content Credentials comes from getting it wrong.

2.1 The claim a credential actually makes

The C2PA states its own limit plainly. From the Harms Modelling document:

"The C2PA specifications do not provide value judgments about the truth or falsehood of digital assets. In other words, the presence of valid manifests does not mean that anything is 'true'; validated manifests only establish whether the provenance information can be verified as associated with the underlying asset, correctly formed, and free from tampering."

The technical specification says the same thing at the level of design principle, quoting the project's Guiding Principles: "C2PA specifications SHOULD NOT provide value judgments about whether a given set of provenance data is 'good' or 'bad,' merely whether the assertions included within can be validated as associated with the underlying asset, correctly formed, and free from tampering."

So a successful validation establishes three things and no more. The record is well formed. The record has not been altered since it was signed. The record is bound to this asset rather than some other one. Whether the statements inside the record are accurate is a separate question that cryptography cannot answer, and the specification does not pretend otherwise.

The Harms Modelling document puts the consequence in one line that is worth quoting to anyone who asks for a truth indicator: "Digital assets, such as images and videos, can have valid C2PA manifests and still be deemed to be mis or disinformation."

The trust model makes the division of labor explicit. Its diagram places the consumer outside the model entirely, describing them as someone "who uses the identity of the signer, along with other trust signals, to decide whether the assertions made about an asset are true." The specification supplies verified attribution. Deciding what that attribution is worth is left to whoever is looking.

2.2 Only created assertions are attributed to the signer

The scope of attribution is narrower than most readers assume, and the specification is precise about it. Signing a claim attributes to the signer only those assertions the signer created. In the specification's words, "Only signed C2PA created_assertions are attributed to the signer. Any asset metadata outside of this specific mechanism, whether included in hard bindings or not, is not attributed to the signer by this specification."

The example the specification chooses is a good one. A hard binding can cover the EXIF block of a photograph, so tampering with the GPS coordinates in that block will break validation. That does not mean the signer vouches for the coordinates. It means the coordinates have not changed since signing. If the signer wants to actually assert the location, the values have to be serialized into a c2pa.metadata assertion and placed in created_assertions, which the specification describes as an explicit signal from the signer that it is asserting that location.

Integrity and endorsement are different properties, and a manifest carries both at once for different pieces of data. A user interface that renders everything in a manifest with the same visual weight erases that distinction.

2.3 Absence proves nothing

The inverse error is more damaging than the first, because it punishes people rather than merely flattering them. Again from the Harms Modelling document:

"The fact that any digital asset does not have Content Credentials does not mean that its contents are not to be trusted. This may be especially relevant to note in a scenario where these specifications are widely adopted."

The document goes on to note that there will be creators with legitimate reasons not to use C2PA-enabled tools, and that their content should not be dismissed for it. In practice the reasons are ordinary: the tool in the chain did not implement the specification, an intermediary discarded the metadata, the file was re-encoded by something that had never heard of C2PA, or the creator has a privacy reason to publish without a record.

The specification also concedes an accessibility dimension. Claim generators may not operate in unlicensed software, and implementations may restrict themselves to newer devices or operating systems. Any policy that treats missing credentials as suspicious therefore falls hardest on exactly the users with the least access to current tooling.

2.4 What this means for the words in your product

If you take one operational rule from this section, take this one: never write a label that converts a validation result into a judgment about the content.

Do not say	Say instead
Verified authentic	Signed by X on DATE, unmodified since
No Content Credentials, may be AI-generated	No Content Credentials found. This is not an indication of how the content was made
AI-detected	Declares generative AI in its creation actions
Trusted image	Signed by a certificate on the trust list this system accepts

The right-hand column is longer and less satisfying. It is also the only column that is true, and the only one you can defend when someone whose honest photograph got flagged asks you to explain the label.

3. Inside a Content Credential

3.1 The five nouns

The specification's data model is small, and once the five nouns are straight the rest of the document reads easily.

An assertion is "a data structure which represents a statement either made (or 'created') by the signer or simply gathered at claim generation-time, concerning the asset." Assertions are the content of provenance: what actions were performed, what the asset is bound to, what metadata applies, what ingredients went into it.

A claim is "a digitally signed and tamper-evident data structure that references a set of assertions, concerning an asset, and the information necessary to represent the content binding." The claim does not contain the assertions; it references them by hashed URI, so altering an assertion invalidates the reference.

A claim signature is "the digital signature on the claim created using the private key owned by a signer," carried in a COSE structure with the signer's certificate chain in the x5chain header. Claim generators are now required to place that header only in the protected bucket, and exactly one identity credential must appear across the protected and unprotected headers, with structures carrying none or two or more rejected. Validators still accept the header from either bucket for compatibility with manifests written under older releases.

A C2PA Manifest is the verifiable unit: one or more assertions, exactly one claim, and one claim signature. The specification describes them as "bound together into a verifiable unit called a C2PA Manifest ... by a hardware or software component called a claim generator."

A C2PA Manifest Store is the collection of manifests for an asset, which can be embedded in the file or held externally.

The user-facing name maps onto that last pair. The specification defines Content Credential as "the preferred non-technical term for a C2PA Manifest," and notes that the Manifest Store therefore represents the Content Credentials of an asset, with the plural form also serving as the name of the technology as a whole. So when a product surface says Content Credentials, the technically precise reading is: the manifest store attached to or resolvable for this asset.

A C2PA Manifest and the Content Credentials of an asset

3.2 Standard manifests and update manifests

Every manifest contains an assertion store with at least one assertion, a claim, and a claim signature. Beyond that there are two kinds, and choosing the wrong one is a common integration bug.

A standard manifest contains exactly one hard binding assertion, drawn from c2pa.hash.data, c2pa.hash.boxes, c2pa.hash.collection.data, c2pa.hash.bmff.v2 (deprecated), or c2pa.hash.bmff.v3 depending on the asset format. Because it carries the binding, it is the predominant type in real provenance data.

An update manifest exists for workflows where assertions need to be added but nothing covered by the content bindings has changed. It must not carry any of those hard binding assertion types, and its actions are restricted to c2pa.edited.metadata, c2pa.opened, c2pa.published, and c2pa.redacted. It must contain exactly one ingredient assertion with a parentOf relationship pointing at the asset being updated.

The distinction matters when you are adding provenance without touching pixels: recording that an asset was published, attaching a certificate status response, or amending metadata. Reaching for a standard manifest there means recomputing bindings you had no reason to recompute.

3.3 The active manifest and the ingredient chain

A manifest store accumulates. The active manifest is defined as "the last manifest in the list of C2PA Manifests inside of a C2PA Manifest Store which is the one with the set of content bindings that are able to be validated." Every earlier manifest describes an earlier state.

Assets built from other assets are modeled through ingredient assertions, whose relationship field takes exactly one of three values: parentOf for the asset that was opened and edited, componentOf for an asset placed into a composition, and inputTo for an asset consumed by a process without becoming part of the output. Any other value causes rejection with assertion.ingredient.malformed.

That third value is the interesting one for generated media, because it is how a model input can be recorded as having influenced an output without being a visible component of it.

Ingredient validation is recursive by design. When a claim generator adds an ingredient, the specification requires it to act as a validator, run the full validation algorithm on that ingredient, and record the outcome in the ingredient assertion's validationResults field. Provenance therefore carries not just what came before but what the tool in the middle thought of it at the time.

4. Marking Generated Media in a Machine-Readable Way

Sections 2 and 3 are about what a credential is. This one is about the specific vocabulary for saying "a model made this," which is the part of the specification most directly relevant to teams shipping generative features, and the part that changed most recently.

4.1 The actions assertion is mandatory, and its first element is constrained

There must be at least one actions assertion in the created_assertions array of a standard manifest's claim. There are two versions of the assertion: the deprecated v1 with label c2pa.actions, and v2 with label c2pa.actions.v2, which adds a templates mechanism so repeated actions do not have to be fully specified each time.

The first element of the actions array is fixed by how the asset came to exist. If it was created de novo, and the specification names generating the media with a generative AI model as an example of that, the first action must be c2pa.created. If it was created by opening an existing asset for editing, the first action must be c2pa.opened, and the generator must add a corresponding c2pa.ingredient.v3 assertion with a parentOf relationship and reference it by hashed URI from the action's parameters. A manifest may contain no more than one action that is either c2pa.created or c2pa.opened.

4.2 digitalSourceType is where the generative claim lives

Every c2pa.created action must carry a digitalSourceType field indicating the nature of the asset at its inception. The values come from the IPTC Digital Source Type NewsCodes vocabulary, plus a small number of C2PA-specific values.

The specification's own worked example is exact: a generative AI model producing a video from a text prompt yields an active manifest whose c2pa.actions assertion starts with a c2pa.created action carrying http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia.

The IPTC definitions, quoted from the published vocabulary:

Term	Name	Definition
`trainedAlgorithmicMedia`	Created using Generative AI	Digital media created algorithmically using an Artificial Intelligence model trained on captured content
`compositeWithTrainedAlgorithmicMedia`	Edited using Generative AI	Augmentation, correction or enhancement using a Generative AI model, such as with inpainting or outpainting operations
`digitalCapture`	Digital capture sampled from real life	The media was captured from a real-life source using a digital camera or digital recording device
`computationalCapture`	Multi-frame computational capture sampled from real life	Multiple frames captured from a real-life source and merged automatically using digital signal processing and/or non-generative AI
`humanEdits`	Human-edited media	Augmentation, correction or enhancement by one or more humans using non-generative tools; successor to the retired `minorHumanEdits`
`compositeSynthetic`	Composite including generative AI elements	Mix or composite of several elements, at least one of which is Generative AI
`digitalCreation`	Digital creation	Media created by a human using non-generative tools

Two C2PA-specific values matter alongside those. http://c2pa.org/digitalsourcetype/empty marks an asset that began as a new empty file, which is what a design tool records when the user starts from a blank canvas. http://c2pa.org/digitalsourcetype/trainedAlgorithmicData covers algorithmically generated output that is data rather than media, such as a CSV or a serialized array; it replaced the older c2pa.trainedAlgorithmicData form.

Version 2.4 extended digitalSourceType to ingredient assertions, for ingredients brought in without a manifest of their own. Such an assertion cannot carry both activeManifest and digitalSourceType; combining them is rejected. Placing a digitalSourceType on an ingredient in created_assertions is the signer asserting that the ingredient has that nature, which is how you record "a generated element went into this composite" when the generated element never got a manifest.

4.3 The AI disclosure assertion, new in 2.4

Version 2.4 introduced c2pa.ai-disclosure, an assertion for machine-readable AI transparency information. It is designed to sit alongside c2pa.actions and digitalSourceType rather than replace them, adding three things the older signals did not carry: which models were used, what subject domain the content belongs to, and how much human involvement there was.

The schema, from the CDDL in the specification:

Field	Required	Content
`modelType`	Yes	Enumerated AI model type
`modelName`	No	Human-readable name of the model used
`modelIdentifier`	No	Unique identifier such as a URI or PURL
`contentProfile`	No	Structured object; currently carries `humanOversightLevel`
`scientificDomain`	No	List of values conforming to the arXiv taxonomy, for example `cs.AI`
`metadata`	No	Additional information about the assertion

humanOversightLevel takes one of three values, and the specification annotates each with the scrutiny it implies: fully_autonomous for no human review after model output (highest scrutiny), prompt_guided for a human who supplied prompts or configuration but did not approve the result (moderate scrutiny), and human_validated for a human who reviewed and approved the final output before release (reduced automated scrutiny when attested).

The specification disambiguates the new field against the old one with a table of combinations: trainedAlgorithmicMedia with fully_autonomous is pure AI generation with no human review; trainedAlgorithmicMedia with prompt_guided is generation steered by human prompts; compositeWithTrainedAlgorithmicMedia with human_validated is AI edits reviewed and approved by a human editor before release; and digitalCreation has no oversight level because no trained model was invoked and the assertion is simply not attached.

Treat this assertion as new. Its CDDL still carries commented-out fields awaiting descriptions, including modelFrontier, trainingCleared, and a harm evaluation object under the content profile. Consuming it defensively, and not building a user-visible feature that breaks if a field's shape changes, is the appropriate posture for something introduced one release ago.

4.4 The field that tells a reader how complete the record is

allActionsIncluded is a boolean on the v2 actions map that says whether the claim generator is claiming the actions assertion describes everything that was done. Set to true it asserts completeness; set to false it says unrecorded actions may have been performed.

The rule that makes it useful to a consumer is the default: "Validators should interpret an omitted allActionsIncluded field as indicating that additional, unrecorded actions may have been performed." Silence is not completeness. Version 2.4 added a related requirement: a claim generator that opens an asset strictly to record c2pa.opened and immediately re-saves without other changes must set allActionsIncluded to true.

For an ingestion pipeline this is the one field that distinguishes "here is the full history" from "here is some of the history," and reading it is cheap.

5. The Two-Layer Strategy

5.1 Hard bindings

A hard binding is one or more cryptographic hashes that uniquely identify the asset or a portion of it. The specification's framing is that it lets a validator establish both that this manifest belongs with this asset and that the asset has not been modified, "by determining values that can match only this asset and no other, not even other assets derived from it or renditions produced from it."

That last clause is the property and the limitation in one sentence. A hard binding is exact. Re-encode the file, resize it, or transcode it to another format, and the hash no longer matches, which is correct behavior, because the bits genuinely changed. It is also the reason a hard binding alone cannot survive ordinary distribution.

The specification defines several forms depending on format: byte-range hashing via a data hash assertion, box-based hashing for formats such as JPEG and PNG, BMFF-based hashing for ISO BMFF assets including fragmented MP4, and a collection data hash for workflows where one manifest covers a set of files rather than a single one.

5.2 Soft bindings

A soft binding is defined as "a content identifier that is either (a) not statistically unique, such as a fingerprint, or (b) embedded as an invisible watermark in the identified digital content." It is computed from the content of an asset rather than its raw bits, which is exactly what makes it useful: it can match derived assets and renditions.

The assertion has the label c2pa.soft-binding. Its alg field names the algorithm, which should come from the C2PA soft binding algorithm list, an authoritative registry of the fingerprinting and watermarking technologies that C2PA clients may use for recovery. Values live in blocks, each with a scope that may specify a region or a timespan in milliseconds from the start of the content, which is how a soft binding can cover part of a video rather than all of it. Optional alg-params carries algorithm parameters and bindingMetadata carries descriptive information about the implementation.

Two fields are deprecated as of 2.4 and are worth knowing about because older manifests contain them: url was never used and is superseded by the asset reference assertion, and scope.extent is superseded by scope.region. Claim generators must not add them; consumers should ignore them, while still including them in the data that gets validated.

5.3 Why one layer is not enough

The specification settles the question with two normative sentences, and they point in opposite directions on purpose.

"A single manifest shall not contain more than one assertion defining a hard binding but may contain zero or more assertions defining soft bindings."

"Because they serve a different purpose, a soft binding shall not be used as a hard binding."

Read together: exactly one exact binding, any number of approximate ones, and no substituting the second for the first. A hard binding proves integrity but cannot follow the content through a re-encode. A soft binding follows the content but proves nothing about integrity, since it is by definition not statistically unique. Tampering that a hard binding would catch may leave a soft binding intact.

So the layers do different jobs. The hard binding answers "has this been altered." The soft binding answers "is this the same content, and if the record went missing, where can I find it." Ship only the first and provenance dies at the first transcode. Ship only the second and you have a lookup key with no integrity guarantee attached to it, which is the weaker half.

5.4 The watermarking actions

Version 2.3 introduced fine-grained watermarking actions, and 2.4 tightened how they link to the binding they create.

Action	Meaning
`c2pa.watermarked`	Deprecated. An invisible watermark was inserted for the purpose of creating a soft binding
`c2pa.watermarked.bound`	An invisible watermark was inserted for the purpose of creating a soft binding
`c2pa.watermarked.unbound`	An invisible watermark was inserted without creating a soft binding

When a c2pa.watermarked.bound action is used, a soft binding assertion describing the inserted watermark must also be present in the manifest, and 2.4 recommends that the action reference those assertions through the relatedAssertions field of its parameters object. The same role values exist for regions of interest, so a manifest can record that a specific area of an image was watermarked.

The bound and unbound distinction is worth respecting. An unbound watermark, one that carries a vendor identifier or an internal tracking value with no C2PA soft binding behind it, is a legitimate thing to record, but it is not a recovery mechanism and marking it as one produces manifests that promise a lookup that will never resolve.

6. Why Credentials Fall Off, and Designing for It

6.1 The specification assumes loss

The C2PA does not treat stripping as an edge case. The Soft Binding API document opens its discussion of decoupled manifests by stating that "while an increasing number of tools and platforms retain and add to C2PA Manifests, a number of workflows remove C2PA Manifests, leading to decoupled provenance information from assets."

The mechanism is mundane. Metadata gets discarded by re-encoding, by resizing, by format conversion, by pipelines that were built before any of this existed and have no reason to preserve a block they do not understand. The C2PA's own use case narratives simply assume a publishing path where the manifest does not survive, and build the recovery design around that assumption.

The right posture is therefore not to prevent stripping. It is to make stripping non-fatal.

6.2 Recovery through a manifest repository

The mechanism is the second layer. As the specification puts it, if a manifest is removed from an asset but a copy remains in a provenance store elsewhere, the manifest and the asset can be matched using available soft bindings.

The published use cases sketch the shapes this takes. A photographer adds an imperceptible watermark before submitting to a platform known to strip metadata, and a reader's client later detects the watermark and retrieves the manifest from a repository. A production pipeline that passes through stages incapable of handling C2PA inserts a watermark on the way in, registers the manifest internally, and re-attaches it on the way out, recording the gap as an ingredient rather than pretending it did not happen. A generative tool signs its output and watermarks it, and the watermark survives a screenshot even though the manifest does not.

The adversarial use cases matter for a different reason. The specification also enumerates cases where a manifest is replaced while a watermark survives, and where both are replaced. The defensive lesson from both is the same and it is a design instruction, not a procedure: comparing a recovered manifest against the one embedded in the file, and looking at who signed each, is a stronger check than reading either one alone. A recovered manifest signed by someone other than the party the embedded manifest names is information, and a system that only ever reads the embedded record cannot see it.

6.3 The soft binding resolution API

Recovery needs an interoperable way to ask a repository a question, and 2.4 specifies one as a web API organized into four route groups.

Group	Purpose	Routes
query	Find manifests matching a soft binding	`GET /matches/byBinding`, `POST /matches/byBinding`, `POST /matches/byContent`, `POST /matches/byReference`
fetch	Retrieve manifest stores or verify a receipt	`GET /manifests/{manifestId}`, `GET /manifests/{manifestId}/receipts`, `POST /manifests/{manifestId}/receipts`
store	Ingest manifests and manage binding associations	`POST /manifests`, `POST /bindings`, `PUT /bindings`, `DELETE /manifests/{manifestId}`
service	Report repository capabilities	`GET /services/supportedAlgorithms`

The two query variants exist for a practical reason: the GET form is preferred when the soft binding value fits comfortably in a URL, and the POST form takes it in a JSON body when it does not. POST /matches/byContent uploads the asset and lets the repository extract or compute the binding itself, and POST /matches/byReference is an optional route that takes an HTTPS URL instead of an upload, intended for large video where uploading is impractical.

Version 2.4 also added the ability to prove ingestion. POST /manifests may return a receipt, and the new c2pa.repository-receipt assertion records proof that a manifest store has been ingested by a repository. A federated lookup layer is specified separately, mapping a soft binding to the repository that holds the corresponding manifest, so that a client does not have to know in advance which store to ask.

6.4 Not embedding at all

Recovery is not the only answer to stripping. The specification supports external manifests, where the manifest store lives beside the asset rather than inside it, and a validator can locate one by reference or through an HTTP Link header.

For a publisher who controls the serving path, this is often the cleaner design. The credential is served from your infrastructure, cannot be stripped by an intermediary that rewrites the file, and can be updated without rewriting the asset. It also fails differently: an asset separated from your serving path loses the record entirely, with no watermark to recover it by. External manifests and soft bindings solve overlapping problems from opposite directions, and a serious deployment usually wants both.

6.5 Designing so that loss is survivable

Concretely, a design that survives stripping has four properties.

The manifest is registered in a repository at publication time, not only embedded in the file.
A soft binding is computed and recorded in the manifest, so the repository can be queried later.
The user-facing surfaces treat a recovered manifest and an embedded manifest as different things, because they are: one came from the file, the other from a party you chose to ask.
Nothing in the product tells a user that a missing credential means anything about the content.

The fourth is the one that gets dropped, and it is the one that turns a stripped file into a false accusation.

7. The Signing-Verification Asymmetry

7.1 What the published conformance data shows

The C2PA runs a conformance program that assesses three categories of participant: generator products that create Content Credentials and add them to assets, validator products that read and validate them, and certificate authorities. Products that pass are placed on a publicly accessible Conforming Products List, published as JSON.

Counting the records in that file gives a picture of where implementation effort has gone.

Basis and limits of these counts. The file was retrieved on 2026-08-09; the most recent lastModification date inside it is 2026-08-06. The inclusion criterion is enrollment in and passage through the C2PA Conformance Program. It is not a census of software that handles Content Credentials, and it does not measure adoption, deployment, or usage. Products that never applied do not appear. These are counts of records in a published list, nothing more.

Measure	Count
Records, all with status `conformant`	157
Records with `productType` of `generatorProduct`	137
Records with `productType` of `validatorProduct`	20
Generator products declaring any `validate` container support	101
Generator products declaring none	36
Records declaring `specVersion` of `2.2`	157, every record as of the retrieval date
Records declaring `conformanceProgramVersion` of `0.1`	157, every record as of the retrieval date

Generator products outnumber validator products by roughly seven to one on this list. Even counting generously, by treating every generator that declares some validation capability as a validation implementation, 36 of the 137 generator products declare none at all.

7.2 The version lag is part of the same story

At the 2026-08-09 retrieval, every record on the list declared conformance at specification version 2.2, under conformance program version 0.1, against a technical specification that is at 2.4.

That lag began to close days later, and the direction matters more than the snapshot. The first records certified at specification version 2.4 under conformance program version 0.2 carry conformance dates from 2026-08-08, and the first of them appeared on the public list within days. So the correct reading is not that the conformance baseline is frozen two minor versions behind, but that it moves in steps and the step to 2.4 has started. Re-derive the split yourself before quoting it: the file is versioned and the counts move weekly.

The lag itself is structural rather than accidental. A specification can add an assertion in April and have it available to implementers immediately; a conformance program has to write requirements, define test procedures, and assess submissions before it can certify against a new version. So a newly specified feature, including the c2pa.ai-disclosure assertion discussed in section 4, exists in the specification for some months before it exists in the assessed conformance baseline, and the practical question for a design is which side of that interval each product you depend on is currently on.

The trust infrastructure shows the same staged transition. The Interim Trust List, a temporary measure for early implementations, was frozen on 2026-01-01, with no further additions or updates; existing certificates remain valid for legacy support, and content signed during an interim certificate's validity period stays valid against the legacy trust model. The official C2PA Trust List, governed by the conformance program and aligned with the 2.x series, is the forward path.

7.3 What the asymmetry means for your design

Three consequences follow, and none of them is "wait."

Signing is the cheap side and it is already done for you. If your generation stack uses a conforming product, your outbound obligation may be largely satisfied by configuration. That is why the generator count is high.

Verification is the expensive side and it is mostly not done for you. Validating a manifest means parsing a JUMBF structure, resolving hashed URIs, checking a hard binding against the asset bytes, building and evaluating a certificate path against a trust list you have to choose and maintain, handling time-stamps, and interpreting revocation information. The specification lists six validation phases: assertions, ingredients, time-stamp, credential revocation information, claim signature, and the asset's content. Skipping any of them yields a system that reports success on input it did not actually check.

A displayed credential that was not validated is worse than no credential. If your product surfaces manifest contents without running validation, an attacker gets to write your user interface. The specification's rule on this is direct: "Manifest Consumers should not display data from manifests which are not Valid nor from assets which are not Valid." Section 10 covers what to do when you display anyway.

The practical reading of the asymmetry is that signing gives you a claim to make and verification gives you a decision to act on, and only the second one requires you to build something.

8. Certificates, Revocation, and Blast Radius

Provenance is a public key infrastructure problem wearing media clothing, and it inherits the operational hazard that comes with that. The C2PA devotes a section of its Security Considerations document to revocation planning, and it is the part of the corpus most likely to matter to you on a bad day.

8.1 What revocation does to content that is already signed

The baseline property is generous. Manifests "can be validated indefinitely regardless of whether the cryptographic credentials used to sign its contents are later expired or revoked," and claim signatures combined with trusted time-stamps can be validated indefinitely to determine whether claims were signed while the credentials were valid and not revoked.

Revocation interacts with that in two different ways depending on why it happened.

A planned revocation, such as retiring a certificate whose properties you want to change, takes effect from the date the certificate authority adds it to its revocation list. Everything signed before that date stays valid and trusted. This is the benign case.

A revocation caused by key compromise carries two dates: when the revocation information was created, and when the organization believes the key was first compromised. The second exists because detection takes time, and the assumption has to be that an attacker was using the key throughout that window. All content signed by that certificate after the compromise date becomes untrusted, whether an attacker or the rightful owner signed it. The specification's own arithmetic makes the scale concrete: a system signing a thousand images a day, breached on the first of the month, with detection and rotation taking seven days, has seven thousand legitimate images revoked alongside whatever the attacker produced.

8.2 Time-stamps are what let old content survive

Content signed without a trusted time-stamp has no defense at all. As the Security Considerations put it, a certificate revocation results in any content signed without a time-stamp being revoked, because the revocation algorithm cannot determine whether the signing happened before or after the revocation and therefore defaults to untrusted.

That makes time-stamping a hard requirement rather than a refinement. Without it, one revocation invalidates everything the key ever signed. The C2PA maintains a separate TSA Trust List of time stamping authority trust anchors precisely so that this dependency has an interoperable answer.

8.3 OCSP stapling cuts both ways

Signers can staple an OCSP response into the manifest, proving the certificate was not revoked at signing time. The benefits are real: downstream validation is streamlined, it works when the OCSP responder is unreachable, and it avoids network calls that would otherwise reveal that someone is looking at a particular asset.

The drawback is specific. Signing can occur after a key was compromised but before the compromise was detected. Once the certificate authority issues the revocation, that content is revoked, but a validator relying on the stapled response will not learn this until the stapled response expires. Stapling is optional in the specification, and the validity period you choose for the stapled response is a direct trade between availability and revocation latency.

The specification also anticipates the support consequence: be ready to explain why some content still appears valid after a revocation has been published.

8.4 Splitting keys is the only real way to bound the damage

Since revocation is coarse and cannot be targeted at individual assets, the only lever that reduces its blast radius is reducing what each key covers. The specification's guidance is to split signing across multiple keys, so that compromising one environment does not revoke everything the organization ever signed, and to use multiple claim generators each with its own certificate.

Short-lived certificates help, with a caveat the specification is careful to state: an adversary who has pre-generated content can sign all of it within a short validity window, so short lifetimes bound the number of affected legitimate users rather than the volume of malicious content.

Key storage in a hardware security module is recommended, with the honest observation that an HSM prevents extraction of the private key but not misuse by an attacker who has reached the systems authorized to send it signing requests.

8.5 The copies you do not control

The part of revocation planning most often missed concerns everything that cached a copy.

Content delivery networks hold copies of the asset that persist until purged. More subtly, an asset's watermark or fingerprint may have been registered with a manifest repository along with the original Content Credential, so a soft binding lookup can return the manifest signed with the now-revoked certificate. The second layer you built in section 6 to survive stripping is also a place where a revoked credential can outlive the revocation.

A revocation plan therefore has to enumerate the caches: your CDN, any repositories where you registered manifests, and any partner systems that resolved and stored a copy.

8.6 Revocation in the middle of a chain

The hardest case involves a certificate used partway through a production chain. Take a photograph captured and signed by a camera, edited by one tool, labeled by a second, and finished by a third. Revoke the certificate belonging to the second step and a viewer inspecting the history sees the first as valid, the second as revoked, and the third and fourth as valid.

Nothing about that display is wrong, and it is nearly impossible for a non-specialist to interpret. The specification's recommendation is a communications plan covering every affected party, since the confusion lands on organizations that did nothing wrong and on consumers looking at content on a site controlled by none of them. Its remediation options are equally sobering: revert to the version of the asset associated with the last valid manifest and redo the work from there, which may not be technically possible and sacrifices the original time-stamps.

If you sign as an intermediary in someone else's chain, your revocation is their incident too.

9. Where to Put Each Step

This is the practical core. Three placements, one per stage, and a fourth stage where the correct action is to expect loss.

Where signing, preservation, and verification belong in a media pipeline

9.1 Generation: sign as close to creation as possible

Signing belongs inside the process that produced the content, because that process is the only one that knows the truth about how it was made.

The canonical shape for generated media, taken from the specification's own example: a standard manifest whose actions assertion begins with c2pa.created, carrying digitalSourceType of trainedAlgorithmicMedia, plus a hard binding appropriate to the format. Where you can say more, c2pa.ai-disclosure carries the model identity and the human oversight level, though as section 4.3 noted it is one release old and should be emitted defensively.

Three prerequisites travel with the signing step. The signing credential has to be protected, ideally in a hardware security module, with the understanding from section 8.4 that this bounds extraction rather than misuse. A trusted time-stamp has to be applied, or a future revocation takes everything with it. And the certificate has to chain to a trust anchor that your intended audience's validators actually accept, which today means a certificate authority on the C2PA Trust List rather than one you stood up internally, unless your audience is entirely inside your own organization.

If a watermark is part of your design, this is also where it goes, recorded with c2pa.watermarked.bound and a corresponding soft binding assertion.

9.2 Editing and transformation: preserve, or the chain ends here

Every tool that modifies the asset has to open the prior manifest, record what it did, and re-sign. The specification's shape for this is c2pa.opened as the first action, a c2pa.ingredient.v3 assertion with a parentOf relationship for the asset that was opened, and a hashed URI from the action's parameters to that ingredient. Subsequent actions record the actual edits.

The failure mode is not corruption but silence. A tool that transforms the content and drops the manifest leaves an asset with no record and no indication that a record ever existed. A tool that transforms the content and copies the old manifest forward unchanged leaves an asset whose hard binding no longer matches, which validators will correctly reject.

Two cases deserve explicit handling. Where nothing covered by the bindings changes, use an update manifest, which by construction cannot carry a hard binding and is limited to metadata edits, opening, publishing, and redaction. Where a stage genuinely cannot re-sign, a legacy encoder, a partner system, an offline step, use a watermark and a repository registration to bridge the gap, and record the bridged segment as an ingredient rather than presenting the result as an unbroken chain.

Set allActionsIncluded honestly. Asserting completeness you cannot deliver is worse than omitting the field, because the omission already means "there may be more."

9.3 Ingestion: verify before anything downstream

Verification belongs at the boundary where external content becomes your responsibility. Practically, that is upload handlers, feed ingestion, partner deliveries, and anywhere a model's output from another system enters yours.

Verification means running the six phases the specification lists rather than checking for the presence of a manifest: assertions, ingredients, time-stamp, credential revocation information, claim signature, and the asset's content. The output is not a boolean. It is a state, plus a set of status codes, plus the identity of the signer, and section 10 is about what to do with each combination.

Two implementation notes. Validation is recursive: a claim generator adding an ingredient must itself act as a validator and record the outcome in validationResults, so if you both consume and produce, your ingestion verifier and your ingredient validator are the same component. And validationResults can carry a trustListURI recording which trust list was used, which is worth populating, because "valid" is meaningless without saying valid against what.

9.4 Distribution: assume the record will not arrive

Nothing you place at the distribution stage is under your control once the asset leaves, so the correct design action is to make the loss recoverable rather than to try to prevent it.

That means registering the manifest in a repository, recording a soft binding so the repository can be queried, and considering an external manifest served from a path you control. It also means writing the product copy for the recipient's side of that loss, since the person who sees your stripped image is going to see whatever the platform says about the absence, and that is where the "no credentials means suspicious" misreading does its damage.

10. Designing an Ingestion Policy

10.1 The three states, and why a boolean is not enough

The specification defines a ladder of manifest states, each including the previous one.

State	What it establishes
Well-Formed	The manifest follows the specification's normative requirements, carries only assertions allowed for its manifest type, and its assertions and ingredients meet their requirements
Valid	Well-Formed, plus unmodified since signing, plus the claim signature validated, plus the signature was inside its validity period, plus the signer's credential was not rejected as revoked
Trusted	Valid, plus the signing credential received the success code `signingCredential.trusted`

An asset is separately a Valid asset when the portions covered by content bindings are unmodified and its active manifest is Valid or Trusted.

The gap between Valid and Trusted is where most ingestion policy lives, and it is exactly the gap a boolean erases. A Valid manifest is genuine and unaltered; what it lacks is any relationship between its signer and a trust anchor you accept. Anyone can obtain a certificate and sign a manifest with accurate structure and false statements. That manifest will be Valid.

The specification also gives you a useful consequence of Valid: if a manifest is Valid, its claim can be attributed to the claim generator identified in the claim's claim_generator_info field. Attribution is what you get at Valid. Trust is a separate rung.

10.2 Case 1: no credential at all

The overwhelmingly common case, and the one where the policy is mostly about what not to do.

Accept the content on its merits. Record internally that no manifest was found; the status code vocabulary has ingredient.unknownProvenance for this condition when it appears in an ingredient chain. If you have a recovery path, attempt a soft binding lookup, and label any manifest you recover as recovered rather than presenting it as if it came from the file.

Do not display a warning that implies the content is suspect. Do not route it to a stricter moderation path on that basis alone. Do not use absence as a signal in a generative-content classifier. The Harms Modelling document's line applies directly here, and it is the single sentence in the corpus most worth pinning above an ingestion policy: the fact that an asset does not have Content Credentials does not mean its contents are not to be trusted.

10.3 Case 2: a credential that fails validation

Failure is not one thing, and the status codes distinguish causes that deserve different responses.

Signal	Reading	Reasonable response
`assertion.dataHash.mismatch`, `assertion.boxesHash.mismatch`, `assertion.bmffHash.mismatch`	The content changed after signing	Treat as no valid credential; a re-encode is the usual innocent cause
`claimSignature.mismatch`, `claim.malformed`, `assertion.cbor.invalid`	The record itself is broken or tampered with	Treat as no valid credential; log for investigation
`claim.hardBindings.missing`	A standard manifest without its required binding	Structurally invalid; do not display its contents
`signingCredential.ocsp.inaccessible`, `signingCredential.ocsp.unknown`	Revocation status could not be determined	Informational, not failure; decide deliberately whether your policy accepts unknown
`algorithm.deprecated`	An older algorithm was used	Informational; accept, but track for migration

The distinction between failure and informational codes is the useful one. A hash mismatch means the credential does not apply to this file. An unreachable OCSP responder means you do not know something, which is a different situation and should not be silently converted into either acceptance or rejection.

The most likely real-world cause of a mismatch is not an attack. It is an intermediary that re-encoded the file without understanding the manifest it was carrying, which produces exactly the same signature. Design the operational response accordingly: it belongs in a metric, not an alert.

10.4 Case 3: valid, but the claim is weak

The subtle case, and the one that separates a thoughtful ingestion policy from a checkbox.

A manifest can be Valid and still tell you very little. The signer may be unknown to you, with a certificate that chains to no anchor you accept, leaving the manifest Valid but not Trusted. allActionsIncluded may be absent, which per the specification means unrecorded actions may have occurred. Assertions may have been redacted, which is a supported operation with a declaration but leaves a hole where a statement used to be. The claim may be attributable to a claim generator while carrying almost no assertions about how the content was made. Or the interesting statements may sit in gathered assertions rather than created ones, and as section 2.2 established, only created assertions are attributed to the signer.

The policy answer is to grade rather than to gate. Record the signer identity, whether the manifest reached Trusted and against which trust list, whether the actions record claims completeness, whether a generative digitalSourceType is present, and whether anything was redacted. Then let downstream decisions read those individually. A pipeline that only wants to know "did the creator declare generative AI" needs a completely different projection of that record than one deciding whether to feature the asset editorially.

10.5 What you owe the reader if you display anyway

Sometimes you will show manifest contents that did not reach Valid, typically in authoring or investigation tools where seeing a broken record is the point. The specification permits that and attaches two obligations: the display must include a warning about the lack of validity, and a warning that the data must not be attributed to the manifest's signer, with an additional note for ingredient manifests that it must not be attributed to the asset manifest's signer either.

Both warnings exist because unvalidated manifest content is attacker-controlled text. A name rendered without those warnings is a byline you gave away.

The specification adds that in authoring scenarios these warnings should be raised more prominently, so that a creator can make an informed decision about proceeding with an asset that is not Valid or that has a flawed provenance history. Treating provenance as something the creating human sees and acts on, rather than only something the consuming human sees, is a design idea worth stealing.

The corresponding question on the site side, how a page should present machine-readable signals to automated readers at all, is covered in Designing Websites for AI Agents and is out of scope here.

11. What This Does Not Solve

11.1 Provenance is not detection

The most persistent misconception deserves stating without hedging: none of this detects generated content.

Content Credentials are a declaration mechanism. They work when the tool that created the asset chose to record what it did and signed that record. An actor who does not want their generated content marked simply uses a tool that does not mark it, and produces a file with no manifest, which is indistinguishable from the millions of unmarked files produced for entirely ordinary reasons.

Detection, meaning inference about origin from the content itself, is a separate discipline with separate failure modes and no guarantees. This article makes no claim about it and takes no position on how well it works. What matters here is the direction of the inference: a manifest declaring trainedAlgorithmicMedia is a signed statement that a model was involved, and it is strong evidence. The absence of such a manifest is not evidence of the opposite. The implication runs one way only, and the whole misreading consists of running it backward.

The naming discipline follows. A tool that reads and validates Content Credentials is an inspector, not an AI detector, and calling it the latter promises something the technology does not do.

11.2 Provenance is not truth

Section 2 established this from the specification's own text, and it bears repeating in the context of what remains unsolved. A photograph can be captured by a conforming camera, signed by a trusted certificate, validated to Trusted, and still be presented with a caption that reverses its meaning. The credential covers the pixels and their history. It says nothing about the sentence next to them.

The specification's design goal is deliberately modest here, and the modesty is a feature. A standard that tried to certify truth would be a standard that assigned some organization the authority to decide it.

11.3 Provenance is not identity

The trust model is about the identity of the signer as a cryptographic fact: this key signed this claim, and this certificate chains to this anchor. Since version 2.0 the specification's notion of actor no longer refers to humans and organizations; it focuses on claim generators and claim signers.

Identity assertions can carry human or organizational identity, but the specification no longer defines how identity must be expressed within one. The security and validity of what an identity assertion contains depends on which identity specification its creator chose. So "signed by a certificate whose subject says Example Corp" and "produced by Example Corp" are different statements, and only the first is what validation gave you.

11.4 What is left to human judgment

After validation succeeds, a person still has to decide whether the signer is a party they trust, whether the recorded actions are consistent with how the content is being used, whether an absent record is expected in this context, and what to conclude when a chain is partially broken.

That is not a gap in the technology. It is the division of responsibility the specification chose, with the consumer explicitly placed outside the trust model, using the signer's identity along with other trust signals to decide whether the assertions are true. Systems that try to automate that final judgment do not eliminate it; they hide it behind a label, which is the failure mode section 2.4 was about.

Treating inbound media as untrusted input, and reasoning systematically about what an adversary could do with it, is the province of threat modeling rather than of provenance, and is covered separately in Threat Modeling Generative AI Applications on AWS.

12. Failure Modes

12.1 Treating credential presence as a truth signal

Symptom: a user interface labels content with a valid manifest as verified or authentic.

Why it fails: validation establishes that a record is well formed, unaltered, and bound to this asset. The specification is explicit that valid manifests do not make anything true, and that assets with valid manifests can still be misinformation.

Instead: state what was verified and by whom. Never render a validation result as a judgment about content.

12.2 Treating credential absence as a generation signal

Symptom: unmarked content is flagged, downranked, or routed to stricter handling.

Why it fails: absence has many innocent causes, and the C2PA says so directly. A policy built on absence penalizes honest creators using tools that have not implemented the specification, and it fails hardest on users with the least access to current software.

Instead: make absence a neutral, recorded fact. If you have a recovery path, try it, and label recovered manifests as recovered.

12.3 Signing without verifying

Symptom: the organization adds Content Credentials to its outputs and never builds anything that reads them.

Why it fails: signing satisfies an outbound obligation and buys you no inbound protection. As section 7 showed, the published conformance data reflects an ecosystem where the generation side is far ahead, and the verification side is the one that requires you to build something.

Instead: treat verification as a separate project with a separate owner. Reading manifests is where the operational value is.

12.4 Displaying manifests you did not validate

Symptom: a viewer parses a manifest and renders the signer name and actions without running validation, or renders them despite validation failing.

Why it fails: unvalidated manifest content is attacker-controlled. The specification tells consumers not to display data from manifests that are not Valid, and if they do, to warn about invalidity and about non-attribution.

Instead: validate first. If you must display invalid content, carry both warnings, and treat every rendered string as untrusted input.

12.5 Signing without a time-stamp

Symptom: content is signed, no trusted time-stamp is applied, and a certificate is later revoked.

Why it fails: without a time-stamp a validator cannot tell whether signing happened before or after revocation, and defaults to untrusted. One revocation invalidates the entire signing history of that key.

Instead: apply trusted time-stamps from an authority on the C2PA TSA Trust List on every signature, from day one. This is not an optimization to add later; retrofitting it does not help content already signed.

12.6 Planning no revocation strategy

Symptom: one signing key covers all content, no HSM, no scoping, no plan for who to call.

Why it fails: revocation is coarse and can reach back to a compromise date, taking legitimate content signed in the detection window with it. The specification's own example puts seven thousand legitimate images inside a seven-day window.

Instead: split signing across multiple keys and claim generators to bound the blast radius, protect keys in an HSM, and write the plan before you need it, including the caches and repositories that hold copies you do not control.

12.7 Ignoring preservation in the transformation pipeline

Symptom: resizing, transcoding, or thumbnail generation drops the manifest, or carries it forward unchanged so that the hard binding no longer matches.

Why it fails: a hard binding is exact by design and will not survive a re-encode. Copying a manifest onto changed bytes produces a mismatch, which validators correctly reject.

Instead: make every transformation stage open the prior manifest, record its actions, and re-sign. Where a stage cannot, bridge it with a watermark and a repository registration, and record the bridged segment as an ingredient rather than presenting an unbroken chain.

12.8 Using a soft binding as if it were a hard binding

Symptom: a system treats a watermark or fingerprint match as proof that content is unmodified.

Why it fails: the specification forbids the substitution, and the reason is in the definition. A soft binding is a content identifier that is either not statistically unique or embedded as a watermark. It answers whether this is the same content, not whether it was altered.

Instead: keep the layers doing their own jobs. Use the soft binding to find the record; use the hard binding to decide whether the record still applies.

13. Frequently Asked Questions

13.1 Does a valid Content Credential mean the content is real?

No. It means the record is well formed, unaltered since signing, and bound to this asset. The C2PA states that the presence of valid manifests does not mean anything is true, and that assets with valid manifests can still be misinformation.

13.2 Does missing Content Credentials mean content was generated by AI?

No, and this is the more damaging version of the same mistake. Absence has many ordinary causes, including tools that never implemented the specification and intermediaries that discard metadata. The specification says explicitly that lacking Content Credentials does not mean content is not to be trusted.

13.3 What version should I cite?

The technical specification at 2.4, whose version history entry is headed 2.4 - April 2026. Note that the other documents are not all at 2.4: the Explainer, Guidance for Implementers, and User Experience Guidance are at 2.2, the AI and ML guidance is at 2.3, and Attestations is at 1.4. PDF bundles are published up to 2.3.

13.4 What is the difference between a manifest and a Content Credential?

They are the same object under two names. The specification defines Content Credential as the preferred non-technical term for a C2PA Manifest, and notes that a manifest store therefore represents the Content Credentials of an asset. The plural also names the technology as a whole.

13.5 Why do I need a watermark if I already sign the manifest?

Because a hard binding cannot survive a re-encode and a manifest can be stripped in transit. A soft binding, which may be an invisible watermark or a fingerprint, lets a stripped asset be matched back to a manifest held in a repository. The specification forbids using a soft binding as a hard binding, so the two layers are complements, not alternatives.

13.6 How do I mark that a model generated an asset?

Put a c2pa.created action first in the actions assertion, with digitalSourceType set to http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia. That combination is the specification's own worked example for a model generating video from a text prompt. Where you can say more, add the c2pa.ai-disclosure assertion introduced in 2.4.

13.7 What does the AI disclosure assertion add over digitalSourceType?

Three things the older signal does not carry: which models were used, the subject domain of the content, and the degree of human involvement through humanOversightLevel, whose values are fully_autonomous, prompt_guided, and human_validated. It complements digitalSourceType rather than replacing it, and its schema still has fields awaiting specification.

13.8 If a certificate is revoked, does all my past content become untrusted?

It depends on the reason and on whether you time-stamped. A planned revocation takes effect from its date, so earlier content stays valid. A compromise-driven revocation reaches back to the believed compromise date, so legitimate content signed in the detection window becomes untrusted too. Content signed with no trusted time-stamp is treated as untrusted regardless, because the validator cannot place it relative to the revocation.

13.9 Should I use OCSP stapling?

It is optional, and it trades revocation latency for availability. Stapling proves the certificate was unrevoked at signing time and lets validation succeed when the responder is unreachable, but a validator relying on the stapled response will not see a later revocation until that response expires. Choose the validity period deliberately.

13.10 What should my system do when a credential validates but the signer is unknown?

Treat Valid and Trusted as different outcomes. Valid means the record is genuine and attributable to the claim generator named in the claim; Trusted additionally means the signing credential chains to an anchor you accept. Record which one you got and against which trust list, and let downstream policy read that rather than a boolean.

13.11 Where do I get a trust list?

Validators are required to maintain trust anchor configurations per accepted extended key usage value, and for the C2PA claim signing EKU that set must include the anchors the C2PA provides, which is the C2PA Trust List. Time stamping authority anchors are maintained in a separate list. The Interim Trust List was frozen on 2026-01-01 and is not the forward path.

13.12 Is any of this tied to a particular cloud or vendor?

No. The specification is vendor-neutral and the trust model is built on ordinary X.509 and COSE. Where a managed platform is involved, the platform-specific parts, principally custody of the signing credential, are a separate topic by design.

14. Summary

Content provenance gives generated media something it otherwise lacks: a signed, tamper-evident record of what was done to an asset, carried with the asset and readable by anyone. The C2PA technical specification at 2.4 defines that record as a manifest built from assertions, a claim, and a claim signature, presented to non-technical readers as a Content Credential.

Four things are worth carrying away.

A valid credential is verified attribution, not verified truth, and the specification says so. Validation establishes that a record is well formed, unaltered, and bound to this asset. It does not establish that the statements inside it are accurate, only created assertions are attributed to the signer at all, and the absence of a credential is not evidence of anything. Every product surface has to be written from that sentence, because a label that converts a validation result into a judgment about content will eventually be wrong about someone's honest work.

The design is two layers, and both are load-bearing. Exactly one hard binding proves integrity but cannot survive a re-encode. Any number of soft bindings, fingerprints or invisible watermarks, survive transformation but prove nothing about integrity, which is why the specification forbids substituting one for the other. Together with a manifest repository and the soft binding resolution API, they make stripping non-fatal, and stripping is something the specification openly expects.

The signing side is far ahead of the verification side, and only the second one is your project. Counting the C2PA Conforming Products List as retrieved on 2026-08-09 gives 137 generator products against 20 validator products out of 157 conformant records, with every record assessed at specification version 2.2 while the specification is at 2.4. That list reflects program enrollment rather than adoption, but the direction is unambiguous: signing is increasingly something you configure, and verification is something you build.

Revocation is the operational risk you will not think about until it happens. A compromise-driven revocation reaches back to the believed compromise date and takes legitimate content with it; content signed without a trusted time-stamp is untrusted regardless; stapled OCSP responses delay revocation visibility; and copies you no longer control, in content delivery networks and in the manifest repositories you registered with, keep serving the old credential. Time-stamp everything, split keys to bound the blast radius, and write the plan before you need it.

Provenance is worth adopting. It is worth adopting for what it actually does, which is to let a recipient know who claimed what, verifiably, and to let that recipient decide what the claim is worth.