C2PA 2.2 in plain terms: manifests, hard and soft bindings

The C2PA 2.2 specification (May 2025) defines a manifest as a signed collection of assertions about a file. A hard binding ties the manifest to the exact bytes with hashes. A soft binding uses things like fingerprints or invisible watermarks to link a file back to its manifest even when the bytes changed. So a re-encoded video usually loses a hard-bound manifest, and only a soft binding could point back to it.

The pieces

A redirect page referenced version 2.4 as the current spec when this was read, so the numbering has moved on from 2.2. Check the current text for details that changed.

What it implies for a trim or re-encode

The implication is an inference from the definitions, so test it on your own files. A hash covers specific bytes. If any step rewrites the bytes, a hash-based claim no longer matches unless the tool that edited the file also updated the manifest. A watermark or fingerprint can survive, because it is derived from the content rather than the byte layout.

In the Sume docs, video trim defaults to precision: exact, a frame-accurate re-encode, and offers keyframe, which copies the stream. Either produces a new MP4. The docs do not describe C2PA handling, so this post makes no claim about what trim does to a manifest.

A test to run once

Take one file that carries credentials, run it through each step in your pipeline, and check after every step. The sheet below is enough to see where the claim is lost.

step,tool,manifest_present,hard_binding_valid
original,generator,yes,yes
trim_exact,video trim,?,?
resize,own encoder,?,?
upload,platform,?,?

What to do with the answer

Provenance metadata is useful when it survives and honest when you say it did not. Report what you measured.

• If credentials vanish at a step, add the label by hand after that step.
• Do not promise credentials to a client unless you tested the full path.
• Keep the original, untouched file as the source of truth.
• Re-test when you change tools or settings.

Reading provenance results

When you read a file's credentials, look for three things: whether a manifest is present, whether its signature validates and whether the binding matches the file you hold. Each can fail on its own.

A manifest that is present but does not match the file tells you the file was changed after signing. That is not a forgery signal by itself, since every re-encode does it; it only means the claim describes an earlier version.

Report results with their conditions, for example "manifest found, hard binding invalid after trim". That statement is useful to a client; "credentials preserved" without a test is not.