Consent Assertion

The C2PA technical specification allows actors in a workflow to make cryptographically signed assertions about the produced C2PA asset.

This specification describes a C2PA assertion referred to here as the consent assertion that carries a signed, machine-readable reference from a digital asset to an authoritative source of consent and related permissions for that asset.

Version 1.0 Draft 12 July 2026 · Version history

This is a working draft of the first version of this specification and may be changed without warning.

License

This specification is subject to the W3C Patent Policy (2004).

For sample or reference code included in the specification itself, that code is subject to the Apache 2.0 license, unless otherwise designated. In the case of any conflict or confusion within this specification repository between the W3C Patent Policy (2004) or other designated license, the terms of the W3C Patent Policy (2004) shall apply.

These terms are inherited from the Decentralized Identity Foundation Project Charter.

Contributing

This section is non-normative.

This specification is an active working draft. If you wish to contribute to its development, please view the CAWG membership page.

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 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, a working group of the Decentralized Identity Foundation.

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

This specification defines a C2PA assertion, the consent assertion, that carries a signed, machine-readable reference from a digital asset to an authoritative source of consent and related permissions for that asset. The reference resolves to the source that holds the current terms.

This specification defines the reference and recommends what a consent authority should be able to express. It does not store consent, resolve conflicting claims, or enforce terms. Those functions belong to the referenced source and to the systems that consume the asset.

The consent assertion is a discoverable, machine-readable reference. It is informational and is not itself a license or a warranty. Any legal effect arises from the referenced source, for example a contract or an authoritative consent record, and not from this assertion.

2. Terms and definitions

The key words SHALL, SHALL NOT, SHOULD, SHOULD NOT, and MAY are interpreted as described in RFC 2119.

2.1. Terms defined in this specification

For the purposes of interpreting consent declarations in this specification, the definitions in this section govern unless otherwise stated.

The following terms are local to this specification:

  • Participant. A natural person.

  • Authorized representative. A party authorized to act on a participant’s behalf.

  • Consent assertion. The C2PA assertion defined here, carrying one or more consent references.

  • Consent reference. A pointer, carried within the CAWG-signed assertion, to an authoritative source of consent or permissions for the asset.

  • Consent authority. A service that holds and resolves the current consent terms a reference points to.

  • Asset consent. Terms governing use of the work, declared by a rights holder.

  • Identity consent. Terms governing use of a person’s name, image, likeness, voice, movement, mannerisms, or persona, declared by the subject of that identity.

  • Asset creator. A party that captures, renders, or encodes the file. An asset creator may be a person, an organization, or a system operated by a person or organization.

  • Rights holder. A person or entity that declares terms regarding a digital asset or an identity embodied in it. The term denotes the declaring party and does not constitute a determination of legal ownership, copyright status, or the validity of any underlying claim.

  • Subject. A human being whose identity is embodied in or associated with a digital asset. A subject may declare identity consent regarding that use.

  • Performer. A subject whose identity is embodied in the asset through their performance, including any combination of likeness, voice, movement, mannerisms, or persona. Every performer is a subject; a subject need not be a performer.

The terms participant and authorized representative are defined locally because the declaration rule in Section 4, “The consent assertion” depends on them. The terms asset creator, rights holder, performer, and subject are defined locally pending adoption of common definitions in the CAWG committee glossary. Upon adoption, the glossary definitions govern.

The term named actor is used as defined in the CAWG identity assertion specification, so that its definition remains consistent across all CAWG assertions. A named actor may be a natural person, an organization, or a non-human device.

3. Conceptual model

This section is non-normative.

Provenance and consent differ in kind. Provenance is append-only and immutable: the record of what was done to an asset does not change once written. Consent is append-only but mutable: a participant may grant, narrow, or withdraw terms over time, and within a given authoritative source the current state is the most recent state recorded by that source.

For this reason consent is referenced rather than embedded. The asset carries a signed pointer; the referenced source holds the live terms. Embedding the terms in the asset would freeze a value that is meant to change.

Consent has two domains, treated separately throughout this specification. Identity consent concerns a person’s likeness, voice, movement, mannerisms, or persona, and is associated with a participant. Asset consent concerns use of a work, and is declared by its rights holder, who may be a natural person or an organization. The normative declaration and binding rules for each domain appear in Section 4, “The consent assertion”.

A note on roles. The signer attests that the consent reference exists and is correctly bound to the asset and, for identity consent, to the participant. The signer does not declare the consent itself. The declaration lives at the authority and is made by the party entitled to make it: the participant or that participant’s authorized representative for identity consent, a rights holder for asset consent.

A consent assertion SHALL have the label cawg.consent and SHALL be expressed as a signer-attested assertion, carried as a CAWG metadata assertion, within a C2PA Manifest. The CAWG signer attests to the consent assertion; it is not a gathered assertion.

Within a single manifest there SHALL be at most one cawg.consent assertion, written at the defined label. All consent references contributed by that signer SHALL be carried within that single assertion, in the consent_references array defined in Section 4.2, “Consent references”, so that they appear at one defined location within the manifest. Where an asset’s provenance includes more than one manifest, and therefore more than one CAWG signer, a consumer assembles the complete consent picture by reading the cawg.consent assertion present in each manifest in the C2PA manifest store.

4.1. Declaration

A participant’s identity consent SHALL be declarable only by that participant or by that participant’s authorized representative.

Asset consent SHALL be declared by a rights holder for the work. A work MAY have more than one rights holder, and each MAY declare consent for the rights that holder controls. A rights holder MAY be a natural person or an organization, identified as a named actor.

An asset MAY carry one or more consent references within the cawg.consent assertion. Each consent reference SHALL contain:

  • uri: a URI, covered by the CAWG signature over this assertion, resolving to the authoritative source. The uri is a locator; any unique identifier for the record at the source is carried within the URI and is opaque to this specification.

  • reference_type: the kind of source referenced. This field describes the type of the reference, not its contents. Permitted values, defined locally pending adoption of common definitions:

    consent_authority

    a service that holds and resolves current consent terms;

    contract

    a record stating agreed terms between parties;

    permission_record

    another record expressing permissions for the asset.

  • consent_domain: the domain of the reference. Permitted values: identity, asset. This value determines the binding requirement in Section 4.3, “Binding”.

Each consent reference MAY contain:

  • supersedes_prior (default false): when true, the signer asserts that this declaration is inclusive of and supersedes prior declarations of the same type made under the same authority. The following rules govern this flag:

    1. The assertion is trusted to the extent the CAWG signer is trusted. It places the clearance burden on the signer as the last party to touch the asset before publication.

    2. A supersedes_prior assertion operates within the binding of Section 4.3, “Binding” and does not extend a grant beyond the terms held by the referenced authority.

    3. A signer may supersede only declarations made under its own authority. Independent, non-exclusive declarations made under different authorities coexist and are not superseded by this flag.

    4. For identity consent, the authority bound to the participant remains the source of the current terms regardless of a downstream signer’s assertion. A later signer cannot widen a participant’s grant by asserting supersedes_prior.

    5. The participant or the participant’s authorized representative may grant, extend, narrow, or withdraw terms at that authority at any time; such changes take effect in the authority’s record and are visible through existing references without modification to the asset.

Each consent reference SHOULD carry the binding appropriate to its domain:

  • For identity consent, the reference SHALL contain bound_actor: a reference to the cawg.identity assertion of the named actor, the participant, to whom the consent applies.

  • For asset consent, the reference binds to the asset carrying the manifest, and MAY contain asset_creator: a reference to the cawg.identity assertion of the asset-creator named actor. No person-shaped binding is required for asset consent.

Each consent reference SHALL identify the asset to which it applies by reference to the asset’s C2PA content binding (the hard binding, and a soft binding where present), in addition to its placement within the asset’s manifest. This allows a consent reference encountered apart from its manifest to be matched to its asset.

Consistent with existing CAWG practice, a consent reference is associated with a named actor by reference to that actor’s cawg.identity assertion.

{
  "consent_references": [
    {
      "uri": "https://authority.example.org/identity/{record-id}",
      "reference_type": "consent_authority",
      "consent_domain": "identity",
      "supersedes_prior": true,
      "bound_actor": "cawg.identity:{participant-actor-id}"
    },
    {
      "uri": "https://authority.example.org/asset/{record-id}",
      "reference_type": "permission_record",
      "consent_domain": "asset",
      "supersedes_prior": false,
      "asset_creator": "cawg.identity:{asset-creator-actor-id}"
    }
  ]
}

If an asset is separated from its manifest, the standard C2PA mechanisms for linking a disconnected manifest, including watermark-based recovery, are used to relocate the manifest and therefore the consent reference.

5. Consent authority recommendation

This section is non-normative.

CAWG does not build consent authorities. This section enumerates what a useful consent authority ought to be able to express on the consent side, so that any service may be validated against a minimum capability set. It does not describe how a service stores, resolves, or enforces those terms, nor how consent is combined with other assertions to reach a use decision. Those matters are out of scope (Section 6, “Out of scope”).

A consent authority ought to be able to express:

  • the declaring party, and where applicable the party on whose behalf consent is declared, with the basis for that authorization, for example parental or guardianship authority, an estate or executorship, or a representation agreement;

  • asset consent terms, including artificial intelligence training and data mining, licensing posture, derivative works, named contextual prohibitions, and compensation;

  • the grant itself, where the authority functions as a license: the granted and prohibited uses, scope, consideration or compensation, term, and the parties to the grant;

  • identity consent terms for a subject, including any performer, covering likeness, voice, movement, mannerisms, and persona;

  • biometric-identifier restrictions for a participant: where biometric identifiers such as fingerprints, palmprints, or iris scans are collected in connection with an engagement, that those identifiers ought not be used for any purpose unrelated to that engagement. Unlike the grant-style terms above, this is expressed as a default restriction;

  • the current state and revocability of each term, where the current state is the most recent within that source;

  • the temporal validity of each term;

  • the continuity of its records, including how the authority provides for durability and succession so that references remain resolvable over time, for example through escrow of records, a designated successor authority, or persistent-identifier infrastructure;

  • the binding of the consent record to the asset and, for identity consent, to the participant’s identity.

A consent authority’s record ought to express at least one term. A record expressing no terms conveys no consent and is treated as absent.

A service that meets this set can be described as meeting the CAWG minimum recommendation for a consent authority.

Absence of a consent reference conveys no permission and is not, by itself, a prohibition. For asset consent, lawful-use doctrines, including fair use and first sale, can permit use of a work without consent. For identity consent, applicable law defines its own exceptions, which are generally narrower than copyright’s; this specification takes no position on their scope. A claimed lawful purpose is a claim rather than a grant; where a downstream actor asserts one, the assertion is theirs to make and theirs to defend. A consumer ought not infer permission from silence, and where identity, harm, or legal exposure is involved and no authoritative consent can be resolved, a conservative consumer withholds use pending verification.

This specification does not define:

  • how a referenced source stores consent;

  • how a referenced source resolves competing or conflicting claims;

  • how any party enforces terms;

  • how consent is combined with other assertions or signals to reach a use decision;

  • how the identity of a signer or participant is credentialed or verified;

  • how a withdrawal or change of consent is propagated to consumers; or

  • how compensation terms are executed or settled.

Conflict resolution is delegated to the referenced source. The supersedes_prior assertion in Section 4, “The consent assertion” is the only conflict signal carried at the assertion level. This specification does not rely on relative timestamps across competing references to adjudicate conflicts.

7. Relationship to other specifications

The consent reference is complementary to rights and licensing frameworks.

Participant identity, including the identity of persons depicted in an asset, is carried through the CAWG identity assertion, to which an identity consent reference binds by way of the bound_actor field.

Downstream use under claimed lawful purposes. An actor who uses an asset under a claimed lawful purpose, for example news reporting, commentary, parody, or education, has a place to record that claim: assertions of their own, in the manifest of the work they publish. Such an actor is ordinarily a rights holder of the new work and may declare asset consent for it in the usual way; the purpose claim is a distinct statement and is not a consent declaration. It is evidence of a claim, made by and attributable to the claimant. It does not modify any consent reference on an upstream asset, which remains accessible through the C2PA ingredient chain. This specification does not define use-purpose declarations; they are anticipated as future work.

8. Acknowledgments

This section is non-normative.

The author thanks the reviewers of the Creator Assertions Working Group, whose comments substantially shaped the reference architecture of this specification.

Appendix A: Version history

This section is non-normative.

v0.21 (June 2026): consent expressed as a signer-attested CAWG metadata assertion rather than a gathered assertion; one consent assertion per CAWG signer, with multiple references carried in the consent_references array; participant and authorized representative defined separately; rights holders may be plural, each declaring the rights it controls; each reference bound to the asset’s C2PA content binding in addition to manifest placement; supersedes_prior scoped to the same authority, with independent non-exclusive declarations coexisting; reference_type value smart_contract removed; identity attributes (movement, mannerisms) synced across Sections 2, 3, and 5; consent authority recommendation expanded to cover license-grade terms and biometric-identifier restrictions; normative keywords removed from the non-normative Section 5; conservative-default note revised so that silence is neither permission nor prohibition and fair use and first sale are acknowledged; pointer clarified as not itself a license; acknowledgments section added; asset creator, rights holder, performer, and subject defined locally pending glossary adoption, with the deference list reduced to named actor. Section 4.3 changed “SHALL” for “SHOULD”.

Editorial flags for this draft (to resolve on the harmonization pass): resolve with the CAWG editors whether this assertion bears its own cawg.consent label or is carried within the cawg.metadata assertion, a structural fork that changes the shape of the JSON example in Section 4.3 and should be settled before other harmonization work; confirm the precise C2PA term for a signer-attested (“created”) assertion; confirm that the use of “claim,” “assertion,” and “declaration” throughout matches C2PA definitions exactly, and flag any divergence in text; confirm whether the C2PA normative reference should cite version 2.3 or 2.4 and align the link accordingly.