JUMBF

JUMBF defines a standardized box-based container that can encapsulate any type of metadata, regardless of its format or schema. Each box contains a type identifier, a payload, and optional label for human readability. This universal design means a single JUMBF container can simultaneously hold C2PA manifests, XML, JSON, CBOR, or proprietary binary data without conflicts. The structure is self-describing, allowing parsers to skip unknown box types while processing recognized ones.

JUMBF content is embedded directly into JPEG files using the XMP and UUID boxes defined in the JPEG standard, ensuring backward compatibility with existing image parsers. Beyond JPEG, the format is designed for file format agnosticism, with defined embedding strategies for PNG, SVG, HEIF, WebP, and AVIF. This multi-format support is critical for C2PA's goal of universal provenance across all digital media types.

JUMBF supports superboxes—containers that hold other JUMBF boxes—enabling complex hierarchical metadata structures. This nesting capability allows C2PA to organize provenance data into logical groupings:

• Assertion boxes for individual claims
• Claim boxes that group related assertions
• Manifest boxes that contain the full provenance record This hierarchical design mirrors the natural structure of provenance data, where a single asset may have multiple assertions from different actors.

JUMBF payloads are typically encoded using CBOR (Concise Binary Object Representation), a binary serialization format defined in IETF RFC 8949. CBOR provides a compact, schema-less encoding that is significantly more efficient than JSON for embedded metadata. This efficiency is critical for hard binding scenarios where the provenance manifest must fit within the file's existing metadata allocation without bloating file size. CBOR also supports deterministic encoding, essential for cryptographic hashing consistency.

JUMBF includes a description box mechanism that allows new metadata schemas to be registered and identified without modifying the core specification. Each description box contains a UUID that uniquely identifies the type of metadata being carried, along with optional versioning information. This extensibility is what allows C2PA to evolve its assertion types—adding support for new kinds of provenance claims—without breaking existing validators or requiring updates to the JUMBF specification itself.

Every JUMBF box can carry an optional UTF-8 label that provides a human-readable name for the contained metadata. This labeling system serves as a bridge between machine-parsable binary structures and human understanding, allowing debugging tools and forensic analysts to quickly identify the purpose of each box. Labels are not cryptographically significant but are invaluable for provenance inspection and validator development, making complex manifest structures navigable without decoding every binary payload.

Asset hashing generates a unique cryptographic fingerprint of the content's binary data, which is then stored within a JUMBF data hash box. This hash serves as the binding mechanism between the manifest and the actual pixels or audio samples. Common algorithms include SHA-256 and SHA-384. Any subsequent modification to the asset invalidates the hash, making tampering immediately detectable during provenance verification.

A claim signature is a digital signature generated over the entire C2PA manifest stored within the JUMBF container. It is produced using the signer's private key, typically backed by an X.509 certificate issued by a trusted Certificate Authority. The signature guarantees two properties: integrity (the manifest hasn't been altered) and non-repudiation (the signer cannot deny creating the signature).

An ingredient assertion documents source media used in creating a composite asset. Stored within the JUMBF manifest, it references the provenance chains of imported files via their cryptographic hashes. This creates a directed acyclic graph of parent-child relationships, allowing validators to trace a final image back through every layer, filter, and source photograph that contributed to it.

Soft binding stores the JUMBF manifest externally as a sidecar file or at a cloud URL, linked to the asset only by a content hash. While easier to implement when direct embedding is impossible, soft binding is fragile: the link breaks if the sidecar file is separated from the asset. It is typically used as a transitional strategy or for legacy file formats that lack JUMBF embedding points.