Proposal: Consent Assertion as a CAWG Gathered Assertion Type

[epassoja]

THE PROBLEM: Identity assertions allow actors to bind their identity to an asset, but there is no standardized way to declare permitted and prohibited use of that asset.

WHY THIS MATTERS: Consent is currently expressed in contracts and platform terms of service, which are not machine-readable and not portable across systems.

PROPOSAL: Introduce a consent assertion as a gathered assertion type, enabling creators and rights holders to express permissions and restrictions in a machine-readable form.

DESIGN PRINCIPLES:

• Consent is declarative, not executable
• Consent is independent from provenance lifecycle
• Consent may reference external systems (e.g., registries)
• Consent should be associated with identity assertions for accountability

EXAMPLE CATEGORIES (illustrative, not exhaustive):

• AI training and data mining
• Licensing posture
• Derivative works
• Ethical/contextual restrictions
• Compensation model
• Revocation / validity

SCOPE BOUNDARY: This proposal defines what can be declared, not how consent is evaluated, enforced, or resolved.
The latter are implementation-specific and explicitly out of scope for CAWG standardization.

A more detailed working draft is available here ==> Consent Assertion Spec Draft

Open to feedback on scope, categories, and alignment with existing CAWG assertions.

[justin-hofstad]

The scope boundary here is the right call. Declaring what is permitted and verifying whether that permission is currently valid at the moment of use are two different problems, and collapsing both into the assertion layer would create the same brittleness that static certificate trust produced before OCSP.

Revocation and validity cannot be fully expressed as declared states. A revocation that lives only in an assertion is only as current as the last time the asset was re-signed. For identity specifically, consent state changes on timescales that asset re-signing cannot track. A performer can suspend consent mid-production, a dispute can arise between capture and distribution, a license can expire between signing and use. Declaring a revocation endpoint or a validity window in the assertion is the right road, and resolving current state against that endpoint at the moment of use requires a whole separate operational layer.

DDT's IPS architecture is built for exactly the layer your scope boundary leaves open. The "consent may reference external systems" principle in your design is the integration point. See #259.