The C2PA specification defines a vocabulary of assertions: structured statements that can appear inside a manifest and be cryptographically sealed by the surrounding claim. Some are mandatory in any valid manifest (the binding assertion linking to the asset bytes). Most are optional but used by convention. A few are custom — defined by vendors or industries to fit specific workflows. This page surveys the standard vocabulary, names the most commonly used assertion types, and explains where the schema is rigid and where it deliberately allows flexibility.
The distinction between assertion and claim is functional. An assertion is the unit of content: an actions list, an ingredient pointer, a binding hash, an EXIF block. A claim is the signed envelope around all assertions in a single manifest: a CBOR-encoded object that references each assertion by URI and hash, signed by the claim generator's certificate. A manifest contains exactly one claim and one or more assertions. The manifest structure page covers the encoding details.
The standard assertion catalog
The C2PA Technical Specification defines a core set of assertion labels under the c2pa.* namespace, plus a few standards-passthrough labels under stds.*. The most commonly used types as of 2026 are:
| Label | Purpose | Required |
|---|---|---|
c2pa.hash.data | Hard binding: hash of asset bytes | One binding required |
c2pa.hash.boxes | Hard binding for box-structured formats | Alternative binding |
c2pa.soft_binding | Soft binding via fingerprint or watermark | Optional, complementary |
c2pa.actions | List of edit actions performed | Recommended on edit |
c2pa.ingredient | Reference to a prior asset that contributed | One per ingredient |
c2pa.ai_generated | AI-generation flag and details | Required when applicable |
c2pa.training-mining | AI training and data-mining permissions | Optional |
c2pa.creative_work | Schema.org CreativeWork metadata | Optional |
c2pa.thumbnail.claim.jpeg | Embedded thumbnail of asset | Recommended |
stds.exif | Pass-through of EXIF metadata | Optional |
stds.iptc | Pass-through of IPTC metadata | Optional |
stds.schema-org | Pass-through of schema.org metadata | Optional |
Actions
The c2pa.actions assertion records edits performed in the current claim generator. Each action has an identifier and optional parameters; the identifier is drawn from a controlled vocabulary that the spec defines. The most common action identifiers are:
c2pa.created— initial creation of the assetc2pa.opened— asset opened from a previous versionc2pa.color_adjustments— color, curves, levels modifiedc2pa.cropped— image croppedc2pa.resized— image resampled to a new resolutionc2pa.filtered— non-destructive filter appliedc2pa.drawing— drawing or painting addedc2pa.placed— content from another file placed into the assetc2pa.removed— content removed (object removal, healing)c2pa.repackaged— re-encoded without semantic changec2pa.published— exported for publication
The granularity is deliberately coarse. A "color_adjustments" action does not specify which curves were moved. The spec assumes a viewer wants to know the kind of change, not the exact parameters; finer detail can be embedded in a custom assertion if a vendor cares. This is a design trade-off in favor of privacy and against detailed editorial replayability.
Ingredients
An c2pa.ingredient assertion references an earlier asset that contributed to the current one. The reference includes the ingredient's hash, format, optional thumbnail, and a pointer to its manifest if one was preserved. Ingredients are how chains form: each new manifest names its parent and binds to it cryptographically.
An ingredient can be present without its full manifest being available. In that case, the validator records a partial chain and reports that earlier provenance could not be verified. This is the normal state for files that have passed through tools that did not preserve C2PA. The ingredient assertion still records that something was there; it just can't be walked back.
Composite images carry multiple ingredients. A photo collage that uses three source photographs and a generative fill produces a manifest with four ingredient assertions, each independently validatable. Validators report per-ingredient status, allowing a consuming application to surface that one ingredient was AI-generated, another was credentialed by Reuters, and a third was an uncredentialed user upload.
AI-generation assertions
The c2pa.ai_generated assertion is the spec's response to generative AI. It indicates that some or all of the asset was produced by an AI model. The assertion includes model identification, the generator's identity, and optional fields for prompt text and training data flags. The Adobe Firefly and OpenAI image generators both emit this assertion by default in their cloud pipelines.
The assertion has refined granularity over the 2.x spec line. As of 2.4, it can indicate that the entire asset is AI-generated, that specific regions are AI-generated (with bounding boxes), or that AI was used in a non-generative capacity (upscaling, inpainting). This last distinction matters editorially: an image upscaled by AI is not the same as one generated by AI, and the spec lets the producer make the distinction in a structured way.
The training-mining assertion (c2pa.training-mining) is separate and carries permissions for AI training use. A producer can mark their asset as opted-out of generative training, opted-out of all training, or permitted. The assertion does not bind training operators legally — that depends on jurisdiction — but it does provide a machine-readable signal that compliant operators can honor. The EU AI Act's training-data transparency obligations, which intersect with this assertion, are covered on the EU AI Act page.
Identity and the producer assertion
C2PA can record the identity of the human or organization responsible for an action. The producer assertion carries name, optional contact information, and optionally a verified identity claim — a separately-signed credential from an identity provider that the C2PA signature can reference. Adobe's identity assertion uses the Adobe account; other implementations have used various federated identity providers.
Identity assertions are optional and contentious. They enable a "who took this" check in addition to "what was done to it," which is useful for editorial accountability but raises surveillance concerns. The privacy page covers the trade-off in detail. As of 2026, most consumer-facing C2PA pipelines default to including only organizational identity (the camera maker, the editing software), with personal identity off by default and opt-in.
Custom assertions
The spec allows custom assertions under namespaces other than c2pa.* and stds.*. A wire service can define com.reuters.editorial_approval with its own schema; a forensic tool can define com.forensics.ela_result. Validators handle unknown assertions by reporting their presence without interpreting them. This extensibility has been used sparingly so far — most production deployments use only the standard vocabulary — but the room is there.
The redaction protocol
Editorial workflows sometimes require removing content from a manifest — a PII field captured at the camera, a location the publisher does not want public, an internal tool name. C2PA 2.x defines a redaction protocol: a specific assertion type that records that an earlier assertion was removed, preserving the chain's validity while indicating the redaction occurred. A validator reading a redacted manifest sees that something was removed but cannot recover what.
The protocol is precise enough that auditors can distinguish authorized redaction from tampering. An assertion deleted via the redaction protocol leaves a structured trace; an assertion deleted by editing the file without the protocol breaks the claim signature. This is one of the cleaner features in the 2.x line and a model for how the spec handles tension between transparency and legitimate privacy needs.
Schema flexibility and the long tail
The standard vocabulary covers the high-volume cases. The schema-org passthrough handles editorial metadata. The EXIF and IPTC passthroughs handle camera and wire-service metadata. The custom-assertion mechanism handles the long tail. For a working implementation, the choice of which assertions to emit is more important than the choice of which fields to populate inside them: validators report whatever is there, and end users interpret a manifest by what it does and does not say.
Where the field is moving
The 2.x spec series has been adding assertion types steadily, particularly around AI generation and training data. The next set of additions, likely landing in 2026 and 2027, includes more structured assertions for live-broadcast workflows, for evidentiary chain-of-custody pipelines in legal contexts, and for human-rights-documentation use cases where C2PA might attest to capture by a trained witness. Whether these specialized assertions stabilize as standard vocabulary or remain in the custom-namespace long tail will depend on how broadly the relevant workflows adopt them.