Hard Binding

The manifest is written directly into the file's internal structure, such as a JPEG header or PNG chunk, rather than stored externally. This creates a single, self-contained asset where the provenance data and the visual content are inseparable at the binary level. The embedding leverages existing container formats like JUMBF (JPEG Universal Metadata Box Format) to store assertions, signatures, and certificate chains without corrupting the rendering of the file for non-aware parsers.

A defining advantage of hard binding is metadata stripping resistance. When a file is uploaded to social media, a CMS, or a CDN, non-essential metadata is often stripped to reduce file size. Because the manifest is embedded within a standard container format recognized as part of the file structure, it has a significantly higher probability of surviving these transformation pipelines compared to sidecar files or external URL references. This ensures provenance persists through common distribution workflows.

The embedded manifest includes all elements required for independent verification:

• Claim Signatures: Digital signatures over the assertion set, binding claims to an identity.
• X.509 Certificate Chains: The public key infrastructure needed to validate the signer's identity.
• Asset Hashes: The cryptographic fingerprint of the content itself, ensuring the binding between the manifest and the visual data is mathematically verifiable.
• Trusted Timestamps: Proof of when the signature was applied, issued by a Timestamp Authority (TSA). This self-containment eliminates dependency on external servers for validation.

Hard binding contrasts with soft binding, where the manifest is stored externally as a sidecar file or accessed via a cloud URL. While soft binding is easier to implement for legacy systems that cannot be modified to accept embedded metadata, it creates a fragile link. If the sidecar file is separated from the asset or the cloud URL becomes inaccessible, the provenance chain is broken. Hard binding eliminates this single point of failure by making the asset its own provenance carrier.

A validator engine can process a hard-bound file entirely offline. The engine:

1. Extracts the JUMBF box containing the manifest.
2. Verifies the cryptographic hash of the asset matches the hash recorded in the manifest.
3. Validates the digital signature against the embedded certificate chain.
4. Checks the certificate against a locally cached Trust List.
5. Confirms the timestamp token from the TSA. No network call is required to fetch a missing manifest, enabling verification in air-gapped or high-security environments.

Hard binding requires the target file format to support extensible metadata containers. Formats with robust support include:

• JPEG (via JUMBF boxes)
• PNG (via custom chunks)
• AVIF and HEIF (ISO base media file format)
• SVG (via structured comments or metadata elements) Formats without standardized extensibility, such as raw text files or legacy bitmap formats, cannot support hard binding and must rely on soft binding or external manifest storage. File size also increases proportionally to the size of the embedded certificate chain and assertion set.

The foundational cryptographic operation that makes hard binding verifiable. A one-way hash function (typically SHA-256) processes the asset's binary data to produce a unique, fixed-size fingerprint.

• Integrity verification: Any modification to the asset—even a single bit—produces a completely different hash, immediately exposing tampering.
• Binding mechanism: The hash is included in the signed manifest, creating an unbreakable mathematical link between the content and its provenance claims.
• Exclusion zones: During hashing, the specific byte ranges reserved for the manifest itself are excluded to avoid a circular dependency.

The property that determines whether provenance data survives common content transformation pipelines. Hard binding offers partial resistance because the manifest is inside the file, but aggressive re-encoding can still destroy it.

• Vulnerability: Platforms that transcode uploads (e.g., social media) often strip all non-essential metadata boxes, including JUMBF-embedded manifests.
• Mitigation: Combining hard binding with invisible watermarking techniques that encode provenance data directly into the perceptual content.
• Real-world impact: A C2PA-signed JPEG uploaded to a major social network typically loses its embedded manifest after server-side compression.

The complete, end-to-end sequence of cryptographically linked manifests that traces an asset's entire history. Hard binding ensures each link in this chain is physically carried by the file itself.

• Structure: Forms a directed acyclic graph where each edit action references the previous version's hash as an ingredient.
• Hard binding's role: Each version embeds its own manifest, creating a self-contained historical record that doesn't require external databases.
• Validation walk: A verifier recursively checks each manifest's signature and hash chain back to the original capture device.