C2PA and Content Credentials, Explained

C2PA is an open technical standard for recording the provenance of digital content: who made it, with what tool, and what was done to it afterward. It works by binding a cryptographically signed data structure called a manifest to the file itself. The consumer-facing name for this manifest data is Content Credentials. If the file is altered after signing, verification fails, so the credential is tamper-evident by design.

That is the whole idea in three sentences. The rest of this page unpacks the organizations behind the standard, the anatomy of a manifest, and exactly how the signing and verification flows work, so you can judge where it fits in your product or content pipeline.

Who is behind C2PA

Two organizations get conflated constantly, so it is worth separating them.

The Coalition for Content Provenance and Authenticity (C2PA) is the standards body. It was formed in February 2021 and publishes the C2PA Technical Specification, the normative document that defines manifests, signing, validation, and the trust model. Its steering committee includes Adobe, Amazon, the BBC, Google, Intel, Meta, Microsoft, OpenAI, Publicis Groupe, Sony, and Truepic. Google joined the steering committee in February 2024, OpenAI in May 2024, Meta in September 2024, and Amazon after that. That roster matters: the companies that generate, edit, host, and distribute most of the world’s digital content are all at the table.

The Content Authenticity Initiative (CAI) is a broader community founded by Adobe in 2019. It promotes adoption and, critically for engineers, maintains the open-source SDKs that implement the C2PA specification: a Rust core library, plus JavaScript, Node.js, Python, C++, and mobile bindings. In short: C2PA writes the spec, CAI ships the reference tooling, and “Content Credentials” is the name of what end users actually see.

The standard is also moving into formal international standardization. The C2PA architecture is being standardized as ISO/DIS 22144, “Authenticity of information: Content Credentials”, which matters for procurement and regulatory contexts where “industry consortium spec” is not enough.

What a C2PA manifest contains

A Content Credential is not a watermark, a hash in a database, or a visible badge. It is a structured binary object, serialized in CBOR inside a JUMBF container, that travels embedded in the asset (or alongside it). Per the specification, each manifest has three core parts.

Assertions

Assertions are individual statements about the content. Each one is a discrete, digestable unit: “this action was performed,” “this is the capture device,” “these were the source ingredients,” “this content hash covers these bytes.” The spec defines a set of standard assertions, and two are required in every manifest:

An actions assertion, which records what happened: created, opened, edited, cropped, color-adjusted, converted, or, importantly, generated by an AI model (via a digitalSourceType value indicating trained algorithmic media).
A hard binding assertion, a cryptographic hash of the actual content bytes. This is what ties the manifest to this exact file rather than any file. If a single pixel changes after signing, the hash no longer matches and validation reports the asset as modified.

All assertions in a manifest are collected in a logical construct called the assertion store.

The claim

The claim is the aggregation layer: a data structure listing the assertions the signer is committing to (the spec distinguishes assertions the signer created itself from assertions it gathered from elsewhere), together with metadata about the claim generator, the software that built the manifest. The claim is what actually gets signed, which is why every assertion it references is covered by the signature.

The claim signature

The claim signature is a COSE digital signature over the claim, made with the signer’s private key and accompanied by their X.509 certificate chain. This is the trust anchor of the whole structure: it tells a validator who is vouching for these statements, and lets the validator check that the certificate chains to a recognized authority. Signatures are typically countersigned by a timestamp authority so they remain verifiable after the signing certificate expires.

Ingredients and the provenance chain

Manifests compose. When you edit a signed photo in a conforming editor and export it, the new manifest records the original as an ingredient, embedding or referencing the prior manifest. The result is a chain: capture, edit, composite, publish, each step signed by whoever performed it. A validator can walk the chain backward to the original capture or generation event. The spec also supports redaction, so a signer can remove a specific assertion (say, precise GPS location, for a photojournalist’s safety) in a way that is itself recorded, rather than silently stripping data.

How the signing flow works

Here is the end-to-end flow when content gets credentialed, step by step:

Content is created or edited. A camera captures a photo, a generative model renders an image, or an editor exports a modified file. The application doing this is the claim generator.
The application collects assertions. It records the actions performed, capture or generation details, ingredient references to any source assets, and any creator-supplied metadata.
It computes the hard binding. The application hashes the finished content bytes (excluding the region where the manifest itself will live) and writes that hash into the hard binding assertion.
It assembles the claim. All assertions go into the assertion store; the claim references each one by hashed URI, so none can be swapped out later without detection.
It signs the claim. The private key, ideally held in a secure enclave or a cloud KMS/HSM rather than on disk, produces the COSE signature. A timestamp authority countersigns. On hardware like the Leica M11-P, the first camera to ship with Content Credentials built in, this happens in a secure chipset at the moment of capture.
The manifest is embedded. The completed manifest (assertion store, claim, signature) is serialized into a JUMBF box and written into the file: as an APP11 segment in JPEG, dedicated boxes in PNG or MP4, and so on. For formats or channels that cannot carry it, the manifest can live in a sidecar file or a remote manifest repository, referenced by URL.

From then on, the file carries its own evidence.

How the verification flow works

Verification is the mirror image, and any conforming validator (the Content Credentials Verify tool, the open-source c2patool, or a library embedded in your own product) performs essentially the same checks:

Locate the manifest. The validator finds the JUMBF container in the file, or follows a reference to a sidecar or remote manifest.
Verify the signature. It checks the COSE signature over the claim using the public key in the attached certificate, and validates the certificate chain. Conforming validators check the chain against the official C2PA trust list, the curated list of certificate authorities accredited under the C2PA Conformance Program launched in 2025. A structurally valid signature from an unknown or self-signed certificate is flagged as such: intact, but not from a recognized signer.
Verify the assertions. Each assertion’s hash is checked against the claim, proving nothing in the assertion store was replaced.
Verify the hard binding. The validator re-hashes the content bytes and compares against the hard binding assertion. A match means the pixels or samples you are looking at are the ones that were signed. A mismatch means the content changed after signing.
Walk the ingredients. The validator recursively validates any embedded ingredient manifests, reconstructing the provenance chain.
Render the result. The user sees who signed the content, when, with what tool, what actions were recorded (including AI generation), and the lineage, typically behind the “CR” Content Credentials pin.

Note what verification does and does not tell you. It proves integrity (unchanged since signing) and attribution (signed by the holder of this certificate). It does not prove the content is true. A signed photo can still frame a misleading scene. C2PA gives you a reliable record of origin and handling, and leaves judgment to the consumer of that record. For how this compares to detection-based approaches, see C2PA vs watermarking.

Where Content Credentials show up today

Adoption has moved from pilots to production surfaces:

Creation tools. Adobe’s Creative Cloud applications attach Content Credentials on export, and the CAI publishes SDKs so any product can do the same.
Cameras. Leica shipped the M11-P with in-camera signing in October 2023, and other manufacturers have followed with firmware programs.
Generative AI. OpenAI adds C2PA metadata to DALL·E and ChatGPT images, and Azure OpenAI image generation does the same, so AI output self-identifies at the point of generation.
Platforms. LinkedIn and TikTok read Content Credentials to label AI-generated media (adoption overview), and the pipeline of platforms committing to display credentials keeps growing.

The honest caveat: many distribution channels still strip embedded metadata on upload, which is why the ecosystem is converging on durable Content Credentials, pairing the signed manifest with an invisible watermark and fingerprinting so provenance can be recovered even after stripping (the three pillars of provenance). We cover that failure mode, and the recovery paths, in how to verify content provenance.

Where to go from here

If you are evaluating C2PA for a product, three pages continue this pillar:

Implementing Content Credentials walks through the build: SDK selection, manifest design, signing certificates, and the gotchas that surface in real integrations.
How to verify content provenance is the operational guide to checking credentials, including the edge cases where they are missing.
C2PA vs watermarking makes the case, honestly, for when you need provenance metadata, when you need a watermark, and why most serious deployments need both.

Webisoft designs and builds C2PA and Content Credentials integrations, from manifest design to key management to verification UX, for companies that need provenance in production.