[proposal] revoke_activation — canonical buyer/producer revocation primitive (signals domain)

[EvgenyAndroid]

Summary

AdCP 3.0 has no protocol-level mechanism for a buyer to stop using a signal mid-campaign once it has been activated to a destination. The existing activate_signal task accepts action: "deactivate" (schema signals/activate-signal-request.json) but:

• No published agent in the live AdCP directory implements it (verified via federation probe against the live registry)
• The semantics of "deactivate this signal everywhere" vs. "deactivate this specific activation" are undefined
• Buyer-triggered revocation carries no reason code, no authorization scope, no async-safe state machine, and no audit trail
• The only alternatives today are manual out-of-band destination action (untraceable) or producer-set validity_period (not buyer-triggered, not implemented in any 3.0.x adapter)

This is a clean greenfield gap: no existing GH issue, no in-flight RFC, no working-group thread covering this surface (verified prior-art check, May 2026).

Proposed primitive: revoke_activation

A new task in the signals domain. Design constraints:

• Async-by-default — revocations may require producer-side propagation to downstream platforms; synchronous response is not realistic
• Reason-coded — reason enum covers compliance, campaign-end, budget-exhausted, policy-violation, producer-request, and test (minimum viable set; open for extension)
• Reason-scoped authorization — not every caller can invoke every reason code (e.g. producer-request may only be callable by the producing agent; policy-violation requires governance context)
• Reuses existing AdCP infrastructure end-to-end — async polling via tasks/get, webhook delivery using the existing signed-webhook contract, no new transport / auth / persistence / envelope
• Additive only — agents that don't implement revoke_activation degrade to today's behavior; no breaking change to activate_signal

Request sketch

{
  "task": "revoke_activation",
  "idempotency_key": "<uuid>",
  "signal_agent_segment_id": "<segment-id>",
  "activation_ref": "<activation-idempotency-key | all>",
  "destinations": ["<destination-id>"],
  "reason": "compliance | campaign-end | budget-exhausted | policy-violation | producer-request | test",
  "effective_at": "<ISO-8601 | null>",
  "context": {}
}

activation_ref: "all" targets all active destinations for the segment. A specific key targets a single activation, enabling per-activation revocation without disturbing siblings.

State machine (proposed)

pending → propagating → revoked | failed

Webhook event: signal.revocation.completed / signal.revocation.failed

Open questions for working-group triage (§14 of full proposal)

1. Producer-initiated revocation routing — sibling tool on the buyer agent, or direct call from producer to buyer agents? What's the right topology?
2. Cascade semantics — when a signal feeds an activation chain, does revoking the root propagate? Proposal default: explicit per-task only for v1.
3. Pricing reconciliation — mid-billing-period revocation creates a partial-use window. In scope for protocol (e.g. a revoked_at timestamp on the activation record), or out of scope?
4. effective_at scheduling — who is responsible for running the timer for future-dated revocations? Caller, producer, or platform?
5. Privacy-budget restoration — when clean-room signals are revoked, should the protocol signal that budget is restorable? How?

Full proposal

Detailed spec (17 sections — request + response schemas, state machine, reason code enum, authorization matrix, worked example, conformance storyboard, test plan):
https://github.com/EvgenyAndroid/adcp-signals-adaptor/blob/master/docs/SPEC_PROPOSAL_REVOKE_ACTIVATION.md

Target milestone

3.1 minor — additive, no breaking changes, testable in <10 conformance storyboards.

Prior art

None found. activate_signal action: "deactivate" exists in schema but is semantically underspecified and unimplemented. This proposal supersedes the deactivate discriminator or can be defined as its normative complement.

Suggested labels

domain:signals, kind:proposal, priority:high

[bokelley]

Thanks for filing!

Triage

Classification: Feature request (RFC proposal)
Bucket(s): spec / protocol, signals
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Gap is real; separate task is architecturally correct (extending activate_signal's discriminated union with revocation fields would break the response oneOf). Two hard blockers before schemas open: (1) proposed pending → propagating → revoked state machine conflicts with task-status.json — revocation must flow through submitted → working → completed | failed with revoked_at in the result payload, not a parallel status axis; (2) reason-scoped authorization (e.g., only a signing producer may invoke producer-request) is not encodable in the current auth model without the RFC 9421 signing work at Mandatory request signing for mutating calls (RFC 9421 HTTP Signatures or JWS) #2307 / Revocation availability: signed heartbeat to decouple freshness from full list fetch #2325. activation_ref: "all" is also idempotency-unsafe as a magic string — needs a typed discriminant. brand/revocation-notification.json is the correct internal precedent for the producer-push shape.
• adtech-product-expert: Gap is genuinely felt by CDP/SSP operators today — GDPR/CCPA segment deletion is manual and legally exposed. Reason codes (compliance, campaign-end, policy-violation) map directly to how agency legal and ops teams describe forced removals. Q1 (producer-initiated routing topology — blocked on Mandatory request signing for mutating calls (RFC 9421 HTTP Signatures or JWS) #2307), Q3 (pricing reconciliation — entangled with billing item 3.1: Billing reconciliation / dispute flow between buyer and seller delivery numbers #2391), and Q5 (privacy-budget restoration — no existing protocol surface) are each multi-sprint WG debates; cutting them from the initial 3.1 scope is the right call. Adoption will remain sparse without a Seller Tier-2 certification requirement.

My take: The gap is genuine and 3.1-appropriate if scoped down. Two decisions must be made before any PR opens: (1) the narrowed scope boundary — especially whether effective_at is in or out — and (2) the action: "deactivate" deprecation strategy. @bokelley, your call: Option A (narrowed first-cut, experts recommend) or Option B (full proposal with all 5 WG questions in scope)?

---

Option A — Narrowed 3.1 (recommended): new task + deprecate action: "deactivate", cut Q1/Q3/Q4/Q5:

Deprecate the underspecified path in activate-signal-request.json:

- "action": { "enum": ["activate", "deactivate"], "default": "activate" }
+ "action": {
+   "enum": ["activate", "deactivate"], "default": "activate",
+   "x-status": "deprecated",
+   "description": "Governed deactivation: use revoke_activation."
+ }

New signals/revoke-activation-request.json (minor bump — new task-type.json enum value):

{
  "task": "revoke_activation",
  "idempotency_key": "<uuid>",
  "signal_agent_segment_id": "<segment-id>",
  "activation_ref": "<activation-idempotency-key>",
  "reason": "compliance | campaign-end | budget-exhausted | policy-violation | producer-request | test",
  "context": {}
}

Also adds optional revoked_at + revocation_reason to deployment.json (additive). Excludes effective_at, cascade semantics, producer topology, and privacy-budget (separate RFC).

---

Option B — Full proposal (all 5 WG questions in scope):

{
  "task": "revoke_activation",
  "activation_ref": "all",
  "reason": "compliance",
  "effective_at": "2026-06-01T00:00:00Z",
  "context": {}
}

Requires: Q1 topology (blocked on #2307 signing profile landing), Q3 pricing (requires revoked_at on report_usage — entangled with #2391), Q5 privacy-budget (no existing protocol surface; experts recommend a separate RFC). Minimum 3 WG sprints before mergeable.

---

Triaged by Claude Code. Session: https://claude.ai/code/cse_014WKggtoKNwMQbQPTasyjdv

---

Generated by Claude Code