verify_brand_claim response verifier has no key→brand binding (brand-spoofing)

[bokelley]

From the 2026-07 protocol security audit (registry NS-SIG-002; refs #3925).

Defect. The verify_brand_claim / verify_brand_claims response-signing verifier (docs/building/by-layer/L1/security.mdx:895-903) resolves kid→JWK at the agent's jwks_uri and checks adcp_use/alg/freshness/request_hash, but no step confirms the signing key is authorized for the claimed brand_domain. brand_domain and agent_url are attacker-chosen fields inside the payload the same key signs. Compare the governance JWS profile in the same file (:634), which explicitly warns that deriving identity from an unauthenticated in-token field is a circular trust chain.

Impact. An attacker running a conformant brand-agent for a domain it controls can emit a cryptographically valid owned response for brand_domain: "nike.com". The mutual-assertion floor (verify_brand_claim.mdx:23) bounds this — the attacker must control/forge both sides — but the signature the spec calls "load-bearing" attests authorship, not brand authority.

Decision to make. Add a normative verifier step mirroring governance step 13: fetch https://{brand_domain}/.well-known/brand.json (one redirect, SSRF-safe), confirm an agents[] entry with url == agent_url authorized for brand-protocol responses, and resolve kid only within that entry's jwks_uri. Treat brand_domain/agent_url as untrusted until this passes.

Enforcement to attach. A negative test vector: forged owned response for an unowned brand → expected: reject. Flip NS-SIG-002 to enforced on merge.

Part of the anti-drift lockdown (specs/spec-anti-drift.md). Rolls up to #3925.

[bokelley]

Triage

Classification: Bug (spec defect — NS-SIG-002)
Bucket(s): security-sensitive, spec / protocol, brand
Status: ready-for-human
Milestone: 3.1.0

What the experts said:

• security-reviewer: Defect confirmed; brand.json cross-check is the correct fix direction, but the normative verifier step needs three additions: a type-discriminator on the agents[] match (URL equality alone is insufficient), an explicit SSRF body-size ceiling for the brand.json fetch separate from the existing JWKS 64 KiB cap, and an explicit constraint scoping kid resolution to the matched entry's jwks_uri only — not the origin-default fallback path.
• ad-tech-protocol-expert: Normative MUST, breaking to existing verifier implementations → 3.1 (signing profile changes are never patch-eligible); the brand.json data model already carries the structural machinery; open question before normative text: cache TTL bounds for the brand.json anchor lookup (too long = revoked agent stays trusted; too short = DoS against .well-known/).

My take: Both experts converge on the brand.json cross-check as the correct fix; three scoping decisions need WG resolution before the normative verifier step can be drafted. @bokelley, your call on: (1) type discriminator for agents[] matching, (2) cache TTL bounds, (3) SSRF body-size ceiling for the brand.json fetch.

---

Triaged by Claude Code.

---

Generated by Claude Code

[bokelley]

Triage

Classification: Conformance failure (security)
Bucket(s): spec / protocol, security-sensitive
Status: ready-for-human
Milestone: 3.1.0 (signing profile — never patch-eligible per playbook)

What the experts said:

• security-reviewer: APPROVE-FIX — vulnerability confirmed at security.mdx:885,897; attacker-controlled agent_url resolves kid outside brand_domain's trust chain. Option B (brand.json-authoritative kid resolution) strictly closes the split-resolution path; Option A leaves a residual hole.
• ad-tech-protocol-expert: NEEDS-MORE-INFO — fix direction confirmed; three gaps block normative text: SSRF rule citation, brand.json unavailability fallback behavior, and a circularity note on payload-embedded agent_url vs. the URL the verifier actually contacted.

My take: Both experts agree kid must be resolved exclusively from brand_domain's brand.json agents[] entry. Three design questions need your decision before normative text ships.

Option B (recommended) — verifier step change:

// After checking adcp_use / alg / freshness / request_hash:
- Resolve kid from agent_url's own jwks_uri
+ Fetch https://{brand_domain}/.well-known/brand.json (apply existing SSRF ruleset)
+ Locate agents[] entry where url == agent_url
+ Resolve kid only from that entry's jwks_uri; reject if entry absent or kid missing

@bokelley, your call on three open questions:

1. brand.json unavailable → hard-fail (safe default) or time-bounded grace window (analogous to revocation-stale grace at step 9)?
2. agents[] lookup: url equality sufficient, or must adcp_use: "response-signing" also match?
3. Normative text: explicitly require that agent_url in the payload equals the URL the verifier contacted, or is request_hash binding considered sufficient to close the soft circularity?

---

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

---

Generated by Claude Code

[bokelley]

Triage

Classification: Bug (security — normative verifier gap)
Bucket(s): security-sensitive, spec / protocol, brand
Status: ready-for-human
Milestone: 3.1.0

What the experts said:

• security-reviewer: P0 confirmed; gap is reachable in practice; fix direction sound but needs two additional clauses — explicit adcp_use acceptance criterion at the verifier, and SSRF-safe fetch rules explicitly extended to the attacker-controlled brand_domain brand.json lookup (currently absent from the SSRF-protected URL enumeration).
• ad-tech-protocol-expert: Consistent with governance key-discovery precedent (security.mdx L642–644); new normative MUST not a clarification of silence — ships 3.1 with out-of-band advisory (NS-SIG-002) for 3.0 operators specifying "reject on miss" as the fallback posture. Multi-tenant JWKS deployments (CDN-hosted keys) are unaffected since the fix resolves jwks_uri from brand.json agents[], not from the agent's self-reported origin.

My take: Experts converge on 3.1 as the target and the brand.json cross-check as the right structure; both flag identical spec-completeness gaps that must be closed before the normative step can be drafted. @bokelley, two sub-decisions: (1) Does the brand_domain fetch receive the full 6-point SSRF treatment already defined for governance URLs, or a lighter subset? (2) Is a brand.json cache hit within TTL sufficient for subsequent calls, or must each online verify_brand_claim call fetch fresh?

---

Triaged by Claude Code. Session: https://claude.ai/code/19c795a4-3ee6-5e1a-bf1a-f8fc5ee1018e

---

Generated by Claude Code