Content Credentials : C2PA Technical Specification

The basis of making trust decisions in C2PA, our trust model, is the identity of the signer associated with the cryptographic signing key used to sign the claim(s) in the C2PA Manifest Store. The claim signatures of C2PA Manifests, when combined with trusted time-stamps, can undergo the validation process indefinitely to determine if claims were signed while the signing credentials were valid and not revoked.

A very common scenario will be a user taking a photograph with their C2PA-enabled camera (or phone). In that instance, the camera would create a manifest containing some 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 C2PA Manifest (see Figure 2, “Example C2PA Manifest of a Photograph”) would be embedded into the output JPEG. This C2PA Manifest would remain valid indefinitely.

A Manifest Consumer, such as a C2PA validator, helps users to establish the trustworthiness of the asset by first validating the digital signature and its associated credential. It also checks each of the assertions for validity and presents 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. Those goals can be found in Table 1, “C2PA Design Goals”.

A human or non-human (hardware or software) that is participating in the C2PA ecosystem. For example: a camera (capture device), image editing software, cloud service or the person using such tools.

The non-human (hardware or software) actor that generates the claim about an asset as well as the claim signature, thus leading to the asset's associated C2PA Manifest.

The credential holder of a private key that is used to sign the claim. The signer is identified by the subject of the credential.

An actor who consumes an asset with an associated C2PA Manifest for the purpose of obtaining the provenance data from the C2PA Manifest.

A Manifest Consumer whose role is to perform the actions described in validation.

An operation performed by an actor on an asset. For example, "create", "embed", or "apply filter".

The portion of an asset that represents the actual content, such as the pixels of an image, along with any additional technical metadata required to understand the content (e.g., a colour profile or encoding parameters).

Non-technical information about the asset and its digital content.

A file or stream of data containing digital content, asset metadata and optionally, a C2PA Manifest.

A derived asset is an asset that is created by starting from an existing asset and performing actions to it that modify its digital content.

A representation of an asset (either as a part of an asset or a completely new asset) where the digital content has had a 'non-editorial transformation' action (e.g., re-encoding or scaling) applied.

A composed asset is an asset that is created by building up a collection of multiple parts or fragments of digital content (referred to as ingredients) from one or more other assets. When starting from an existing asset, it is a special case of a derived asset - however a composed asset can also be one that starts from a "blank slate".

A data structure which represents a statement either made (or "created") by the signer or simply gathered at claim generation-time, concerning the asset. This data is a part of the C2PA Manifest.

A digitally signed and tamper-evident data structure that references a set of assertions, concerning an asset, and the information necessary to represent the content binding. If any assertions were redacted, then a declaration to that effect is included. This data is a part of the C2PA Manifest.

The digital signature on the claim using the private key of a signer. The claim signature is a part of the C2PA Manifest.

The set of information about the provenance of an asset based on the combination of one or more assertions (including content bindings), a single claim, and a claim signature. A C2PA Manifest is part of a C2PA Manifest Store.

A collection of C2PA Manifests that can either be embedded into an asset or be external to its asset.

This is the preferred, non-technical, term for a C2PA Manifest. The C2PA Manifest Store therefore represents the Content Credentials of an asset.

Content Credentials also refers to the overall C2PA technology, and is therefore essentially treated as a plural noun. If a C2PA Manifest is a Content Credential, then multiple C2PA Manifest or the broader, universal concept is Content Credentials.

The last manifest in the list of C2PA Manifests inside of a C2PA Manifest Store which is the one with the set of content bindings that are able to be validated.

The logical concept of understanding the history of an asset and its interaction with actors and other assets, as represented by the provenance data.

The set of C2PA Manifests for an asset and, in the case of a composed asset, its ingredients.

A property of digital content comprising a set of facts (such as the provenance data and hard bindings) that can be cryptographically verified as not having been tampered with.

Information that associates digital content to a specific C2PA Manifest associated with a specific asset, either as a hard binding or a soft binding.

One or more cryptographic hashes that uniquely identifies either the entire asset or a portion thereof.

A content identifier that is either (a) not statistically unique, such as a fingerprint, or (b) embedded as an invisible watermark in the identified digital content.

The collection of information that can inform a Manifest Consumer’s judgment of the trustworthiness of an asset. These are in addition to the signer of a claim, upon which the fundamental trust model relies.

A C2PA-managed list of X.509 certificate trust anchors that issue certificates to hardware & software signers that are trusted to sign claims.

A set of inherent properties computable from digital content that identifies the content or near duplicates of it.

Information incorporated in a substantially human imperceptible way into the digital content of an asset which can be used, for example, to uniquely identify the asset or to store a reference to a C2PA Manifest.

A perceptible component of the digital content carrying some human consumable information about the provenance of the asset.

A repository into which C2PA Manifests and C2PA Manifest Stores can be placed, and which can be searched using a content binding.

This version focuses on both technical and editorial changes to the specification for the purposes of improving the security and reliability of Content Credentials. All publicly disclosed security vulnerabilities have been addressed, and the specification has been updated to reflect the latest best practices in the field.

This version represents a significant departure from previous versions. It reduces the use of the term "actor", which no longer represents humans and organisations. In addition to validator-configured trust lists, it also introduces a new default trust list, the "C2PA Trust List", which is intended to cover certificates issued to hardware and software. This philosophical change led to the following functional changes in the specification:

In addition, the following other changes were made to improve various aspects of the spec:

String values in C2PA data structures may be organized into namespaces using a period (.) as a separator. The C2PA namespace, c2pa, shall be the beginning of any string value defined in this specification. Entity-specific namespaces shall begin with the Internet domain name for the entity similar to how Java packages are defined (e.g., com.litware, net.fineartschool).

The period-separated components of an entity-specific namespace shall follow the variable naming convention ([a-zA-Z0-9][a-zA-Z0-9_-]*) specified in the POSIX or C locale, as defined in the ABNF below (ABNF for Namespaces).

Each assertion has a label defined either by the C2PA specifications or an external entity. These labels are strings which are namespaced, as described in the preceding clause or by an entity. The most common labels will be defined in the c2pa namespace, but labels may use any namespace that follows the conventions. Labels 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 18, 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.

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:2023, C.2. These URIs shall be used either as part of a hashed_uri or hashed_ext_uri data structure.

When the reference is to a compressed manifest, the JUMBF URI shall not contain anything about the brob box, but the URI to the manifest is treated as if the manifest was not compressed. This means that the URI would include the label of the c2ma or c2um box, but not the label of the c2cm box. In addition, the URI reference to a compressed manifest shall not include the label of the brob box - but only the label of the compressed manifest itself.

The simplest type of hard binding that can be used to detect tampering is a cryptographic hashing algorithm, as described in Section 13.1, “Hashing”, over some or all of the bytes of an asset. This approach can be used on any type of asset, but should only be considered for formats that don’t support one of the forms of box-based hashing.

When using this form of hard binding, a data hash assertion is used to define the range of bytes that are hashed (and those that are not). Because a data hash assertion defines a byte range, it is flexible enough to be usable whether the asset is a single binary or represented in multiple chunks or portions.

When an asset’s format is a non-BMFF-based box format, such as JPEG, PNG, GIF or others listed here, then a general box hash assertion should be used. This 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.

If the asset is based on ISO BMFF then a hard binding optimized for the box-based format (called BMFF-based hash assertions) may be used instead.

For a monolithic MP4 file asset where the mdat box is validated as a unit, the assertion is validated nearly identically to a data hash assertion. It simply uses a box exclusion list instead of byte ranges to define the range of bytes that are hashed (and those that are not).

For fragmented MP4 (fMP4) files, the assertion itself shall be combined with chunk-specific hashing information which is located as specified in Section A.4, “Embedding manifests into BMFF-based assets”.

In workflows where the C2PA Manifest will refer to a collection of assets, instead of a single asset, the collection data hash assertion shall be used as the method to specify the hard bindings for the assets in the collection.

Signers of the C2PA Manifest are not required to sign the asset metadata not contained within the C2PA Manifest. In such a case, the asset metadata shall be excluded by data hash assertions and their boxes shall not be listed by general box hash assertions or BMFF-based hash assertions.

Any asset metadata values that are supported by the common metadata assertion, as described in Appendix B, Implementation Details for c2pa.metadata, and can be asserted by the signer should be copied into such an assertion and included in the C2PA Manifest.

All soft bindings shall be generated using one of the algorithms listed in the soft binding algorithm list as supported by this specification.

The schema for this type is defined by the claim-map-v2 and claim-map rules in the following CDDL Definition for claims with labels c2pa.claim.v2 and c2pa.claim, respectively:

An example of the claim-map-v2 structure in CBOR-Diag:

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 created_assertions field shall be present and it shall contain one or more URI references to assertions being made by this claim that were created by the claim generator. In a standard manifest or time-stamp manifest, it shall contain at least one assertion that represents a hard binding.

When present, the gathered_assertions field shall contain one or more URI references to assertions that have not been created by the claim generator but have been provided by other components in the workflow.

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

Before the claim can be finalized, all assertions need to be created and stored in a newly created C2PA Assertion Store as described later in this document.

When creating a standard manifest, it may not be possible to know all of the required binding information at the time of claim creation, in which case use the multiple step processing method to setup and then later fill-in the information.

When creating a standard manifest, its claim shall include one or more content binding assertions in its list of assertions to ensure that the asset is tamper-evident.

Create the data hash assertion and add it to the assertion store taking into account the following considerations.

In many cases, such as with JPEG 1, it is not possible to hash the asset in its entirety because the manifest will be embedded in the middle of the file, so the size or location manifest data will not be known at the time the asset hash is computed. This circular dependency is avoided by allowing exclusion ranges to be specified during hashing. When exclusion ranges are specified, a single hash is performed, but only over the asset ranges that are not in any of the exclusions. The data present in an exclusion range shall only contain a C2PA Manifest and any padding.

If a manifest is embedded in the center of a JPEG 1 file in an APP11 segment, then the claim creator may exclude the APP11 segment(s) from the hash calculation.

In order to prevent insertion attacks, it is desirable to have only a single exclusion range when possible. When the size or location (or both) of the manifest in the asset is not known, then the start and length values in the data hash assertion shall both be zero and the size of the pad value should be large enough to accommodate writing in the values during the second pass. At least 16 bytes is recommended. The value of the pad key shall consist of all 0x00’s.

If padding is employed, it is possible that the pad data could be changed without resulting in a validation failure. Claim generators shall ensure that changes to pad data (or any other excluded asset data) cannot change how the asset is interpreted.

Add the newly created data hash assertion reference to the claim’s assertion list providing a temporary hash value, such as empty spaces.

At this point, the temporary claim is complete and can be added to the C2PA Manifest being created.

Since the claim is only temporary at this time, it is not possible to sign it. To ensure the claim signature box contains a valid CBOR structure, create a temporary COSE_Sign1_Tagged structure as described in RFC 8152, section 4.2. The COSE_Sign1_Tagged is a tag byte followed by a COSE_Sign1 structure, which is a four-element CBOR array. Construct the array as follows:

At this point all of the boxes that comprise the entire C2PA Manifest for the asset are completed and can be (if not already) constructed into its final form. The asset’s C2PA Manifest, along with the manifests of any ingredients, are combined together to form the complete C2PA Manifest Store. The active manifest is required to be the last C2PA Manifest superbox in the C2PA Manifest Store superbox. The C2PA Manifest Store can then be embedded into the asset as discussed in Section 11.3, “Embedding manifests into various file formats”.

Now that the C2PA Manifest Store has been embedded into the asset, the starting offset and the length of the active manifest can be updated in its data hash assertion. It is necessary that when doing so, you do not change the size of the assertion’s box, only its data. This is done by adjusting the value of the pad field to be the necessary length to "fill up" the remaining bytes.

Once the data hash assertion has been updated, it can be hashed and the hash written over the empty spaces that were used previously to hold the location.

The claim is now complete, and it can be hashed and signed as described in Section 10.3.2.4, “Signing a Claim”, with the resultant signature filling the pre-allocated space. The pad header can then be shrunk as required so that the claim signature box remains the same size; because this header is unprotected, changing it does not invalidate the claim signature.

If the serialized COSE_Sign1_Tagged structure exceeds the reserved size of the C2PA Claim Signature box, multiple step processing shall be repeated with a larger padding size chosen in Section 10.4.2, “Create a temporary Claim and Signature”. Revocation information retrieved during the previous attempt should be reusable if it is still within its validity interval (RFC 6960, section 4.2.2.1), but a new time-stamp will be required on the new claim with the file offsets changed as the result of added padding.

A C2PA Manifest may contain assertions defined outside of this specification, and they could depend on file layout. As such, the claim generator may no longer be able to change the file layout and/or offsets in a data hash assertion. In this case, claim generators should use padding prior to assertion creation to ensure that the file layout need not change once the assertion has been finalized.

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 - ISO 19566-5:2023 (JUMBF) - 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 JUMBF type UUID it does not recognize, it shall skip over (and ignore) its contents.

If the Requestable and Label Present toggles are both set in the JUMBF Description box of any JUMBF box or superbox, that box or superbox shall be maintained in any updated C2PA Manifest Store.

All C2PA Manifests shall contain an assertion store with at least one assertion, a claim and a claim signature.

A standard C2PA Manifest (JUMBF type UUID: 63326D61-0011-0010-8000-00AA00389B71 (c2ma)) shall contain exactly one hard binding to content assertion - either a c2pa.hash.data, c2pa.hash.boxes, c2pa.hash.collection.data, c2pa.hash.bmff.v2 (deprecated), or c2pa.hash.bmff.v3 based on the type of asset and version for which the manifest is destined. Because of this requirement, they are the predominant type of manifest that will be present in C2PA provenance data.

Manifest Consumers shall also accept standard C2PA Manifests specified with JUMBF type UUID 63326D64-0011-0010-8000-00AA00389B71 (c2md), but claim generators shall not create manifests with this JUMBF type UUID.

There are, however, provenance workflows where additional assertions need to be added but the digital content is not changed. In these workflows, an Update Manifest (JUMBF type UUID: 6332756D-0011-0010-8000-00AA00389B71 (c2um)) should be used.

An Update Manifest shall not contain assertions of types c2pa.hash.data, c2pa.hash.boxes, c2pa.hash.collection.data, c2pa.hash.bmff.v2 (deprecated), or c2pa.hash.bmff.v3 because the content has not changed and therefore the bindings need not be updated. In the case of a file offset hash (c2pa.hash.data), the C2PA Manifest Store has to continue to start at the same file offset after updating - only its length may change.

An Update Manifest may contain assertions of type c2pa.actions or c2pa.actions.v2, provided that the value of the action field of each action present in the actions array of these assertions shall only be one of the following values:

An Update Manifest shall not contain an assertion of type c2pa.actions or c2pa.actions.v2 that contains an action field outside of this list.

An Update Manifest shall not contain a thumbnail assertion.

The Update Manifest shall contain exactly one c2pa.ingredient.v3 assertion that (a) includes both activeManifest and claimSignature fields with values that are the URI references to the C2PA Manifest and Claim Signature respectively (or one c2pa.ingredient.v2 or c2pa.ingredient that includes a c2pa_manifest field) of the asset that is being updated and (b) has the value of parentOf for the relationship field.

Standard and Update Manifests can be compressed, in their entirety, using the Brotli compression algorithm as described above. For either type of manifest, the value of the TYPE field shall be c2cm, the value of the label field shall be the identical to the label of the compressed manifest superbox, and the contents of the brob content box shall be the compressed bytes of the entire manifest superbox. See Figure 7, “Example of a compressed manifest” for an example of a compressed standard manifest.

In some provenance workflows, a standard or update manifest is created offline, where it is not possible to obtain a trusted time-stamp (as per RFC 3161) from a TSA at the time of signing. In order to accommodate this, it is possible to use a Time-Stamp Manifest (JUMBF type UUID: 6332746D-0011-0010-8000-00AA00389B71 (c2tm)) to add the time-stamp in a later operation when a TSA can be contacted.

A Time-Stamp Manifest shall contain only a single assertion, which is the c2pa.ingredient.v3 assertion that (a) includes an activeManifest field with a value that is the URI reference to that C2PA Manifest that is being updated and (b) has the value of parentOf for the relationship field.

The allowed list is:

The deprecated list is empty.

Implementations are required to check that keys provided for signing or verification operations are correct for the chosen algorithm, as required by RFC 8152, section 8.1 for ECDSA, RFC 8152, section 8.2 for EdDSA, and RFC 8230 section 2 and section 4 for RSASSA-PSS.

These requirements are summarized here for convenience:

Implementations shall refuse to generate or verify signatures with keys that are not correct for the algorithm choice. Implementations may refuse RSA keys with modulus length greater than 16384 bits.

The signature for the CBOR-encoded claim is produced by CBOR Object Signing and Encryption (COSE) as described in RFC 8152, sections 4.2 and 4.4.

Regardless of whether the payload will be present in or detached from the COSE_Sign1_Tagged signature; the contents of the payload field of Sig_structure in memory, when constructed to compute or verify a digital signature, shall be populated with that external data as described by the particular use of digital signature in this specification. The payload field of Sig_structure shall never be nil.

When computing or verifying the signature of a standard or update manifest, the payload field of the Sig_structure will contain the contents of the claim JUMBF box, as described in Section 10.3.2.4, “Signing a Claim” and Section 11.1, “Use of JUMBF”.

When computing or verifying the signature of a time-stamp manifest, the payload field of the Sig_structure will contain the C2PA Claim Signature box of the C2PA Manifest of its parent ingredient, and shall use detached content mode.

The signature is computed or verified as described in RFC 8152, section 4.4. The following additional requirements apply to the construction of Sig_structure:

All digital signatures in C2PA structures shall be a COSE_Sign1_Tagged structure as defined in RFC 8152, section 4.2. COSE_Sign1_Tagged contains a COSE_Sign1 structure. The following additional requirements apply to the construction of COSE_Sign1_Tagged:

When producing a signature, if the claim generator can also act as a validator, the claim generator should validate that the signing credential is acceptable according to Chapter 14, Trust Model and produce a warning if it is not. The claim generator may still allow signing with that credential if so desired. This may be desirable if it is known that the local claim generator’s validator has a different configuration than validators used by the expected audience of the asset.

When verifying a signature, an in-memory Sig_structure is generated. Its body_protected field is populated with the contents of the protected header bucket from the COSE_Sign1_Tagged structure (RFC 8152, section 4.4). For the payload field, if the payload was specified as present in the signature, it is populated from the payload field of the COSE_Sign1_Tagged structure. If the payload was specified as detached, the payload field of the COSE_Sign1_Tagged structure will be nil. In this case, the contents of the payload field of Sig_structure shall be populated from the same external source that was used in the generation of the signature. These are defined in the places where the digital signature is used in this specification.

A C2PA Manifest Consumer may wish to display an icon or logo for the signer. To locate such a graphic, it shall look inside the embedded certificate for a logotype as defined in RFC 9399. If no logotype is present, the Manifest Consumer may use icons or logos from other sources in an implementation-dependent manner.

A validator is a Manifest Consumer that will make some validation statements about that asset and its associated active manifest. The process for retrieving these statements is described in the validation section. 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 those statements and the contents of the asset itself.

Based on these statements, a C2PA Manifest may be one of the following:

If a validator reports that the portions of the asset that are covered by content bindings have not been modified since the active manifest was produced [Section 15.12, “Validate the Asset’s Content”], and its active manifest is either Valid or Trusted, then the asset itself is a Valid asset.

A C2PA Manifest is Well-Formed if validation determines that each of the following is true:

A C2PA Manifest is Valid if validation determines that each of the following is true:

If a C2PA Manifest is Valid, then the manifest’s claim can be attributed to the claim generator which is identified by the claim_generator_info field of the claim [Section 10.2.3, “Claim Generator Info”].

A C2PA Manifest is Trusted if validation determines that each of the following is true:

A validator shall maintain the following lists for C2PA signers:

In addition to the list of trust anchors provided in the C2PA Trust List, a validator should allow a user to configure additional trust anchor stores, 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.

A validator shall maintain a list of X.509 certificate trust anchors for Time Stamp Authorities, which shall be different than the lists for C2PA signers and will be referred to as the C2PA TSA Trust List.

In addition to the list of trust anchors provided in the C2PA TSA Trust List, a validator should allow a user to configure additional trust anchor stores, 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 Time Stamp Authorities.

A validator may also allow the user to create and maintain a private credential store of signing credentials. This store is intended as an "address book" of credentials they have chosen to trust based on an out-of-band relationship. If present, the private credential store shall only apply to validating signed C2PA manifests, and shall not apply to validating time-stamps. If present, 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 shall not be pre-configured with any entries in a private credential store.

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

X.509 certificates support revocation status queries. A claim generator should use the Online Certificate Status Protocol (OCSP, see RFC 6960) and OCSP stapling (as originally conceptualized in RFC 6066, Section 8, but implemented as described in this clause) to implement revocation. The claim generator shall not use Certificate Revocation Lists (CRLs, see RFC 5280). ``

A conforming CA should include an AuthorityInfoAccess (AIA) extension (RFC 5280, section 4.2.2.1) to provide access information for the OCSP service operated by the CA.

If the certificate has an AIA extension, revocation information shall be stored in an unprotected header of the COSE_Sign1 structure with the string label rVals and the value’s schema shall follow the rVals rule in Example 3, “CDDL for rVals”:

Before signing a claim, if a signer’s certificate has the AIA extension, a signer should query the OCSP service indicated therein, capture the response, and store it in an element of the ocspVals array of the rVals header.

The process for validating the revocation status of certificates is described in more detail in Validate the Credential Revocation Information.

Validation of a C2PA Manifest is a multi-step process that involves validating the assertions, claim & associated claim signature contained within it along with (for active manifests, only) validation of any associated hard bindings. This validation process is performed by a validator, which is a hardware or software actor that implements the validation algorithms described in this clause.

These phases, which are listed in no particular order, are described in the following clauses:

As described in Section 14.3, “Validation states”, a C2PA Manifest may be considered as Well-Formed, Valid or Trusted based on the results of these steps.

Figure 13, “Validating a Claim” is a visual representation of the process of validating a C2PA Manifest.

Various parts of the C2PA Manifest utilize a hashed_uri structure for encapsulating a URI, its hash and (optionally) the algorithm used to compute the hash. If there is an alg field in the hashed_uri structure, it shall be used as the hashing algorithm. If the alg field is not present in the hashed_uri structure, the hash algorithm shall be determined by evaluating the nearest enclosing structure that contains an alg field. If no alg field is found in any of these locations, the value of the alg field in the claim shall be used as the hash algorithm. If no alg field is present in any of these locations, the claim shall be rejected with a failure code of algorithm.unsupported.

Some parts of a C2PA Manifest utilize a hashed_ext_uri structure for encapsulating an external URI, its hash and the algorithm used to compute the hash. If there is an alg field in the hashed_ext_uri structure, it shall be used as the hashing algorithm. If the alg field is not present in the hashed_ext_uri structure, the failure code of algorithm.unsupported shall be used.

Once the hashing algorithm is determined, it shall be compared to the values in the allowed list or the deprecated list in Section 13.1, “Hashing”. If it is not present in either list, the claim shall be rejected with a failure code of algorithm.unsupported. If the algorithm is present in the deprecated list, the claim shall be issued an informational code of algorithm.deprecated.

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

As described previously, both standard and update manifests can be compressed. When a compressed manifest is encountered, a validator shall decompress it before proceeding with the standard validation process. If the data contained in the brob box of a compressed manifest is not either a standard or update manifest or if the decompression fails, the validator shall reject the manifest with a failure code of manifest.compressed.invalid.

A validator may wish to validate that the located C2PA Manifest Store is indeed the one associated with asset.

If the C2PA Manifest Store was located then the hard binding assertion present in its active manifest shall be used to validate that it is the matching manifest and whether the asset has been modified without manifest updates. If the hard binding does not match, it is unknown if that is because of (a) modification of the asset or (b) the wrong C2PA Manifest Store was located. Accordingly, the validator shall treat this as a non-matching hard binding and reject the manifest with a failure code of assertion.dataHash.mismatch if a data hash assertion is used, assertion.boxesHash.mismatch if a general boxes hash assertion is used, assertion.collectionHash.mismatch if a collection data hash assertion is used, or assertion.bmffHash.mismatch if a BMFF hash assertion is used.

Once the manifest to be validated has been located (hereafter referred to as the "current manifest"), the claim is found by locating, within the current manifest, the JUMBF Superbox with a label of c2pa.claim.v2 (or c2pa.claim for files with older claim structures) and a JUMBF type UUID of 0x6332636C-0011-0010-8000-00AA00389B71 (c2cl). Note that the JUMBF type UUID is the same for both the new (with c2pa.claim.v2 label) and old (with c2pa.claim label) claim formats. There shall only be one such box in the current manifest. If more than one is located, the C2PA Manifest shall be rejected with a failure code of claim.multiple.

If the content of the claim is not well-formed CBOR, the claim shall be rejected with a failure code of claim.cbor.invalid.

For a "c2pa.claim.v2", the following fields are expected to be present in the CBOR object. If any are absent, then the claim shall be rejected with a failure code of claim.malformed.

If the claim_generator_info field does not contain a name field, the claim shall be rejected with a failure code of claim.malformed.

If there is an icon field in the generator-info-map referenced by the claim_generator_info field of the claim-map or claim-map-v2, then its value shall be validated as described in Section 15.10.3.3, “Validation of References”.

A validator shall decode the OCSP response per the requirements of RFC 6960, in particular RFC 6960, section 3. If it is accepted and if all of the following requirements are met, then this establishes that the signer’s certificate was not revoked at the time of signing.

Validators shall check the revocationReason of any revoked response to disambiguate the removedFromCRL case from an actual revocation.

If the above conditions are met, the certificate shall be considered not revoked at the time of signing, the validator shall issue a signingCredential.ocsp.notRevoked success code. Otherwise the claim shall be rejected with a signingCredential.ocsp.revoked failure code.

If the rVals header is not present, or if the manifest does not have a time-stamp, the validator may choose to query the OCSP responder per the information in the AuthorityInfoAccess (AIA) extension (RFC 5280, section 4.2.2.1) of the Section 14.5, “X.509 Certificates”.

If the validator chooses not to perform an online OCSP check, it shall issue a signingCredential.ocsp.skipped informational code.

If the validator attempts to query the OCSP responder but is unable to receive a response, the validator shall issue a signingCredential.ocsp.inaccessible informational code.

If a response is received and accepted per the requirements of RFC 6960, it shall establish the signer’s certificate was not revoked at the time of signing if either of the following requirements is fulfilled:

And both of the following requirements are fulfilled:

If the certStatus field of the response is revoked but with a revocationReason that is not removeFromCRL, it shall establish the signer’s certificate was not revoked at the time of signing if both of the following requirements are met:

If the above conditions are met, the certificate shall be considered not revoked at the time of signing, the validator shall issue a signingCredential.ocsp.notRevoked success code.

Otherwise: . If the certStatus field of the response is unknown, the claim shall be rejected with a signingCredential.ocsp.unknown failure code. . Else, the certificate shall be considered revoked at the time of signing and the claim shall be rejected with a signingCredential.ocsp.revoked failure code.

A validator, when processing a claim, shall gather the set of redacted assertions for each ingredient’s manifest (if present) based on each JUMBF URI listed in its redacted_assertions field. A claim’s redacted_assertions field shall never include a JUMBF URI to any of its own assertions.

For more details, please see the Section 15.11.3.2, “Performing explicit validation” section.

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

An asset’s active manifest may list one or more ingredients, through the use of ingredient assertions. Some of those ingredients may have their own manifests associated with them, and some of those manifests may themselves have ingredients and ingredient manifests.

For any portions of an asset rendered for presentation to a user, including but not limited to audio, video, or text, the corresponding hard binding corresponding to the rendered content shall be validated in accordance with Section 9.2, “Hard Bindings”. If at any time content fails to be validated, the validator shall clearly signal to the user that some of the content does not match the claim, and if possible, should indicate what part of the content did not validate. If any content is absent for which content bindings exist, discovery of this absence is also a validation failure. The validator shall continue to report validation has failed, even if later portions of the content validate correctly.

For content that is not wholly available before rendering begins, such as during adaptive bitrate streaming (ABR) and progressive download, absence of not-yet-available portions of content is not considered a validation failure. As the content becomes available, the validator shall validate each portion of the content before it is rendered as previously described. In addition, the validator shall validate that the sequence of said content is the same as when the manifest was produced. Unless the player has explicitly signalled the validator that a discontinuity is expected (e.g., when the consumer performs a manual seek operation via the UI), the validator shall clearly signal to the user that an unexpected discontinuity has occurred whenever the sequence does not match. This includes validating that the location values for a given Merkle tree start at zero and increments by one for each following chunk; equivalently, the location value always indicates which chunk is being rendered.

For content that is to be validated during playback via progressive download, the leaf nodes of the merkle tree may align to synchronization points of the video track in the 'mdat' (e.g., the RAP points random access points). When the 'variableBlockSizes' are setup to achieve such alignment, validation during linear playback or seeking to desired playback time can be both achieved via the same sequence. The desired blocks shall be fetched, validated and the tracks within them selected for rendering.

For content that is intentionally not being rendered as the claim generator originally intended, such as during fast-forward, rewind, or playback at a different speed, the validator may not be able to validate the content. In this case, the validator shall clearly signal to the user that the content cannot be validated during the corresponding operation.

If the bmff-hash-map does not contain an exclusions field or that field’s value is not of type array with at least one entry, then the manifest shall be rejected with a failure code of assertion.bmffHash.malformed.

Determine the hash algorithm identifier (or possible failure code) by following the procedure in Section 15.4, “Determining the hashing algorithm”.

If the ending byte offset of one subset range (offset + length) is greater than the offset value of the next range in the array, or an offset or length value is negative, then the manifest shall be rejected with a failure code of assertion.bmffHash.malformed. The assertion.bmffHash.mismatch failure code is used for all other failures described in this section. Otherwise, the validator shall add the success code assertion.bmffHash.match to the list it eventually returns.

Once a standard manifest (and its bindings) has been located, the list of boxes to be validated shall be extracted from the boxes field of the box-map structure stored in the c2pa.hash.boxes assertion. If no such field is present, then the manifest shall be rejected with a failure code of assertion.boxesHash.unknownBox.

The boxes shall appear in the asset in the same order that they appear in the boxes array, including the box containing the C2PA Manifest. If there are any other boxes present in the asset, then the manifest shall be rejected with a failure code of assertion.boxesHash.unknownBox. If the boxes appear out of order, or any of the hash values do not match, then the manifest shall be rejected with a failure code of assertion.boxesHash.mismatch. Otherwise, the validator shall add the success code assertion.boxesHash.match to the list it eventually returns.

If the hash algorithm specified in any alg field does not appear in the allowed or deprecated list in Section 13.1, “Hashing”, or an alg field does not appear in either the box-map or any specific box-hash-map, then the manifest shall be rejected with a failure code of algorithm.unsupported.

If any box-hash-map in the boxes array does not contain a names field, then the manifest shall be rejected with a failure code of assertion.boxesHash.unknownBox.

For each box listed in the names and boxes array, the specified hash algorithm shall be computed over the bytes of the box (along with any associated header). If there are multiple entries in a names array, the hash value for that 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.

If the hash field is not present, or any resultant hash does not match the value of the hash field for those boxes, then the manifest shall be rejected with a failure code of assertion.boxesHash.mismatch.

Information security is a principal concern of C2PA. C2PA maintains a threat model and security considerations for the C2PA specification. This effort complements other security-related work within C2PA. Associated documentation is currently in development and can be found at Security Considerations.

The C2PA is developing security considerations documentation that includes:

The C2PA builds security into our designs as they are being developed, but also expects that security design and threat modelling will continue as the system, ecosystem, and threat landscape evolve.

To this end, the C2PA uses a focused threat modelling process to support development of a strong security and privacy design. Outcomes of the effort directly support development of explicit threats and security considerations documentation, but also facilitate security thinking throughout the design process.

The threat modelling process combines synchronous (live) threat modelling sessions consisting of focused groups of subject matter experts (SMEs) with asynchronous development of content. The number of attendees in each synchronous session is kept small to promote efficient discussions, but all members of the C2PA have the opportunity to participate via either modality.

Like other security activities, we expect our threat modelling process to evolve with the C2PA ecosystem. Process documentation is considered a guide rather than a strict directive on how threat modelling works within the C2PA.

The C2PA Guiding Principles establish that C2PA specifications must be reviewed with a critical eye towards the potential abuse or misuse of the framework to cause unintended harms, threats to human rights, or disproportionate risks to vulnerable groups globally.

To ensure that the C2PA is meeting this aspect of its principles, the harms, misuse, and abuse assessment aims to identify and address potential concerns during the specifications development and as encountered in subsequent implementations.

In addition, the specifications are being reviewed to:

The harms, misuse, and abuse assessment is an ongoing process. The information presented in the Harms Modelling documentation should not be considered the end result of a comprehensive evaluation, but as a basis for ongoing discussions centered on impacted communities, and aimed at mitigating potential abuse and misuse and protecting human rights.

There are two critical aspects of the approach:

Harms modelling focuses on analysing how a socio-technical system might negatively impact users, other stakeholders or broader society, or otherwise create or re-enforce structures of injustice, threats to human rights, or disproportionate risks to vulnerable groups globally. The process of harms modelling systematically requires combining knowledge about a system architecture and its user affordances with historical and contextual evidence about the impact of similar existing systems on different social groups and participatory consultation with a range of communities who may be implicated by the system. This combined information frames the ability to anticipate harm and proactively identify responses.

The Harms Modelling documentation describes the framework and the process carried out to date, followed by the methodology, an overview of the assessment, an outline for public review and feedback, and due diligence actions being developed to accompany version 1.0 of these specifications, its implementations and evolution.

The harms, misuse and abuse assessment has informed, and should continue to inform, the development of the C2PA technical specifications as well as its accompanying documentation:

In addition, the harms, misuse and abuse assessment should inform the governance of the Coalition and guide potential multilateral cooperation for the promotion of a diverse C2PA ecosystem that pushes for the optimization of the benefits in terms of trust in media, user control and transparency that prompted the development of the C2PA specifications.

In some use cases, a given assertion, such as an actions assertion, 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, spatial, textual or a combination of them. A region definition serves that purpose.

The most important part of the region definition is the range field which is used to describe a temporal range, a spatial range, a frame range, a textual range or a combination of them, for the region.

A region may also contain one of more common fields:

Older versions of this specification included a role field. This field has been deprecated and shall no longer be included when generating a region of interest.

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

A series of examples in CBOR Diagnostic Format (.cbordiag) are shown below:

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.

The CDDL Definition for the assertion-metadata-map rule is found in CDDL for Assertion Metadata:

An example in CBOR-Diag:

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.

This dataSource field is an optional field that allows the claim generator to inform downstream Manifest Consumers about the source from which the assertion contents originated. If no dataSource is provided for a given assertion, the dataSource is considered to be the Signer.

The value of the field is a dataSource object that is composed of two fields: type and details.

The dataSource type field defines the type of the dataSource. It is assembled with labels in the format described in Section 6.2, “Labels”. The value can be one of the following specification-defined values from Table 5, “Data source types”, or entity-specific namespaces can be used as an extension mechanism.

The details field is a human-readable string that provides additional information about the dataSource, e.g., the name of the API used to provide the assertion contents, or the URL of the server from which the contents were provided. For example, a broad location assertion source may have a type value of remoteProvider.3rdParty, with the details value set to www.googleapis.com/geolocation/v1/geolocate.

When present, the reviewRatings array provides a place for the claim generator to provide one or more rating objects on the quality (or lack thereof) of an assertion. A reviewRatings shall not be present if a dataSource object is present with a type field whose value is either humanEntry.anonymous or humanEntry.credentialed.

The value field of the rating object shall be present with any integer value from 1 (worst) through 5 (best). If present, the explanation field shall contain a human-consumable string description of the type of rating. In addition, an optional machine-readable code field which defines assertion-specific evaluation outcome codes may be provided. The value of the code field is defined using the same format described in Section 6.2, “Labels”. The value can be one of the following specification-defined values from Table 6, “Values of code field”, or entity-specific namespaces can be used as an extension mechanism.

Because the reference field of the assertion metadata assertion is a standard hashed_uri, it is also possible to have an assertion metadata assertion refer to assertions in other manifests than the active one. For example, the active manifest may include an assertion metadata assertion that validates the c2pa.metadata assertion present in an ingredient’s manifest.

If a dateTime field is present, its value shall be a date time string that complies with ISO 8601.

The assertion may be specific to only a portion of an asset - such as a range of frames in a video or a specific area on an image. Such a portion may be identified using a regionOfInterest field, whose value is a region-map object (as defined in Section 18.2, “Regions of Interest”).

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 that 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 13.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. These excluded ranges shall be ordered by increasing start position and shall not overlap.

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 favour 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 15.10.3, “Assertion Validation”.

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

A data hash assertion shall not appear in a cloud data assertion.

A data hash assertion shall not be used with a compressed manifest.

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

An example in CBOR Diagnostic Format (.cbordiag) is shown below:

Normally, the start and length values of an exclusion shall be written in their preferred serialization (i.e., "as short as possible"). However, when a data hash assertion needs to be created but the start and length values are not yet known, they shall be created "as large as possible", which would be as a 32-bit integer.

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. pad2 is an optional zero-filled byte string that is used if the desired padding cannot be achieved with pad.

When hashing a JPEG 1 (.jpg) file into which the C2PA Manifest will be embedded, the APP11 marker (FFEB) and the segment’s length (Lp) of all APP11 segments containing the JUMBF data shall be included in the exclusion range.

When hashing a PNG (.png) file into which the C2PA Manifest will be embedded, it is important that the Length and the 'caBX' (representing the chunk type) of the chunk containing the JUMBF data be included in the exclusion range.

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.v3.

A BMFF-based hash assertion shall 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 favour 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 15.10.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. These subset ranges shall be ordered by increasing offset value and shall not overlap.

In a c2pa.hash.bmff.v2 (deprecated) and c2pa.hash.bmff.v3 assertion, 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.

In addition, a c2pa.hash.bmff.v2 (deprecated) and c2pa.hash.bmff.v3 assertions includes the following features:

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.

Any given exclusion entry may match zero or more boxes. It is not required that an exclusion entry match exactly one box.

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 range(s) 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 A.4, “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 C2PA Manifest store size is reduced by using compressed manifest after the C2PA Manifest is created, a 'free' box shall be inserted in its place to ensure the offsets remain the same. 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 or the C2PA Manifest store size is increased, the 'free' box shall be shrunk (or removed) to compensate for the added data. However if there is insuffificent space in the 'free' box, a standard manifest shall be used.

Embedding C2PA data into a BMFF-based asset via MP4 boxes changes file offsets in other MP4 boxes as well as the absolute file byte offsets being included in the input data contributed to the hash for any root box. Those boxes and offsets shall 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.

There are two possible ways an implementation can ensure that post-embed values for all file byte offsets are hashed:

While the latter method is significantly more complex, it does enable correct hashing without any foreknowledge of the maximum manifest size. It also minimizes the final asset’s size. Common boxes (not exhaustive) with file offsets include 'iloc', 'stco', 'co64', 'tfhd', 'sidx', and 'saio'.

The schema for the c2pa.hash.bmff.v2 (deprecated) and c2pa.hash.bmff.v3 assertions are defined by the bmff-hash-map rule in the following CDDL Definition:

An example in CBOR Diagnostic Format (.cbordiag) for a monolithic MP4 file asset where the mdat box is validated as a unit is shown below:

An example in CBOR Diagnostic Format (.cbordiag) for an asset composed of fragmented MP4 files is shown below:

A pseudo-code implementation of this algorithm is in Example 6, “Pseudo-code for BMFF-based hash assertion”.

A example of generating a hash for the Merkle map is in Example 7, “A suggested example of a merkle map”.

Validating a given chunk requires first validating the merkle field’s initHash over the corresponding initialization segment and then locating the correct entry in the merkle field’s hashes array and validating it against the hash of the chunk’s data plus (if needed) deriving the hash using the other hashes specified in the chunk’s C2PA-specific box.

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 shall appear in the assertion in the same order that they appear in the asset, including the box containing the C2PA Manifest. If there are any other boxes present in the asset that are not explicitly included in this assertion, or if the boxes appear out of order, the manifest will be rejected during validation as described in Section 15.12.3, “Validating a general boxes hash”.

In the case where there are multiple instances of the same box type, such as multiple APP1 segments in a JPEG 1 file, each instance shall be listed separately in the assertion. JPEG segments that are fragments sharing the same segment identifier are also listed as separate boxes, with the exception of the segments comprising the C2PA Manifest Store (as described below).

The creation of the hashes is described in Section 13.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 Store (e.g. caBX for PNG, or 21FF for GIF) shall also be listed in its own array. 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 00 (a single byte with a value of 0). The C2PA Manifest Store shall be represented as a single box, even in the case of a JPEG file where the box is fragmented across multiple APP11 marker segments.

The pad value shall always be present and shall be a zero-filled byte string unless it was replaced by something else during multiple pass processing, in which case no pad shall be present.

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

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

Five examples in CBOR Diagnostic Format (.cbordiag) are shown in Example Boxes Hash:

In workflows where it is known in advance that the C2PA Manifest will refer to a collection of assets, instead of a single asset, the collection data hash assertion shall be used as the method to specify the hard bindings (i.e., cryptographic hashes) for the assets in the collection.

A collection data hash assertion shall have a label of c2pa.hash.collection.data.

A collection data hash assertion shall not appear in a cloud data assertion.

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

An example in CBOR Diagnostic Format (.cbordiag) is shown below:

The uris field consists of an array of uri-hashed-data-map values that represents a collection of assets. The alg field, is as described in Section 13.1, “Hashing” and by having it here ensures that all content items in the list are hashed with the same algorithm.

For each uri-hashed-data-map, the uri field shall be present and shall be a valid relative URI. All URIs shall be considered as relative to the location of the manifest, regardless of whether that is local, in a container (e.g., ZIP) or in the cloud. As a relative URI can contain navigation elements (e.g., ../), it is possible to refer to content items that are not in the same folder as the manifest - which would be a security issue. A claim generator shall validate or sanitize the URIs before use, ensuring that neither . nor .. appear as part of the URI.

The hash field is a byte string representing of the valid hash value for the content item, as determined by the alg field. The hash shall be over all bytes (from 0 to n) of the content item - no exceptions.

The rest of the fields are identical to those of an ingredient assertion.

Each file in the collection shall be hashed individually using the specific hash algorithm defined in the alg field. The resultant hash value shall be stored in the hash field of the uri-hashed-data-map associated with the uri to the file.

Not all files in a given hierarchy are required to be included in a hashed collection.

If a claim generator will be providing a soft binding for the asset’s content, it shall be described using a soft binding assertion. The types of soft bindings which may be created and stored in such an assertion are described in Section 18.9, “Soft Binding”.

A previous version of this specification provided a url field to provide a pointer to where the hashed data may 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 15.10.3, “Assertion Validation”.

A previous version of this specification provided an extent field within the scope field to describe a portion of the digital content covered by the soft binding assertion, in an algorithm specific format. This field is now deprecated in favor of the region field. Claim generators shall not add this field to a soft binding assertion, and consumers should ignore the field when present. This does not affect inclusion of the field as part of the content being validated as described in Section 15.10.3, “Assertion Validation”.

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

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

An example in CBOR Diagnostic Format (.cbordiag) is shown below:

The soft binding algorithm used shall be present as the value of the alg field, and the blocks over which is was applied shall be listed in the blocks field. If the algorithm used requires any additional parameters, they should be present as the value of alg-params.

The scope field may contain either a region or timespan field to describe the portion of digital content that the soft binding has been computed over. The region field, when present, contains a region-map object (as defined in Section 18.2, “Regions of Interest”). The timespan field, when present, describes the time interval over which the soft binding was computed in milliseconds from the start of the content.

The soft binding algorithm list is a machine readable list of permissible values for the alg field. The alg field shall correspond to the alg field of an algorithm present in that list. The format of alg-params and value fields are algorithm specific and described via a human readable information page referenced by informationalUrl within the entry for alg in the list.

The list is maintained as a JSON document by the C2PA at the following location: https://github.com/c2pa-org/softbinding-algorithm-list

Entries in the soft binding algorithm list that have a deprecated field of true shall be considered deprecated and shall not be used to create soft binding assertions in manifests. Soft binding algorithms marked deprecated may be used for resolving soft bindings but this behaviour is discouraged.

The JSON schema for entries within the soft binding algorithm list is shown below:

An JSON example of a entry in the soft binding algorithm list is shown below:

The unique name of the algorithm is given in the alg field, and corresponds to the string that shall be used in the alg field a soft binding assertion that uses that algorithm. The name shall follow the namespacing requirements and represent the owner of the algorithm. A unique numeric identifier is also assigned for each algorithm. If different versions of an algorithm are provided, then each shall have a separate entry in the Soft Binding Algorithm List.

The type of the algorithm shall be either 'watermark' or 'fingerprint' to represent that the algorithm is an invisible watermark, or a fingerprint.

The deprecation status of the algorithm is given in the deprecated field. A validator should not resolve any soft-bindings that use deprecated algorithms. C2PA Manifests shall not be written using deprecated soft-bindings.

The soft binding algorithm list entry shall contain a list of supported media types either as encodedMediaTypes or as decodedMediaTypes. The supported media types for decodedMediaTypes shall correspond to one more of the top-level IANA media types comprising of: "application", "audio", "image", "model", "text", "video". The supported media types for encodedMediaTypes shall correspond to one more of the registered IANA subtypes of a decodedMediaType listed in the preceding sentence. These IANA top-level and subtypes are listed at https://www.iana.org/assignments/media-types/media-types.xhtml

Additional information shall accompany each entry in the soft binding algorithm list, within the entryMetadata field. These are a human readable description of the algorithm (description), and the date it was proposed for entry into the soft binding algorithm list (dateEntered).

The contact details of the owner of the entry shall be provided as an email address (contact, required). An informational URL (informationalUrl, required) shall be provided that references a human readable page describing characteristics of the soft binding algorithm. The information at that page is unconstrained but might include details such as how to interpret the value field in the soft binding registry, which is encoded in an algorithm specific form.

The soft binding algorithm list entry may contain a list of URIs of soft binding resolution APIs in the softBindingResolutionApis field. The soft binding resolution API provides a mechanism for resolving soft bindings to manifests. If several URIs are given then any may be used for a soft binding resolution.

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 shall not refer to an assertion with the label c2pa.hash.data, c2pa.hash.boxes, c2pa.hash.collection.data, c2pa.hash.bmff.v2 (deprecated), or c2pa.hash.bmff.v3.

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

An example in CBOR Diagnostic Format (.cbordiag) is shown below:

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 10.3.2.2, “Adding Ingredients”), one should 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 shall be the bits of a file (such as a raster image) in whatever format is desired by the claim generator. The JUMBF Embedded File content type, bfdb, shall be used to contain the thumbnail’s data.