C2PA Manifest States: Well-Formed, Valid, and Trusted

Save the exact result before naming the state

Open the preserved file in a C2PA-compatible validator and keep the complete output, not only a badge or headline. Record the file name or source URL, retrieval time, validator name and version, active-manifest label, and every status code shown. This worksheet is a review method proposed here; it is not a form required by C2PA.

Ask which validation state the active manifest meets in this run and which checks support that state. C2PA defines a hierarchy. Every Trusted manifest is Valid, and every Valid manifest is Well-Formed. The reverse does not follow. A Well-Formed result alone does not establish signature integrity or signer trust, and a Valid result alone does not establish the Trusted state.

Keep the manifest state separate from a claim about the asset or the event shown. C2PA says an asset is Valid when the portions covered by content bindings have not been modified since the active manifest was produced and the active manifest is Valid or Trusted. That asset-level statement still concerns covered bytes and provenance validation, not whether a caption, identity, location, or depicted event is factually correct.

Check Well-Formed requirements first

A C2PA Manifest is Well-Formed when validation finds that its contents follow the normative requirements checked by the validation process. The manifest must contain only assertions allowed for that manifest type. Its assertions must meet the requirements for assertions, and any ingredients must meet the requirements for ingredients.

Use a row for each of those four areas: specification requirements, allowed assertions for the manifest type, assertion requirements, and ingredient requirements. Copy the validator's exact result beside each row. If the output does not expose a detail, mark it as not displayed instead of assuming that it passed.

Well-Formed is therefore a structural and rules-compliance state. It is a prerequisite for Valid, but it does not say that the manifest has remained unchanged since signing. It also does not say that the claim signature was validated, that its validity-period check succeeded, or that the signer is trusted.

Add the checks required for Valid

A Valid manifest must first be Well-Formed. The specification then requires validation to determine that the manifest has not been modified since it was signed. The claim signature must receive claimSignature.validated, and the validity-period check for that signature must receive claimSignature.insideValidity.

Credential revocation is another separate condition. The signer's credential must not be rejected with signingCredential.ocsp.revoked or signingCredential.ocsp.unknown. Keep these entries on separate lines. A signature result, a time result, and a revocation result answer different technical questions, even though all contribute to the Valid state.

When a manifest is Valid, C2PA says its claim can be attributed to the claim generator identified by the claim's claim_generator_info field. Record the field as shown. Do not expand that attribution into a claim that the tool witnessed the event, verified every statement inside an assertion, or endorsed the media's surrounding narrative.

Require signer trust before using Trusted

Trusted requires a Valid manifest and a signing credential that receives signingCredential.trusted. A reviewer should therefore keep the credential-trust result next to, but distinct from, the Valid-state checks. If a tool reports Valid without signingCredential.trusted, do not upgrade the label because the publisher or software name looks familiar.

Trust also depends on the validator's trust configuration. The specification requires validators to maintain accepted Extended Key Usage values and corresponding X.509 trust anchors. For the c2pa-kp-claimSigning EKU, those anchors include the C2PA Trust List, though lists may be empty and validators may allow additional user-configured anchors. Record the validator version and trust configuration that are visible in the output. Results from two validators can differ when their applicable trust stores differ; report the observed difference without inventing a cause that the outputs do not show.

A compact review table can use columns for manifest label, Well-Formed checks, signature-integrity result, validity-period result, revocation result, signer-trust result, final state, and unresolved items. This prevents the word “trusted” from hiding the checks that produced it.

Keep status codes, asset integrity, and event claims separate

Do not collapse validation states into the lists of success, informational, and failure status codes. Status codes are the recorded checks; Well-Formed, Valid, and Trusted are states derived from their required conditions. Also keep the Valid-manifest state separate from the Valid-asset condition, which adds the content-binding result for the covered portions of the asset.

If you also submit the preserved file to DeepFakeCheck, store that probabilistic risk signal in another section. Automated detection can produce false positives on authentic media and false negatives on synthetic or altered media. DeepFakeCheck does not assign C2PA manifest states or issue C2PA validation codes.

A high-risk signal supports further review, while a low-risk signal does not turn a Well-Formed manifest into a Valid or Trusted one. Likewise, a Trusted manifest does not prove that the depicted event happened, that a caption is accurate, or that a speaker is who the post claims. Verify those real-world claims against the original publication and independent evidence.

Finish with the exact file, complete validator output, required checks for the state reported, trust context, asset content-binding result if available, outside-source findings, and the action taken. The next reviewer should be able to reproduce the technical conclusion without turning provenance trust into a factual verdict.

Sources

• C2PA, “C2PA Technical Specification, Validation states”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_validation_states