Context
A signal activated under one consent scope (e.g., `sync_audiences` from a CRM with first-party advertising consent) can be referenced downstream — re-targeted, attached to a different campaign, composed with other signals — without a protocol-level mechanism enforcing scope alignment. Today each party verifies scope compatibility off-protocol via DPAs and operational controls.
External defensibility review (NOYB-class privacy advocates) flagged this as the central attack vector against AdCP's consent story. Adding it to `known-limitations.mdx` as an explicit non-goal for 3.0 (already done in this PR — search for the consent-scope propagation bullet). This issue tracks the 3.1 surface for closing it.
What a 3.1 surface might look like
Sketches, not commitments — for working-group discussion:
-
Consent-scope tag on signal activations. `activate_signal` and `sync_audiences` carry a `consent_scope` object: `purpose` (one of `first_party_advertising`, `look_alike_modeling`, `measurement_only`, `not_for_advertising`, etc.), `jurisdiction`, `expires_at`. Downstream operations (re-targeting, signal composition) MUST check compatibility before use.
-
Scope-derivation rules. When two signals are composed (e.g., union, intersection, look-alike), the derived signal inherits the strictest scope of its inputs. A protocol-level rule prevents accidental scope expansion.
-
Scope-violation error code. New `CONSENT_SCOPE_INCOMPATIBLE` returned when an operation references a signal whose scope does not cover the requested use. Recovery: `correctable` if the deployer can supply an alternate signal; `hard_fail` otherwise.
-
Audit-log scope propagation. `get_plan_audit_logs` records the consent scope of every signal touched by a campaign decision, so regulators and auditors can verify scope alignment after the fact.
Open questions
- How does this interact with the existing `policy_categories` mechanism on campaigns? Are scopes a separate axis or a refinement?
- IAB TCF / GPP integration — should the `consent_scope` derive from a TCF string when one is available?
- TMP boundary — does Identity Match enforce scope on the eligibility check side, or is that out of scope for TMP itself?
Related
Context
A signal activated under one consent scope (e.g., `sync_audiences` from a CRM with first-party advertising consent) can be referenced downstream — re-targeted, attached to a different campaign, composed with other signals — without a protocol-level mechanism enforcing scope alignment. Today each party verifies scope compatibility off-protocol via DPAs and operational controls.
External defensibility review (NOYB-class privacy advocates) flagged this as the central attack vector against AdCP's consent story. Adding it to `known-limitations.mdx` as an explicit non-goal for 3.0 (already done in this PR — search for the consent-scope propagation bullet). This issue tracks the 3.1 surface for closing it.
What a 3.1 surface might look like
Sketches, not commitments — for working-group discussion:
Consent-scope tag on signal activations. `activate_signal` and `sync_audiences` carry a `consent_scope` object: `purpose` (one of `first_party_advertising`, `look_alike_modeling`, `measurement_only`, `not_for_advertising`, etc.), `jurisdiction`, `expires_at`. Downstream operations (re-targeting, signal composition) MUST check compatibility before use.
Scope-derivation rules. When two signals are composed (e.g., union, intersection, look-alike), the derived signal inherits the strictest scope of its inputs. A protocol-level rule prevents accidental scope expansion.
Scope-violation error code. New `CONSENT_SCOPE_INCOMPATIBLE` returned when an operation references a signal whose scope does not cover the requested use. Recovery: `correctable` if the deployer can supply an alternate signal; `hard_fail` otherwise.
Audit-log scope propagation. `get_plan_audit_logs` records the consent scope of every signal touched by a campaign decision, so regulators and auditors can verify scope alignment after the fact.
Open questions
Related