How C2PA Content Credentials Work: Technical Architecture Deep Dive

The Coalition for Content Provenance and Authenticity (C2PA) specification defines a system for embedding cryptographically signed provenance metadata directly into media files. Unlike EXIF data, which can be trivially edited or stripped, C2PA Content Credentials are bound to the asset's binary content through cryptographic hashes and signed by X.509 certificates with verifiable trust chains. This article walks through the full technical architecture — from the on-disk container format through to the validation pipeline that a verifier like AttestTrail implements.

If you are looking for a higher-level explanation first, start with What is C2PA?. This page is the technical companion focused on architecture and verification flow.

C2PA architecture diagram

The diagram below shows the basic C2PA verification flow from signed asset to trust decision:

That is the core architecture in operational terms: embedded manifests, cryptographic verification, then a separate trust decision layered on top. The rest of this guide breaks down each component in detail.

The JUMBF Container Format

C2PA data is stored inside media files using the JUMBF (JPEG Universal Metadata Box Format) container, defined in ISO 19566-5. JUMBF provides a typed, hierarchical box structure that can be embedded within JPEG, PNG, TIFF, WebP, AVIF, and other file formats without disrupting the host format's parsers.

Each JUMBF box consists of a description box (specifying the box type via a UUID and an optional label) followed by one or more content boxes. For C2PA, the top-level JUMBF superbox uses the UUID d8fec3d6-1b0e-483c-9297-58d1c78c63e0 and carries the label c2pa. Inside this superbox, each manifest is stored as a labeled child box.

The embedding location varies by format. In JPEG files, the JUMBF data is stored in APP11 marker segments. In PNG, it sits in a caBX chunk. For ISO Base Media File Format containers (MP4, HEIF), it occupies a top-level uuid box. The key design constraint is that the JUMBF data must be insertable and extractable without re-encoding the host media — provenance metadata should survive lossless round-trips.

Manifest Structure

A C2PA manifest store contains one or more manifests. Each manifest represents a signed assertion about the asset at a specific point in its lifecycle. The active manifest describes the current state; ingredient manifests describe prior states from upstream in the editing chain.

A single manifest contains four primary components:

Claim

The claim is the central data structure. It references all assertions by their JUMBF URIs, specifies the claim generator (the software that created the manifest), and declares the hash algorithm used for binding. The claim itself is a CBOR-encoded data structure (not JSON — CBOR is used for its canonical encoding properties, which matter for signature stability).

A simplified representation of a claim's logical structure:

{
  "dc:title": "IMG_2847.jpg",
  "dc:format": "image/jpeg",
  "claim_generator": "Adobe Photoshop 26.4.1/c2pa-rs 0.36.1",
  "claim_generator_info": [
    {
      "name": "Adobe Photoshop",
      "version": "26.4.1"
    }
  ],
  "signature_ref": "self#jumbf=c2pa.signature",
  "assertions": [
    {
      "url": "self#jumbf=c2pa.assertions/c2pa.actions",
      "hash": "sha256:b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c"
    },
    {
      "url": "self#jumbf=c2pa.assertions/c2pa.hash.data",
      "hash": "sha256:7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730"
    },
    {
      "url": "self#jumbf=c2pa.assertions/c2pa.ingredient",
      "hash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
    }
  ]
}

Note that each assertion reference includes a hash. This means tampering with any individual assertion invalidates the claim, which in turn invalidates the signature over the claim. The entire structure is a Merkle-like commitment: the signature covers the claim, and the claim commits to every assertion by hash.

Claim Generator

The claim_generator field identifies the software that produced the manifest. This is a free-text string, typically including the application name and version plus the C2PA library version. The claim generator is informational — it is not independently verified, but it is covered by the signature, so it cannot be altered after signing without detection.

Assertions

Assertions are the payload of a manifest — they carry the actual provenance information. Each assertion has a label (a namespaced string) and a data payload. The C2PA specification defines several standard assertion types:

c2pa.actions — Records what operations were performed on the asset. Each action entry includes an action type (from a controlled vocabulary: c2pa.created, c2pa.edited, c2pa.published, c2pa.resized, c2pa.cropped, c2pa.transcoded, among others), a softwareAgent identifying the tool, and an optional timestamp.

c2pa.ingredient — References a source asset that was used as input. Ingredients can carry their own manifest (enabling provenance chains) or reference an external manifest store by hash. Each ingredient includes the source asset's hash, title, format, and relationship type (e.g., parentOf, componentOf).

c2pa.hash.data — The hard binding assertion. Contains the hash of the asset's binary data, used to detect any modification to the media content after signing.

c2pa.thumbnail.* — An embedded thumbnail of the asset at the time of signing, providing a visual reference for what was signed even if the full asset is unavailable.

stds.schema-org.CreativeWork — Carries structured metadata following Schema.org conventions: author name, copyright, licensing information.

IPTC Digital Source Type — Declares the origin of the content using IPTC NewsCodes vocabulary. Values include trainedAlgorithmicMedia (AI-generated), digitalCapture (camera), compositeSynthetic (composite with AI elements), and others. This assertion is critical for moderation pipelines — it is the primary signal for distinguishing AI-generated content from camera captures.

Claim Signature

The claim signature is a COSE Sign1 structure (CBOR Object Signing and Encryption, RFC 9052) containing the digital signature over the serialized claim. The signature is produced using the private key of an X.509 certificate and can be verified using the corresponding public key from the certificate chain embedded in the COSE structure.

Hard Bindings and Soft Bindings

The relationship between a manifest and the asset it describes is established through hash bindings.

Hard bindings hash the entire asset file (excluding the JUMBF metadata region itself). The c2pa.hash.data assertion specifies the hash algorithm, the byte ranges to include, and the expected digest. When a verifier processes the asset, it computes the hash over the same byte ranges and compares it to the value in the assertion. Any modification to the image data — even a single bit flip — produces a different hash and the binding fails.

The exclusion ranges are critical. Because the JUMBF data is embedded within the file, the hash must skip over the bytes occupied by the manifest store. The claim specifies these exclusion ranges precisely so that the verifier can reconstruct the same hash.

Soft bindings provide a weaker but more resilient form of binding. Instead of hashing raw bytes, a soft binding uses a perceptual hash or a content-derived fingerprint that tolerates certain transformations (format conversion, mild recompression). The C2PA specification supports soft bindings but they are less commonly implemented by signers today. Most production implementations rely on hard bindings, accepting the tradeoff that any re-encoding will invalidate the binding.

X.509 Certificate Signing

C2PA uses standard X.509 public key infrastructure for signing. The signer holds a private key associated with an X.509 certificate. The certificate chain — from the end-entity certificate through intermediates to a root CA — is embedded in the COSE Sign1 structure's unprotected headers.

The signing process works as follows:

1. •The claim is serialized to canonical CBOR.
2. •A COSE Sign1 structure is constructed with the serialized claim as the payload.
3. •The structure is signed using the signer's private key (typically ECDSA P-256, P-384, or Ed25519).
4. •The certificate chain is included in the COSE headers.
5. •An OCSP (Online Certificate Status Protocol) response is stapled to prove the certificate was not revoked at the time of signing.
6. •A countersignature from a trusted timestamp authority (TSA) is included, establishing a verifiable signing time independent of the signer's clock.

The timestamp authority countersignature is important because it establishes when the signature was created, even if the signer's own certificate later expires or is revoked. As long as the certificate was valid at the timestamp authority's recorded time, the signature remains valid.

The Validation Pipeline

When an application like AttestTrail's C2PA Viewer or verification API receives an image for validation, it executes the following steps:

1. Parse JUMBF

The verifier locates the JUMBF superbox within the file. For JPEG, this means scanning APP11 markers; for PNG, finding the caBX chunk. If no JUMBF data is found, the asset has no C2PA provenance — validation terminates with an "absent" status.

2. Extract Manifest Store

The JUMBF superbox is parsed into its component manifests. The active manifest is identified (it is the last manifest in the store, per the specification). Ingredient manifests referenced by the active manifest are also extracted.

3. Verify Claim Signature

The COSE Sign1 structure in the active manifest's signature box is parsed. The verifier extracts the certificate chain from the COSE headers and verifies the signature over the claim payload using the end-entity certificate's public key.

4. Validate Certificate Chain

The certificate chain is validated from the end-entity certificate up through intermediates. The verifier checks: certificate expiry dates (considering the TSA timestamp, not the current time), basic constraints, key usage extensions, and revocation status via the stapled OCSP response. If an OCSP response is missing or stale, the verifier may attempt to fetch a fresh one, though many implementations treat a missing OCSP response as a non-fatal warning rather than a hard failure.

5. Verify Hard Binding

The verifier computes the hash of the asset data using the algorithm and byte ranges specified in the c2pa.hash.data assertion. The computed hash is compared to the stored hash. A mismatch means the asset has been modified after signing — the provenance data does not describe the current content.

6. Validate Assertion Hashes

Each assertion referenced in the claim includes a hash. The verifier independently hashes each assertion's JUMBF box content and compares it to the hash recorded in the claim. This ensures no assertion has been tampered with independently of the claim.

7. Evaluate Assertions

With structural integrity confirmed, the verifier reads the assertion contents to extract provenance information: what actions were taken, what software was used, what the digital source type is, and whether ingredient manifests establish an editing history.

Trust List Validation

Signature validation and trust validation are distinct steps. A manifest can have a perfectly valid cryptographic signature — correct hash bindings, valid certificate chain, unexpired certificates — and still not be trusted. Trust depends on whether the signer's certificate (or its issuing CA) appears on a trust list maintained by the verifier.

The C2PA specification defines a trust list format, but each verifier can maintain its own. For example, a news organization might trust only certificates issued to camera manufacturers and established news agencies. A social media platform might maintain a broader trust list that includes AI generation tools like Adobe Firefly and OpenAI's DALL-E.

AttestTrail's API implements a curated trust list that maps signers to signer types (camera manufacturer, AI generator, editing software, news organization). The trust decision — trusted, untrusted, or unknown — is returned alongside the cryptographic validation result, enabling downstream moderation logic to treat these signals differently.

Ingredient Manifests and Provenance Chains

One of C2PA's most powerful features is the ability to chain manifests across editing steps. When Adobe Firefly generates an image, it signs a manifest with a c2pa.created action and an IPTC digital source type of trainedAlgorithmicMedia. When that image is opened in Photoshop, Photoshop creates a new manifest with the Firefly-signed image as an ingredient. The new manifest records c2pa.edited actions, and the Firefly manifest is embedded as an ingredient manifest in the store.

This chain can extend through multiple tools. A photographer captures an image on a Leica M11-P (which signs at the hardware level), imports it into Lightroom (new manifest, ingredient references the camera manifest), exports and uploads to a wire service (another manifest link). Each step is independently signed and independently verifiable.

The verifier walks the ingredient chain, validating each manifest independently. A break anywhere in the chain — an unsigned intermediate step, a failed hash binding on an ingredient — is reported but does not necessarily invalidate the active manifest's own signature. The active manifest's integrity is self-contained; ingredient validation provides additional provenance depth.

Limitations and Edge Cases

C2PA's design is robust, but several practical limitations exist:

Re-encoding strips manifests. If an image is decoded and re-encoded (e.g., opened in a tool that does not support C2PA and saved), the JUMBF data is lost. The hard binding hash also becomes invalid because the binary content changes. This is the most common way provenance is lost in practice.

Screenshots break provenance. Taking a screenshot of a C2PA-signed image produces a new file with no manifest. The screenshot tool has no awareness of the original file's embedded metadata.

Social media and messaging platforms strip metadata. Most platforms re-encode uploaded images for optimization and strip all metadata in the process. Some platforms (notably LinkedIn and Truepic-integrated services) are beginning to preserve or re-sign C2PA data, but the majority do not as of early 2026.

Fingerprint recall as a mitigation. To address metadata stripping, the C2PA ecosystem supports fingerprint-based recall: before an image's metadata is stripped, a perceptual fingerprint is stored in a lookup service. When a stripped image is encountered later, its fingerprint can be computed and matched against the database to recover the original provenance. This is a complementary system, not part of the core C2PA specification, but it is increasingly deployed alongside C2PA verification.

No assertion content verification. C2PA guarantees that assertions have not been tampered with after signing, but it does not verify that the assertions are truthful. A malicious signer with a valid certificate could sign a manifest claiming a digital source type of digitalCapture for an AI-generated image. Trust list curation is the primary defense here — only certificates from reputable signers should be trusted.

File format support is not universal. While C2PA supports JPEG, PNG, TIFF, WebP, AVIF, MP4, and several other formats, some formats (GIF, BMP, SVG) have no defined JUMBF embedding. Content in unsupported formats cannot carry C2PA provenance.

Conclusion

C2PA Content Credentials represent the most comprehensive standard for media provenance available today. The architecture — JUMBF containers, CBOR-encoded claims, COSE signatures, X.509 trust chains, and hash-based bindings — provides a layered defense against tampering while maintaining compatibility with existing media formats and workflows. The AttestTrail verification API implements the full validation pipeline described here, and the C2PA Viewer provides an interactive way to inspect manifests in any supported image.

Understanding the technical underpinnings is essential for anyone building systems that consume provenance data — whether for content moderation, editorial verification, or regulatory compliance. The latest published specification is available from the C2PA technical working group and is worth reading in full.