Manifest Assertion

Every assertion follows a strict, machine-readable schema defined by the C2PA specification. This ensures interoperable validation across different tools and platforms.

• Label: A unique identifier for the claim type (e.g., stds.schema-org.CreativeWork)
• Data: The payload containing the actual claim, formatted as a JSON-LD object
• Schema Reference: A pointer to the formal definition that governs the data structure

This structure allows validators to programmatically parse and verify claims without human interpretation.

An assertion is not merely a text tag; it is cryptographically bound to the content and the signer's identity through a digital signature.

• The assertion data is hashed and included in the manifest's claim signature
• The signature is generated using the private key associated with an X.509 certificate
• Any post-signing modification to the assertion data invalidates the signature

This creates a non-repudiable link between the claim, the content, and the identified party making the assertion.

C2PA defines a taxonomy of assertion types to cover the full content lifecycle. Key categories include:

• Creative Work Assertions: Claims about authorship, copyright, and the nature of the work itself, often using schema.org vocabularies
• Action Assertions: Document specific edits performed, such as c2pa.cropped or c2pa.color_adjusted, including software agent and parameters
• Ingredient Assertions: Reference source media used in composites, forming the backbone of the provenance chain
• Identity Assertions: Link the content to a verified real-world identity via a trusted certificate chain

Assertions can be attached to content using two distinct methods, each with different resilience characteristics:

• Hard Binding: The manifest containing all assertions is embedded directly into the asset's binary file structure using the JUMBF container format. This ensures the provenance data travels with the file but increases file size.
• Soft Binding: The manifest is stored externally as a sidecar file or cloud URL, referenced by a content hash. This is lighter but risks metadata stripping if the asset is transferred without its sidecar.

The choice depends on the distribution pipeline and resilience requirements.

An assertion's credibility is only as strong as the signer's identity. Validation relies on a Trust List—a cryptographically signed roster of approved issuers and Certificate Authorities.

• The validator engine checks the signer's X.509 certificate chain against the trust list
• It performs a revocation check via OCSP to ensure the certificate hasn't been invalidated
• Only assertions signed by entities on the trust list are displayed as verified

This prevents self-signed or compromised certificates from producing convincing but fraudulent provenance claims.

Assertions support selective disclosure to balance transparency with privacy. Sensitive metadata can be redacted without breaking the cryptographic chain.

• A pre-redaction hash is included in the signed manifest
• Redacted fields are replaced with a placeholder, and a zero-knowledge proof can optionally demonstrate the redaction was valid
• This allows, for example, a photojournalist to assert their identity while redacting the exact GPS coordinates of a sensitive location

The verifier can still confirm the manifest's integrity even with redacted fields.

A cryptographic digital signature generated over a set of assertions, binding them to a specific identity. It ensures integrity (the assertions haven't been altered) and non-repudiation (the signer cannot deny signing).

• Uses the signer's private key from an X.509 certificate
• Validated by the verifier using the corresponding public key
• Forms the mathematical proof that a manifest assertion is authentic

A specialized assertion type that documents a piece of source media used in creating a composite asset. It records the relationship between a final output and its constituent parts.

• Creates a verifiable lineage chain back to original captures
• Includes the hash of the ingredient asset for integrity verification
• Enables viewers to trace every element in a composite image or video
• Essential for proving content was not generated from whole cloth by AI

A cryptographically signed claim that links content to a verified, real-world identity. Unlike a generic creator assertion, this is backed by an X.509 certificate issued by a trusted Certificate Authority.

• Binds a legal entity or individual to the content
• Validated against the C2PA Trust List during verification
• Provides the strongest form of creator attribution
• Often used by news organizations and professional photographers

Documents a specific operation performed on the content, such as cropping, resizing, color correction, or AI-based generative fill. Each action becomes a node in the provenance chain.

• Includes parameters describing the transformation
• Records the software agent that performed the action
• Enables full edit transparency: what was done, by what tool, in what order
• Critical for distinguishing minor corrections from deceptive manipulations

The abstract graph-based structure that represents entities, agents, and activities involved in content creation. Often aligned with the W3C PROV standard.

• Defines three core node types: Entity (the asset), Agent (creator/tool), Activity (action)
• Provides the semantic framework that manifest assertions populate
• Ensures interoperability across different provenance implementations
• Enables machine-readable querying of the full creation history

The software component that performs cryptographic verification of a content credential. It checks every assertion's integrity and authenticity.

• Validates signature chains back to a trust anchor
• Checks certificate revocation status via OCSP
• Confirms signers are on the configured Trust List
• Returns a pass/fail determination that a consumer-facing app displays
• The final arbiter of whether a manifest assertion is trustworthy