C2PA Content Credentials through four asset states
Published ; updated
A Content Credential is often described as telling you whether an image is genuine. It does not do that. It records who signed a claim about an asset and whether the asset still matches the claim. Those are different questions, and a validator answers them separately.
This page follows one small test image through four states and reports, for each, what a C2PA validator actually says. Every asset, the unedited validator output and the script that rebuilds the starting image are published with the reproduction check, so the table below can be recomputed rather than taken on trust.
Scroll horizontally to see all columns
| Property | This page | A production Content Credential |
|---|---|---|
| Credential | Self-signed test certificate made for these fixtures | Issued to a real publisher |
| Trust status | Not trusted by public trust lists | Depends on the validator's configured list |
| What it shows | How a validator reports store, binding, signature and trust | Nothing on this page is evidence about any real publisher |
Anatomy of an embedded Content Credential
A C2PA manifest holds assertions, a claim, a signature and exactly one hard binding to its asset. Validation checks more than the signature. It checks the assertions, the ingredients, the certificate and the asset binding.
The trust decision is separate from signature mathematics. A signature can be cryptographically perfect while the certificate that made it is unknown to the validator. The fixtures here use a test certificate that public trust lists do not trust, and the validator says so on every signed state below.
One asset, four states
The starting image is built by a committed script, so the chain begins with something reproducible rather than an opaque file. Signing, editing and stripping were then applied with c2patool 0.27.15, which records its library version, c2pa-rs 0.90.15, inside each claim it writes. No timestamp authority was used, so nothing here depends on a network service.
Scroll horizontally to see all columns
| State | Bytes | Embedded store | Claim signature | Hard binding | Credential |
|---|---|---|---|---|---|
| Original, unsigned | 10,370 | absent | none | none | none |
| Test-signed | 65,012 | present | validated | match | untrusted |
| Naive derivative | 64,875 | present | validated | mismatch | untrusted |
| Provenance-aware derivative | 163,959 | present | validated | match | untrusted |
| Stripped copy | 10,370 | absent | no claim found | no claim found | no claim found |
The naive derivative is the state worth pausing on. Its pixels were changed while its manifest was left in place. The claim signature still validates, because the signature covers the claim and the claim was not touched. The hard binding is what fails, and the validator reports it precisely, as `assertion.dataHash.mismatch`. A viewer that collapsed these into one green word would show a valid tick over content the credential no longer describes.
The provenance-aware derivative carries the same pixel change, but it was signed again with the test-signed state recorded as a parent ingredient. Its manifest store holds two manifests, and the earlier one is recorded with the relationship `parentOf`. The binding matches once more, because the new claim describes the new pixels. The credential is still untrusted, and the validator still says so.
What stripping does and does not remove
The stripped copy was made by removing the `caBX` chunk that carries the manifest store in PNG. The result is byte-identical to the pre-signing original, and c2patool reports `No claim found`. Signing had not altered a single pixel, which is why the bytes return exactly.
That is a narrow result. It establishes that this copy has no supported embedded manifest store. It does not establish that provenance has been erased. The C2PA design pairs hard bindings with optional soft bindings such as fingerprints or invisible watermarks, and a manifest can be held remotely. Any of those could reconnect a stripped asset to its history. Unrelated metadata was left untouched here, so this page says nothing about EXIF, XMP or IPTC either.
Reading a validator honestly
Four facts travel together and mean different things.
A store can be present or absent. Absence is not proof of innocence, only absence of one carrier.
A signature can validate over a claim while the asset has moved on. Validation of the signature is not validation of the picture.
A binding is the part that ties a claim to actual bytes. When it fails, the credential describes something the asset no longer is.
Trust is a policy decision made by the validator against its configured list. Every signed state on this page is untrusted, by construction.
Limits of this page
The credential here is self-signed for these fixtures, so nothing on this page is evidence about any real publisher or any production Content Credential. The signing key is deliberately not published: ECDSA signatures are randomised, so re-signing could never reproduce these bytes, and the reproducible facts are the asset bytes, the store presence, the pixel content and the recorded validator output. Those are what the published check recomputes.
This page is about C2PA file metadata. It is not about text watermarking, and it carries no information about Claude's text mark, which remains untestable without Anthropic's key and matching detector.