A DeepMark's Guide to C2PA: From Manifests to Soft-Bindings

Information delivered through images or audio is often not easily verifiable, trustworthy, or transparent, and in a world drowning in content, this is a growing problem. The C2PA Standard aims to solve it, or at least, provide end-users with sufficient data to form more informed opinions about content. Founded in 2021 and guided by a global mission, this organization strives to establish standardization around transparency by inserting the history behind content creation, tracking to every piece of media that travels across the internet.

C2PA Manifests - the core building block

The C2PA specification is what makes this possible in practice, translating the organization's mission into a concrete technical format. The core building block is what's known as a manifest - simply put, a piece of content metadata containing provenance information, i.e., the data's history. A manifest can be inserted as soon as a piece of content is created, capturing information about its origin. Each time the content is edited or credentials are added, a new manifest is generated. The new manifest contains assertions - records of the changes that were made. The most recently added manifest is called the active manifest, and all manifests (active included) live in the manifest store, all within content metadata. When a new manifest is created, the previous active manifest usually becomes its ingredient (in this case, a parent) - forming a chain of provenance. There is, of course, a wide range of possible assertions and different cases of ingredients; guidance on how to include them in a manifest can be found on the C2PA Specification site.

Note: This article references the C2PA Specification version 2.4. The specification is actively evolving, with new versions released every few months.

The image above illustrates an example of manifest transformations across successive content changes, showing how provenance information evolves throughout the editing process (source: C2PA Specification).

Hard bindings for integrity

A hard binding is a cryptographic hash that ties a manifest to the exact bytes of its associated asset. Every C2PA manifest is required to have one. When the manifest is created, a hash is computed over the asset's content. This hash is stored as an assertion within the manifest and covered by the Claim Signature (described later). If even a single byte of the asset is later modified, the hash will no longer match - and validation (process of checking all claims in the manifest) will fail. In other words, a hard binding answers the question: "Is this the exact same file that was signed?" If the answer is no, the manifest is invalidated. This is how the integrity of the asset is ensured - any tampering, no matter how small, becomes immediately detectable, making the manifest tamper-evident.

Digital Signatures for Manifest Authentication

However, integrity alone is not sufficient - nothing prevents a malicious actor from creating a manifest with false assertions while claiming to be someone else. What is needed is a trusted third party that can vouch for the identity of whoever is signing the manifest. For this, C2PA relies on Public Key Infrastructure (PKI) - the same widely adopted international standard that underpins the security of the entire internet. PKI works through key pairs: a private key, known only to the signer, is used to sign data by encrypting a hash of it, while a corresponding public key, shared via the certificate, allows anyone to decrypt that hash and compare it against the original.

When a manifest is created, all of its assertions are hashed and their references are collected into a structure called the Claim. The person who writes the manifest purchases a signing certificate and public key from a trusted Certification Authority (CA), and uses it to sign the Claim. This way, anyone validating the manifest can verify not only that the content hasn't been tampered with, but also who signed it - and whether that signer is trusted within the C2PA ecosystem.

A short introduction to the C2PA Ecosystem

The twin sister of C2PA is the Content Authenticity Initiative (CAI), which was founded two years earlier and works actively alongside C2PA. One of the CAI's main contributions are open-source tools and libraries. While anyone could technically build their own tooling for working with manifests, doing so would be difficult and time-consuming, requiring compliance with numerous normative references prescribed by the C2PA specification - making CAI's open-source solutions a welcome alternative. Some of the key capabilities of the CAI libraries include tools for writing and signing manifests, validating them, and reading manifests in a human-readable format (i.e., as JSON). Creating a manifest using these libraries is straightforward - the manifest definition is written in JSON, and operations such as adding ingredients, setting assertions, and signing are handled through simple, high-level function calls. The library also takes care of the underlying complexity: generating the Claim structure, computing hard binding hashes, and producing a valid JUMBF-encoded manifest store (which is the standard format of manifests) - all of which would otherwise require deep familiarity with the specification.

Currently, the C2PA organization consists of over 6,000 members, some of which have already integrated C2PA technology into their products. Within the C2PA ecosystem, several distinct roles are defined:

- Generator Product Company - an organization that has created a Generator Product: the set of software, hardware, and platform configurations that work together to produce digital assets with C2PA manifests.

- Validator Product Company - an organization that has created a Validator Product: the system responsible for validating digital assets with C2PA manifests.

- Certification Authority (CA) — a trusted entity that issues, signs, and revokes digital certificates. CAs on the C2PA Trust List are recognized as approved issuers of claim signing certificates.

- Time-Stamping Authority (TSA) — a server that provides cryptographic proof of when a manifest was created or last modified.

- Manifest Consumer - any entity that relies on content credentials to evaluate the provenance and authenticity of digital assets.

- Relying Party - an entity that evaluates the trustworthiness of assertions made by a signer, based on the signer's identity and the assurance level.

The C2PA Conformance Program is a governance framework through which Generator Products, Validator Products, and Certification Authorities can demonstrate compliance with the specification and be placed on trusted, machine-readable lists - giving Manifest Consumers confidence that they are working with approved participants. Only Certification Authorities on the C2PA Trust List are authorized to issue claim signing certificates to Generator Products listed on the Conforming Products List. The image below illustrates the overall C2PA trust model (source: Adobe).

Soft bindings for preservation

If metadata remained attached to content as it travels across the internet, existing solutions would be sufficient. However, entirely trivial actions, such as sharing a photo on social media, taking a screenshot, or sending audio in a group chat can strip metadata as a side effect. This demands a solution where provenance information lives within the content itself. Fortunately, techniques such as watermarking and perceptual hashing provide exactly this. Watermarking embeds a fixed number of information bits directly into the content using an embedder. These bits can later be extracted by a detector. The key properties of modern watermarks are robustness to edits and imperceptibility (no perceptible difference to the human eye or ear). Perceptual hashing (also known as fingerprinting) derives a compact identifier from the content itself. Ideally, this identifier is unique to the perceptual content, meaning two visually or audibly identical assets produce the same hash, regardless of format or minor modifications. In both cases, a unique piece of information is either embedded into or derived from the content. This association makes it possible to establish a soft binding, the bridge between the content and its C2PA Manifest, linking provenance data to an asset without relying on metadata that can be stripped away.

Soft Binding Assertion

To associate a manifest with a soft binding, the relevant properties of the soft binding algorithm must be included within the manifest as assertions. The specification defines both mandatory and optional fields, giving implementors some flexibility in how much information they include, while ensuring a minimum set of required data is always present.

A soft binding assertion shall carry the label c2pa.soft-binding and contains the following structure:

-- alg (required) - the algorithm identifier, taken from the C2PA soft binding algorithm trust list

-- blocks (required) - one or more blocks, each containing:
---- value (required) - the computed soft binding value

---- scope (required) - defines what portion of the content the binding covers. If scope is empty, the binding applies to the entire asset. All fields are optional:

------ timespan - start and end time in milliseconds (for audio/video)

------ region - contains a region of interest object

-- bindingMetadata (optional) - additional info such as description, contact, or a URL about the algorithm

-- alg-params (optional) - algorithm-specific parameters

-- name (optional) - a human-readable description of what the binding covers

Actions Assertion

In addition to the c2pa.soft-binding assertion, a soft binding can also be referenced through the actions assertion. An actions assertion provides information about edits and other actions performed on the asset - each action declaring what took place and optionally when, along with details such as what software performed it. For watermark-based soft bindings specifically, the action c2pa.watermarked.bound should be used to indicate that watermarking was applied for the purpose of establishing a soft binding. (A separate action, c2pa.watermarked.unbound, exists for cases where watermarking is applied for other purposes)

Regions of Interest

As shown in the soft binding assertion structure above, the scope field within each block contains an optional region field. This region field uses the C2PA's region of interest structure - a standardized way to describe which specific portion of the asset the soft binding covers.

A region is defined by the following structure:

-- region (required) — one or more ranges, each specifying a type:

---- spatial — a physical area, described by a shape with coordinates in pixels or percentages

---- temporal — a time period, described by start and end times

---- frame — a range of frames or pages

---- textual — a range of text

---- identified — a specific media track or content item

-- name (optional) — human-readable name for the region

-- identifier (optional) — machine-readable unique identifier

-- type (optional) — from a controlled vocabulary

-- role (optional) — indicates the purpose of the region. For soft bindings, the value c2pa.watermarked.bound connects the region to the corresponding action in the actions assertion, explicitly linking the watermarked area to its soft binding purpose

-- description (optional) — human-readable description

Resolution API and Algorithm List

Since manifests can be stored across different databases maintained by different vendors and organizations, there is a need to standardize how they are discovered and retrieved. This is exactly what the Soft Bindings Resolution API specification addresses. It defines a set of routes: fetch, store, query, and service, that any API serving this purpose should implement. The API should be able to store manifests along with their corresponding soft binding values, using a store route. Given query and fetch routes, it should support retrieving manifests by manifest ID, or by content itself (i.e., performing watermark detection internally against supported algorithms). Additionally, each resolution API supports only a specific set of soft binding algorithms, which can be queried through the service route.

It is also worth noting that a Soft binding Algorithm List containing watermark and fingerprint algorithms currently registered in the C2PA ecosystem is maintained on GitHub. Anyone wishing to register an existing watermark or fingerprint algorithm in the C2PA ecosystem can do so by submitting a pull request on GitHub, following the schema described by specification. For each algorithm, the list provides its canonical name - the same identifier that appears in a resolution API's supported algorithms, but also the name that should be mentioned in the assertions described above. Furthermore, each watermark algorithm entry may include an associated soft binding URL, pointing to where manifests bound using that algorithm can be stored and queried.

Of course, in practice, the process of discovering a lost manifest can vary significantly depending on what the client already knows. The C2PA specification outlines a three-step discovery process: first, identify the technology - determine which soft binding algorithm(s) to use. This can be pre-determined by the client, derived from category tags in the Algorithm List, or discovered via a signposting watermark (a lightweight watermark embedded in the asset that identifies which other watermarks are co-present). Second, extract the soft binding by applying the identified algorithm(s)to the asset, if such technologies are available to the client. Third, determine the Resolution API endpoint. The endpoint can be listed in the Algorithm List; query it to retrieve the corresponding manifest. Additionally, if the user knows the software that signed the manifest, the Resolution API endpoint may be built directly into that software.

In the worst case, when someone looking for a lost manifest knows nothing about the soft binding or the manifest itself, one possible approach is to consult the algorithm list and iterate through each available soft binding URL, sending the content whose manifest is missing to each one until a watermark is successfully detected and the corresponding manifest is returned. A diagram illustrating this workflow for watermark-based resolution is shown below.

Where DeepMark fits

As a company deeply committed to digital security, DeepMark actively follows the development of C2PA technology, participating in relevant working group meetings, with a particular interest in the area where we hold the strongest expertise: soft bindings. Our goal is to join the official list of soft binding solutions, offering our own model for this purpose. Current neural-based audio watermarking systems typically support capacities of only 16–20 bits, making them unsuitable as identifiers for the vast quantities of digital content generated today. To address this limitation, we are developing an algorithm with a capacity of 128 bits, making it significantly more suitable for large-scale provenance and identification use cases.

At the same time, there is currently no major open-source solution focused specifically on soft-binding systems. This is precisely the gap DeepMark aims to address. We are actively building and planning to open-source a solution that includes manifest ingestion, enabling creators or platforms to declare within the C2PA manifest that a piece of audio contains a watermark, together with a soft-binding resolution API for verifying and resolving these bindings. This solution can be especially valuable for companies, organizations, or any stakeholders looking to integrate C2PA with soft-binding technologies into their workflows, providing them with a ready-to-use framework. By bridging this gap, we aim to make robust content provenance more accessible and to contribute meaningfully to a more transparent and trustworthy digital media landscape.