Content Authenticity Initiative (CAI)

A core architectural principle is the hard binding of the provenance manifest directly into the asset's binary file structure. Using the JPEG Universal Metadata Box Format (JUMBF), the cryptographically signed manifest is embedded within the file header. This ensures the provenance data travels with the asset, resisting accidental separation. The binding is achieved by hashing the asset's visual data and including that hash within the signed manifest, creating a mathematically unbreakable link.

• Uses JUMBF for embedding in JPEG, PNG, AVIF, and video formats
• Creates a cryptographic hash chain linking edits to the original
• Survives basic file copying and renaming operations

Provenance is expressed through a system of structured, digitally signed assertions. Each assertion is a specific claim about the content, such as its creator, creation date, or an edit action. The primary assertion types include Creative Work Assertions (describing the final asset), Ingredient Assertions (documenting source media used in a composite), and Action Assertions (recording specific edits like cropping or resizing). Each assertion is individually hashed and collectively signed, allowing verifiers to detect tampering with any single claim.

• Ingredient Assertions form a verifiable lineage graph
• Action Assertions capture software agent and parameter details
• Supports Identity Assertions backed by X.509 certificates

The CAI ecosystem does not rely on a single central authority. Instead, it uses a Public Key Infrastructure (PKI) based on X.509 certificates. Content creators and editors sign manifests with private keys linked to certificates issued by trusted Certificate Authorities (CAs). Verifier applications consult cryptographically signed Trust Lists—curated registries of trusted issuers, CAs, and validators—to determine if a credential is trustworthy. This model allows for multiple trust anchors, from global CAs to industry-specific consortia.

• Relies on standard X.509 certificate chains
• Trust Lists are themselves signed and versioned
• Enables domain-specific trust configurations (e.g., journalism vs. advertising)

Recognizing that hard binding is not always possible, the CAI architecture also supports soft binding. In this method, the manifest is stored externally as a sidecar file or accessed via a cloud URL. The asset is linked to its manifest through a cryptographic content hash. If an asset is screenshotted or processed by a legacy pipeline that strips embedded metadata, a cloud-based recovery service can use perceptual hashing or watermarking to re-associate the asset with its original provenance manifest, providing resilience against metadata stripping.

• Uses sidecar metadata files for legacy formats
• Enables cloud-based manifest recovery via content hashing
• Complements hard binding for a defense-in-depth strategy

The final component is the Validator Engine, the software that performs the cryptographic verification of a content credential. The verification flow is a multi-step process: it checks the integrity of each assertion by recomputing hashes, validates the digital signature against the signer's certificate, verifies the certificate chain up to a trusted root, performs a revocation check via OCSP to ensure the certificate hasn't been revoked, and confirms the signer is on the configured Trust List. This rigorous process results in a binary trustworthy/untrustworthy determination.

• Performs hash integrity checks on all assertions
• Validates full certificate chain to a trust anchor
• Executes real-time OCSP revocation checks

A structured, digitally signed statement within a C2PA manifest that makes a specific claim about the content. Each assertion is a discrete unit of provenance data.

• Creative Assertions: Claim authorship and creation date
• Action Assertions: Document edits like cropping or resizing
• Ingredient Assertions: Reference source media used in composites
• Signed by the actor who performed the action

Two strategies for attaching a provenance manifest to an asset. Hard binding embeds the manifest directly into the file's binary structure (e.g., JPEG header via JUMBF), ensuring the data travels with the file. Soft binding stores the manifest externally as a sidecar file or cloud URL, referenced by a content hash.

• Hard binding: Resilient to file copying, survives basic transfers
• Soft binding: Useful when file format constraints prevent embedding
• Both rely on cryptographic hashing for integrity

A curated, cryptographically signed list of trusted issuers, Certificate Authorities, and validators. A validator engine uses this list to determine if a content credential is trustworthy.

• Acts as a trust anchor for the verification process
• Can be maintained by industry consortia or individual organizations
• Prevents unauthorized actors from issuing seemingly valid credentials
• Enables customizable trust policies for different use cases

The software component that performs the cryptographic verification of a content credential. It checks signature validity, certificate chains, revocation status via OCSP, and trust list membership.

• Validates the entire provenance chain
• Detects any tampering with assertions or content hashes
• Returns a verifiable trust status to the user interface
• Open-source implementations available from the CAI

The complete, end-to-end sequence of cryptographically linked manifests that traces a digital asset's entire history from initial capture through all subsequent edits. Represented as a directed acyclic graph of ingredients and actions.

• Each node is a signed manifest with assertions
• Cryptographic hash chains link each version to its predecessor
• Altering any past version invalidates all downstream signatures
• Provides a verifiable edit history graph