How to verify content credentials: a tester's session

What verification actually checks

A validator does four jobs. It verifies the signature on the claim: the claim generator signed the claim with a private key, and the validator checks that signature against the public key in the signing certificate. It checks the certificate chain: the certificate must chain to a root that the validator trusts, using the X.509 rules that secure the web, and the C2PA specification allows only X.509 certificates for signing. It checks the hash bindings: the manifest carries a hash of the content, and the validator recomputes that hash over the bytes you gave it. And it checks the assertions: the actions, ingredients and other statements must be of the allowed kinds, and any ingredient manifests must validate in turn.

Time matters in two of those checks. A signing certificate expires, so the specification lets the claim generator attach a time-stamp from a trusted time-stamp authority proving that the signature existed while the certificate was valid; without one, an old manifest can fail years later for no reason connected to tampering. And the trust list is a configuration of the validator, which is why the same file can be trusted in one tool and merely valid in another. Record which validator and which trust list you used.

The four outcomes and what each proves

The second row deserves attention because it is common. Anyone can obtain a certificate and sign a manifest, so a valid signature by itself only shows internal consistency: these bytes match this claim by whoever held this key. Trust comes from the list, and lists differ between validators and change over time. A result should always name the list it was judged against.

How to verify content credentials: the session

1. 1

   Obtain the exact bytes

   Download the original file, not a screenshot and not a browser-converted copy. Note where it came from, the URL and the time. If a platform offers an original download, use it; if it offers only a re-encoded view, say so in the record.

2. 2

   Hash the file before anything else

   Compute a SHA-256 of the file as received and write it down. Every later statement refers to this hash, and it is what a second tester will ask for.

3. 3

   Run a pinned validator

   Use a C2PA validator whose name and version you record, and note the trust list version or source it uses. Two validators with different lists can disagree on the trust outcome for the same file.

4. 4

   Read the manifest store

   Identify the active manifest, its claim generator, the signer's certificate subject, the actions asserted and the ingredients. For each ingredient, note whether its own manifest validated.

5. 5

   Confirm the hash binding against your file

   Check that the validator computed the content hash over the bytes you hashed in step 2, and that it reports a match. A validator fed a different copy proves nothing about yours.

6. 6

   Classify the outcome

   Place the result in one of the four rows above and write the conclusion from the third column, in those words. Resist stronger language.

7. 7

   Write the record

   Record the fields in the next section. A verdict without a record is an anecdote.

The two traps: reading absence and reading validity

The first trap is treating no credentials as evidence of fakery. Most files in circulation have none, because most cameras and tools do not attach them and most platforms strip metadata on upload. Absence tells you that this copy carries no provenance record, and nothing else. A genuine photograph that has been through a messaging app and a social upload arrives with no credentials, and so does a generated image. The guide to testing AI disclosure labels covers the related mistake of reading a missing label as a statement.

The second trap is treating valid as true. A trusted manifest proves that a named signer produced these bytes and asserted these actions. If the signer is a camera, that is strong evidence the pixels came from that camera's sensor at that time, subject to the device's security. If the signer is an editing tool, it proves the tool applied the listed actions to the listed ingredients. Neither proves that the scene was not staged, that the caption is accurate, or that the ingredient itself was not generated. Credentials describe origin and edit history as signed; truth is a separate question, and the same limit applies to detector scores, as the guide to proving you wrote it argues for text.

Writing the result up as evidence

If the verification may be quoted in a dispute, a correction, an audit or a court, it has to be reproducible by a stranger. The full discipline is in evidence-grade test records; the minimum for a verification session is short.

• The SHA-256 of the file as received, with the source and the time of receipt in UTC.
• The validator name and version, and the trust list version or source it used.
• The outcome in the four-way classification, and the exact validator status codes behind it.
• The active manifest's claim generator, signer subject, time-stamp status, actions and ingredients, with each ingredient's own outcome.
• Who ran the session, when, on what machine, and where the file and the validator output are stored read-only.

Pitfalls that produce false conclusions

Almost every wrong verdict comes from verifying the wrong bytes. A screenshot of an image is a new image with no manifest. A copy saved from a browser preview has usually been re-encoded. A file downloaded from a social platform has almost always had its metadata stripped, so a photo that was signed at capture arrives as no credentials. A file emailed through a proxy or pasted into a document has been rewritten. In every one of those cases the honest outcome is that this copy cannot be verified, and the record should say which copy it was. If a colleague reports a different outcome, compare hashes first; in most disputes the two people verified different files. How a pipeline turns a signed original into an unverifiable copy is the subject of testing a content provenance pipeline, and the hub for testing AI systems collects the detection guides that people reach for when credentials are absent.

This guide is part of the testing AI systems hub. It is best read alongside testing a content provenance pipeline and evidence-grade test records for authenticity systems, which cover the neighbouring questions.