C2PA Content Credentials survive exactly as long as you never touch the bytes

A C2PA Content Credential is a small cryptographic miracle: a signed manifest, embedded in the file, that says who made this asset, with what tool, and what's been done to it since. It survives being copied, uploaded, downloaded, and stored — perfectly, indefinitely. And then someone's thumbnail job runs, and it's gone.

What's actually in the file

The C2PA standard (the coalition behind it includes Adobe, Google, Microsoft, OpenAI, and the BBC) defines a manifest: a set of assertions — "created by model X", "edited with tool Y" — hashed together and signed. The manifest is bound to the asset by a hard binding: a cryptographic hash of the asset's content. That binding is the whole point. Anyone can verify that the manifest belongs to exactly these bytes and was signed by the claimed party.

It's also the whole fragility. The binding covers the bytes, so the credential is only valid for the bytes. Change the bytes and the signature no longer matches — by design, since an edited image shouldn't inherit its original's provenance. But most tools don't update the manifest when they touch a file. They just drop it.

Where credentials die

Take an image generated by a provider that embeds Content Credentials, and follow it through an ordinary product pipeline:

• The resize. Your API downloads the output and makes a 512px preview with sharp or ImageMagick. New pixels, new bytes, no manifest. Most image libraries strip metadata by default — it's a feature, for privacy reasons.
• The re-encode. The video pipeline runs everything through ffmpeg to normalize codecs. -map_metadata -1 is in half the ffmpeg invocations on the internet, and even without it, transcoding produces a different bitstream — the binding is dead either way.
• The optimizing CDN. Image CDNs re-compress and convert formats on the fly (that's the product). The bytes that reach the browser are not the bytes you stored. WebP-ified, quality-adjusted, credential-free.
• The screenshot. Marketing pulls the asset into a deck, exports a PNG, posts it. Nothing survives a screenshot. Nothing ever will — this is the boundary of what provenance tech can do.

None of these steps is a mistake. Each is the correct default for the tool doing it. That's why credential loss is the norm: it takes exactly one lossy hop, and the hops are everywhere.

Provenance doesn't leak out of pipelines. It's scrubbed out, by well-configured tools doing their jobs correctly.

The fix is boring: stop touching the bytes

The reliable way to keep a provider-embedded credential valid is to preserve the provider's output byte-exactly and treat it as the master. Concretely:

• Stream, don't process. Move the output from the provider URL into your storage as an opaque byte stream. Compute the sha256 in the same pass — the hash is your proof, later, that what you hold is what was produced.
• Derive off to the side. Thumbnails, previews, transcodes — generate them as separate objects, clearly derivative, and serve those where convenience wins. The master never gets re-encoded, so the master's credential never dies.
• Watch the serving path. If the master is what you serve for download or verification, it has to bypass any transform layer — no CDN image optimization on that route, no content-negotiation format swaps.

This is the custody model Wakemark runs: outputs stream into storage byte-exactly with the hash recorded at ingestion, before the provider's URL expires, and derivatives are always separate objects. Provider-embedded Content Credentials survive because nothing between the model and the archive ever re-encodes the asset.

You can check any file yourself:

$ c2patool asset.jpg
# prints the manifest chain: claim generator, assertions,
# signature status — or "No claim found" after a lossy hop

What a credential does and doesn't prove

Worth being precise, because the marketing around provenance sometimes isn't. A valid Content Credential proves the asset hasn't changed since signing and that the signer is who the certificate says. It does not prove content is "real", and its absence doesn't prove content is fake — as we just saw, absence usually means somebody resized a JPEG. Provenance is a chain-of-custody tool, not a lie detector.