C2PA Technical Specification

With the increasing velocity of digital content and the increasing availability of powerful creation and editing techniques, establishing the provenance of media is critical to ensure transparency, understanding, and ultimately, trust.

We are witnessing extraordinary challenges to trust in media. As social platforms amplify the reach and influence of certain content via ever more complex and opaque algorithms, mis-attributed and mis-contextualized content spreads quickly. Whether inadvertent misinformation or deliberate deception via disinformation, inauthentic content is on the rise.

Currently, creators who wish to include metadata about their work (for example, authorship) cannot do so in a secure, tamper-evident and standardized way across platforms. Without this attribution information, publishers and consumers lack critical context for determining the authenticity of media.

Provenance empowers content creators and editors, regardless of their geographic location or degree of access to technology, to disclose information about who created or changed an asset, what was changed and how it was changed. Content with provenance provides indicators of authenticity so that consumers can have awareness of who has altered content and what exactly has been changed. This ability to provide provenance for creators, publishers and consumers is essential to facilitating trust online.

To address this issue at scale for publishers, creators and consumers, the Coalition for Content Provenance and Authenticity (C2PA) has developed this technical specification for providing content provenance and authenticity. It is designed to enable global, opt-in, adoption of digital provenance techniques through the creation of a rich ecosystem of digital provenance enabled applications for a wide range of individuals and organizations while meeting appropriate security requirements.

This specification has been, and continues to be, informed by scenarios, workflows and requirements gathered from industry experts and partner organizations, including the Project Origin Alliance and the Content Authenticity Initiative (CAI). It is also possible that regulatory bodies and governmental agencies could utilize this specification to establish standards for digital provenance.

This specification describes the technical aspects of the C2PA architecture; a model for storing and accessing cryptographically verifiable information whose trustworthiness can be assessed based on a defined trust model. Included in this document is information about how to create and process a C2PA Manifest and its components, including the use of digital signature technology for enabling tamper-evidence as well as establishing trust.

Prior to developing this specification, the C2PA created our Guiding Principles that enabled us to remain focused on ensuring that the specification can be used in ways that respect privacy and personal control of data with a critical eye toward potential abuse and misuse. For example, the creators and publishers of the media assets always have control over whether provenance data is included as well as what specific pieces of data are included.

It is important that the specification does not negatively impact content accessibility for consumers.

Other documents from the C2PA will address specific implementation considerations such as expected user experiences and details of our threat and harms modelling.

The C2PA information comprises a series of statements that cover areas such as asset creation, authorship, edit actions, capture device details, bindings to content and many other subjects. These statements, called Assertions, make up the provenance of a given asset and represent a series of trust signals that can be used by a human to improve their view of trustworthiness concerning the asset. Assertions are wrapped up with additional information into a digitally signed entity called a Claim.

The W3C Verifiable Credentials of individual actors that are involved in the creation of the assertions can be added to the C2PA information to provide additional trust signals to the process of assessing trustworthiness of the asset.

These assertions, claims, credentials and signatures are all bound together into a verifiable unit called a C2PA Manifest by a hardware or software component called a Claim Generator. The set of C2PA Manifests, as stored in the asset’s C2PA Manifest Store, represent its provenance data.

The basis of making trust decisions in C2PA, our Trust Model, is the identity of the actor associated with the cryptographic signing key used to sign the claim in the Active Manifest. The identity of a signatory is not necessarily a human actor, and the identity presented may be a pseudonym, completely anonymous, or pertain to a service or trusted hardware device with its own identity, including an application running inside such a service or trusted hardware. C2PA Manifests can be validated indefinitely regardless of whether the cryptographic credentials used to sign its contents are later expired or revoked.

A very common scenario will be a user (called an actor in the C2PA ecosystem) taking a photograph with their C2PA-enabled camera (or phone). In that instance, the camera would create a manifest containing some such assertions including information about the camera itself, a thumbnail of the image and some cryptographic hashes that bind the photograph to the manifest. These assertions would then be listed in the Claim, which would be digitally signed and then the entire manifest would be embedded into the output JPEG. This manifest would remain valid indefinitely.

A Manifest Consumer, such as a C2PA Validator, could help users to establish the trustworthiness of the asset by first validating the digital signature and its associated credential. It can also check each of the assertions for validity and present the information contained in them, and the signature, to the user in a way that they can then make an informed decision about the trustworthiness of the digital content.

In the creation of the C2PA architecture, it was important to establish some clear goals for the work to ensure that the technology was usable across a wide spectrum of hardware and software implementations worldwide and accessible to all.

This image shows how all these various elements come together to represent the C2PA architecture.

It is expected that each of the actors in the system that creates or processes an asset will produce one or more assertions about when, where, and how the asset was originated or transformed. An assertion is labelled data, typically (though not required to be) in a CBOR-based structure which represents a declaration made by an actor about an asset. Some of these actors will be human and add human-generated information (e.g., copyright) while other actors are machines (software/hardware) providing the information they generated (e.g., camera type).

Some examples of assertions are:

Certain assertions may be redacted by subsequent claims (see Section 6.7, “Redaction of Assertions”), but they cannot be modified once made as part of a claim.

Each assertion has a label defined either by the C2PA specifications or an external entity.

Labels are string values organized into namespaces using a period (.) as a separator. The namespace component of the label can be an entity, or a reference to a well-established standard (see ABNF below). The most common labels will be defined by the C2PA and will begin with c2pa.. Entity-specific labels shall begin with the Internet domain name for the entity similar to how Java packages are defined (e.g., com.litware, net.fineartschool). Well-established standards can use the "stds." prefix when describing their namespace. They are also versioned with a simple incrementing integer scheme (e.g., c2pa.actions.v2). If no version is provided, it is considered as v1. The list of publicly known labels can be found in Chapter 19, C2PA Standard Assertions.

The period-separated components of a label follow the variable naming convention ([a-zA-Z_][a-zA-Z0-9_]*) specified in the POSIX or C locale, with the restriction that the use of a repeated underscore character (__) is reserved for labelling multiple assertions of the same type.

When an assertion’s schema is changed, it should be done in a backwards-compatible manner. This means that new fields may be added and existing ones may be marked as deprecated (i.e., can be read, but never written). Existing fields shall not be removed. The label would then consist of an incremented version number, for example moving from c2pa.hash.bmff (deprecated) to c2pa.hash.bmff.v2.

Since the addition of optional fields can be done while maintaining backwards compatibility, such fields may be added to an existing assertion’s schema without a change to the version number.

Deprecated fields for C2PA standard assertions shall be indicated in Chapter 19, C2PA Standard Assertions. Tools which enable actors to create assertions shall prevent the actor from inserting data into deprecated assertion fields.

In addition, there are situations where a non-backwards compatible change is required. In that case, instead of increasing the label’s version number, the assertion shall be given a new label. For example, c2pa.ingredient could be changed to the fictional c2pa.component.

Multiple assertions of the same type can occur in the same manifest, but since assertions are referenced by claims via their label, the assertion labels must be unique. This is accomplished by adding a double-underscore and a monotonically increasing index to the label. For example, if a manifest contains a single assertion of type stds.schema-org.CreativeWork, then the assertion label will be stds.schema-org.CreativeWork. If a manifest contains three assertions of this type, the labels will be stds.schema-org.CreativeWork, stds.schema-org.CreativeWork__1 and stds.schema-org.CreativeWork__2.

When a label includes a version number, that version number is part of the label itself. As such, when there are multiple instances, the instance number continues to follow the label - e.g., c2pa.ingredient.v2__2.

The set of assertions referenced by a claim in a manifest are collected together into a logical construct that is referred to as the assertion store. The assertions and assertion store shall be stored as described in Section 12.1, “Use of JUMBF”; in particular, the assertion store shall be located in the same C2PA Manifest box as the claim that refers to its assertions.

For each manifest, there is a single assertion store associated with it. However, as an asset may have multiple manifests associated with it, each one representing a specific series of assertions, there may be multiple assertion stores associated with an asset.

Some assertion data, due to its size or an infrequent need for it, may be externally hosted. Such data are not embedded in the assertion store, but instead are referenced by URI. This is accomplished through a cloud data assertion (see Section 19.10, “Cloud Data”). Unlike embedded assertion data, cloud data is not retrieved nor validated as part of manifest validation, and are only retrieved and validated when specifically needed by an application according to a different set of validation rules as described in Section 16.7, “Validate the Assertions”.

Assertions that are present in an asset-embedded manifest may be removed from that asset’s manifest when the asset is used as an ingredient. This process is called redaction.

Redaction involves removing either the entire assertion from the manifest’s assertion store or retaining the labelled assertion container but replacing its data with zeros (binary \0 values). In addition, a record that something was removed must be added to the claim in the form of a URI reference to the redaction assertion in the redacted_assertions field of the claim. It is also strongly recommended that the claim generator should add a c2pa.redaction action assertion with a redacted field as described in Section 19.12.2, “Parameters”.

Unless the redaction of the assertion also requires modification to the digital content, an update manifest shall be used to document the redaction as it makes a statement about the non-changes to the content.

Claims generators shall not redact assertions with a label of c2pa.actions as this assertion type represents essential information in understanding the history of an asset.

The schema for this type is defined by the data-box-map rule in the following CDDL Definition:

When an asset contains embedded XMP, that XMP shall include (at least) values for xmpMM:DocumentID and xmpMM:InstanceID as defined in XMP Specification Part 2, 2.2. If an asset does not contain XMP at the time a claim is made, and the type of the asset supports it, an embedded XMP packet may be created as part of the process, and the identifiers shall be added to it.

Instead of using XMP, a unique identifier for an asset could be a URI defined by standards such as Decentralized Identifiers (DID), Handle, EIDR and DOI.

Another standard unique identifier for an asset could be the cryptographic hash of the asset. When this method is used, the hash shall be represented using a standard RFC 4122 UUID following the recommendations at https://datatracker.ietf.org/doc/html/draft-thiemann-hash-urn-01 .

All references to information in the manifest, whether stored internally to the asset (i.e., embedded) or stored externally to the asset (e.g., in the cloud), shall be referenced via JUMBF URI references as defined in ISO 19566-5, C.2. These URIs shall be used either as part of a hashed_uri or hashed_ext_uri data structure.

In some use cases, the actors in the system may wish to provide their own W3C Verifiable Credential, as they exist at that moment in time, to the claim generator to have them associated with one or more assertions. These actors may be individuals, groups or organizations.

W3C Verifiable Credentials are used in this specification to decorate the actors identified in assertions with more information, potentially providing additional trust signals. Although these W3C Verifiable Credentials can include proofs of their own authenticity, they are not a mechanism for verifying that a particular actor authorised a claim, assertion or piece of metadata. Any validation or usage of the W3C Verifiable Credential is out of scope of this specification and has no bearing on the C2PA Trust Model.

For example, conveying a W3C Verifiable Credential for the actor identified as the author in an assertion might link that author’s ID with an email address, social media ID, or real name, or it might identify that actor as a member of a particular professional body, or provide other qualifications relevant to the actor’s involvement in the asset.

Such credentials shall be compliant with the W3C Verifiable Credentials Data Model using the JSON-LD serialisation described there.

An example of a compliant credential for an individual might be one issued by the National Press Photographers Association (NPPA), which links an identifier for a person to their name ("John Doe") and a statement about their membership of the NPPA. It might look like:

A W3C Verifiable Credential used with C2PA shall contain only a single credentialSubject and that credentialSubject shall have an id value.

The set of credentials in a manifest are collected together into a logical construct that is referred to as the credential store or VCStore (for short) and it shall be stored as described in Section 12.1, “Use of JUMBF”. Just as with the assertion store, the VCStore shall always be included/embedded in the JUMBF - it is not stored separately.

For each manifest, there is a VCStore associated with it. However, as an asset may have multiple manifests associated with it, there may be multiple VCStores associated with an asset.

Some assertions, such as Creative Work and Actions, may contain references to Persons or Organisations which are responsible for various roles and responsibilities. These references to Actors are defined in [_common_data_model_actor].

In most W3C Verifiable Credential workflows, the information about the subject (e.g., the cryptographic keys) is fetched on demand at the time of validation. While that is an acceptable model, it does open up a possible attack vector by providing an attacker with an externally-visible signal about what the validator is validating. Therefore, C2PA also supports having the information captured and embedded at the time of signature. This not only prevents leakage, but also makes it very clear what data the signer is asserting about the credential’s subject.

Since a W3C Verifiable Credential can contain personally identifiable information, there may be workflows where it is necessary to remove/redact a W3C Verifiable Credential from the VCStore. To redact a W3C Verifiable Credential, a claim generator shall overwrite the contents of the credential in the W3C Credential Store with all zeroes, just as one would when redacting an assertion, however, doing only that will cause validation failures later on since the hashed_uri to the W3C Verifiable Credential will fail to resolve causing a validation failure. To fully redact a W3C Verifiable Credential, the associated (referencing) assertion would also need to be redacted.

A key aspect to the standard C2PA manifest is the presence of one or more data structures, called content bindings, that can uniquely identify portions of the asset. There are two types of bindings that are supported by C2PA - hard bindings and soft bindings. A hard binding (also known as a cryptographic binding) enables the validator to ensure that (a) this manifest belongs with this asset and (b) that the asset has not been modified, by determining values that can match only this asset and no other, not even other assets derived from it or renditions produced from it. A soft binding is computed from the digital content of an asset, rather than its raw bits. A soft binding is useful for identifying derived assets and asset renditions.

A single manifest shall not contain more than one assertion defining a hard binding.

Soft bindings are described using soft binding assertions such as via a perceptual hash computed from the digital content or a watermark embedded within the digital content. These soft bindings enable digital content to be matched even if the underlying bits differ, for example due to an asset rendition in a different resolution or encoding format. Additionally, should a C2PA manifest be removed from an asset, but a copy of that manifest remains in a provenance store elsewhere, the manifest and asset may be matched using available soft bindings.

Because they serve a different purpose, a soft binding shall not be used as a hard binding.

All soft bindings shall be generated using one of the algorithms listed as supported by this specification. This section is intended to provide:

A claim gathers together all the assertions about an asset from an actor at a given time including the set of assertions for binding to the content. The claim is then cryptographically hashed and signed as described in Section 11.3.2.4, “Signing a Claim”. A claim has all the same properties as an assertion including being assigned the label (c2pa.claim) and supporting the use of assertion metadata. It encoded as CBOR data, and such, shall comply with the "Core Deterministic Encoding Requirements" of CBOR.

The schema for this type is defined by the claim-map rule in the following CDDL Definition:

An example in CBOR-Diag is shown below:

The Media Type of the asset shall be declared in dc:format. If present, the value of dc:title shall be a human-readable name for the asset.

If the asset contains XMP, then the asset’s xmpMM:InstanceID should be used as the instanceID. When no XMP is available, then some other unique identifier for the asset shall be used as the value for instanceID.

The signature field shall be present containing a URI reference to a claim signature.

The assertions field shall be present containing one or more URI references to the assertions being made by this claim.

When present, the redacted_assertions field shall contain one or more URI references to redacted assertions.

Some asset file formats require file offsets of the C2PA Manifest Store and asset content to be fixed before the manifest is signed, so that content bindings will correctly align with the content they authenticate. Unfortunately, the size of a manifest and its signature cannot be precisely known until after signing, which could cause file offsets to change. For example, in JPEG-1 files, the entire C2PA Manifest Store must appear in the file before the image data, and so its size will affect the file offsets of content being authenticated.

To accomplish this, a multiple step approach is taken, similar to how signatures in PDF are done.

In order to support many of the requirements of C2PA, C2PA Manifests needed to be stored (serialized) into a structured binary data store that enables some specific functionality including:

In addition to supporting all of the requirements above, our chosen container format - JUMBF, ISO 19566-5 - is also natively supported by the JPEG family of formats and is compatible with the box-based model (i.e., ISOBMFF, ISO 14496-12) used by many common image and video file formats. Using JUMBF enables all the same benefits (and a few extras, such as URI References) while being able to work with classic image formats, such as JPEG/JFIF and PNG as well as 3D and document (e.g., PDF) formats. This serialized format shall be used also in formats that do not natively support JUMBF, or when C2PA Manifest Stores are stored separately from the asset, such as in a separate file or URI location.

A C2PA Manifest Consumer shall never process an assertion, assertion store, claim, claim signature or C2PA Manifest that is not contained inside of a C2PA Manifest Store. Additionally, when a C2PA Manifest Consumer encounters a JUMBF box or superbox whose UUID it does not recognize, it shall skip over (and ignore) its contents.

In some cases, it may not be possible (or practical) to embed a C2PA Manifest Store in an asset. In those cases, keeping the C2PA Manifests externally to the asset is an acceptable model for providing providence to assets. The C2PA Manifest should be stored in a location, referred to as a manifest repository, that is easily locatable by a manifest consumer working with the asset, such as by reference or URI. As the C2PA Manifest Store is a JUMBF box, it shall be served with the JUMBF Media Type, application/x-c2pa-manifest-store.

Some common reasons to use an external manifest are:

If the asset has embedded XMP, it is recommended that the claim generator add a dcterms:provenance key to the XMP, the value (a URI reference) being where to locate the Active Manifest. The URI shall either be a JUMBF URI for an embedded C2PA Manifest or a standard URI for any non-embedded scenarios, whether stored remotely or locally on the same storage system as the asset itself.

An example JUMBF URI would be stored as:

All cryptographic hashes that are stored in a C2PA Manifest shall be generated using one of the hash algorithms as described in this section. This section defines both:

An algorithm must appear in no more than one list. An algorithm that is instantiated over multiple output lengths (such as the various lengths of SHA2) will each be considered different algorithms, and each instantiation must be listed separately. If an algorithm does not appear in either list, it is forbidden and must not be used or supported. Algorithms can be removed from the lists in order to implement forbidding an algorithm. For this reason, implementations must not support additional algorithms on an optional basis.

Implementers should consult this section in the current version of the specification when releasing software updates and ensure their supported algorithms conform to it.

These lists establish the allowed algorithms for creating hashes and a string algorithm identifier to be used as the algorithm identifier (usually called alg) in the corresponding field of C2PA data structures. The outputs of hash functions shall be stored as their binary values encoded into CBOR as byte strings (major type 2) with a declared length. Wherever a field contains the output of a hash function, an algorithm identifier string field shall be present within the same structure, or within an enclosing structure, to declare which algorithm was used. A hash algorithm identifier field should be present in exactly one of these places, but if more than one is present within the structure and its enclosing structures, the nearest identifier must be used. Nearest is defined first as an identifier that is a sibling field of the hash value, and then the immediately enclosing structure, up to the root structure.

The allowed list is:

The deprecated list is empty.

All digital signatures that are stored in a C2PA Manifest shall be generated using one of the digital signature algorithms and key types listed as described in this section. This section defines both:

These lists establish the allowed algorithms and key types by referencing an algorithm identifier from the relevant standards that define algorithms for COSE and their mappings to CBOR identifiers, including but not limited to RFC 8152 and RFC 8230. These standards also specify the hash algorithm used in the signature scheme. Nothing in Section 14.1, “Hashing” shall apply to this use of hash algorithms; if a digital signature algorithm is present in the digital signature algorithm and key type registry, the use of its specified hash algorithm in the signature scheme shall be allowed and followed.

The above model shows, in yellow, green and red, the three entities specified in the trust model, which is concerned with trust in a signer’s identity. In dashed lines, below, is the consumer (who is not specified in the trust model), who uses the identity of the signer, along with other trust signals, to decide whether the assertions made about an asset are true.

Identity in the trust model is the means by which a cryptographic signing key is associated with an actor for the basis of making trust decisions based on any structure (including, but not limited to, claims and manifests) signed with that key. The identity of a signatory is not necessarily a human actor, and the identity presented may be a pseudonym, completely anonymous, or pertain to a service or trusted hardware device with its own identity, including an application running inside such a service or trusted hardware.

The credential should be listed in the COSE protected headers of the COSE_Sign1_Tagged structure used for digital signatures in all C2PA manifests. The credential may appear in the unprotected headers, for backwards compatibility with previous versions of this specification. Regardless, exactly one instance of an identity credential must appear in the union of the protected and unprotected headers. COSE_Sign1_Tagged structures with no credentials, or two or more credentials, must be rejected. Repeating the same credential more than once, including separately in the protected and unprotected headers, is also an instance of two or more credentials and must be rejected.

Each credential type will define the following data to be provided to the validator:

The name of the header to indicate credential type, how the credential is stored in the header value, and how trust chains are constructed are specified for each credential type in Section 15.4, “Credential Types”.

As part of the validation of an asset, the signer’s credential is validated as being trusted to sign manifests. Credential types are defined in Section 15.4, “Credential Types”.

A validator shall maintain the following lists:

In this section, "user" refers to human actors that are using C2PA-compliant validators in consumption and authoring scenarios.

A validator should allow these trust anchor stores to be configured by the user, and should provide default options or offer lists maintained by external parties that the user may opt into to populate the validator’s trust anchor store for C2PA signers or Time Stamp Authorities.

A validator may also allow the user to create and maintain a private credential store of signing credentials for each credential type. This store is intended as an "address book" of credentials they have chosen to trust based on an out-of-band relationship. For example, a journalist may choose to add sources to their private credential store to facilitate accepting and validating media with C2PA provenance data attached, even though the sources themselves would have no reason to be on an externally-maintained trust list used broadly by the general public. Credentials in the private credential store may be self-issued, and may be anonymous or pseudonymous (that is, containing no identifying information about the signer, or information that only identifies by pseudonym). The private credential store shall only apply to validating signed C2PA manifests, and shall not apply to validating time-stamps. The private credential store shall only allow trust in signer certificates directly; entries in the private credential store cannot issue credentials and shall not be included as trust anchors during validation.

A validator must not be pre-configured with any entries in a private credential store.

A validator must only add entries to a private credential store in response to a user request to trust the credential. Similarly, a validator must only remove entries from a private credential store in response to a user request to stop trusting the credential.

Each credential type defined in this section may be used to sign C2PA manifests.

Some assertions (such as stds.schema-org.CreativeWork) allow a person’s identity to be associated in a defined way with the asset. This identity is purely scoped via the definition in each assertion and does not imply any larger involvement or responsibility for any assertion made in the claim, or the asset itself. All assertions, as stated below, are made by a signer.

A validator is a manifest consumer that will produce some validation statements about that asset. The actor consuming the asset, usually through their user agent and its user interface, then has to interpret those statements to arrive at a set of conclusions of their own about the provenance of the asset they are consuming. These conclusions will be drawn from these statements, the set of trust relationships that consumer currently has with the actors in the asset, and the contents of the asset itself.

A validator can make the following true or false statements about the asset they are validating, and no more.

Endorsements are a way of indicating approval of three possible actions, c2pa.published, c2pa.transcoded and c2pa.repackaged, that could be applied to an asset in a C2PA manifest in which the asset is used as an ingredient.

For example, the signer of a C2PA Manifest may want to endorse another party who wishes to transcode its asset. The signer creates an endorsement that identifies the transcoder, and conveys the endorsement to them (in some method that is out-of-band from this specification). When the transcoder creates their asset containing the ingredient, they include the endorsement as a c2pa.endorsement assertion, which lets the manifest consumer know that the actions they performed have been endorsed.

Endorsements are made by signers, and describe the actor they are endorsing through the use of their signing credentials and a validity period. These endorsements are conveyed out-of-band from the endorser to the endorsee. When the endorsee is using an asset created by the endorser as an ingredient in their own asset, they shall include the endorsement in its C2PA Manifest.

Endorsements endorse the specific actions (described in Section 16.9, “Validate the Endorsements”) that may be taken by the endorsee, and are therefore valid for asset manifests that use only the specified actions. Actions are only endorsed by the signer of that action’s referenced ingredient; they cannot be endorsed across more than multiple C2PA Manifests in the asset’s provenance.

The validation algorithm outputs status codes to indicate successful or failed portions of the validation process. They are also used by ingredient assertions to document the validation done on ingredients during the claim generation process.

The set of standard success and failure codes are defined below. Custom status codes are also permitted, when a claim generator has a need to record some process-specific status information. The code shall conform to the same syntax as custom labels, e.g. com.litware. When using custom labels, because they are not inherently success or failure codes, a boolean success or failure result must be returned as well. This is either part of the output of the validation algorithm when performing validation, or the value of the success boolean in the validationStatus object inside an ingredient assertion.

The CDDL Definition for status codes is included in the schema for the ingredient assertion at Section 19.13.5, “Schema and Example”.

The last C2PA Manifest superbox in the C2PA Manifest Store superbox is the active manifest, but locating the C2PA Manifest Store may involve looking in a number possible locations.

Once the active manifest has been located, the claim is found by locating, within the active manifest, the JUMBF Superbox with a label of c2pa.claim and a UUID of 0x6332636C-0011-0010-8000-00AA00389B71 (c2cl). There shall only be one such box in the active manifest, if more than one is located, the manifest shall be rejected with a failure code of claim.multiple.

Retrieve the URI reference for the signature from the value of the claim’s signature field and resolve the URI reference to obtain the COSE signature. The signature must be embedded in the same manifest as described in Section 12.1.1, “C2PA Box details”. If the signature URI does not refer to a location within the same C2PA Manifest box (a self#jumbf location), the claim must be rejected. If no such field is present or the URI cannot be resolved, then the claim must be rejected with a failure code of claimSignature.missing.

Validate that the credential used in the signature is acceptable according to Chapter 15, Trust Model for the credential’s type. If a chain of trust cannot be built from the credential to an entry in the trust anchor list, the claim must be rejected with a failure code of signingCredential.untrusted. If the credential is not acceptable per the requirements of the credential’s type, then the claim must be rejected with a failure code of signingCredential.invalid. If the signature algorithm is not on the allowed or deprecated list in Section 14.2, “Digital Signatures”, then the claim must be rejected with a failure code of algorithm.unsupported. After confirming the credential type and signing algorithm are acceptable, validation should proceed according to the specified procedure in Section 14.2, “Digital Signatures”. If validation of the signature fails, then the claim must be rejected with a failure code of claimSignature.mismatch.

For the remainder of this chapter, headers refer to the union of the set of protected and unprotected header parameters in the COSE signature. Unless otherwise specified in Section 14.2, “Digital Signatures” or Section 15.4, “Credential Types”, a header may appear in either bucket. RFC8152 section 3 describes COSE headers.

If the sigTst header is present, the claim is valid if the tstTokens array contains at least one tstToken whose val property is an RFC3161-compliant TimeStampResp which satisfies the following requirements. To aid in diagnosing time-stamp problems, a validator should maintain a list called timeStampStatusCodes which is also described in the following requirements:

If the sigTst header is not present, or if it is present but no time-stamp tokens satisfy the above requirements, then the claim is valid if the current time at validation is within the validity period of the signer’s credential. If it is not, the claim must be rejected with a failure code of signingCredential.expired.

If the claim is rejected with a failure code of signingCredential.expired, and the sigTst header is present, and no time-stamp tokens satisfy the above requirements, and timeStampStatusCodes is non-empty, then the validator should also return timeStampStatusCodes.

A validator may stop processing further time-stamp tokens in the tstTokens array after validating that there exists one token that satisfies the above requirements. This is because there is no difference between one or multiple valid time-stamps being present.

If the signer’s credential type does not support revocation status, or the credential’s issuer did not provide a method to query its revocation status, the validator presumes the credential is not revoked.

If the signer’s credential type supports revocation, and the credential’s issuer provided a method to query its revocation status:

In all cases, if the credential is deemed revoked at the time of signing, the claim shall be rejected with a failure code of signingCredential.revoked.

A validator must perform the above validation steps for the asset being presented and its manifest. If any of the above steps conclude the manifest is invalid, that manifest must be rejected with the indicated failure code.

An asset’s manifest may list one or more ingredients. For standard manifests, a validator may choose to optionally recurse through any ingredient manifests, however the parentOf ingredient of an update manifest shall be validated by the procedure below. There is no requirement that signers of ingredient manifests are trusted by the validator (except in the case of endorsement validation), and building of trust chains of signers of ingredients shall not be attempted. Instead, as the ingredient is included by the signer of the active manifest, and if the signer of the active manifest is accepted per the rules above, ingredient manifests will share in that trust for the purposes of this recursive validation. Applications should not display data from ingredient manifests with failed integrity checks. If the application chooses to display such data, it must flag the display with a warning about the failed integrity check, and that the data cannot be reliably attributed to the ingredient manifest’s signer nor to the asset’s manifest’s signer.

When ingredients are being added to an asset as part of an authoring workflow, the ingredient may undergo full validation and the results expressed in a validation status. In this scenario, the ingredient’s manifest is considered the active manifest for validation purposes, before the ingredient is added to another asset’s ingredients.

For consumption scenarios, it is expected that problems with ingredient manifests from a standard manifest would be ignored during normal consumption use but may be surfaced as a warning if a user opts to explore the provenance history. However, the parentOf ingredient of an update manifest shall be surfaced.

In authoring scenarios, it may be desirable to more prominently raise warnings so that a creator making use of such an asset with a flawed provenance history can make an informed decision of how to proceed.

If the manifest is an update manifest, or if a validator chooses to validate the ingredients of a standard manifest, then for each ingredient, it must recursively:

Endorsement validation shall only be attempted if the active manifest first meets a number of conditions:

Retrieve the endorsement assertion in the active manifest, as described in Section 19.15, “Endorsement Assertion”. In order to provide resilience in the case of a claim generator unexpectedly adding multiple endorsement assertions to an assertion store, a validator may iterate through the validation process below with each endorsement, stopping the iteration immediately if an endorsement validates successfully.

For each action object in the actions assertion:

When endorsement validation has completed, for each actions assertion in the active manifest where all actions are marked as endorsed, the actions assertion itself shall be marked as endorsed in the validation results returned by the validator.

Here is a visual representation of the process of validating a claim (and its assertions).

If the active manifest is an update manifest, its Section 10.2, “Hard Bindings” are inherited from the parentOf ingredient’s manifest. If that manifest is also an update manifest, the search for a standard manifest shall recurse though the chain of ingredients. If no standard manifest is found, then the manifest shall be rejected with a failure code of manifest.update.wrongParents.

The C2PA intends to provide clear recommendations and guidance for implementers of provenance-enabled user experiences (UX). Developing these recommendations is an ongoing process that involves diverse stakeholders, with the results balancing uniformity and familiarity with utility and flexibility for users across contexts, platforms, and devices. These recommendations can be found in the User experience guidance document.

The UX recommendations aim to define best practices for presenting C2PA provenance to consumers. The recommendations strive to describe standard, readily recognizable experiences that:

User interfaces designed for the consumption of C2PA provenance must be informed by the context of the asset. We have studied 4 primary user groups and a collection of contexts in which C2PA assets are encountered. These user groups have been defined in the C2PA Guiding Principles as Consumers, Creators, Publishers and Verifiers (or Investigators). To serve the needs of each of these groups across common contexts, exemplary user interfaces are presented for many common cases. These are recommendations, not mandates, and we expect best practices to evolve.

Because the complete set of C2PA data for a given asset can be overwhelming to a user, we describe 4 levels of progressive disclosure which guide the designs:

The team authoring the UX recommendations is cognizant of its limitations and potential biases, recognizing that feedback, review, user testing and ongoing evolution is a key requirement for success. The recommendations will therefore be an evolving document, informed by real world experiences deploying C2PA UX across a wide variety of applications and scenarios.

This section provides a summary of information security considerations and processes for technology described in the C2PA core specification. More detailed content will be provided in future releases of C2PA material including the Guidance document.

This section of the document lists the standard set of assertions for use by C2PA implementations, describing their syntax, usage, etc. To keep things simple, all example JUMBF URIs have been shortened for illustrative purposes - full URIs are necessary in the actual data.

All C2PA standardized assertions use the JSON JUMBF content type, the CBOR JUMBF content type, or the Embedded File content type from ISO 19566-5:AMD-1. Entity-specific assertions can be any of those, any of the other JUMBF content types from ISO 19566-5, B.1 (such as XML) or may create its own (as per the instructions in ISO 19566-5, Table B.1). The Codestream content type shall not be used for a C2PA assertion.

Unless otherwise mentioned, all assertions documented in this standard set of assertions shall be serialized as CBOR. For all assertions of type CBOR, their schemas shall be defined using CDDL. All assertions that are serialized as CBOR shall comply with the "Core Deterministic Encoding Requirements" of CBOR. For those defined using JSON, their schemas shall be defined using the latest version of JSON Schema.

All assertions shall have a label as described in Section 6.2, “Labels” and shall be versioned as described in Section 6.3, “Versioning”.

An actor object references a particular person or organisation. A valid actor object shall have either:

In some use cases, a given assertion, such as an Action, may only be relevant to a specific portion of an asset as opposed to the entire asset. In those cases, it is necessary to have a way to describe that region - whether it be temporal or spatial or both. A region definition serves that purpose.

In many cases, it is useful or even necessary to provide additional information about an assertion, such as the date and time when it was generated or other data that may help manifest consumers to make informed decisions about the provenance or veracity of the assertion data.

Below shows the core schemas used inside other assertions.

In CDDL it is defined by the assertion-metadata-map rule in the following schema:

In JSON Schema:

In most cases, this assertion specific metadata will appear directly inside of other assertions (e.g., ingredients) as the value of their metadata field. However, sometimes it is necessary or desirable to store the assertion metadata in a separate, independent assertion metadata assertion, such as when an assertion is not in JSON or CBOR, such as thumbnails.

The label for the assertion metadata assertion is c2pa.assertion.metadata.

The standard C2PA assertions are:

The most common way to uniquely verify the integrity of portions of a non-BMFF-based asset is via the hard bindings (i.e., cryptographic hash) present in data hash assertions. However, for those formats are "box like" but not compatible with BMFF, the General Box Hash assertion is recommended.

The data hash assertion supports the creation and storage of hashes as described in Section 14.1, “Hashing”, and the value shall be present in the hash field.

Each data hash assertion defines a specified range of bytes over which the hash has been computed. If only a portion of the asset shall be hashed, then the range(s) to be excluded shall be present in the array value of the exclusions field.

A previous version of this specification provided a url field to provide a pointer to where the hashed data can be located, but it was never used. This field is now deprecated in favor of the Asset Reference Assertion. Claim generators shall not add this field to a data hash assertion, and consumers shall ignore the field when present, except this shall not affect inclusion of the field as part of the content being validated as described in Section 16.7.3, “Assertion Validation”.

A Data Hash assertion shall have a label of c2pa.hash.data.

A Data Hash assertion must not appear in a Cloud Data assertion.

Portion(s) of a BMFF-based asset that a claim generator wishes to uniquely identify with a hard binding (i.e., cryptographic hash) shall be described using BMFF-based Hash assertions.

A BMFF-based Hash assertion shall have a label of c2pa.hash.bmff for v1 (deprecated) and c2pa.hash.bmff.v2 for v2. Claim generators shall not create c2pa.hash.bmff (v1) assertions in new manifests.

A BMFF-based Hash assertion must not appear in a Cloud Data assertion.

A previous version of this specification provided a url field to provide a pointer to where the hashed data can be located, but it was never used. This field is now deprecated in favor of the Asset Reference Assertion. Claim generators shall not add this field to a BMFF hash assertion, and consumers shall ignore the field when present, except this shall not affect inclusion of the field as part of the content being validated as described in Section 16.7.3, “Assertion Validation”.

To compute the hash specified in the value field of a BMFF hash, all bytes of the file are added to the hash excluding those BMFF boxes or subset[s] thereof which match any exclusion entry in the exclusions array.

Boxes that are included in their entirety also include their box headers in the input data contributed to the hash. Similarly, boxes that are excluded in their entirety also exclude their box headers from the input data contributed to the hash. When a box is partially excluded from the input data contributed to the hash through the use of a subset field in the exclusion specification, the portion(s) of the box to be excluded defined by the relative byte offsets in the subset field are offsets from the start of the box including the box headers, not offsets from the start of the box’s content.

In BMFF-based hash v1, for any root box not excluded in its entirety, the input data contributed to the hash for that box is comprised of data, where data is defined as the box’s contents, including headers, minus any exclusions.

In BMFF-based hash v2, for any root box not excluded in its entirety, the input data contributed to the hash for that box is comprised of the concatenation of the binary strings offset || data, where offset is defined as the absolute file offset of the box as an 8-byte integer in big-endian format, and data is defined as the box’s contents, including headers, minus any exclusions. In this definition, "||" represents the binary concatenation of the two. The offset shall not be included for Merkle tree hashes when the bmff-hash-map includes both the hash and merkle fields.

There are two differences between BMFF-based hash v1 and v2.

A box matches an exclusion entry in the exclusions array if and only if all of the following conditions are met.

The xpath field’s string syntax shall be limited to the following strict subset.

Complete Syntax:

A non-leaf xpath node shall only point to a container box that has no fields of its own (i.e., contains no data, only child boxes) and that does not inherit from FullBox. This ensures that a C2PA validator does not need to be aware of the syntax and semantics of unusual boxes that contain other boxes. If a child box of such an unusual box needs to be excluded in full or in part, the exclusions-map entry’s xpath field shall point to the unusual box itself and the subset-map field shall exclude the byte rang(es) containing the excluded child box data. For example, the 'sgpd' box contains other boxes but is unusual in that it inherits from FullBox; as such, if excluding child box(es), in whole or in part, from 'sgpd' is required, the assertion shall use an xpath field pointing to the 'sgpd' itself (e.g., /moof/traf/sgpd) and shall use the subset-map field to exclude the desired bytes.

If the C2PA Manifest is embedded into the file, the box containing it shall be one of the entries in the exclusions array. Refer to Section 12.3.2, “Embedding manifests into BMFF-based assets” for more information.

If a non-root excluded box is removed after the C2PA Manifest is created, it shall be replaced with a 'free' box of the same size to ensure that the input data contributed to the hash for other boxes are not invalidated. If it is expected that a non-root excluded box may be added after the C2PA Manifest is created, then, at manifest creation time, a 'free' box shall be inserted with sufficient space for the excluded box and that 'free' box shall also be excluded by an exclusion entry using its full xpath. When the excluded box is added, the 'free' box shall be shrunk (or removed) to make space for the added box.

Embedding C2PA data into a BMFF-based asset via MP4 boxes changes file offsets in other MP4 boxes and, in v2, the absolute file byte offsets being included in the input data contributed to the hash for any root box. Those boxes and offsets must be included in the input data contributed to the hash with their post-embed values, not their pre-embed values, or the BMFF-based Hash assertion will not validate.

A claim generator should use a general box hash assertion to verify the integrity, with a hard binding (i.e., cryptographic hash), of assets whose formats use a non-BMFF-based box format such as JPEG, PNG, or GIF.

A General Box Hash assertion shall have a label of c2pa.hash.boxes. Such an assertion consists of an array of structures, each one listing one or more boxes (by their name/identifier) and a hash that covers that data of those boxes (and any possible data that may be present in the file between them), along with the algorithm used for hashing. The boxes must appear in the assertion in the same order that they appear in the asset. The creation of the hashes is described in Section 14.1, “Hashing”, and the value shall be present in the hash field.

The hash value for a range of boxes shall be computed from the start of the first box (in the range) until the end of the last box (in the range). This would include any arbitrary bytes that may be present between boxes.

The box containing the C2PA Manifest (e.g. APP11 for JPEG, caBX for PNG, or 21FF for GIF) shall also be listed, but in order to clearly identify it as the C2PA Manifest box, it shall have the name C2PA and the value of hash shall be the binary string 0 (a single byte with a value of 0).

The pad value shall always be present but shall be a zero-filled byte string of length 0 unless used to replace (i.e., "pad") bytes during multiple pass processing.

A General Box Hash assertion shall not appear in a Cloud Data assertion.

If a claim generator wishes to provide a soft binding for the asset’s content, it shall be described using a soft binding assertion. The types of soft bindings which can be created and stored in such an assertion are described in Section 10.3, “Soft Bindings”.

A previous version of this specification provided a url field to provide a pointer to where the hashed data can be located, but it was never used. This field is now deprecated in favor of the Asset Reference Assertion. Claim generators shall not add this field to a soft binding assertion, and consumers shall ignore the field when present, except this shall not affect inclusion of the field as part of the content being validated as described in Section 16.7.3, “Assertion Validation”.

A Soft Binding assertion shall have a label of c2pa.soft-binding.

There are use cases where storing the data for the assertion remotely, such as in the cloud, is better than embedded inside the asset, especially when the data is large. For any such cases, it is possible to use a special type of assertion that serves as a reference to that information. For privacy and reliability reasons, data referenced through a Cloud Data assertion shall be considered optional: their contents should not be retrieved as part of manifest validation. A validator may retrieve the contents later to serve an application-dependent need, such as further exploration of the provenance history.

If assertion metadata is included as part of another assertion, then it too would be part of the information referenced from a Cloud Data assertion. It is also possible to store individual assertion metadata assertions remotely, just as with other assertion types.

A Cloud Data assertion shall have a label of c2pa.cloud-data.

A Cloud Data assertion must not refer to an assertion with the label c2pa.hash.data, c2pa.hash.boxes, c2pa.hash.bmff (deprecated), or c2pa.hash.bmff.v2.

A thumbnail assertion provides an approximate visual representation of the asset at a specific event in the lifecycle of an asset. There are currently two specific events:

For thumbnails created at claim creation time, the Thumbnail assertion shall have a label that starts with c2pa.thumbnail.claim and be followed by the IANA registry image type (e.g., c2pa.thumbnail.claim.png). For each of these types of thumbnails, there can be only one per claim.

When importing an ingredient (see Section 11.3.2.2, “Adding Ingredients”), it is preferable to reference that ingredient’s own manifest-stored thumbnail. However, some ingredients may not include a thumbnail assertion, or even a manifest. In that case, a new thumbnail of the ingredient should be generated, and a new thumbnail assertion in the active manifest created. The Thumbnail assertion shall have a label that starts with c2pa.thumbnail.ingredient and be followed by an underscore (_ (U+005F)) then a unique ID such as a simple monotonically increasing integer and ending with the image type. For example, an ingredient thumbnail of type jpeg could have label c2pa.thumbnail.ingredient_1.jpg.

The data in a thumbnail assertion is the bits of a file (such as a raster image) in whatever format is desired by the claim generator. The Embedded File content type (ISO 19566-5:AMD-1), bfdb, shall be used to contain the thumbnail’s data.

An actions assertion provides information on edits and other actions taken that affect the asset’s content. There will be an array of actions - each action declaring what took place on the asset, when it took place, along with possible other information such as what software performed the action.

There are two versions of the Actions assertion - the original v1 (which shall have a label of c2pa.actions) and the new and improved v2 (which shall have a label of c2pa.actions.v2). There shall be no more than one Actions assertion of any version per C2PA Manifest. Actions are modelled after XMP ResourceEvents, though contain a number of C2PA-specific adjustments.

v1 actions are fully specified in its actions array. However, in v2, an action may either be fully specified in an element of the actions array or it may be derived from an element in the templates array with the same action name.

For each action present in either the actions or templates arrays, the value of the action field shall be either a pre-defined action name (c2pa.resized, c2pa.edited, etc.) or entity-specific action name (com.fabrikam.gaussianBlur, etc.).

The set of pre-defined names, prefixed with c2pa. are:

An action may include a free-text description, in the description field, of what an action does. This is most useful for non-standard actions, however, it could also be used as a way to provide additional information about a standard action. For example, a c2pa.edited action could have a description that says "Paintbrush tool".

If present, the reason field shall contain one of the standard values, or a custom value which conforms to the same syntax as custom labels, for the rationale behind the action.

When using a c2pa.redacted action, the reason field shall contain the rationale for the redaction. Additional requirements for the c2pa.redacted action can be found in Section 19.12.2, “Parameters”.

Also present may be the date and time when the action took place in the when field. If included, the value of the when field shall be compliant with ISO 8601.

The software or hardware used to perform the action can be identified via the softwareAgent field. In a v1 action, this is a simple text string. However, for v2, softwareAgent uses the richer generator-info-map structure as described in Section 11.2.2.1, “Generator Info Map”.

An action may include an actors key which can point to the identity of one or more human actor who performed the action as described in [_common_data_model_actor]. It may also include a digitalSourceType key, whose value shall be one of the terms defined by the IPTC or a C2PA specific value from the list below:

For "trained algorithmic media" assets, such as those created by Generative AI, one or more ingredients may be added to the C2PA Manifest to provide info about the inputs that led to the production of the asset. They can be referenced from a c2pa.placed or c2pa.created action as shown below.

When assets are composed together, for example placing an image into a layer in Photoshop or an audio clip into a video in Premiere, it is important that information about any claim from the placed asset be recorded into the new asset to provide a way to understand the entire history of the new composed asset. This is also true when an existing asset is used to create a derived asset or asset rendition.

Another common use for an ingredient is to describe some assets or data that was used as input to a process, such as the training or inference requests associated with an AI/ML model.

There are two versions of the Ingredients assertion - the original v1 (which shall have a label of c2pa.ingredient) and the new and improved v2 (which shall have a label of c2pa.ingredient.v2).

A Depthmap assertion provides a 3D description of the scene being captured by a camera. A Depthmap assertion may contain a pre-computed depth map, or data which can later be used to compute a depth map by downstream ingestion or viewing software (e.g., left/right stereo images).

All Depthmap assertions shall have a label that starts with c2pa.depthmap and be followed by a third section that identifies the type of depth map.

C2PA Depthmap assertions shall be captured optically, not inferred from a single 2D image via, for example, a machine learning model.

An endorsement is a way of indicating approval for specific actions made on content after it has had a manifest attached (see Section 15.7, “Endorsement”). The Endorsement assertion is where an endorsement from the signer of an ingredient asset is stored. These endorsements are typically provided (out-of-band of this specification) by ingredient asset signers to actors those signers trust to perform the actions listed in Section 15.7, “Endorsement”. They are used by a validator when assessing whether the actions of the active manifest are "endorsed" or not (see endorsement validation).

To attach an endorsement, a claim generator must ensure that:

An Endorsement assertion shall have a label of c2pa.endorsement, and there shall be at most one Endorsement assertion per manifest. The assertion contents shall be a COSE_Sign1_Tagged structure that is created as defined in Section 15.7.1, “Endorsement Generation”.

The Exif Information assertion can be used to ensure that Exif information, for example about the capture device, is added to the asset in a way that can be validated cryptographically. It is preferable to copy this information from the Exif block or from the Exif namespace of the XMP block. Information should be copied to JSON-LD using the XMP field names specified in the Exif 2.32 metadata for XMP specification. When copying the information from XMP, the data shall be re-serialized according to the rules of the JSON-LD serialization of XMP.

An Exif Information assertion shall have a label of stds.exif.

Any property from the latest version of the Exif specification (currently 2.32) can be added to the stds.exif assertion, with the exception of the MakerNote (37500, 0x927c) field, the contents of which are vendor-specific.

This assertion should be used to assert the precise location associated with the content using the Exif GPS properties (those starting exif:GPS). For broad information about the location, see Section 19.17, “IPTC Photo and Video Metadata”.

An example of an Exif Information assertion:

The International Press Telecommunications Council defines a standard set of descriptive, administrative and rights metadata typically used by photographers, distributors, news organizations, archivists, and developers. Early versions of the standard used IPTC’s binary Information Interchange Model (IPTC-IIM) format and later versions introduced XMP support for all IIM fields, plus a new set of fields which can only be expressed in XMP. Together, these are called the IPTC Photo Metadata Standard.

More recently, the IPTC has introduced an equivalent standard for video, the IPTC Video Metadata Hub. This re-uses many of the administrative and rights properties from the Photo Metadata Standard and introduces new properties specific to video, such as duration, episode information and frame rate.

The stds.iptc assertion can be used to ensure that properties from the IPTC Photo Metadata Standard and Video Metadata Hub, for example describing ownership, rights and descriptive metadata about a media object, are added to the asset in a way that can be validated cryptographically.

IPTC properties shall be stored in JSON-LD format using the XMP field names and structures specified in the IPTC Photo Metadata Standard Specification and the IPTC Video Metadata Hub specification. The data shall be re-serialized according to the rules of the JSON-LD serialization of XMP.

Any property from the IPTC Photo Metadata Standard or the IPTC Video Metadata Hub can be added to the stds.iptc assertion.

A useful subset of IPTC Photo and Video Metadata properties is listed below:

In particular, the Location Created property can be used to assert the broad location associated with an asset. To assert the precise GPS location associated with an asset, the Exif information assertion should be used.

An example of an IPTC Photo and Video Metadata assertion including location information:

Schema.org is a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet. As such, they provide numerous JSON-based grammars that one may wish to include as an assertion. When using a schema.org type as a C2PA assertion, we require a full JSON-LD serialisation. Thus, the top-level @context field must have a value of http://schema.org.

All Schema.org assertions shall have a label that starts with schema.org and be followed by the name of the schema that is being used. For example, schema.org.ImageObject can be used to include something extra about an image. Since schemas on Schema.org are not versioned as described here, no version indicator is used in their labels.

This assertion is used to indicate one or more locations where a copy of the asset may be obtained. Such locations shall each be described using an asset reference assertion. The location shall be expressed via a URI.

An Asset Reference Assertion shall have a label of c2pa.asset-ref.

The timestamp within the assertion metadata provides a basis for determining the freshness of the link described as the reference.

The asset type assertion provides a way to more completely describe an asset, specifically additional context on how to parse or otherwise process it. Although both Claims and Ingredients must include a valid (IANA Media Type) in the dc:format field, there are many file formats for assets that cannot be completely described by a single Media Type value.

The asset type assertion shall have a label of c2pa.asset-type. There shall be at most one asset type assertion in a C2PA Manifest.

The asset type assertion has a single required field; the types field, whose value is an array of one or more asset types. These types can either come from the following table or be an entity-specific type (e.g., com.litware.types.abc), provided that they conform to the same syntax as custom labels. If relevant, the version of the asset (e.g., the version of a dataset or model) can be documented in the version field.