C2PA Explainer

Provenance generally refers to the facts about the history of a piece of digital content assets (image, video, audio recording, document). Content Credentials enables the authors of provenance data to securely bind statements of provenance data to instances of content using their unique credentials. These provenance statements are called assertions in a Content Credential. They may include assertions about who created the content and how, when, and where it was created. They may also include assertions about when and how it was edited throughout its life. The content author, and publisher (if authoring provenance data) always has control over whether to include provenance data as well as what assertions are included, such as whether to include identifying information (in order to allow for anonymous or pseudonymous assets). Included assertions can be removed in later edits without invalidating or removing all of the included provenance data in a process called redaction.

The provenance data and the asset are the two parts of the same puzzle - a unique puzzle. The possibility of any other pieces ever matching, either by coincidence or by a purposeful attempt to generate a match, is so low that it would be practically impossible. In other words, any alteration to either the asset or the provenance, however insignificant, would alter the mathematical algorithm - the shape of the piece of the puzzle - in such a way that they would no longer match.

We refer to this as a hard binding. For more technical information on this see "hard binding" in the glossary and the non-normative guidance.

When one asset is created from a series of other assets, those sources are referred to as the ingredients. Each ingredient that is used in the (composed) asset is recorded in that asset’s provenance, including the addition of the provenance of each individual ingredient. This process creates a chain of provenance that can stretch all the way back to each ingredient’s creation.

Redaction is the process of permanently removing information. In the world of Content Credentials it specifically refers to removing assertions.

For example, if a human rights organization wishes to remove assertions about the photographer from an image, it can do so via the redaction process. The act of redaction (and the optional inclusion of a reason for that redaction) becomes part of the provenance of the asset.

No. Provenance is not always complete. It may happen that an asset is modified in a way that the provenance data is not updated. For example, if an asset is cropped using a non-Content Credentials aware tool, the provenance data may not be updated to reflect that action. However, if the asset is then brought back into a Content Credentials-aware tool for additional modification or preparation for publication, the actor responsible for signing the new Content Credentials also implicitly attests to the crop action. So even though there is missing provenance information, the asset can still be trusted based on the signer of the active Content Credential.

With Content Credentials, trust decisions are made by the consumer of the asset based on the identity of the actor(s) who signed the provenance data along with the information in the assertions contained in the provenance. This signing takes place at each significant moment in an asset’s life (e.g., creation, editing, etc.) through the use of the actor’s unique credentials and ensures that the provenance data remains cryptographically bound to the newly created or updated asset.

To enable consumers to make informed decisions about the provenance of an asset, and prevent unknown attackers from impersonating others, it is critical that each application and ecosystem reliably identify the actor to whom a signing credential (also known as a digital certificate) is issued. A certification authority (CA) performs this real-world due diligence to ensure signing credentials are only issued to actors who are whom they claim to be.

In the world wide web, CAs verify that someone requesting a certificate to operate a secure web site owns and/or controls the site’s domain name before issuing such a credential. For example, before issuing a certificate for https://c2pa.org/, the CA verified the requester did in fact control C2PA’s domain name before issuing a certificate for that site name. Unlike the world wide web, Content Credentials will be used in multiple different application settings, and each setting will have its own requirements. Each application will therefore provide users with one or more trust lists, which are lists of certification authorities that issue signing credentials for that application.

Once the signing credential is issued by a certification authority, the identity it has confirmed and placed in that credential cannot be altered by anyone else, including and especially the credential’s owner. This allows the consumer or user to rely upon the identity presented in a signed asset.

No. Adding provenance to an asset is optional, and it is not the intention of the specification and guidance to create a two-tier media ecosystem where assets without Content Credentials are universally less trusted than assets with it. The C2PA Specifications for Content Credentials is open and available to everyone, and so no assumption should be made about the trustworthiness of a particular asset or signer purely based on their usage of Content Credentials.

Content Credentials becomes useful to users when they can use the data and the signer’s identity to build a trust relationship with that signer. For example, if a well-known media publisher adds provenance data to an asset and signs it, a consumer that knows that publisher can use Content Credentials to understand that the asset and its provenance data definitely came from them, and wasn’t manipulated. Conversely, if a bad or unknown actor adds provenance data and signs it, a consumer would see the actor’s identity, and then make their own decision on whether to trust the asset and the provenance data.

Each ingredient that is included in a Content Credential can include its own provenance data, specifically its Content Credential is also included in the asset’s full set of Content Credentials. However, while the provenance data of each ingredient may be present, the ingredient’s provenance cannot be verified in the same way as the provenance data of the asset in which it is contained. This is because the actual data of the ingredient is not usually included in the asset’s Content Credential. Without the actual data, the ingredient’s hard bindings cannot be verified.

Each action that is performed on an asset is recorded in the asset’s Content Credentials. These actions can be performed by a human or by an AI/ML system. When an action was performed by an AI/ML system, it is clearly identified as such through it’s digitalSourceType field.

Yes. A Content Credential can include a Training and Data Mining assertion that can be used to indicate that the asset should not be used for either training or data mining purposes. The assertion is flexible and allows the author of the asset to specify whether each type of process - data mining, general AI training, or training specific to generative AI - is permitted, or not.