Expand the Training & Data Mining Assertion to a Broader Set of Consent Assertions

[ScottSPerryCPA]

Currently, the CAWG Specification includes the following consent assertions: Training and Data Mining Assertion: Describes an assertion that enables someone to provide information about whether an asset with C2PA metadata may be used for data mining or AI/ML training.

In working with Erik Passoja, CAWG member, there is a broader set of consent assertions that should be added to this category that creators need to protect their digital assets. Erik has created a separate proposal which is too long to include in this issue but available on the CAWG Slack Channel. I have highlighted "The Problem" and "The Proposal" from this document:

1. The Problem

CAWG currently supports a single consent-related assertion: training and data mining. This assertion offers a binary choice (allowed / not allowed) across a narrow scope. It 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 gathered assertions have no standardized way to express their permissions alongside their provenance. Identity without consent is incomplete. A creator can prove they
made something, but they cannot express what they allow to be done with it.

The result is that consent remains trapped in platform Terms of Service, unstructured contract language, and unenforceable verbal agreements. When disputes arise, there is no machine-readable record of creator intent.

2. The Proposal

I propose expanding the current training-and-data-mining assertion into a set of consent assertion categories that cover the essential dimensions of creator and performer permissions. These categories are designed to be:

• Thin enough to hard-bind directly to the asset — each category is a high-level flag or enumerated value, not a full contract
• Machine-readable and interoperable — platforms can parse and act on them programmatically
• Extensible via registry URI — each assertion can point to a trust registry where granular terms, full consent declarations, and verification live
• Industry-agnostic at the spec level — applicable to performers, photographers, musicians, writers, and enterprise IP holders alike
• Complementary to C2PA created assertions — these are gathered assertions that express creator intent, not product telemetry

Recently an IEEE standard has been enacted to perform similar consent actions. Please refer to https://myterms.info/ for more information.

[justin-hofstad]

The problem statement is right, the direction is right. One structural issue worth surfacing before the assertion schema is expanded: for identity, a broader set of static assertions has the same limitation as the current binary one.

Consent in commercial identity use is always scoped, time-limited, and revocable. Those constraints are not incidental; they are where the value lives. A performer's consent to a 2024 theatrical production does not authorize a 2026 AI training pipeline even if the assertion at signing said allowed. That scope was never agreed to in provenance. Expanding the flag set does not change this.

Time and scope are not administrative details. They are the terms under which identity has commercial value at all. A static declaration strips that value from the subject and transfers it permanently to the asset holder. The specification should not encode that transfer as the default.

Identity is not static content. The industry whose tools are their identity has never treated consent as a one-time declaration and the specification should not require it.

Closing this gap requires a live query layer that reflects current consent state at the moment of use, not the moment of creation. The "extensible via registry URI" design in your proposal already implies this layer. DDT's IPS architecture addresses it directly. See #259.