Identity Assertion

This specification describes a C2PA assertion that allows a named actor to document their relationship to a C2PA asset produced by them or on their behalf independently from the C2PA claim generator, and to allow consumers of a C2PA asset to independently verify that the received asset was in fact produced by the named actor and has not been tampered with.

This specification draws upon and extends existing work from two standards organizations:

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

The C2PA technical specification allows other standards bodies to define additional metadata that can be incorporated into a C2PA Manifest. These statements come in the form of a C2PA assertion.

This specification describes a specific C2PA assertion that can be added to a C2PA Manifest to allow an actor to prove control over an digital identity and to bind that identity to a C2PA asset (and, at their option, one or more C2PA assertions) produced by them or on their behalf.

The Trust over IP Foundation (ToIP) has developed a technical architecture specification for describing a decentralized digital trust infrastructure.

The ToIP architecture specification introduces the concept of verifiable identifier as follows:

This specification describes mechanisms to support two common individual and organizational identity mechanisms that fit the conceptual description of ToIP verifiable identifier:

Each identity assertion instance allows exactly one credential holder to sign a data structure known as signer_payload which will subsequently be included in a C2PA claim. The signer_payload and corresponding signature from the credential holder binds this identity assertion to a specific C2PA asset and allows the credential holder to endorse or make additional statements about the named actor’s relationship to that C2PA asset.

The credential holder’s signature should generally be construed as reflective of the named actor’s authorization of or active participation in the production of the the C2PA asset in which it appears, as described by the specific C2PA assertions that are referenced in the identity assertion.

This is intended to provide an additional trust signal over and above the signature provided by the C2PA claim generator, as illustrated in the following diagram, which is non-normative:

The C2PA claim, which is signed by the C2PA claim generator, contains a list of assertions which may contain any number of identity assertions.

Each identity assertion contains a signer_payload with hashlink references to one or more other C2PA assertions, known here as referenced assertions, and a signature from the credential holder over that payload, thus providing a non-repudiable, tamper-evident binding between the named actor and the list of referenced assertions.

This trust signal may be repeated any number of times to convey information specific to distinct named. The following diagram, which is non-normative, illustrates two credential holders, each independently signing different actions and metadata assertions:

The following is a non-exhaustive list of potential and general use cases for the identity assertion. Some of these are taken from, or built upon, the use cases developed within the Project Origin Alliance and the Content Authenticity Initiative (CAI) frameworks. Each use case will be described using some generic personas to help make the flow clear.

The following definitions are adapted from the glossary provided in the C2PA technical specification. This specification uses the prefix “C2PA” to denote data structures incorporated from that specification.

The following definitions are adapted from the Trust over IP (ToIP) technology architecture specification. This specification uses the prefix “ToIP” to denote concepts incorporated from that specification.

This specification defines a C2PA assertion known as an identity assertion which MAY be used to bind one named actor to a set of referenced assertions. This binding SHOULD generally be construed as authorization of or participation in the creation of the statements described by those assertions and corresponding portions of the C2PA asset in which they appear.

The identity assertion contains the following data fields:

The signer_payload field is a structure of type signer-payload-map which is signed by the credential holder. It contains the following fields:

The content of signature depends on the type of credential that is used. Valid credential types and the corresponding signature data structures and sig_type values are defined in Section 8, “Credentials, signatures, and validation methods”.

The identity assertion shall have a label of cawg.identity.

Multiple identity assertions may be used in the same C2PA Manifest to describe the distinct roles of multiple actors in creating a single C2PA asset. This is illustrated in the multi-author example from the conceptual overview. If this occurs, these assertions shall be given unique labels as described by Section 6.4, “Multiple instances,” of the C2PA technical specification.

The schema for this type is defined by the identity rule in the following CDDL definition:

Possible values for the sig_type field and the corresponding interpretations of the signature field are described in Section 8, “Credentials, signatures, and validation methods”.

The hashed-uri-map rule is defined in Section 8.3.1, “Hashed URIs,” of the C2PA technical specification.

Prior to presenting the credential holder with the signer_payload data structure for signature, the referenced assertions MUST themselves be created. This process is described in Section 10.3.1, “Creating assertions,” of the C2PA technical specification.

The list of referenced assertions MUST include the same hard binding assertion that is present in the C2PA claim itself. The list of referenced assertions SHOULD include any assertions necessary to allow the actor to accurately describe their relationship to the content. For example, a c2pa.actions assertion could be referenced to attest that the actor performed those specific actions.

The signer_payload data structure MUST be presented to be signed by the credential holder corresponding to each identity assertion. This process is described in more detail in Section 8, “Credentials, signatures, and validation methods”.

Once the signature is obtained, the identity assertion can be created and added to the C2PA Manifest’s assertion store, and then referenced in the C2PA claim. If a placeholder assertion was previously added to the C2PA claim, its content MUST now be replaced with the final assertion content as described below.

The signer_payload data structure MUST be unchanged from the data structure that was presented to the credential holder for signature.

The values for the sig_type and signature fields depend on the nature of credential used. Some common signature types are described in Section 8, “Credentials, signatures, and validation methods”.

The C2PA claim generator SHOULD independently validate the signature from the credential holder before proceeding.

If a placeholder assertion was used, the values of the pad1 and pad2 fields MUST now be recomputed (adjusted in size) such that the resulting identity assertion exactly matches the size in bytes of the placeholder assertion. If the signature exceeds the space available in the placeholder assertion, the claim generation process as described in Section 6.3, “Interaction with data hash assertion” MUST be repeated with a larger placeholder assertion.

If no placeholder assertion was used, the values of the pad1 and pad2 fields MAY be empty.

The pad1 and pad2 fields of an identity assertion MUST contain only zero-value (0x00) bytes.

The C2PA technical specification explains the need for pre-computing the C2PA asset’s final file layout when using a data hash assertion as follows:

Similarly, the size of the identity assertion cannot be known until its signature is obtained. Changing the size of the identity assertion after file layout is completed would invalidate the file offsets contained within the data hash assertion.

In this case, it is necessary to use a placeholder assertion to reserve space for the content of the final identity assertion (including its signature) which will be created later.

When using a data hash assertion, a C2PA claim generator MUST follow the process described in Section 10.3, “Creating a claim,” and Section 10.4, “Multiple step processing,” of the C2PA technical specification with additional steps as described below:

These steps are also represented by the following sequence diagram, which is non-normative:

An identity assertion MUST contain a valid CBOR data structure that contains the required fields as documented in the identity rule in Section 5.2, “CBOR schema”. The cawg.identity.cbor.invalid error code SHALL be used to report assertions that do not follow this rule. A validator SHALL NOT consider any extra fields not documented in the identity rule during the validation process.

For each entry in signer_payload.referenced_assertions, the validator MUST verify that the same entry exists in either the created_assertions or gathered_assertions entry of the C2PA claim. (For version 1 claims, the entry must appear in the assertions entry.) The cawg.identity.assertion.mismatch error code SHALL be used to report violations of this rule.

The validator SHOULD verify that no entry in signer_payload.referenced_assertions is duplicated. The cawg.identity.assertion.duplicate error code SHALL be used to report violations of this rule.

The validator MUST ensure that signer_payload.referenced_assertions contains at least one hard binding assertion as described in Section 9.2, “Hard bindings” of the C2PA technical specification. The cawg.identity.hard_binding_missing error code SHALL be used to report a missing hard binding assertion.

The validator MUST maintain a list of valid sig_type values and corresponding code paths for the signature values that it is prepared to accept. Validators SHOULD be prepared to accept all signature types described in Section 8, “Credentials, signatures, and validation methods”. The cawg.identity.sig_type.unknown error code SHALL be used to report assertions that contain unrecognized sig_type values.

The signature field of an identity assertion MUST contain a valid signature. The procedure for validating each signature type and corresponding status codes are described in Section 8, “Credentials, signatures, and validation methods”.

The pad1 and pad2 fields of an identity assertion MUST contain only zero-value (0x00) bytes. The cawg.identity.pad.invalid error code SHALL be used to report assertions that contain other values in these fields.

The set of standard success and failure codes for identity assertion validations are defined below. These follow the format defined by the section titled Section 15.1, “Status codes,” of the C2PA technical specification.

The url field for a status code MUST always be the label of the identity assertion. It is omitted from the tables below.

In some use cases, an actor in the system may wish to provide an X.509 certificate to have an organizational or individual identity described by the certificate associated with the list of referenced assertions.

The sig_type value for such an assertion MUST be cawg.x509.cose. The signature value MUST be a COSE signature as described below.

This section is non-normative.

Digital trust is typically described using a trust triangle as shown in the following diagram:

The three roles depicted can each be performed by a human, organization, machine, or some combination thereof. A credential holder establishes a relationship with a credential issuer. If the issuer trusts the credential holder, it will then issue a digital credential which makes statements about the credential subject (which may or may not be the same actor as the credential holder) and is signed by the issuer.

Later, the credential holder can then present this credential to a verifier (also often known as a “relying party”). If the verifier has an existing trust relationship with the credential issuer, then the verifier can choose to trust the credential and the statements made within it.

This pattern can be repeated if there is not a direct trust relationship between the verifier and issuer. The issuer itself might have a credential that is issued by another issuer that is known to the verifier as shown in the following diagram:

In this scenario, issuer 2 is playing a dual role as credential holder and credential issuer. The verifier does not have a direct relationship with the issuer of the credentials that were presented (issuer 2). However, it can inspect issuer 2’s credentials and find that they were issued by issuer 1, with whom it does have a direct relationship. Based on the nature of that relationship, it may choose to extend transitive trust to issuer 2 and thus to the credential that issuer 2 issued.

Web browsers provide a well-known example of transitive trust. Browsers have direct relationships with relatively few root trust anchors. Those anchors, known as root certificate authorities, in turn issue credentials to certificate authorities who then issue credentials to individual web site operators who then sign the content presented to a browser. This pattern may be repeated with multiple layers of intermediate certificate authorities. The web browser evaluates this entire chain of credentials when deciding whether to present a web site as trusted or not.

The signature in an identity assertion could be considered as a new credential documenting the relationship between named actor and C2PA asset, which will be referred to in this section as an asset-specific credential.

For each form of credential that an identity assertion consumer is prepared to accept, it SHOULD maintain:

There are a few possible relationships between the implementation of the identity assertion, named actor, and credential issuer, as documented in the following subsections.

This section is non-normative.

This section enumerates a number of potential attacks on the identity assertion trust model. If concrete guidance to mitigate or prevent a specific attack is available, that guidance should be incorporated as specific normative requirements elsewhere in this specification and referenced here.