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 enables a creator or rights holder to express machine-readable declarations of permitted and prohibited use for a digital 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. Introduction

This section is non-normative.

1.1. Motivation

CAWG currently supports a single consent-related assertion: the training and data mining assertion, which enables a human creator or rights holder[1] to express whether an asset may be used for data mining or AI/ML training workflows. This assertion offers a three-value choice (allowed / notAllowed / constrained) across a defined set of training and mining use cases.

This existing assertion does not address the broader question that every creator and performer needs to answer when publishing digital content: What may be done with this asset, by whom, under what conditions, and what is explicitly prohibited?

Without a comprehensive consent framework in CAWG, creators who attach their identity to digital assets via identity assertions have no standardized way to express their permissions alongside their provenance. A creator can prove they made something, but they cannot express what they allow to be done with it.

The result is that consent is expressed through inconsistent platform Terms of Service, unstructured contract language, and verbal agreements – none of which are machine-readable. When disputes arise, there is no structured record of creator intent.

Emerging distribution patterns further illustrate this gap. In practice, multiple consent domains are often implicated simultaneously. For example, serialized video content may be scraped, ingested into AI systems, and used to generate near-identical reproductions with superficial modifications – altered scenery, appearance, or presentation – while retaining the structure, performances, and creative contributions of the original work. In such cases, the original asset content, performer identity, and human-authored creative contributions are reused without a structured, machine-readable expression of permitted or prohibited use. This can result in uncertainty for downstream platforms and users regarding what uses are authorized, and highlights the need for a standardized consent framework that distinguishes and coordinates these domains.

Terms used in this specification are defined in Section 3, “Standard terms and definitions”. Where this specification uses terminology from the C2PA technical specification or CAWG identity assertion, the definitions in those specifications apply unless stated otherwise in Section 3, “Standard terms and definitions”.

This section is non-normative.

Consent in the context of digital media spans at least three related but distinct domains:

  1. Asset consent: Permissions attached to a digital asset. What can be done with the file itself: training, licensing, derivatives, prohibited contexts, compensation terms.

  2. Creator consent: Permissions made by the asserted creator of an asset regarding use of their creative work. What can be done with the asset by the person who made it. Permissions made by the asserted creator of an asset which applies to their consent regarding use of their likeness, voice, movement, or persona. What can be done with a person when their identity is embodied in or associated with a digital asset.

  3. Subject consent: Permissions not made by the asserted creator of an asset but by the subject of an asset who asserts their consent regarding the capture and use of their likeness, voice, movement, or persona. What can be done with a person when their identity is embodied in or associated with a digital asset.

  4. Access and purpose consent: Permissions attached to disclosure, access, or use in a governed context (e.g., a parent authorizing a school to use a child’s photo, medical record access controls, classified document handling).

  5. Delegated consent: Permissions not made by the asserted creator of an asset but by a delegated party (human or authorized AI agent[2]) of the creator or subject who acts on behalf of them to assert their consent regarding use of their likeness, voice, movement, or persona. What can be done with a person when their identity is embodied in or associated with a digital asset.

    Delegated consent is in dark green, not crossed out. It is still in play.

This specification primarily addresses asset consent (Domain A). Where creator consent (Domain B) or subject consent (Domain C) is expressed as a gathered assertion attached to a digital asset or digital replica, it may also be accommodated within this framework through industry-specific consent profiles (see Section 7, “Domain-specific consent profiles”).

Access and purpose consent (Domain D) is outside the scope of this specification. CAWG’s work should remain compatible with adjacent systems addressing those concerns, but this specification does not define them.

Consent declarations defined herein may inform such disclosure decisions but do not define how those decisions are evaluated, enforced, or verified. Such behavior is implementation-specific and may be governed by external identity, credential, or policy frameworks.

A single digital asset may involve consent interests across multiple domains simultaneously. For example, a video production may involve asset consent from the production company, identity consent from multiple performers, and access restrictions from the original distributor. The consent assertion framework accommodates multiple consent declarations within the same manifest, each attributable to a distinct named actor via the identity assertion pattern described in Section 8, “Use with identity assertion”.

1.2.1. Relationship to selective disclosure

While subject consent (Domain C) is out of scope for this specification, consent declarations defined herein may influence what identity, metadata, or consent-related information is disclosed in a given context.

Implementations may apply selective disclosure mechanisms such that only a subset of available information is revealed based on requestor, purpose, or trust relationship.

Consent declarations within this framework may be expressed as signals embedded directly in the asset (hard-bound) or as references to external systems that maintain current permission state (soft-bound). These concepts are defined in Section 4, “Conceptual model”.

Five dimensions of consent in an illustrated case study below: a school works with a company to take yearbook photographs.

Five dimensions of consent illustrated by a school yearbook photography case study

1.3. Scope

Given the breadth of the consent domains described above, it is important to define the boundaries of this specification clearly.

This specification defines how consent is declared, how consent is structured, and how consent may reference external systems.

This specification does NOT define how consent is evaluated, how consent is enforced, or how conflicts between consent declarations are resolved. These behaviors are intentionally left to implementers and are outside the scope of CAWG standardization. No inference should be made from this specification regarding how such behaviors are implemented.

1.4. Legislative context

This section is non-normative.

Legislation across multiple jurisdictions is establishing requirements for machine-readable consent declarations in digital media. These mandates converge around three areas that intersect with CAWG and C2PA capabilities:

1.4.1. Disclose AI origin

Statutes in multiple jurisdictions require disclosure when content has been generated or materially modified by AI systems, typically through a combination of visible labeling and embedded technical signals that are durable and machine-detectable.

In the United States, most action has occurred at the state level, with examples including California SB 942 (AI Transparency Act), the New York Stop Deepfakes Act (S6954A), and Utah HB 276. Comparable obligations have emerged internationally. The European Union AI Act, Article 50, requires providers of generative AI systems to mark synthetic audio, image, video, and text outputs in machine-readable form, with transparency obligations entering full force on 2 August 2026. China’s Measures for Labeling AI-Generated Synthetic Content and mandatory national standard GB 45438-2025, in force since 1 September 2025, require both explicit visible labels and implicit metadata identifiers. India’s Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Amendment Rules 2026, effective 20 February 2026, mandate labeling for “synthetically generated information” and impose accelerated takedown timelines on intermediaries. South Korea’s AI Basic Act, effective 22 January 2026, requires labeling of generative AI outputs and special notice for synthetic media difficult to distinguish from reality.

These statutes describe functional requirements (metadata, latent disclosures, detection tools) broadly consistent with the functional requirements C2PA addresses, though they generally do not name specific standards.

1.4.2. Preserve provenance

A second set of measures focuses on ensuring that provenance metadata, once attached, is preserved across the content lifecycle and not stripped by intermediaries.

In the United States, California AB 853 extends provenance obligations to large online platforms and capture device manufacturers, including requirements to retain provenance data and provide user-visible indicators. Internationally, the EU AI Act’s draft Code of Practice extends similar expectations to deployers, requiring that intrinsic provenance signals be preserved through subsequent processing and contractually protected from removal by third parties. China’s Labeling Rules impose parallel obligations on online content distribution services to preserve embedded identifiers.

These provisions reinforce a policy expectation that provenance metadata should be durable, non-strippable, and accessible, objectives aligned with C2PA’s append-only manifest model and CAWG’s assertion framework.

1.4.3. Informed consent for digital identity

A parallel body of legislation addresses consent for the use of human identity (likeness, voice, movement, and persona) in digital and AI-generated content.

In the United States, California AB 2602 and AB 1836 (both sponsored by SAG-AFTRA) establish consent requirements for digital replicas of living and deceased performers. Tennessee’s ELVIS Act modernizes right-of-publicity protections to address AI-generated uses of personal identity. At the federal level, the TAKE IT DOWN Act was signed into law in May 2025, with platform notice-and-removal obligations entering force on 19 May 2026 and enforced by the Federal Trade Commission. Additional federal measures, including the NO FAKES Act, the COPIED Act, and the TRAIN Act, remain pending in Congress.

Internationally, the UK’s Data (Use and Access) Act 2025, Section 138, in force from 6 February 2026, criminalizes the creation of intimate images of an adult without consent, expressly covering AI-generated deepfakes. The UK Information Commissioner’s Office has further confirmed that AI-generated images of real people are subject to data protection law, extending regulatory reach beyond the criminal statute. Denmark has proposed amendments to its copyright law to recognize a person’s right to their own body, facial features, and voice, providing a takedown right against non-consensual AI imitations. France’s Penal Code Article 226-8-1 criminalizes the public distribution of algorithmically generated sexual content depicting a real person without consent. India’s 2026 IT Rules treat AI-generated impersonation and non-consensual intimate imagery as priority categories, with two-hour takedown windows for non-consensual intimate imagery and three-hour windows for other unlawful synthetic content.

Collectively, these statutes establish consent requirements governing identity use in digital contexts.

This legislative landscape, spanning multiple regions and legal traditions, highlights a structural gap: while provenance and disclosure mechanisms are emerging, there is no standardized, machine-readable way for creators and rights holders to declare permitted and prohibited uses of their assets or identity.

This specification defines only the declaration of consent and does not establish legal validity, enforcement, or evidentiary sufficiency.

2. Normative references

3.1. Conformance keywords

The key words “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,” and “MAY” in this document are to be interpreted as described in BCP 14, RFC 2119, and RFC 8174 when they appear in any casing (upper, lower, or mixed).

3.2. Terms from C2PA and CAWG specifications

The following terms are used in this specification with the meanings defined in the referenced specifications. Where this specification addresses the same concept in a consent-specific context, any narrowing or clarification is noted.

3.2.1. Actor

A human or non-human (hardware or software) participant in the C2PA ecosystem. Defined in the C2PA technical specification. This specification uses “actor” only when referring to the C2PA concept (e.g., “named actor” in the context of a CAWG identity assertion). Where this specification addresses the human individuals whose consent is being declared, it uses the terms “creator,” “rights holder,” or “performer” as defined in Section 3.3, “Terms defined in this specification”.

3.2.2. Assertion

Labelled data within a C2PA Manifest representing a declaration about an asset. Defined in Section 6 of the C2PA technical specification. Consent assertions as defined in this specification are a specific type of gathered assertion.

3.2.3. C2PA Manifest

A digitally signed and tamper-evident data structure that references a set of assertions concerning a C2PA asset. Defined in Section 11 of the C2PA technical specification.

3.2.4. Gathered assertion

An assertion whose content is provided by an actor other than the generator product signer of the C2PA Manifest. Defined in the C2PA technical specification. Consent assertions as defined in this specification are expressed as gathered assertions.

3.2.5. Named actor

An actor whose identity is documented through a CAWG identity assertion. Defined in the CAWG identity assertion specification.

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

3.3.1. Consent assertion

The specific C2PA gathered assertion (labeled cawg.consent) that carries one or more consent declarations within a C2PA Manifest. A consent assertion is the container; the consent declarations within it are the substantive content. See Section 5.1, “Overview”.

3.3.2. Consent category

A single dimension of permission or restriction within a consent assertion. Each consent category addresses a distinct aspect of what may or may not be done with an asset or identity. Examples include AI training posture, licensing posture, and derivative works policy. See Section 5.2, “Consent categories”.

3.3.3. Consent declaration

The substantive expression of permissions and restrictions made by a creator or rights holder regarding a digital asset or identity. A consent declaration is carried within a consent assertion but is conceptually distinct from it: the assertion is the C2PA data structure; the declaration is the expressed intent. A consent declaration represents a statement of intent and does not, by itself, constitute verified authorization, enforceable rights, or proof of permission.

3.3.4. Consent domain

One of three conceptual areas in which consent may apply to digital media: asset consent (permissions attached to the digital asset itself), identity consent (permissions attached to a human being’s identity as embodied in a digital asset), and access and purpose consent (permissions attached to disclosure, access, or use in a governed context). This specification primarily addresses asset consent. See Section 1.2, “Consent domains”.

The cross-reference above points from this normative term definition to Section 1.2, “Consent domains”, which is a non-normative section. Linking from normative text to non-normative text is problematic and should be resolved before this specification is finalized.

3.3.5. Cooperative system

A platform, application, or service that voluntarily evaluates consent declarations before permitting external use of a digital asset. Consent enforcement as described in this specification applies when an asset is presented to a cooperative system. This specification does not define what makes a system cooperative, nor does it impose any obligation on any system to evaluate consent declarations or act upon them. The term describes the class of systems for which consent declarations are relevant at the point of use. See Section 4.6, “Enforcement boundary”.

Eric’s detailed comparison with the original Google Doc will need to resume from here.

3.3.6. Digital asset

Any content in electronic form, regardless of format, encoding, or distribution method, including but not limited to images, audio, video, text, and three-dimensional models. References to “digital” assets, replicas, and content in this specification do not create a separate category of content exempt from the consent declarations defined herein.

3.3.7. Digital replica

A computer-generated representation of identifiable characteristics of a specific, recognizable person – including but not limited to their likeness, voice, movement, mannerisms, or other biometric features – that is sufficiently realistic or detailed that it could reasonably be perceived as depicting that person, whether or not the depiction is accurate. A digital replica may be produced through any technical means, including but not limited to AI synthesis, motion capture, voice cloning, or compositing.

Legislative definitions of “digital replica” vary across jurisdictions. California AB 2602 and AB 1836 scope the term primarily to voice and likeness. The federal NO FAKES Act encompasses voice, image, and likeness. This specification adopts a broader definition encompassing voice, likeness, movement, mannerisms, and biometric characteristics, in order to accommodate existing and anticipated legislative frameworks and to support consent declarations across the full range of identity dimensions that may be embodied in digital media. This definition is intended to be compatible with, not duplicative of, any particular legislative definition. Implementations operating under specific legal frameworks should consult applicable statutory definitions. For an illustrative example of how digital replica consent may be expressed through domain-specific consent profiles, see Section 7.2, “Identity consent (performer profile)”.

3.3.8. Hard-bound signal

A consent declaration embedded directly within a C2PA Manifest, representing the declared permission state at the time of publication. Hard-bound signals are available without network access and provide baseline interpretation when a registry is unreachable. See Section 4.4, “Hard-bound vs reference-bound consent signals”.

3.3.9. Performer

A human individual whose identity – including any combination of their likeness, voice, movement, mannerisms, or performance – is embodied in or associated with a digital asset, and who may declare consent regarding the use of that identity. The term encompasses actors, voice performers, musicians, dancers, and any other individuals whose personal characteristics are captured in or referenced by a digital asset.

3.3.10. Permission state

The current set of permissions and restrictions applicable to a digital asset or identity as expressed through consent declarations. Permission state may be represented on-asset (hard-bound), referenced via an external system (reference-bound), or both. Permission state is mutable and may evolve independently of the asset’s provenance history.

3.3.11. Reference-bound signal

Consent-related information referenced via a registry URI, representing current or evolving permission state external to the asset. Reference-bound signals may include updates, revocation, validity status, and extended terms not embedded in the asset. See Section 4.4, “Hard-bound vs reference-bound consent signals”.

3.3.12. Rights holder

A person or entity that makes a consent declaration regarding a digital asset or identity. The use of this term in this specification denotes the party making the declaration and does not constitute a determination of legal ownership, copyright status, or the validity of any underlying rights claim. This specification provides a structure for rights holders to declare permissions; it does not adjudicate who holds rights, nor does it define the legal relationship between a rights holder and the asset or identity to which a consent declaration refers. Determination of rights ownership is outside the scope of this specification and may be addressed by applicable law, contractual agreements, or adjacent standards such as JPEG Trust (ISO/IEC 21617).

Multiple rights holders may make consent declarations regarding the same asset. For example, a video production may involve consent declarations from a production company (asset rights), individual performers (identity rights), and a music rights holder (composition and recording rights). Each rights holder’s declaration is independently expressed and independently attributed via the identity assertion pattern described in Section 8, “Use with identity assertion”.

3.3.13. Trust registry

An external system referenced by a registry URI within a consent assertion, which may maintain current permission state, granular consent terms, revocation status, validity information, and other consent-related data. Different trust registries may serve different communities (e.g., voice performers, musicians, photographers), each using the same CAWG consent assertion categories on the asset while maintaining their own data structures, policies, and interfaces. This specification defines the URI reference mechanism by which a consent assertion points to a trust registry. The structure, behavior, trust characteristics, and legal standing of trust registries are out of scope for this specification. The presence of a registry URI does not imply that the referenced system is authoritative, complete, or trusted. See Section 6.8, “Registry pointer” and Section 10, “Relationship to external systems”.

This section defines the conceptual relationship between consent declarations, provenance, identity, disclosure, and external use. Terms used in this section are defined in Section 3, “Standard terms and definitions”.

4.1. Provenance and consent

Provenance assertions provide a time-ordered, append-only record of actions taken on an asset. They answer: “What happened to this asset?”

Consent assertions provide a declarative expression of permitted and restricted future use. They answer: “What is permitted to be done with this asset?”

These two concepts are related but distinct. A valid provenance record does not imply that a use is permitted under consent. A valid consent declaration does not constitute a provenance record of any action having been taken.

4.2. Independence from provenance lifecycle

Consent assertions SHALL NOT be treated as part of the provenance event history.

Provenance is append-only and reflects historical transformations. Consent is mutable and reflects current permission state, including:

  • updates to permissions

  • revocation of prior permissions

  • expiration of previously granted rights

  • modification of conditions or restrictions

Binding consent to the provenance lifecycle would create false historical records and break the append-only integrity of the provenance chain. Consent SHOULD be capable of evolving independently of the asset’s provenance history.

Design principle: Consent is declared alongside provenance, not inside it.

4.3. Three-layer architecture

Consent declarations MAY be represented across three conceptual layers:

1. Hard-bound (on-asset)

Category-level declarations embedded in the C2PA Manifest.

These represent declared consent signals associated with the asset at the time of publication and are available without network access.

2. Reference-bound (registry)

Consent-related information that MAY be referenced from a hard-bound manifest via a registry URI, including updated or additional declarations, including updates, revocation, validity status, and extended terms.

3. Disclosure layer (contextual)

Implementations MAY selectively disclose identity, metadata, or consent-related information based on requestor, purpose, or trust relationship.

The disclosure layer is influenced by consent declarations but is not itself a static component of the consent assertion.

Implementations MAY choose to embed a full permission manifest directly within the asset in addition to, or instead of, a registry pointer, where payload size and workflow constraints permit.

The disclosure layer does not constitute a component of the consent assertion and is not encoded as a fixed structure within the asset.

This section is conceptual and does not define system architecture or implementation requirements.

Consent categories defined in this specification MAY be implemented as either:

  • Hard-bound signals: embedded in the asset and representing durable declarations at time of publication

  • Reference-bound signals: referenced via registry and representing current or evolving permission state

Illustrative examples (non-normative):

Hard-bound:

  • AI training posture

  • baseline licensing posture

  • derivative works posture

  • ethical prohibitions

  • precedence declaration

Reference-bound:

  • revocation status

  • validity windows

  • active licensing state

  • compensation details

These examples are illustrative only and do not prescribe implementation behavior or classification requirements.

Both layers are independently meaningful. Hard-bound signals provide baseline interpretation when registry access is unavailable. Reference-bound signals provide current authoritative state.

Whether a given category is represented on-asset or via external reference is implementation-dependent.

4.5. Disclosure boundary and consent-linked disclosure

Consent declarations define what is permitted to be done with an asset or identity. In some implementations, consent declarations MAY also influence what information is disclosed to a given party.

Disclosure behavior is external to the consent assertion and is evaluated at time of use. Consent declarations MAY serve as inputs to such evaluation but do not define it.

Selective disclosure mechanisms may be implemented by external identity or privacy-preserving frameworks. This specification does not define such mechanisms and does not require any particular technology. Consent declarations defined herein are intended to be compatible with such systems where implementations choose to use them.

This specification does not define how disclosure decisions are evaluated, how disclosure policies are structured, or how selective disclosure is implemented or enforced. The presence of a consent assertion does not imply that all associated identity or metadata must be disclosed in all contexts.

Consent declarations govern external use of a digital asset: distribution, publication, platform ingestion, playback, licensing, and any transfer to an external party or system.

Internal workflows of the asset’s creator, rights holder, or parties acting within the scope of the rights holder’s authority are not required to be subject to consent evaluation under this specification, provided that such workflows remain within the consent scope declared by all governing parties. A creator working on their own asset, a cinematographer shooting under contract, an editor working within a production, or a delegated agent acting within their delegated scope is not required to bind consent assertions during such use. This specification SHALL NOT preclude voluntary internal consent evaluation as part of an organization’s compliance practices.

Creator identity remains part of the asset’s provenance regardless of contractual rights transfer. The creator field and the rights holder field describe separate facts about the asset and persist independently through the provenance chain, even when both resolve to the same party.

Subject consent governs use of a subject’s identity according to the scope declared at the time of consent. Transfer of an asset by the rights holder to a third party SHALL NOT expand the scope of subject consent. Expanded use beyond the originally declared scope MAY require new subject consent, typically negotiated through additional contractual terms and compensation.

Once an asset is transferred to any external party or system, the consent declaration governs that party’s use of the asset, including internal workflows, regardless of whether such use is characterized as “private.”

When an asset is presented for external use, the consent declaration is available for evaluation against the proposed use. The mechanism by which evaluation occurs is outside the scope of this specification.

4.7. Use-purpose declarations and bidirectional consent evidence

Consent declarations as defined in this specification express the original creator’s or rights holder’s permissions and restrictions. In practice, digital assets may be incorporated into derivative works by downstream creators who claim legitimate use purposes such as parody, satire, news reporting, commentary, or education.

The distinction between derivative works that are referential or transformative in nature (e.g., commentary, criticism, parody) and those that are competitive substitutes for the original is significant in many legal frameworks governing fair use. This specification does not define or adjudicate that distinction. However, the availability of structured use-purpose declarations from downstream creators, alongside the original creator’s consent declarations, provides evidence that may be relevant to such determinations.

This specification anticipates that downstream creators MAY declare the intended purpose of their use through their own assertions, whether these are consent assertions, provenance assertions, or other gathered assertions attached to the derivative work.

Where both the original creator’s consent declarations and a downstream creator’s use-purpose declarations are accessible – whether embedded in their respective manifests or referenced via registry – they collectively provide structured, machine-readable evidence that may be relevant to determining whether a particular use was authorized, claimed as a legitimate purpose, or potentially fraudulent.

This specification does not define:

  • how use-purpose declarations are structured (this may be addressed in a future specification or by domain-specific profiles)

  • how original consent and downstream use-purpose declarations interact

  • how disputes between such declarations are resolved

The availability of structured declarations from both parties provides a more complete evidentiary record than unilateral declaration alone.

Consent declarations apply to the asset on which they are made. A consent assertion on a derivative work SHALL NOT be interpreted as modifying, overriding, or superseding consent declarations attached to upstream assets in the provenance chain. Upstream consent declarations remain operative on their original assets and are accessible through the C2PA ingredient manifest mechanism. The evaluation of how multiple consent declarations across a provenance chain affect the permitted use of a downstream work is out of scope for this specification.

5. Assertion definition

A consent assertion SHALL have a label of cawg.consent.

A consent assertion SHALL be expressed as a gathered assertion within a C2PA Manifest, as described in the C2PA Claim schema.

The consent assertion MAY be repeated to express consent declarations from distinct rights holders or named actors for the same asset.

If multiple consent assertions appear in the same C2PA Manifest, they SHALL be given unique labels as described by Section 6.4, “Multiple instances,” of the C2PA technical specification.

Consent assertions may express declarations from two distinct perspectives: a creator consent assertion expresses permissions and restrictions declared by the creator or rights holder of the asset, and a subject consent assertion expresses permissions and restrictions declared by a human subject whose identity is embodied in the asset. Both are expressed using the same structural pattern and may coexist within the same manifest, each attributable to a distinct named actor via the identity assertion pattern described in Section 8, “Use with identity assertion”.

This specification normatively defines creator consent categories (Section 6, “Consent categories: asset consent”). Subject consent categories are anticipated as a future extension and are described illustratively in Section 7, “Domain-specific consent profiles”.

A consent assertion SHALL contain one or more consent categories, each expressing a distinct dimension of permission or restriction. These categories define what may be declared, not how such declarations are interpreted or enforced.

Each consent category SHALL be represented as a structured map entry within the assertion, containing at minimum:

  • A category identifier (a label conforming to the conventions described in the CAWG identity assertion specification, Section 5.3, “Labels”)

  • A value expressing the permission state for that category

Category identifiers beginning with cawg. are reserved for categories defined in this specification and future versions thereof, and SHALL NOT be assigned by any other entity.

Domain-specific categories (e.g., for performers, musicians, or journalists) MAY use entity-specific labels following the naming convention described in the identity assertion specification (e.g., com.example.performer.replica_creation).

The absence of a consent category from a consent assertion SHOULD NOT be interpreted as either permission or prohibition for that category. Incomplete declarations reflect the scope of what the creator chose to declare, not the full scope of what is permitted. Consuming systems SHOULD treat undeclared categories as indeterminate rather than as implicitly permitted or implicitly prohibited.

Implementations are encouraged to adopt a conservative interpretation of undeclared categories, particularly in contexts involving identity, harm, or legal exposure.

5.3. Schema

The CDDL (schema) definition for this assertion type will be developed during the PR process. The schema will follow CBOR serialization per C2PA conventions. The structure below represents the intended pattern.

The consent assertion is expected to follow a structure analogous to the training and data mining assertion, with an entries map containing one or more consent category entries:

; Consent assertion structure (illustrative, not yet normative)

consent-map = {
    "entries"          : $consent-entries-map,
    ? "registry_uri"   : tstr .size (1..max-tstr-length),
    ? "metadata"       : $assertion-metadata-map
}

consent-entries-map = {
    ? "cawg.ai_training_and_mining"    : $consent-category-entry,
    ? "cawg.licensing_posture"         : $consent-category-entry,
    ? "cawg.derivative_works"          : $consent-category-entry,
    ? "cawg.ethical_restrictions"      : $consent-category-entry,
    ? "cawg.compensation_model"        : $consent-category-entry,
    ? "cawg.revocation_status"         : $consent-category-entry,
    ? "cawg.precedence"                : $consent-category-entry,
    * tstr => any    ; allow for domain-specific consent categories
}

consent-category-entry = {
    "value"            : tstr .size (1..max-tstr-length),
    ? "constraint_info": tstr .size (1..max-tstr-length),
    ? "registry_ref"   : tstr .size (1..max-tstr-length)
}

The registry_uri field at the top level, if present, SHALL be a persistent URI pointing to an external system where the full consent declaration resides (see Section 10, “Relationship to external systems”).

Individual category entries MAY include a registry_ref field providing a category-specific reference within the external system identified by registry_uri.

This section defines the consent categories applicable to any digital asset. These represent the minimum viable consent framework for CAWG gathered assertions.

6.1. AI training and data mining

Category identifier: cawg.ai_training_and_mining

What it expresses: Whether the asset may be used for AI training, data mining, inference, or generative model development. Extends the existing model of the existing training and data mining assertion with a richer set of values and the ability to reference granular conditions via registry.

Values: PROHIBITED | CONDITIONAL | PERMITTED

If the value is CONDITIONAL, the constraint_info field SHOULD provide summary information, and the registry_ref field MAY point to granular terms at the trust registry.

The relationship between this category and the existing CAWG training and data mining assertion is discussed in Section 9, “Relationship to training and data mining assertion”.

6.2. Licensing posture

Category identifier: cawg.licensing_posture

What it expresses: The creator’s general licensing model. Signals to platforms the creator’s declared licensing posture without encoding full terms.

Values: ALL_RIGHTS_RESERVED | TIERED | RIGHTS_MANAGED | CREATIVE_COMMONS | CONTACT_FOR_TERMS

Where the value is CREATIVE_COMMONS, the specific license variant (e.g., CC-BY, CC-BY-SA, CC-BY-NC) MAY be specified via constraint_info or at the registry.

6.3. Derivative works policy

Category identifier: cawg.derivative_works

What it expresses: Whether modifications, remixes, and adaptations of the asset are permitted.

Values: PROHIBITED | CONDITIONAL | PERMITTED

The constraint_info field MAY include flags for conditions such as: attribution required, revenue share required, separate agreement required, parody/satire stance.

Where derivative works are permitted, the creator MAY declare accepted use purposes (e.g., parody, satire, news_reporting, editorial, commercial, educational) via constraint_info or at the registry. A downstream creator producing a derivative work MAY declare the intended use purpose of that derivative within its own consent or provenance assertions. This specification does not define how such declarations are verified or adjudicated.

When a derivative work is distributed as a C2PA asset, the C2PA ingredient manifest mechanism provides the structural link between the derivative and the original work. The original work’s consent assertions, including its registry URI, remain accessible through the ingredient chain. This specification does not require a derivative work’s consent assertion to reference the original work’s registry, as that linkage is provided by the C2PA provenance architecture. However, where a downstream creator claims a legitimate use purpose (e.g., parody, commentary), the presence of a traceable ingredient reference to the original work strengthens the evidentiary value of that claim.

6.4. Ethical and contextual restrictions

Category identifier: cawg.ethical_restrictions

What it expresses: Prohibited associations and contexts for the asset. Machine-readable flags for categories of use that the creator explicitly disallows.

Values: A non-empty array of prohibited context identifiers. Pre-defined identifiers include:

Value Meaning

cawg.political

Use in political campaigns or political advertising

cawg.hate_speech

Use in content promoting hatred or discrimination

cawg.surveillance

Use in surveillance systems

cawg.military

Use in military applications

cawg.adult

Use in adult or sexually explicit content

cawg.data_broker

Transfer to, sale to, or ingestion by third-party data aggregation services

Other string values MAY be used, subject to label restrictions described in Section 5.2, “Consent categories”.

Exceptions for editorial, educational, and news reporting use MAY be declared via constraint_info or at the registry.

Downstream creators producing content that incorporates the original asset MAY declare the purpose of their use (e.g., parody, satire, news reporting, commentary, educational) as part of their own assertion set. Where both an original creator’s restriction declarations and a downstream creator’s use-purpose declarations are accessible from their respective manifests, they provide structured, machine-readable evidence on both sides of a use dispute. This specification does not define how such declarations interact or are resolved.

6.5. Compensation model

Category identifier: cawg.compensation_model

What it expresses: The type of compensation structure. Not the specific amounts, but the model, so platforms can understand the declared compensation structure and support interoperability with systems that may implement compensation workflows.

Values: FLAT_FEE | REVENUE_SHARE | PER_USE | CONTACT_FOR_TERMS

This specification does not define allocation or reconciliation of compensation across multiple rights holders.

6.6. Revocation and validity status

Category identifier: cawg.revocation_status

What it expresses: Whether consent is revocable, general trigger categories for revocation, and a pointer to a live validity-status reference. Provides a reference point for external systems that may maintain updated permission information.

Values: IRREVOCABLE | REVOCABLE | CONDITIONAL

The registry_ref field, if present, SHOULD point to a reference where current permission status may be obtained.

6.7. Precedence declaration

Category identifier: cawg.precedence

What it expresses: Whether the consent terms declared in this assertion should be treated as the primary expression of permitted and prohibited use for the asset.

Values: ASSET_TERMS_GOVERN | PLATFORM_DEFAULT

Where the value is ASSET_TERMS_GOVERN, the declarant expresses that the consent terms associated with this asset represent their authoritative statement of permissions, and that consuming systems should interpret these terms as the primary expression of intent rather than relying solely on platform-level defaults. This field expresses declared intent regarding interpretive priority. It does not establish legal precedence over any contract, agreement, or platform policy. Enforcement of such priority is implementation-specific.

This declaration does not establish a conflict resolution mechanism between systems.

What it expresses: The top-level registry_uri field in the consent assertion map provides a persistent URI pointing to an external system that may contain additional consent-related information.

This field provides a reference mechanism by which implementations may associate the on-asset declaration with externally maintained information.

Different systems may serve different communities – for example, voice actor systems, music systems, or photography systems – each using the same CAWG consent assertion categories on the asset, while maintaining their own data structures, policies, and interfaces.

The presence of a registry_uri does not imply that any referenced system is authoritative, complete, or trusted.

The structure, behavior, and trust characteristics of such external systems are out of scope for this specification.

This section is non-normative.

The consent categories defined in Section 6, “Consent categories: asset consent” address asset-level consent that applies to any digital content. Some communities require additional consent dimensions specific to their industry or use case.

Industry-specific consent profiles extend the base consent assertion by adding categories relevant to a particular community or use case. These additional categories:

  • use entity-specific labels (e.g., com.example.performer.replica_creation)

  • follow the same structural pattern as the base categories

  • are included in the same entries map within the consent assertion

  • are defined and maintained by the communities that use them, not by this specification

This specification does not define or standardize any industry-specific profiles. The following section provides an illustrative example to demonstrate how the framework accommodates identity consent for performers.

This section is non-normative and illustrative.

Standardization of identity consent is emerging as a critical area for future work due to emerging legal requirements around digital replicas and biometric identity use.

When a digital asset embodies a human being’s identity – their voice, image, name, likeness, movement, and/or performance – consent applies to the person as well as to the asset. Asset consent and identity consent address distinct dimensions and coexist within the same manifest; neither supersedes the other. This is the identity consent domain described in Section 1.2, “Consent domains”.

Standardized identity consent profiles are anticipated as a natural next-stage extension of this framework, and may be developed by industry groups, standards bodies, or registries. This specification does not define such profiles.

An example of a domain-specific consent profile (e.g., performer identity consent) may include categories such as the following. The following categories are representative examples of dimensions that may be relevant in identity consent, and are not intended to define a complete or canonical model.

The following illustrative categories represent an example of how a subject consent assertion, as described in Section 5.1, “Overview”, might be structured for performer identity consent.

Category What it expresses

Digital replica creation and use

Whether a digital replica may be created. Scope: voice cloning, likeness capture, motion/performance modeling.

Identity scope

Which aspects of identity are included: voice, likeness, body, movement, performance style.

AI training and model use (identity)

Whether identity specifically (as distinct from the asset) may be used in AI systems for training, generation, or enhancement.

Character and representation rights

Whether identity may portray characters: original roles, composite characters, synthetic personas. Attribution requirements.

Contextual and ethical restrictions (identity)

Where the identity may NOT appear, e.g. hate speech, political use, surveillance, military, adult content.

Standalone asset creation

Whether identity may be used outside the original production context: marketing assets, virtual influencers, digital merchandise, stock media.

Intimate and sensitive use

Whether identity may be used in sensitive scenarios: nudity, sexual content, biometric sensitivity.

Usage terms, duration, and revocation

Time limits, geographic restrictions, revocation rights, conditional continuation terms.

Identity consent record pointer

Persistent URI to the full identity consent record, with versioned consent state and identity verification context.

These categories are illustrative only and do not constitute a standardized schema within this specification.

These categories may be expressed using entity-specific labels within the same consent assertion entries map, with detailed terms optionally referenced via the registry URI.

External frameworks and industry-specific systems may define structured approaches to identity consent using categories such as these.

A consent assertion is included in gathered_assertions in the C2PA Claim schema, and the assertion is not attributed to the signer of the C2PA Manifest.

It is required to include a consent assertion as a referenced assertion within a CAWG identity assertion.

This reference SHALL represent a declaration by the named actor of that identity assertion to the accuracy and intent of the declared consent terms.

This pattern is consistent with the approach described in Section 5, “Use with identity assertion,” of the CAWG metadata assertion specification.

The CAWG training and data mining assertion (cawg.training-mining) addresses a subset of the consent domain covered by this specification – specifically, whether an asset may be used for data mining, AI inference, AI training, and generative AI training.

This specification proposes to extend that work into a broader family of consent assertions. Two approaches are under consideration:

Option A: Subsumption. The consent assertion incorporates the AI training and data mining categories within its cawg.ai_training_and_mining category entry, and the standalone training and data mining assertion is deprecated in favor of the consent assertion’s expanded scope.

Option B: Coexistence. The training and data mining assertion continues to exist as a standalone assertion for backward compatibility, while the consent assertion provides a broader framework. Where both are present in the same manifest, the consent assertion’s values SHOULD take precedence.

Subsumption is generally preferred to reduce ambiguity and avoid conflicting declarations.

The preferred approach will be determined during CAWG working group review.

Consent assertions MAY reference external systems (e.g., trust registries or policy stores) that maintain current permission state, granular terms, and related information.

This allows:

  • consent to evolve independently of the asset

  • up-to-date permission information to be referenced when needed

  • industry-specific consent modules to provide templates appropriate to the asset type

  • revocation and update status to be referenced as needed

  • compensation-related information to be declared and referenced

The structure and behavior of such external systems are out of scope for this specification. This specification defines only the URI reference mechanism by which the on-asset consent assertion points to an external system.

This specification does not define synchronization, validation, or resolution behavior between the asset and any external system. Nor does it define mechanisms for establishing the authenticity, legal sufficiency, or evidentiary weight of any consent declaration or referenced record.

Implementations MAY rely on external trust or credential frameworks when evaluating referenced systems.

This specification defines consent declarations as gathered assertions within C2PA Manifests. Adjacent standards efforts, including JPEG Trust (ISO/IEC 21617), address how provenance and rights-related signals are evaluated against context-specific trust policies. Consent assertions as defined herein may serve as inputs to such evaluation frameworks. This specification does not define evaluation logic and is intended to be compatible with, not duplicative of, trust evaluation standards.

ISO/IEC TS 27560:2023 (Consent Record Information Structure) defines an interoperable, extensible framework for recording consent to PII processing, including consent records, consent receipts, and lifecycle management. While that standard addresses consent in the context of personal data processing, rather than creative asset permissions, its design explicitly accommodates domain-specific schema extensions (see ISO/IEC TS 27560:2023, 6.3.1 and Annex B). Registry implementations that support consent assertions as defined in this specification MAY adopt structural patterns from ISO/IEC TS 27560, including versioned consent records, lifecycle state management, and party identification, expressed as a domain profile appropriate and useful to creative asset and performer identity consent.

11. Scope of standardization

11.1. In scope (CAWG)

  • Defining consent categories and their enumerated values

  • Defining field structure for consent declarations

  • Defining how consent is represented as a gathered assertion

  • Defining optional reference to external systems via URI

  • Aligning consent assertions with existing CAWG assertion patterns

11.2. Out of scope (implementation-specific)

  • How consent is evaluated at runtime

  • How consent is enforced

  • How conflicts between consent declarations are resolved

  • How systems interpret or act upon consent declarations

  • How registries operate internally

  • How trust is established between registries and consuming platforms

  • The legal enforceability of any particular consent declaration

  • How selective disclosure of identity, metadata, or consent-related information is determined or enforced

  • Any runtime evaluation, scoring, or decision-making processes derived from consent declarations

Guiding constraint: If a statement answers “what can a creator declare?” it is in scope. If a statement answers “how does the system decide or act?” it is out of scope.

The presence of a consent assertion in a manifest does not imply that any system is required to honor, enforce, or recognize that declaration.

11.3. Out of scope (legal frameworks)

The following are out of scope because they are governed by applicable law in the jurisdiction where content creation, distribution, or use occurs:

  • The legal enforceability of any particular consent declaration

  • How conflicts between consent declarations are resolved when multiple parties have governing interests

  • The legal duty of any party to honor, enforce, or recognize a consent declaration

  • How consent is legally interpreted or acted upon by any party

11.4. Out of scope (implementation)

The following are out of scope because they are determined by the design of specific systems implementing this specification:

  • How registries operate internally

  • How trust is established between registries and consuming platforms

  • How selective disclosure of identity, metadata, or consent-related information is technically determined or enforced

  • How consent is evaluated at runtime

  • How consent is enforced through technical mechanisms

  • How systems technically interpret or act upon consent declarations

  • Any runtime evaluation, scoring, or decision-making processes derived from consent declarations

Guiding constraint: If a statement answers “what can a creator declare?” it is in scope. If a statement answers “how does the system decide or act?” or “what legal force does this declaration carry?” it is out of scope.

The presence of a consent assertion in a manifest does not imply that any system is required to honor, enforce, or recognize that declaration. Such requirements arise from applicable law and from contractual or platform-level commitments, not from this specification.

12. Proposed implementation path

  1. Issue creation. Two CAWG issues. First: expand the training-and-data-mining assertion into a consent assertion family (asset consent categories). Second: add trust registry URI field to the CAWG specification.

  2. Working group review. Present categories to CAWG for feedback, refinement, and consensus on scope.

  3. PR development. Draft pull request to update the CAWG specification with the agreed assertion categories and field definitions, including CDDL schema.

  4. Registry guidance. Develop guidance documentation for how trust registries should implement consent modules that connect to CAWG assertions.

  5. Pilot implementation. Demonstrate end-to-end flow with a real-world registry (e.g., voice actor community) to validate the architecture.

Appendix A: Terminology mapping

This section is non-normative.

This appendix is provided for implementer convenience.

The following table maps the human-role terminology used in this specification to the related C2PA and CAWG terms, and clarifies each term’s conceptual function within the consent framework.

Term Conceptual role Defined in

Actor

Any participant in a C2PA workflow (human, hardware, or software)

C2PA technical specification

Named actor

An actor whose identity is documented through an identity assertion

CAWG identity assertion

Creator

Human originator of creative work who may declare asset consent

This specification (Section 3.3, “Terms defined in this specification”)

Rights holder

Party making a consent declaration (does not adjudicate legal ownership)

This specification (Section 3.3, “Terms defined in this specification”)

Performer

Human whose identity is embodied in or associated with a digital asset

This specification (Section 3.3, “Terms defined in this specification”)

Consent assertion

C2PA gathered assertion container (labeled cawg.consent)

This specification (Section 3.3, “Terms defined in this specification”)

Consent declaration

Substantive expression of permissions and restrictions

This specification (Section 3.3, “Terms defined in this specification”)

Consent category

Single dimension of permission within a consent assertion

This specification (Section 3.3, “Terms defined in this specification”)

Hard-bound signal

On-asset consent declaration embedded in the C2PA Manifest

This specification (Section 3.3, “Terms defined in this specification”)

Reference-bound signal

Registry-referenced consent state external to the asset

This specification (Section 3.3, “Terms defined in this specification”)

Trust registry

External system maintaining current consent state

This specification (Section 3.3, “Terms defined in this specification”)

Digital replica

Computer-generated representation of a recognizable person’s identifiable characteristics

This specification (Section 3.3, “Terms defined in this specification”)
The terms “creator,” “rights holder,” and “performer” describe roles in the context of consent declarations. A single individual may occupy more than one role (e.g., a performer who is also the creator of the asset). These roles are not mutually exclusive.

Appendix B: Version history

This section is non-normative.

March 2026

  • Initial working draft (0.1) of this specification.

  • Proposed eight asset consent categories.

  • Defined consent domain taxonomy (asset, identity, access/purpose).

  • Established three-layer architecture (hard-bound declarations, soft-bound registry state, and contextual disclosure compatibility).

  • Described relationship to existing training and data mining assertion.

  • Included non-normative performer consent profile as domain-specific extension example.

  • Included non-normative legislative context.

  • Introduced conceptual framework for bidirectional consent evidence (use-purpose declarations by downstream creators).

1. See NOTE at the bottom of Section 10, “Relationship to external systems” re: JPEG Trust.
2. In the future, AI may be given power-of-attorney or represent a person within a specific domain (e.g. an actor’s agent or an enterprise AI social media manager).