Soft Binding

In soft binding, the cryptographic manifest is stored as a separate sidecar file or accessed via a cloud URL, not embedded in the asset's binary structure. The asset file contains only a content hash that serves as a pointer to the external manifest. This architecture is essential when working with file formats that lack native metadata containers or when file size constraints prohibit embedding. Common implementations store the manifest alongside the asset with a matching filename (e.g., image.jpg and image.jpg.c2pa) or reference it through a manifest store service accessible via HTTPS. The separation means the asset and its provenance data can travel independently, requiring systems to maintain the association through the hash reference.

The integrity of soft binding depends entirely on a cryptographic hash computed over the asset's binary content. This hash acts as the immutable link between the asset and its external manifest. The process works as follows:

• A SHA-256 hash of the asset is generated at the time of creation or export
• This hash is stored within the external manifest as the subject reference
• Verification involves re-hashing the asset and comparing it to the manifest's stored hash
• Any modification to the asset—even a single bit—will produce a different hash, breaking the binding This mechanism ensures that the provenance claims in the manifest can only be associated with the exact file they were generated for, preventing substitution attacks.

Soft binding is often the only viable option when integrating provenance into legacy media pipelines that strip unknown metadata. Many content management systems, transcoding services, and social media platforms aggressively remove non-essential binary data from uploaded files. By storing the manifest externally, the provenance information survives these transformations—provided the asset's visual content remains unchanged. Key scenarios include:

• Cloud-based transcoding services that re-encode video files, destroying embedded metadata
• CDN optimization pipelines that strip file headers to reduce bandwidth
• Legacy file formats without extensible metadata containers
• Streaming protocols where the complete file is never assembled in one location The trade-off is that the external manifest must be preserved and accessible through a separate storage and retrieval infrastructure.

Soft binding introduces a two-step verification process that creates a dependency on external infrastructure. To validate a soft-bound asset, a verifier must:

1. Compute the cryptographic hash of the asset file
2. Locate and retrieve the external manifest using that hash as a lookup key
3. Verify the manifest's digital signatures and certificate chain
4. Confirm that the manifest's subject hash matches the computed asset hash This chain breaks if the external manifest becomes unavailable—due to server downtime, URL rot, or storage failure. Organizations implementing soft binding must therefore invest in persistent manifest storage with high availability guarantees. The W3C PROV data model often underpins these external manifests, providing a standardized graph structure for representing entities, agents, and activities.

The choice between hard and soft binding represents a fundamental architectural decision in provenance system design:

Hard Binding

• Manifest embedded directly in the file's binary structure (e.g., JUMBF box in JPEG)
• Self-contained and portable—the provenance travels with the asset
• Survives file copying and transfers automatically
• Vulnerable to metadata stripping by transcoding pipelines
• Increases file size by the size of the manifest

Soft Binding

• Manifest stored externally, referenced by content hash
• Survives aggressive metadata stripping and re-encoding
• Requires external infrastructure for manifest storage and retrieval
• Smaller asset file size—only the hash reference is carried
• Verification fails if the external manifest is lost or inaccessible

Many production systems implement a hybrid approach, embedding the manifest where possible and falling back to soft binding for distribution channels that strip metadata.

Enterprise soft binding implementations often rely on cloud-hosted manifest services that provide persistent, scalable storage and retrieval APIs. These services function as provenance registries, accepting content hashes as lookup keys and returning the corresponding signed manifests. Key architectural considerations include:

• High availability: Manifest services must be accessible whenever verification is required, potentially for years or decades
• Global distribution: CDN-based replication ensures low-latency manifest retrieval across geographic regions
• Access control: Some implementations restrict manifest retrieval to authorized verifiers, adding a privacy layer
• Immutability guarantees: Once stored, manifests must never be altered—any update creates a new manifest version linked to a new asset hash
• API standardization: Services typically expose RESTful endpoints conforming to C2PA specifications for interoperability

The cloud manifest service becomes a critical piece of infrastructure whose availability directly impacts the verifiability of all soft-bound assets in the ecosystem.

A separate file stored alongside the primary asset that contains the provenance manifest, linked via a cryptographic hash of the asset.

• Structure: Typically a .c2pa or JSON file sharing the same base filename.
• Use Case: Essential when the original file format cannot be modified or when embedding violates operational constraints.
• Key Risk: The logical bond between the asset and sidecar can be broken if files are moved independently. Requires strict asset hashing to maintain integrity.

The process of running a digital file through a one-way cryptographic algorithm (e.g., SHA-256) to produce a unique, fixed-size fingerprint.

• Function: This hash acts as the immutable reference pointer in a soft binding scenario, connecting the external manifest to the exact binary state of the asset.
• Integrity Check: Any modification to the asset, even a single bit flip, results in a completely different hash, immediately signaling tampering or corruption.
• Role: The foundational mechanism that makes tamper-evident metadata possible.

The complete cryptographic process of validating the signatures, hashes, and certificate chains within a content credential.

• Soft Binding Validation: The verifier must first retrieve the external manifest via the cloud URL, then check that the asset's current hash matches the hash referenced in the manifest.
• Chain of Trust: Validates the claim signature against the signer's X.509 certificate, then checks the certificate against a trust list and performs a revocation check.
• Outcome: Confirms the integrity of the provenance data and the authenticity of the binding itself.

The property of a provenance system to survive common content transformation pipelines that typically remove non-essential metadata.

• The Soft Binding Problem: Social media platforms and content delivery networks routinely strip unknown metadata to optimize file size, which can sever a cloud URL reference.
• Mitigation Strategies: Combining soft binding with invisible watermarking or perceptual hashing allows re-linking a stripped asset to its original provenance record.
• Resilience Engineering: A critical design consideration when choosing between hard and soft binding for public-facing content distribution.

The JPEG Universal Metadata Box Format, a universal container framework used by C2PA to embed any type of metadata directly into file formats.

• Contrast with Soft Binding: JUMBF is the primary mechanism for hard binding, allowing the manifest to live inside the asset rather than externally.
• Structure: Organizes data into nested boxes with type identifiers, enabling multiple provenance manifests and assertions to coexist within a single file.
• Adoption: Beyond JPEG, JUMBF is extensible to PNG, SVG, AVIF, and other formats, making it the standard container for embedded content credentials.