Endorsement Assertion

An endorsement is a way of indicating approval for specific actions made on content after it has had a C2PA Manifest attached. (See Section 4, “Generating an endorsement”.) The endorsement assertion is where an endorsement from the signer of an ingredient C2PA asset (known here as an endorser) is stored. These endorsements are typically provided (out-of-band of this specification) by ingredient C2PA asset signers to actors those signers trust to perform the actions listed in the assertion (known here as endorsees). They are used by a validator when assessing whether the actions of the active C2PA Manifest are “endorsed” or not. (See Section 5, “Validation”.)

Version 1.0 Draft 05 May 2024 · Version history

Maintainers:

License

This specification is subject to the Community Specification License 1.0.

Additional information about this specification’s scope and governance can be found at the project’s GitHub repository (creator-assertions/endorsement-assertion). The Community Specification License documents at the root of that repository are the authoritative governance documents for this specification.

Contributing

This section is non-normative.

This specification is an active working draft. If you wish to contribute to its development, you are invited to:

Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. No party shall not be held responsible for identifying any or all such patent rights.

Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.

This document was prepared by the Creator Assertions Working Group.

Known patent licensing exclusions are available in the specification’s notices.md file.

Any feedback or questions on this document should be directed to the specifications repository (GitHub: creator-assertions/endorsement-assertion).

THESE MATERIALS ARE PROVIDED “AS IS.” The Contributors and Licensees expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. IN NO EVENT WILL THE CONTRIBUTORS OR LICENSEES BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Table of contents

1. Introduction

This section is non-normative.

1.1. Scope

For purposes of the Community Specification License, the scope.md document at the root of this project’s GitHub repository is the governing document of this specification’s scope.

1.2. Overview

Endorsements are a way of indicating approval of three possible actions (see Section 4.3, “Permitted actions”) that could be applied to an C2PA asset described by a C2PA Manifest in which the C2PA asset is used as an ingredient.

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

1.3. Use case

As one example, an endorser may want to endorse another party, such as a content-distribution network, who will transcode its C2PA asset as part of a publication workflow. The endorser creates an endorsement that identifies the transcoder, and conveys the endorsement to them in some method that is out-of-band from this specification. When the transcoder creates their C2PA asset containing the ingredient, they include the endorsement as an endorsement assertion, which lets the C2PA Manifest consumer know that the actions they performed have been endorsed.

2. Normative references

3. Terms and definitions

3.1. Actor

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.

An organization or group of actors may also be considered an actor.

3.2. C2PA asset

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

For the purposes of this definition, we will extend the typical definition of “file” to include cloud-native and dynamically-generated data.

The definition of “C2PA asset” in this specification differs from the definition of “asset” given in the C2PA technical specification. A “C2PA asset” as defined in this specification MUST contain a C2PA Manifest.

3.3. C2PA Manifest

The set of information about the provenance of a C2PA asset based on the combination of one or more assertions, a single C2PA claim, and a claim signature.

See Section 11, “Manifests,” of the C2PA technical specification.

3.4. Endorsee

An actor who receives an endorsement to perform a limited set of actions.

3.5. Endorsement

A signed credential intended to convey approval from an endorser to perform a limited set of actions on C2PA assets on their behalf. Endorsements are not constrained to specific C2PA assets.

3.6. Endorser

An actor who provides an endorsement authorizing an endorsee to perform a limited set of actions on any C2PA asset signed by the endorser.

4. Generating an endorsement

4.1. Endorser workflow

Any actor MAY choose to become an endorser by producing the following outputs:

An endorsement does not convey permission to perform these actions on any specific C2PA asset. Therefore, an endorsement MUST NOT be included in any C2PA Manifest or C2PA asset created by the endorser. It SHOULD be provided separately to the endorsee.

The relationship among endorser, endorsee, and the endorser’s C2PA Manifest is represented by the following diagram, which is non-normative:

erDiagram er["Endorser"] { x509-cert signingCredential } em["Endorser’s C2PA manifest"] { assertions anyAssertions cose-sig claimSignature } oa["Endorser’s C2PA asset"] { c2pa-manifest manifest } e["Endorsement"] { der endorseeCredential date notValidBefore date notValidAfter cose-sig endorsementSignature } ee["Endorsee"] { x509-cert signingCredential } er ||--|| em: "creates and signs" er ||--|| e: "creates and signs" em ||--|| oa: "describes" e ||--|| ee: "identifies"

4.2. Endorsee workflow

An endorsee, once in possession of a C2PA asset and an endorsement signed by the same actor that signed the C2PA asset’s C2PA Manifest, MAY choose to perform one or more of the actions permitted in Section 4.3, “Permitted actions”, and describe those actions in a new C2PA Manifest.

The endorsee MAY include the endorsement by adding an endorsement assertion in the new C2PA Manifest’s assertion store.

Before generating an endorsement assertion, the endorsee MUST ensure that:

The endorsement assertion MUST have a label of cawg.endorsement. The assertion contents MUST be a COSE_Sign1_Tagged structure that is created as defined in Section 4.4, “Endorsement COSE payload”.

There MUST NOT be more than one endorsement assertion in any C2PA Manifest.

The relationship between the endorser’s C2PA asset and the endorsee’s C2PA asset is illustrated by the following diagram, which is non-normative:

erDiagram oa["Endorser’s C2PA asset"] { c2pa-manifest manifest } aa["Actions assertion"] { list actionsPerformed } ia["Ingredient assertion"] { ref endorsersAsset } e["Endorsement"] { any endorseeCredential date notValidBefore date notValidAfter cose-sig endorsementSignature } ea["Endorsement assertion"] { ref endorsement } ee["Endorsee"] { x509-cert signingCredential } eas["Endorsee’s C2PA asset"] { c2pa-manifest manifest } eem["Endorsee’s C2PA manifest"] { assertion ingredients assertion actions assertion endorsement cose-sig claimSignature } oa ||--|| ia: "referenced by" ee ||--|| eem: "creates and signs" ee ||--|| aa: "creates" e ||--|| ea: "included in" aa ||--|| eem: "included in" ia ||--|| eem: "included in" ea ||--|| eem: "included in" eem ||--|| eas: "describes"

4.3. Permitted actions

The c2pa.actions assertion in a C2PA Manifest containing an endorsement assertion MAY contain any of the following action codes:

  • c2pa.published

  • c2pa.transcoded

  • c2pa.repackaged

The actions assertion MUST NOT contain any other action codes.

4.4. Endorsement COSE payload

Endorsements are COSE objects (see Section 13.2, “Digital Signatures,” of the C2PA 2.0 Technical Specification), where the COSE payload is an “endorsement target” data structure encoded as CBOR, as shown below. The endorseeCredential field is an object with a single field, labelled according to the type of credential used to sign the endorsement. The label of this field indicates to validators the type of the credential present, so that they know how to decode, parse and validate the credential correctly. The following table details the format of each of the currently specified credential types:

4.4.1. Endorsement credential types

Credential name CBOR label Value type Compares To

Reserved

0

Reserved (deprecated)

1

This CBOR label was used in a prior version of the endorsement assertion specification and should no longer be used.

n/a

X.509 Certificate Hash

2

A SHA-256 hash of the endorsee’s X.509 certificate chain that will be used for signing the claims of C2PA assets that this endorsement is expected to be used with.

The value of the credential shall be compared (bitwise identical) to a SHA-256 hash of the entire certificate chain located in the x5chain or 33 (integer) COSE header of the active C2PA Manifest claim signature. (See Section 14.6, “X.509 Certificates,” of the C2PA 2.0 Technical Specification.)

Endorsers SHALL place the credential of the signer they are endorsing (the endorsee) and its type in the endorseeCredential. To limit the length of time that an endorser is lending their endorsement to the endorsee, the notValidBefore and notValidAfter fields MUST contain ISO 8601 date times.

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

endorsement-target-map = {
  "endorseeCredential" : public-credential, ; a DER-encoded SubjectPublicKeyInfo containing the public key
  "notValidBefore": tdate, ; the date-time that this endorsement valid from; before this time it is not valid
  "notValidAfter": tdate ; the date-time that this endorsement expires and is no longer valid
  ? "metadata": $assertion-metadata-map, ; additional information about the assertion
}

public-credential = {
  $credential-type: any ; an extensible field allowing the specification of the credential payload
}

$credential-type /= 1 ; credentials with this type are a DER-encoded ASN.1 SubjectPublicKeyInfo structure, as a bstr (specification text for usage)

An example endorsement target is shown below:

{
  "endorseeCredential": {
    2: 'A SHA-256 hash of endorsee’s X.509 certificate chain'
  },
  "notValidBefore": 0("2021-03-21T20:04:00Z"),
  "notValidAfter": 0("2022-03-21T20:04:00Z")
}

To sign an endorsement, follow the procedure specified in Section 13.2, “Digital Signatures,” of the C2PA 2.0 Technical Specification, using the serialised CBOR endorsement-target object as the contents of the payload field. An endorser SHALL NOT include a x5chain header and value, as endorsements are validated in the context of their use as an ingredient, and therefore use the signing credential of that ingredient C2PA Manifest. (See Section 5, “Validation”.)

The serialized COSE_Sign1_Tagged structure resulting from the digital signature procedure is the endorsement that MAY be conveyed to the endorsee identified in the endorsement-target, but the process for conveying it is out of scope of this specification.

5. Validation

Validation of an endorsement assertion SHALL only be attempted if the active C2PA Manifest first meets a number of conditions:

For each action object in the actions assertion:

  1. Check that the action field is set to c2pa.published, c2pa.transcoded, or c2pa.repackaged. If any other action is present, fail the endorsement assertion validation process for this C2PA Manifest and do not proceed with further validation.

  2. Check the ingredient field that is a member of the parameters object for the presence of a JUMBF URI. If the JUMBF URI is not present, or cannot be resolved to the related ingredient assertion, fail the endorsement assertion validation process for this C2PA Manifest and do not proceed with further validation.

  3. Follow the JUMBF URI link in the ingredient field to the ingredient assertion. Check that the URI link resolves to the single ingredient assertion in the active C2PA Manifest. If it does not, fail the endorsement assertion validation process for this C2PA Manifest and do not proceed with further validation. Check that the relationship field is parentOf. If it is not, fail the endorsement assertion validation process for this C2PA Manifest and do not proceed with further validation.

  4. Check the c2pa_manifest field in the ingredient assertion for the presence of a hashed URI. If the hashed URI is not present, or cannot be resolved to a C2PA Manifest, fail the endorsement assertion validation process for this C2PA Manifest and do not proceed with further validation.

  5. Follow the JUMBF URI link in the c2pa_manifest field to the ingredient’s C2PA Manifest. Ensure that this ingredient C2PA Manifest has been validated according to Section 15.8, “Recursively validating integrity of ingredients,” of the C2PA 2.0 Technical Specification, but do not skip the establishing of signer credential trust. If it does not validate, fail the endorsement assertion validation process for this C2PA Manifest and do not proceed with further validation.

  6. Validate the endorsement as described in Section 15.4, “Validate the signature,” of the C2PA Technical Specification, using the credential of the ingredient C2PA Manifest signer. If a signing credential is present in the endorsement’s signature’s headers, it shall not be used for validation. If validation fails, fail the endorsement assertion validation process for this C2PA Manifest and do not proceed with further validation.

  7. Validate the endorsement-target payload itself, following the steps below:

    1. Compare the endorseeCredential to the SHA-256 hash of the credential of the active C2PA Manifest signer, according to the table found in Section 4.4.1, “Endorsement credential types”. If the comparison fails, fail the endorsement assertion validation process for this C2PA Manifest and do not proceed with further validation.

    2. If the active C2PA Manifest is timestamped, then the time-stamp must fall within the endorsement’s validity time range. If it does not, fail the endorsement assertion validation process for this C2PA Manifest and do not proceed with further validation.

    3. If the active C2PA Manifest is not timestamped, then the time of validation must fall within the endorsement’s validity time range. If it does not, fail the endorsement assertion validation process for this C2PA Manifest and do not proceed with further validation.

If all steps above have been completed without failure, the endorsement assertion SHOULD be considered valid.

Appendix A: Version history

This section is non-normative.

28 February 2024

04 March 2024

  • Promoted from pre-draft to draft status.

05 May 2024

  • Substantial rewrite, introducing the terms endorser and endorsee, and clarifying the workflow for each role.