Naming: brand-operator authorization Protocol should be BrandAuthorizationResolver, not AdagentsResolver

[bokelley]

Coordination issue tracking the naming alignment item from the AdCP spec Tier-3 follow-up #3828 on the BuyerAgentRegistry work in adcp-client #1269.

The ask

The in-flight Python docs/proposals/v3-identity-bundle-design.md (referenced from adcp-client #1269 §4) names the brand-operator authorization Protocol AdagentsResolver. The name doesn't match the file the Protocol consults.

The Protocol's job is to verify, on each request, whether the operator named in the request is authorized to act for the brand. That check is governed by:

• brand.json authorized_operators — brand-side declaration of which operators may represent the brand. Lives at {brand-house-domain}/.well-known/brand.json. The schema field is the authoritative list the seller consults during sync_accounts.

It is NOT governed by:

• adagents.json — publisher-side / data-provider-side declaration of which sales agents may sell that publisher's inventory. Different relationship, different consumer (sellers verifying buyer-side authorization don't read adagents.json).

Naming the buyer-side resolver AdagentsResolver confuses the two surfaces and locks adopters — and any future Python implementer reading the type — into the wrong mental model.

Recommendation

Name the Protocol BrandAuthorizationResolver (or the idiomatic Python equivalent — BrandAuthorizationResolver reads cleanly as a Protocol class).

Alternative if a more action-shaped name is preferred: OperatorAuthorizationResolver. Either preserves the brand-side framing; both avoid the adagents.json mis-attribution.

Why this is a coordination ask, not a Python-only decision

The JS SDK (adcp-client) does not yet have this Protocol — it lands as a follow-up to #1269. When it does, it should ship under the same name. Aligning before either SDK ships saves a forced rename later.

Spec-side coordination

The AdCP spec at docs/building/integration/accounts-and-agents.mdx Buyer-agent identity section now carries a normative recommendation that SDKs name this Protocol after the file consulted (brand.json/authorized_operators) — added in adcp #3831, landing alongside this coordination ask. The spec wording recommends BrandAuthorizationResolver as the canonical name.

Asks for the Python team

1. Confirm the proposal can rename to BrandAuthorizationResolver (or specify the idiomatic Python casing if Brand_Authorization_Resolver / BrandAuthorizationProtocol reads more naturally — flag whatever convention the rest of the SDK already follows).
2. Once confirmed, file the JS-side issue against adcp-client so both SDKs ship under the same name.

cc @bokelley

[bokelley]

Triage

Classification: tracking/coordination — cross-SDK naming alignment
Bucket(s): docs, cross-repo (neither label found in repo — gap flagged)
Status: deferred

Blocked-on: #345 — resurfaces on merge.

AdagentsResolver lives exclusively in docs/proposals/v3-identity-bundle-design.md, which is part of PR #345's diff and doesn't exist on main. The rename to BrandAuthorizationResolver (per adcp spec #3831) should be folded into PR #345 before it merges — that avoids a separate single-symbol rename PR and keeps the proposal doc and the eventual implementation name consistent from day one.

Suggested scope fold posted on #345.

---

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

---

Generated by Claude Code

[bokelley]

Naming locked in — BrandAuthorizationResolver is the agreed name and was adopted in #350's RFC and the v3-identity-bundle proposal. The previous AdagentsResolver reference no longer exists in any in-flight code. Closing as resolved-by-#350.