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 a claim in a C2PA Manifest. 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 type of transformation that alters either the intent or meaning or both of the digital content.

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 created using the private key owned by 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 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 use them to sign claims.

A C2PA-managed list of X.509 certificate trust anchors that issue certificates to Time Stamping Authorities (TSAs).

A Durable Content Credential is a Content Credential for which there exists one or more soft bindings that enable its discovery in a manifest repository.

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 introduces several new features and enhancements to the C2PA Specification, focusing on expanding support for various asset types, improving validation processes, and refining existing assertions and actions. Key highlights include:

This version focuses on both technical and editorial changes to the specification to clarify some of the new features of 2.1, while addressing requests from implementers. The specification has been updated to reflect the latest best practices in the field.

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 are normally 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.

When resolving an internal JUMBF URI reference, if any label in the path is ambiguous due to multiple child boxes having the same label, a validator shall treat the reference as unresolved.

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.5, “Embedding manifests into BMFF-based assets”.

The details on how to hash individual segments for live video can be found here.

For unstructured text assets that have a C2PA Manifest embedded using Unicode Variation Selectors as described in Section A.7, “Embedding Manifests into Unstructured Text”, a data hash assertions shall be used. This assertion provides a hard binding mechanism specifically designed for text content where the C2PA Manifest is embedded as a sequence of non-rendering Unicode characters.

Normative references: Unicode Standard, Ch. 23 (Variation Selectors)

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.

One of the capabilities of a hard binding is that it can exclude parts of an asset, for various reasons. However, a Claim Generator should, where possible, include asset metadata (i.e., metadata outside a C2PA Manifest such as EXIF or XMP) in the hard binding, in order to protect its integrity throughout the asset’s lifecycle.

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.

Soft bindings are described using soft binding assertions such as a fingerprint computed from the digital content or an invisible watermark embedded within the digital content. These soft bindings enable digital content to be matched even if the underlying bits differ.

Additionally, if a C2PA manifest is 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.

Soft bindings are generated by an algorithm named in the `alg' field of the soft binding assertion. The algorithm name should be among those 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 diagnostic notation (RFC 8949, clause 8):

The alg field shall contain the hash algorithm used to compute the hash for any hashed-uri, hard binding assertion, or hash assertion that does not explicitly define it. The value of this field, if present, shall be a string that is one of the allowed hash algorithms as defined in Section 13.1, “Hashing”. If the alg field is not present, then each hashed-uri, each hard binding assertion, and each hash assertion shall explicitly declare which hashing algorithm is to be used.

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 and it shall contain an absolute URI reference to the claim signature in the same C2PA Manifest.

The created_assertions field shall be present and it shall contain one or more URI references to assertions being made by this claim. In a standard manifest, it shall contain, at minimum, a reference to an assertion that represents a hard binding.

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

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

A specVersion field may be present, and if so, shall contain a SemVer formatted specVersion field which represents the version of this specification that was used to create this C2PA Manifest.

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

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. In addition, it shall not contain a c2pa.hash.multi-asset assertion.

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 may contain either a time-stamp assertion, a certificate status assertion or both.

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.

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

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:

A claim generator may also wish to establish a "claimed time of signing" by adding an iat protected header, whose value is a NumericDate. If present, it shall represent the time at which the signature was generated.

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 information for evaluating C2PA signers:

An individual trust anchor configuration shall include the X.509 certificate for that trust anchor. Additionally, the configuration should include a "notBefore" date/time, before which there is no trust for that trust anchor configuration. If the trust for that trust anchor configuration has ended, it should also include a "notAfter" date/time, after which there is no trust for that configuration.

If a "notBefore" date/time is present, the trust anchor configuration shall not be used for claim signatures whose timestamp (or current time, if no timestamp is present) is before that date/time. If a "notAfter" date/time is present, the trust anchor configuration shall not be used for claim signatures whose timestamp (or current time, if no timestamp is present) is after that date/time.

For the c2pa-kp-claimSigning (1.3.6.1.4.1.62558.2.1) EKU, the list of trust anchor configurations shall include, but need not be limited to, the signer trust anchor configurations provided by C2PA (i.e., the C2PA Trust List).

In addition to the list of trust anchor configurations for the c2pa-kp-claimSigning EKU provided in the C2PA Trust List, a validator should allow a user to configure additional trust anchor configurations for that EKU and/or for other EKUs (e.g., id-kp-emailProtection (1.3.6.1.5.5.7.3.4) or id-kp-documentSigning (1.3.6.1.5.5.7.3.36)). A validator 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 Stamping Authorities (TSAs), which shall be separate from the lists for C2PA signers. This list shall include, but need not be limited to, the Time Stamping Authority trust anchors provided by the C2PA (i.e., 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 TSA 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 Stamping 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 credentials 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, 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, RFC 5280). ``

A conforming CA should include an AuthorityInfoAccess (AIA) extension (RFC 5280, section 4.2.2.1) in their issued certificates 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 claim generator 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 claim generator should do the same for any intermediate CA certificates it includes with the claim signature.

Upon receipt of the claim, stapled OCSP responses shall be validated according to section 3.2 of RFC 6960.

The process for validating the revocation status of a certificate after a claim has been signed 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.

The validation algorithm shall return a consolidated set of validation results for the all manifests in the asset’s C2PA Manifest Store, including the active manifest as well all other manifests in the C2PA Manifest Store that are referenced via ingredient assertions.

Validation results are expressed via a standard set of success, informational, and failure codes, as defined below in Section 15.2.2, “Standard Status Codes”. Custom status codes are also permitted, when a claim generator has a need to record some process-specific status information. Custom codes shall conform to the same syntax as entity-specific namespaces, e.g. com.litware.

When a claim generator adds an ingredient asset via an ingredient assertion, it shall act as a validator, and perform the full validation algorithm described in this section on the ingredient. The claim generator shall record the validation results of the ingredient, per the following CDDL Definition schema, as the value of the validationResults field in the ingredient assertion.

The validation results may also contain a SemVer formatted specVersion field which represents the version of this specification that was used as the basis for the validation procedure. It may also contain a trustListURI field, which is a URI that identifies the trust list that was used to validate the claim signature.

Each hard binding assertion has an alg field that specifies the hashing algorithm used to compute the hash of the asset. If the alg field is present, it shall be used as the hashing algorithm for the hard binding assertion. If no alg field is present in the hard binding assertion, the value of the alg field in the Claim shall be used as the hash algorithm. If no alg field is present in the Claim, the Claim shall be rejected with a failure code of algorithm.unsupported.

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 box 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 6332636C-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”.

All validators shall continue the process as follows:

At time of validation, when a time-stamp is present, trusted, and validated, validators shall use the attested time, and not the current time, when determining the time validity of the signing certificate and the time-stamp authority’s certificate.

If neither the sigTst nor the sigTst2 headers are present, or if at least one of them is present but their time-stamp token does not satisfy the above requirements, then the C2PA Manifest is valid if the current time at validation is within the validity period of the signer’s certificate and all CA certificates up to the trust anchor. If it is, the validator shall return a success code of claimSignature.insideValidity. If it is not, the C2PA Manifest shall be rejected with a failure code of claimSignature.outsideValidity.

A validator may choose to validate the "claimed time of signing" as attested by the value present in the iat protected header. If the iat header is present, the validator may validate that the attested time falls within the validity period of the signer’s certificate and all CA certificates up to the trust anchor, and not later than the time attested by any associated trusted time-stamp. If the validator does the validation of this value, and it falls inside the validity period, the validator shall return the timeOfSigning.insideValidity informational code, but if it falls outside the validity period, then the validator shall return the timeOfSigning.outsideValidity informational code.

A validator shall decode OCSP responses per the requirements of RFC 6960, in particular requirements 1 through 4 of section 3.2. If an OCSP response is accepted, and if all of the following requirements are met, then this establishes that the relevant 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 for any OCSP response in the C2PA Manifest Store, then the validator shall either issue a signingCredential.ocsp.notRevoked success code, indicating that the certificate is considered not revoked at the time of signing, or (for additional assurance) perform an online OCSP check as described in Section 15.9.2, “Determining revocation from online OCSP response”.

Otherwise, if an OCSP response in the C2PA Manifest Store meets all of the above conditions except that the certStatus field is revoked, the certificate shall be considered revoked and the claim shall be rejected with a signingCredential.ocsp.revoked failure code.

If, for a given certificate, no OCSP response in the C2PA Manifest Store satisfies the conditions in Section 15.9.1, “Determining revocation through OCSP responses in the C2PA Manifest Store”, or if the claim signature does not have a time-stamp, the validator may choose to query the OCSP responder, per RFC 6960, with the responder accessLocation found via RFC 6960, section 3.1.

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 1 - 4 of RFC 6960, section 3.2, 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, and the validator shall issue a signingCredential.ocsp.notRevoked success code.

Otherwise:

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, refer to 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 the standard hard binding does not validate, and a multi-asset hash assertion is present, it shall be validated as described in Section 15.12.4, “Validating a multi-asset hash”. 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.

For content with C2PA ContentProvenanceBox with box_purpose set to update presence, the active manifest is first searched in the C2PA ContentProvenanceBox with box_purpose set to update then in the C2PA ContentProvenanceBox with box_purpose set to original. If the active manifest is in the C2PA ContentProvenanceBox with box_purpose set to update, trace the ingredient parent chain (looking in either C2PA ContentProvenanceBox with box_purpose set to update or original as needed) until the first non update manifest is found. The BMFF hash of this manifest content shall be validated in accordance with Section 9.2, “Hard Bindings”. The addition of an C2PA ContentProvenanceBox with box_purpose set to update should not affect the hash calculation since it was added to the end of the file not changing any offsets.

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.

If a validator encounters exclusion ranges other than for just the C2PA Manifest Store and appropriate padding (e.g., zero’d data), such as for all or part of the asset metadata (as described in Section 9.2.6, “Binding Non-C2PA Asset Metadata”), the informational code assertion.bmffHash.additionalExclusionsPresent shall be issued.

The validator shall ignore the presence and contents of pad and pad2 fields.

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.

If the BMFF hashing process produces a assertion.bmffHash.mismatch failure code, then the validator shall look for presence of a multi-asset hash assertion. If one is present, the assertion.bmffHash.mismatch failure code shall not be issued, and instead the multi-asset hash assertion shall be validated as described in Section 15.12.4, “Validating a multi-asset hash”; otherwise, the manifest shall be rejected with a failure code of assertion.bmffHash.mismatch.

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

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, then the manifest shall be rejected with a failure code of assertion.boxesHash.mismatch.

The hash algorithm for each box-hash-map shall be determined by its alg field, or if that is not present, by the alg field in the containing box-map, or if that is not present, by the alg field in the Claim. If the hash algorithm is not specified in any of these places, or does not appear in the allowed or deprecated list in Section 13.1, “Hashing”, then the manifest shall be rejected with a failure code of algorithm.unsupported.

Refer to boxIndex to determine which box the exclusion ranges indicated in the exclusions field correspond to. If the box indicated by boxIndex does not exist, the manifest shall be rejected with a failure code of assertion.boxesHash.malformed. The start that indicates the beginning of an exclusion range specifies an offset measured from the start of the box indicated by boxIndex. If the ending byte offset of one exclusion range (start + length) is greater than the starting byte offset of the next exclusion range in the array, or a start or length value is negative, then the manifest shall be rejected with a failure code of assertion.boxesHash.malformed.

The validator shall ignore the presence and contents of pad and pad2 fields.

Follow the procedure in Section 15.4, “Determining the hashing algorithm” to determine the hash algorithm and any possible failure codes. The hash shall be computed over the bytes of the asset, except for the ranges specified in the exclusions field and any boxes where excluded field is true. If the end of an exclusion range falls beyond the end of the box that contains the exclusion range, then the manifest shall be rejected with a failure code of assertion.boxesHash.mismatch.

The combination of exclusion ranges and padding values, especially padding needed to support multi-pass processing workflows, may enable an attacker to replace parts of that padding with arbitrary data that could impact the consumption of the asset without invalidating the hash. For this reason a validator shall ensure that the data contained within the exclusion range including a C2PA Manifest Store consists only of the C2PA Manifest Store and appropriate padding (e.g., zero’d data) in clearly marked pad fields or free/skip boxes. Within other exclusion ranges than above C2PA Manifest Store, all or part of the asset metadata may also be included as described in Section 9.2.6, “Binding Non-C2PA Asset Metadata”. If a validator encounters any data other than those permitted above, then the manifest shall be rejected with a failure code of assertion.boxesHash.mismatch. If a validator encounters exclusion ranges other than that for the C2PA Manifest Store and appropriate padding (e.g., zero’d data) in clearly marked pad fields or free/skip boxes, an informational code assertion.boxesHash.additionalExclusionsPresent shall be set.

If the hash value for any box does not match, and that box does not have an excluded field with a value of true, then the manifest shall be rejected with a failure code of assertion.boxesHash.mismatch.

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

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. If the box hashing process produces a assertion.boxesHash.mismatch failure code, then the validator shall look for presence of a multi-asset hash assertion. If one is present, it shall be validated as described in Section 15.12.4, “Validating a multi-asset hash”, but if one is not present, 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 standard validation of the asset’s hard binding fails, and the asset contains a multi-asset hash assertion, then the validator shall proceed to validate the multi-asset hash assertion. If more than one multi-asset hash assertion is present, then the manifest shall be rejected with a failure code of assertion.multiAssetHash.malformed.

Validation of the multi-asset hash assertion (c2pa.hash.multi-asset) shall be performed by iterating over the array of parts in the multi-asset-hash-map. If the parts field is not present, or it is present with a value that is an empty array, then the manifest shall be rejected with a failure code of assertion.multiAssetHash.malformed.

For each part, the validator shall ensure that it contains both valid a locator and a valid hashAssertion field. If either of these are missing, then the manifest shall be rejected with a failure code of assertion.multiAssetHash.malformed.

If the locator is a byte-offset-locator, then the validator shall ensure that the byteOffset and length fields are present and non-negative. If these conditions are not met, then the manifest shall be rejected with a failure code of assertion.multiAssetHash.malformed.

If the locator is a bmffBox, then the validator shall ensure that the specified box is present in the asset. If the box is not present, then the manifest shall be rejected with a failure code of assertion.multiAssetHash.malformed.

Given a valid locator and hash, the validator shall attempt to locate the part using the locator information. If it is not present, and the optional field is either not present or present with a value of false, then the manifest shall be rejected with a failure code of assertion.multiAssetHash.missingPart. If the optional field is present with a value of true, then the validator shall skip over this part and continue with the next part.

If the located parts are overlapping or do not, in aggregate, cover every byte of the asset, then the manifest shall be rejected with a failure code of assertion.multiAssetHash.malformed.

For each located part, the validator shall compute the hash of the part using the specified algorithm & methodology (i.e., data hash, general box hash, or BMFF hash) over the bytes of the part. Any uses of absolute byte offsets in a part’s hash assertion (e.g., the start value in a data hash exclusion range) shall be interpreted relative to the beginning of that part. If the part is truncated (shorter than the length in the locator), or the resultant hash does not match the value present in the hard binding assertion referenced from the hashAssertion field, then the manifest shall be rejected with a failure code of assertion.multiAssetHash.mismatch.

If the hash assertion for each located part validates successfully, then the validator shall record the success code assertion.multiAssetHash.match and shall not record any failure codes associated with the asset’s hard binding.

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 shall 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 notation (RFC 8949, clause 8) 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 diagnostic notation (RFC 8949, clause 8):

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 CBOR date/times (RFC 8949, 3.4.1).