The Container: JUMBF

JUMBF stands for JPEG Universal Metadata Box Format. It is an ISO standard (ISO 19566-5) for embedding structured metadata inside media files. Think of JUMBF as a container inside the container: the manifest data lives in a JUMBF structure that is itself stored inside the file format's own container.

A JUMBF structure consists of boxes. Each box has a type label and a content payload. Boxes can be nested - a JUMBF box can contain other JUMBF boxes. The C2PA specification defines a specific JUMBF hierarchy for manifests:

• A top-level JUMBF box labeled as a C2PA manifest store
• One or more manifest boxes within the store (for content with history)
• Within each manifest: claim, signature, and assertion boxes

The manifest store can contain multiple manifests, representing a content history. An image edited by multiple parties might carry a manifest store with the original creator's manifest and a subsequent editor's manifest. Each manifest extends the history without replacing prior manifests.

The Signature: COSE

COSE stands for CBOR Object Signing and Encryption (RFC 8152). CBOR is a binary data format similar to JSON but more compact. COSE defines how CBOR objects are cryptographically signed. C2PA uses COSE_Sign1 (a single-signer signature format) to sign the manifest claim.

The COSE signature contains:

• The protected header (signature algorithm, certificate chain)
• The unprotected header (additional metadata that is not signed)
• The payload (the signed claim data)
• The signature bytes (the cryptographic signature)

The protected header includes the signer's X.509 certificate chain. This is what allows verification to establish identity: the certificate chain traces back to a Certificate Authority that vouches for the signer's identity. If you trust the CA, you can trust the signer's identity in the manifest.

The Claim

The claim is the central assertion in a C2PA manifest. It is a CBOR-serialized data structure that records what the signer is asserting about the content at the time of signing. The COSE signature covers the claim, so the claim is tamper-evident: any modification to the claim after signing breaks the signature.

The claim includes:

• The content hash (SHA-256 of the signed content, or of a specific data segment)
• References to assertion boxes (which assertions belong to this claim)
• The claim generator identifier (which software created this manifest)
• A timestamp (when the claim was created)

The content hash is the link between the manifest and the content. If the content changes after the manifest is created, the hash in the claim no longer matches the content hash, and verification reports a mismatch. This is the tamper detection mechanism.

Assertions

Assertions are specific claims about the content. They are separate JUMBF boxes within the manifest that are referenced by the claim. The claim's reference list includes a hash of each assertion, so the assertions are also tamper-evident: modifying an assertion changes its hash and breaks the claim's reference.

Common assertion types in C2PA manifests:

The Certificate Chain

The certificate chain in the COSE protected header establishes signer identity. The chain follows the X.509 certificate standard: a leaf certificate identifying the signer, signed by an intermediate certificate, signed by a root Certificate Authority (CA).

When verifying, the verifier checks:

1. The leaf certificate is signed by the intermediate
2. The intermediate is signed by the root CA
3. The root CA is trusted (in the verifier's trust anchor list)
4. None of the certificates have been revoked
5. The certificates were valid at the time of signing (timestamp check)

For Encypher-signed content, the leaf certificate identifies the publisher (or Encypher on behalf of the publisher). The intermediate and root CAs are operated by a trusted Certificate Authority. Enterprise customers with BYOK can use their own certificate infrastructure.

Ingredient Lists

When content is created from other signed content - an edited image derived from an original, a document that incorporates a signed image - the manifest can include an ingredient list. Each ingredient references another C2PA-signed asset and records how it was used.

This creates provenance chains: the derivative content's manifest proves it was derived from specific signed originals. For editorial workflows where images are cropped, color-corrected, or composed into layouts, the ingredient list documents the full lineage.

The Encypher API supports ingredient relationships in signing requests. The /sign/media endpoint accepts ingredient identifiers that reference previously signed assets. The resulting manifest includes the ingredient relationships in accordance with the C2PA specification.

What a Verification Result Looks Like

When you verify a C2PA-signed file, the output maps directly to the manifest structure described above: