Clarify: does revoked_publisher_domains apply to inline_properties[]?

[bokelley]

Question

The revoked_publisher_domains[] array (added in #4504 / adagents.json 3.0.10+) carries the spec language:

Validators MUST treat any publisher domain listed here as no-longer-authorized regardless of where else it appears.

For publisher_properties[] selectors (cross-domain) and top-level properties[] arrays this is unambiguous: revoke by publisher_domain match.

For an agent with authorization_type: "inline_properties", the intent is less clear. A typical payload:

{
  "url": "https://agent.example",
  "authorization_type": "inline_properties",
  "properties": [
    {"publisher_domain": "cnn.com", "property_id": "p1"},
    {"publisher_domain": "owned-and-operated.example", "property_id": "p2"}
  ]
}

If the same file declares:

{
  "revoked_publisher_domains": [
    {"publisher_domain": "owned-and-operated.example", "revoked_at": "2026-05-20T00:00:00Z"}
  ]
}

Should the resolver strip the second inline property?

Two readings

Reading A — literal "regardless of where else": Yes, strip. Defense-in-depth; consistent treatment across all three authorization-type branches. The publisher might be migrating off an O&O domain and listing it as revoked simultaneously, expecting inline properties on it to stop resolving.

Reading B — inline-properties are self-scoped: No, leave alone. Inline properties are the publisher's direct authorization for a specific agent; revoked_publisher_domains is targeted at cross-publisher selector references (publisher_properties[]) and the top-level shared properties[] pool, not at an agent's own inline list. A publisher revoking its own domain in its own adagents.json is unusual.

Context

• AdCP SDKs are already implementing the filter for two of the three branches (e.g., adcp-client-python#753, adcp-client-python#758). The third branch is held pending this clarification.
• Either reading is defensible; the spec text is ambiguous on inline_properties specifically.
• A docs-side clarification (one sentence) would unblock SDK implementations.

Ask

Could the spec body for revoked_publisher_domains explicitly state whether it filters inline_properties arrays, or carve that branch out? Either decision is fine — the asymmetry just needs to be documented so SDKs implement consistently.

Related

• adcp#4504 (original revoked_publisher_domains scope)
• adcp-client-python#758 (SDK-side tracking issue)
• adcp-client-python#753 (SDK-side implementation that filters the other two branches)

[bokelley]

Triage

Classification: Spec question
Bucket(s): registry / discovery, spec / protocol
Status: drafting-pr

What the experts said:

• ad-tech-protocol-expert: Reading A is correct — the revoked_publisher_domains revocation predicate is domain-keyed, not authorization-type-keyed; the "regardless of where else it appears" prose already captured this intent, and the normative enumeration was simply incomplete. The fix is a patch-level schema description clarification.
• adtech-product-expert: Landing-right — zero adoption cost; the inline branch needs the same revokedDomains.has(domain) guard already used for the other two branches. Not a WG decision: the rule is structurally identical regardless of authorization type.

My take: Both experts converge: revocation applies to all three branches, including inline_properties. PR #4871 adds authorized_agents[].properties[].publisher_domain (inline_properties authorization type) to the explicit enumeration in the JSON schema description and the managed-networks.mdx validator-behavior bullet — unblocking adcp-client-python#758.

Drafting PR: adds the missing branch to the revoked_publisher_domains description in two places; patch-level clarification only, no wire change.

---

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

---

Generated by Claude Code