How C2PA Verification Works

C2PA verification is the process of locating an asset's Content Credentials and evaluating whether the associated manifests, assertions, signatures, signing credentials, and content bindings remain structurally and cryptographically sound. It is not a single signature check. It is a coordinated sequence of discovery, parsing, hashing, certificate evaluation, provenance traversal, and result reporting.

A useful validator does more than return true or false. It explains whether a credential was found, whether its claim and assertions are intact, whether the asset still matches its hard binding, whether the signer is recognized under a particular trust configuration, whether time and revocation evidence are usable, and which parts of the recorded history could or could not be evaluated.[1]

What C2PA verification actually evaluates

The word verification is often used loosely. In a C2PA system, several different questions must be answered, and a positive answer to one does not automatically answer the others.

The final row is deliberately outside the C2PA validation algorithm. A newsroom, marketplace, insurer, or AI platform may use the same technical results but apply different acceptance rules. Raw C2PA validation should therefore remain separate from business policy.

The actors and the verification context

Verification involves more than a parsing library. A production result depends on the actor performing validation and the context supplied to it.

For reproducibility, a validator should record the exact asset hash, validation-engine version, specification version, trust-list snapshot or identifier, evaluation time, and network mode. The same bytes can receive a different trust conclusion later if a trust list changes, a certificate is revoked, or fresh network evidence becomes available.

The complete verification lifecycle

A complete verification workflow can be understood as twelve connected stages. Implementations may perform some checks in a different internal order, but they should preserve the same technical distinctions and equivalent results.

1. Establish the exact asset bytes or asset representation being evaluated and record the execution context.

2. Locate an embedded or external C2PA Manifest Store using the rules appropriate to the asset format.

3. Select the active manifest and decompress it if necessary.

4. Locate the current claim, parse it, and confirm that required fields and supported algorithms are present.

5. Resolve every declared assertion, verify its hash, and apply manifest-type and assertion-specific rules.

6. Locate and cryptographically validate the COSE claim signature.

7. Validate the signing credential and determine whether it chains to a configured trust anchor.

8. Evaluate trusted time-stamps, certificate validity periods, and available revocation evidence.

9. Validate the asset's content against the active hard binding, following update-manifest parents when required.

10. Traverse and validate ingredient manifests, redactions, and recorded validation results.

11. Consolidate success, informational, and failure status codes and derive Well-Formed, Valid, and Trusted states.

12. Present the results with appropriate warnings and then apply any separate business or compliance policy.

1. Establish the exact asset and execution context

Verification begins with the exact representation the user, API, or workflow wants to evaluate. For a file, that usually means immutable bytes plus the detected media type. For a collection, stream, segmented asset, structured-text document, or live-media session, it means the complete representation defined by the relevant C2PA binding rules.

A production service should compute its own content identifier before parsing, retain the original media type and source information, and avoid normalizing, transcoding, or rewriting the asset before validation. A harmless-looking conversion can produce a different representation and cause a valid binding for the original asset to fail on the converted copy.

All inputs should be treated as hostile. Media containers, compressed manifests, CBOR, JSON-LD, certificates, thumbnails, remote references, and deeply nested ingredient graphs can all be used to consume memory, CPU, file descriptors, or network capacity. Parsing and remote retrieval should run inside bounded, isolated execution environments rather than inside the public web process.

2. Locate the Manifest Store

The validator first looks for a Manifest Store in the standard embedded location for the asset format. If an embedded store is not found, it may use defined external-discovery mechanisms, including an HTTP Link header, an XMP provenance reference, a format-specific reference, an HTML link element, or a nearby file with a .c2pa extension.

When both an embedded store and an HTTP reference are available, the embedded store takes precedence. Multiple embedded stores are generally invalid, although PDF incremental updates require special handling because separate update sections can carry separate Manifest Stores. An external reference that is known to exist but cannot be retrieved should be reported as inaccessible rather than silently treated as though no credential was ever present.[2]

External retrieval creates a security boundary. A verifier should block loopback, link-local, private, and metadata-service addresses; re-check the destination after redirects and DNS resolution; enforce strict size, media-type, decompression, redirect, and timeout limits; and avoid forwarding caller credentials to a manifest host. Remote assertions and OCSP queries require similar controls.

Soft-binding discovery is a separate step

A fingerprint or invisible watermark can help locate candidate Manifest Stores when embedded metadata and direct references have been lost. That process is discovery, not proof. A candidate returned by a soft-binding resolver must still be inspected, matched according to the soft-binding algorithm, and subjected to the ordinary C2PA validation process. Because soft bindings can produce approximate or ambiguous matches, a verifier may also need human review.

A soft-binding match must never be substituted for the hard binding required to validate the current asset representation. If the candidate manifest's hard binding does not match the asset, the verifier cannot determine from that mismatch alone whether the asset was transformed, the wrong candidate was retrieved, or the content was altered.[6]

3. Select the active manifest

Within a conventional Manifest Store, the last manifest is the active manifest. It is the starting point for validation and interpretation. Earlier manifests matter only when they are connected through recognized ingredient relationships, update chains, redactions, or other supported structures.

The active manifest may be a standard manifest with its own hard binding or an update manifest that adds restricted provenance without changing the protected content. When the active manifest is an update, the validator follows its required parentOf relationship through earlier update manifests until it reaches the first standard manifest containing the hard binding for the current content.

Compressed manifests must be decompressed before ordinary validation. Decompression failure, an invalid compressed payload, or an unsupported manifest structure should produce a precise failure result rather than a generic parser exception.

4. Locate and validate the claim

The claim is the signed organizing structure of the manifest. The validator locates the one claim permitted in the current manifest, decodes its CBOR, and checks required fields such as the asset instance identifier, signature reference, created-assertion list, and claim-generator information. Missing fields, multiple claims, invalid CBOR, or an unresolved signature reference are structural failures.

The validator also determines the hashing algorithms used by hard bindings and hashed references. Algorithms are compared with the versioned allowed and deprecated lists. An unsupported algorithm is a failure; a deprecated algorithm is normally recorded as informational so that the credential can be interpreted without treating the algorithm as a recommended choice for new manifests.

Schema validation can be useful during development, interoperability testing, or diagnostics, but it is not a substitute for the normative validation algorithm. A document can satisfy a schema and still contain a bad signature, mismatched assertion hash, invalid trust path, or incorrect content binding.

5. Validate the assertion set

Every created and gathered assertion referenced by the claim must be resolved and hashed. The computed hash must match the value recorded in the claim. The reference must point to the appropriate location, the assertion must be present, and the manifest must not contain undeclared assertions that sit outside the claim's protected set.

The validator then applies rules for the manifest type. A standard manifest requires exactly one supported hard-binding assertion and is constrained in how many parentOf ingredients it may contain. An update manifest must contain exactly one parentOf ingredient, must not contain a hard binding or thumbnail, and may include only the restricted actions permitted for updates.

Some assertion types have additional validation rules. Examples include checking action and ingredient consistency, validating hashes and labels for external references, confirming required fields in AI disclosure or identity-related structures, and handling redactions without allowing a claim to redact its own assertions. Both gathered and created assertions are covered by the claim and must pass integrity checks even though their attribution differs.[4]

6. Validate the claim signature and signing credential

The claim points to a COSE signature stored in the same manifest. The validator retrieves that signature, checks that the signing algorithm is permitted, validates the credential profile, and verifies the signature over the serialized claim. A successful cryptographic check shows that the signed claim has not changed since the private-key operation.

Credential trust is evaluated separately. The certificate chain is compared with the validator's accepted extended key usages and configured trust anchors. A signature can be cryptographically correct even when the signer is not recognized by the validator's public or private trust configuration. That result should be reported as a valid signature with an untrusted credential rather than rewritten as a statement that the signature itself failed.

Trust is contextual. An organization may accept the official C2PA Trust List, a private enterprise trust list, or both. A credential trusted inside a supply chain may be untrusted to a public consumer, while the underlying signature and assertion hashes remain technically verifiable.[3]

7. Evaluate trusted time and revocation evidence

Certificate validity is evaluated at a relevant time. A valid, trusted time-stamp can show that the completed claim signature existed at an attested time and allow the validator to compare that time with the validity periods of the signing certificate and its chain. Without a usable trusted time-stamp, current time is used for the signature-validity decision.

A claimed time of signing is different from a trusted time-stamp. The claimed value can be checked and reported as informational, but it is supplied by the signing workflow rather than independently attested by a Time Stamping Authority.

Revocation evidence may be stapled into the signature, added later through certificate-status assertions, or queried from an OCSP responder when the validator is online. Online checking is optional because it can reveal information about what is being validated. The result should distinguish not revoked, revoked, skipped, inaccessible, and unknown. A revoked credential is materially different from a responder that could not be reached.

For durable evidence, store the time-stamp token, available OCSP evidence, trust configuration, and validation time with the result. Re-running validation years later without the original context can produce a different answer even when the asset bytes are unchanged.

8. Validate the asset's content

The hard binding connects the active provenance to the asset being examined. If the active manifest is standard, the validator uses its hard-binding assertion. If the active manifest is an update, the validator follows the parentOf chain until it reaches the standard manifest that binds the current content.

The exact calculation depends on the asset type. A file hash may exclude the Manifest Store and defined padding; a box-based format may hash selected boxes; a collection or multi-part asset may validate several components; and structured text may require format-specific normalization. The validator must implement the correct binding rules rather than hashing the entire file naively.

A successful hard-binding result supports the conclusion that the protected representation matches the one described by the manifest. A mismatch does not reveal its cause. The content may have been transformed, metadata or byte ranges may have changed, the wrong external Manifest Store may have been located, or an attacker may have altered the asset. The safe conclusion is that this manifest cannot validate the asset as received.

9. Validate ingredients and the provenance graph

Ingredient assertions connect the active asset to parents, components, and computational inputs. The validator traverses the ingredient graph, processes redactions, checks the hashes that connect ingredient manifests or claim signatures, and validates the claims and non-redacted assertions in those ingredient manifests.

The original bytes of an ingredient are usually not present in the final asset. For that reason, the ingredient's content binding normally cannot be recomputed during later verification. Instead, the final credential preserves the ingredient manifest, its cryptographic connection, and the validation results observed when the ingredient entered the workflow. The current validator compares and consolidates those results rather than pretending it has revalidated source bytes it does not possess.

An ingredient without a connected manifest may receive an informational unknown-provenance result. That is not the same as a corrupt ingredient. It means the relationship is recorded without a verifiable C2PA history for that input. Extra manifests that are present in the store but not reached through recognized ingredient relationships are normally ignored.

Recursive processing needs explicit limits. Production systems should enforce maximum manifest counts, graph depth, cumulative assertion size, and repeated-node detection. This protects the service from circular or intentionally expansive provenance structures while preserving deterministic results.[4]

10. Consolidate status codes and derive states

C2PA validation returns structured success, informational, and failure codes. The codes can identify the manifest, claim, assertion, signature, ingredient, or asset component to which a result applies. A complete report should retain the raw codes and their locations before generating any simplified summary.

The specification defines a hierarchy of manifest states. A Trusted manifest is also Valid, and a Valid manifest is also Well-Formed. Well-Formed describes structural and assertion compliance. Valid adds cryptographic integrity, signature validity, acceptable signing time, and non-revocation requirements. Trusted adds a signing credential accepted by the validator's trust configuration. An asset is Valid when the protected content matches and its active manifest is Valid or Trusted.[5]

11. Present results responsibly

A verification interface should not reduce the entire process to one green check. At minimum, it should separate credential presence, asset integrity, claim and assertion integrity, signer and trust status, time and revocation evidence, recorded AI or editing disclosures, ingredient history, and unresolved issues.

Manifest data from an invalid manifest or invalid asset should generally not be presented as attributable provenance. If an application chooses to display it for diagnostics or authoring, the interface should clearly warn that validity failed and that the displayed statements must not be attributed to the manifest signer. This is especially important when an attacker has changed an assertion but left readable text in the file.[5]

A policy result should appear as an additional layer, not as a replacement for technical evidence. For example, an asset can have a valid and trusted credential but still fail an internal rule requiring a particular capture identity, AI disclosure, jurisdictional label, or approved workflow.

A practical verification example

Consider a retailer receiving a product image from a supplier through an asset-ingestion API.

1. The service stores the exact JPEG, computes an internal content identifier, and validates it in an isolated media worker.

2. An embedded Manifest Store is found, so a remote Link header is not used.

3. The active manifest is an update manifest recording publication. Its parentOf chain leads to the standard manifest created when the final JPEG was exported.

4. The claim and all referenced assertions are structurally valid and their hashes match.

5. The COSE signature validates. The signing certificate does not chain to the public C2PA Trust List but does chain to a private supplier trust anchor configured by the retailer.

6. A trusted time-stamp places signing inside the certificate validity period. Stapled OCSP evidence indicates that the certificate was not revoked at that time.

7. The standard manifest's hard binding matches the received JPEG.

8. One component ingredient has connected, validated provenance; a second ingredient records unknown provenance and produces an informational result.

9. The raw result is therefore Valid and Trusted under the retailer's private trust profile, with one provenance gap.

10. The retailer's policy engine still rejects automatic publication because the image lacks a required product-identity assertion.

This example shows why the validator, trust configuration, and policy engine should be separate. The same asset may be technically valid, privately trusted, and operationally unacceptable at the same time without any contradiction.

Building a production verification service

A scalable verification product usually separates several responsibilities:

• An intake layer that authenticates callers, applies quotas, and stores or streams the exact input safely.
• A hostile-content worker that detects format, parses media, extracts manifests, and enforces memory, time, recursion, and decompression limits.
• A constrained fetcher for remote manifests, external assertions, repositories, and credential-status services.
• A C2PA engine that returns raw, version-aware validation facts without applying customer business rules.
• A trust service that supplies immutable trust snapshots and private trust configurations.
• A policy engine that turns normalized facts into workflow-specific pass, warning, or rejection decisions.
• An evidence store that retains the asset hash, raw status codes, engine version, trust context, network observations, and policy version.

The public API should be idempotent and should return a stable verification-operation identifier. Large jobs should run asynchronously, while small assets may be validated synchronously behind strict limits. Repeated validation of the same bytes under the same engine, trust snapshot, time basis, and network evidence can be cached, but the cache key must include all context that can change the result.

Common verification mistakes

Production readiness checklist

• The verifier preserves the exact asset representation and records a stable input hash.
• Media parsing, manifest decompression, certificate parsing, and remote retrieval run in isolated, bounded workers.
• Embedded, external, PDF, HTML, structured-text, and other supported discovery paths are implemented deliberately rather than guessed.
• The active manifest, update chain, claim, assertion set, signature, time evidence, revocation evidence, hard binding, and ingredients are evaluated separately.
• The engine returns standard success, informational, and failure codes with precise locations and explanations.
• Trust configuration is versioned and separate from cryptographic signature validation.
• Online OCSP and soft-binding lookup are explicit, privacy-aware network operations rather than invisible defaults.
• Ingredient recursion has graph, depth, count, byte, and time limits.
• Raw validation results are immutable; later trust or policy changes create new evaluations.
• Invalid manifest data is suppressed or accompanied by prominent validity and attribution warnings.
• Business policy consumes normalized facts without changing the original C2PA result.
• The service can reproduce a historical conclusion from the stored engine, trust, time, network, and policy context.

The simplest mental model

• Find the Manifest Store without confusing absence with inaccessibility.
• Start from the active manifest and follow recognized provenance relationships.
• Validate the claim structure, algorithms, and every assertion hash.
• Verify the claim signature, then evaluate the credential, time, revocation, and trust context separately.
• Confirm that the applicable hard binding matches the asset as received.
• Preserve ingredient validation results without pretending missing source bytes were rechecked.
• Return structured status codes and derive Well-Formed, Valid, and Trusted states.
• Display provenance only with the warnings required by its validity state.
• Apply organization-specific policy after raw technical validation.

When these stages remain distinct, C2PA verification becomes an auditable evidence process rather than a decorative badge. It tells downstream systems exactly which provenance relationships are cryptographically supported, which trust decisions depend on local configuration, and where uncertainty or failure remains.

Sources and notes

[1] C2PA Technical Specification 2.4, "Validation Process" and "Returning Validation Results". These sections define validation as a multi-phase process and specify consolidated success, informational, and failure results.

[2] C2PA Technical Specification 2.4, "Locating the Active Manifest" and "Locating and Validating the Claim". These sections define embedded and external discovery, active-manifest selection, claim location, and structural checks.

[3] C2PA Technical Specification 2.4, "Validate the Signature", "Validate the Time-Stamp", and "Validate the Credential Revocation Information". These sections govern claim-signature validation, trust paths, trusted time, certificate validity, and OCSP evidence.

[4] C2PA Technical Specification 2.4, "Validate the Assertions", "Validate the Ingredients", and "Validate the Asset's Content". These sections define assertion integrity, manifest-type rules, recursive ingredient processing, and hard-binding validation.

[5] C2PA Technical Specification 2.4, "Validation states" and "Displaying Manifest Information". These sections distinguish Well-Formed, Valid, and Trusted states and require warnings when invalid manifest data is displayed.

[6] C2PA Implementation Guidance 2.4, "Guidance on use of soft bindings" and "Data validation using schemas", together with C2PA Security Considerations 2.4. These sources distinguish candidate recovery from hard-binding validation, clarify the limited role of schemas, and describe validation-related security concerns.