feat(signing): verifier key_origins check + IDNA-2008 canonicalization (closes #776, #777)

[bokelley]

Summary

Two related follow-ups from the #350 v3-identity series that PR #785 (just merged) had no room for; both touch src/adcp/signing/ canonicalization so they ship together to keep the IDNA story coherent.

#777 — IDNA-2008 canonicalization

Migrate four IDNA callsites from stdlib host.encode("idna") (IDNA-2003) to idna.encode(host, uts46=True) (IDNA-2008 / UTS#46) and add idna>=3.0 to [project.dependencies]:

• src/adcp/signing/jwks.py — JWKS URI host pinning (SSRF + TOCTOU close)
• src/adcp/signing/ip_pinned_transport.py — pin-host normalization
• src/adcp/signing/revocation_fetcher.py — governance issuer origin normalization
• src/adcp/signing/key_origins.py — _origin_host canonicalization

The IDNA-2003 path mismaps Eszett (ß → ss) and final-sigma, both of which IDNA-2008 preserves as Punycode. A counterparty hosting straße.de would canonicalize under IDNA-2003 to strasse.de — a different registrable domain than the spec mandates, with an attacker-controlled write to either side able to either silently match a non-owned origin or deny a legitimate one.

Regression test (tests/test_key_origins.py::test_consistency_eszett_preserves_as_punycode_idna_2008) pins the behavior change explicitly with both positive (straße.de ↔ xn--strae-oqa.de matches) and negative (straße.de ↔ strasse.de does NOT match) cases — without the negative case the migration is silent under a future refactor.

#776 — Verifier wiring for identity.key_origins

PR #775 landed check_key_origin_consistency as a standalone helper but did not wire it into verify_request_signature. Per ADCP #3690 §step 7, the check is mandatory ONLY when the JWKS source for the (agent, purpose, role) tuple was the operator brand.json — and skipped for publisher-pinned tuples (where the JWKS origin is the publisher's domain by design).

Design (least invasive):

• Source discriminant via duck-typing: resolvers expose a jwks_source: Literal["brand_json", "publisher_pin"] class attribute. BrandJsonJwksResolver declares "brand_json"; the publisher-pin path (CachingJwksResolver, StaticJwksResolver) omits the attribute. The verifier treats absence as "publisher_pin"-equivalent (= skip), so the existing JwksResolver Protocol is preserved and adopter-supplied resolvers keep working unchanged.
• VerifyOptions extensions (three new fields, all backward-compatible defaults):
  • expected_key_origins: Mapping[str, str] | None = None — the signing peer's declared identity.key_origins map. None skips the check unconditionally.
  • signing_purpose: str = "request_signing" — the purpose key to look up.
  • posture: str | None = None — diagnostic context attached to _key_origin_missing rejections.
• The check runs after JWK resolution + key-purpose validation but before crypto verify — a misconfigured tuple is rejected cheaply.

No new error codes; the helper already raises request_signature_key_origin_{mismatch,missing} from errors.py.

Files changed

• pyproject.toml — idna>=3.0 added to [project.dependencies]
• src/adcp/signing/jwks.py — IDNA-2008
• src/adcp/signing/ip_pinned_transport.py — IDNA-2008
• src/adcp/signing/revocation_fetcher.py — IDNA-2008
• src/adcp/signing/key_origins.py — IDNA-2008
• src/adcp/signing/brand_jwks.py — declare jwks_source = "brand_json"
• src/adcp/signing/verifier.py — _maybe_check_key_origin helper + VerifyOptions fields
• tests/test_key_origins.py — IDNA-2008 regression test (Eszett)
• tests/conformance/signing/test_verifier_key_origins.py — new file, 9 verifier-integration tests

Test plan

• pytest tests/test_brand_jwks.py tests/test_etld.py tests/test_key_origins.py tests/test_brand_authz.py tests/test_decisioning_brand_authz_dispatch.py tests/conformance/signing/ --tb=short — 598 passed locally
• pytest tests/ -q — full suite, 5028 passed locally
• ruff check src/adcp/signing/ — clean
• mypy src/adcp/signing/ — clean
• mypy src/adcp/ — clean (811 source files)
• CI green across Python 3.10–3.13

[aao-ipr-bot]

Holding for two blockers in the dependency floor and the production-helper wiring — both fail-open where this PR claims to fail-closed. IDNA-2008 migration and the verifier-side _maybe_check_key_origin are otherwise the right shape.

Must fix before merge

1. idna>=3.0 floor admits CVE-2024-3651. pyproject.toml:108. idna 3.0–3.6 has a quadratic-complexity DoS in idna.encode() — the exact function this PR adds at four hot verifier callsites. An attacker-controlled IDN host in a counterparty's jwks_uri triggers the bug on every signature verification. The PR's own justification for stating the dep directly is "closes the supply-chain contract" — then close it: pin idna>=3.7,<4. One character; half the point of pinning the floor.

2. verify_from_agent_url bypasses the new check. src/adcp/signing/agent_resolver.py:608-618. The SDK's recommended buyer-side entry point builds StaticJwksResolver(resolution.jwks) and never sets expected_key_origins. _maybe_check_key_origin skips on both counts (jwks_source absent, expected_key_origins=None). The brand.json walk that produced resolution.jwks IS the operator-attested source the new check defends — that's exactly where the shared-tenancy spoof bites. As shipped, the closes-#776 wiring engages only when an adopter hand-builds VerifyOptions; the production helper is unprotected. Either (a) wrap the resolved JWKS in a jwks_source = \"brand_json\" marker resolver and surface identity.key_origins from the capabilities fetch into AgentResolution, or (b) call check_key_origin_consistency directly inside verify_from_agent_url after resolution. If staging that as a follow-up PR is preferred, file the issue and edit this PR's body to state the production wiring is deferred — but as written the SDK ships a defense its own recommended helper doesn't use.

Things I checked

• Four IDNA-2008 callsites use byte-identical encoding (idna.encode(host, uts46=True).decode(\"ascii\")) and the same exception triplet. No asymmetric-canonicalization path inside src/adcp/signing/.
• _maybe_check_key_origin fires after _check_key_purpose (verifier.py:263) and before crypto verify — matches the spec checklist step 7 placement.
• Duck-typed jwks_source != \"brand_json\" discriminant correctly treats \"publisher_pin\" and absence as skip.
• Eszett regression test pins all three required directions — straße.de ↔ xn--strae-oqa.de matches both ways, straße.de ↔ strasse.de raises request_signature_key_origin_mismatch. Without the negative case the migration would be silent under a future refactor.
• expected_key_origins: Mapping[str, str] matches the canonical wire shape at schemas/cache/3.0/protocol/get-adcp-capabilities-response.json:982-1008 — one origin per purpose, not a list.
• tests/conformance/signing/test_verifier_key_origins.py (359 lines) covers the five behavior cases — brand-json match / mismatch / missing, publisher-pin skip, legacy-resolver skip — and test_key_unknown_still_surfaces_before_origin_check pins the rejection ordering against future refactor.
• VerifyOptions field additions are all backward-compat defaults — feat(signing): semver signal is correct.

Follow-ups (non-blocking — file as issues)

• Pass transitional_processing=False explicitly at all four idna.encode sites. The current default is False (Eszett-preserving), but >=3.0 admits future minors that could flip it. Self-documents intent and locks the canonicalization regardless of upstream default drift.
• Warn when expected_key_origins is None AND jwks_source == \"brand_json\". A BrandJsonJwksResolver configured without origins is observable misconfig — make it a UserWarning, not a silent skip.
• Warn when expected_key_origins is supplied AND the resolver carries no jwks_source. Legacy adopter resolvers upgrading the SDK silently lose the check; a one-shot DeprecationWarning gives the upgrade signal.
• Cold-cache jwks_uri=None path routes through mismatch with synthetic empty-string actual origin (verifier.py:547, key_origins.py:155). Fail-closed posture is right; the error detail is ambiguous on dashboards. Consider REQUEST_SIGNATURE_JWKS_UNAVAILABLE for the resolver-misconfig branch.
• Protocol-fidelity confirms: `ad-tech-protocol-expert` flagged two spec-text questions worth confirming against ADCP #3690 — (1) does step 7 mandate IDNA-2008 explicitly, and (2) for publisher-pinned tuples is the spec "no check" or "alternative check (publisher eTLD+1)"? The PR's reading is internally consistent with errors.py:73-79 and key_origins.py:26-29 but the spec PR itself is the source of truth.

Minor nits (non-blocking)

1. jwks_source annotation widens to a value the class never produces. src/adcp/signing/brand_jwks.py:350 types it as ClassVar[Literal[\"brand_json\", \"publisher_pin\"]]. ClassVar[Literal[\"brand_json\"]] would let mypy catch a future reassignment typo. Style only.
2. Redundant UnicodeEncodeError in the exception triplet at all four IDNA callsites. UnicodeEncodeError is a subclass of UnicodeError. Harmless; trim or leave.
3. jwks.py:201 comment says "transitional_processing=False" but the call passes only uts46=True. Either pass the kwarg or trim the parenthetical — currently a reader has to know the package default.
4. No regression test for the documented jwks_uri=None fail-closed path at verifier.py:542-546. Behavior is correct via empty-string-routes-to-mismatch; the path lacks a pin.
5. Test plan: six boxes, none checked. Prose states 5028 passed, mypy clean across 811 files, ruff clean — the actual values are stated, the checkboxes aren't. Habit-of-ticking-them-as-you-go, not a hold.

Request changes — idna>=3.7,<4 is non-negotiable; the verify_from_agent_url plumbing is either in this PR or explicitly deferred in the PR body.

[bokelley]

Pushed 66b17de3 addressing both MUST-FIX items.

#1 — CVE-2024-3651 pin

idna>=3.7,<4. Comment block in pyproject.toml documents the rationale: the four signing-side callsites all hand idna.encode() attacker-influenceable hosts (JWKS URI authority, redirect targets, revocation-issuer canonicalization, operator-declared key_origins), so the quadratic-complexity DoS in 3.0–3.6 hits every hot verifier path.

#2 — verify_from_agent_url engages the new check

Took option (a) from the review (richer fix — surface identity.key_origins into AgentResolution AND mark the resolver source). Two pieces:

• AgentResolution.key_origins: dict[str, str] | None — populated by a new _extract_key_origins(capabilities) helper that filters non-string entries and returns None on absence. Legacy 3.0 operators who haven't published the map see no behavior change; the verifier's check skips on expected_key_origins=None per the existing contract.
• _BrandJsonStaticJwksResolver — a StaticJwksResolver subclass that carries jwks_source = "brand_json". The brand.json walk in async_resolve_agent IS the operator-attested source the spec's consistency check defends, so marking the wrapped resolver engages _maybe_check_key_origin on every signed request routed through the helper.
• Two new kwargs on verify_from_agent_url: signing_purpose (default "request_signing") and posture. Webhook callers route through webhook_signing; default is request-side for the buyer-verify common case.

Four new tests pin the wiring:

• test_factory_threads_key_origins_into_verify_options — Argus's exact bypass scenario, now a regression test.
• test_factory_passes_signing_purpose_through — webhook routing.
• test_factory_resolver_carries_brand_json_source_marker — verifier engagement via the class-level discriminant.
• test_factory_passes_none_origins_when_capabilities_omit_them — back-compat for legacy 3.0 operators.

Non-blocking items deferred (with reasons)

• transitional_processing=False at all four sites — defaults to False already; pinning it explicitly is doc-style. Worth doing in a follow-up that touches all four sites together.
• UserWarning on misconfig (brand_json source + no origins) — useful but better as a small follow-up so it gets its own review on warning ergonomics.
• DeprecationWarning on legacy resolver + origins set — same. Adopter-facing warning needs its own pass.
• Cold-cache jwks_uri=None → JWKS_UNAVAILABLE — current routes through mismatch with empty-string actual origin. Worth fixing but not a security gap; follow-up.

Will file the four follow-ups as issues if you're aligned on shipping the two MUST-FIX items now.

Verification

• pytest tests/test_agent_resolver.py tests/test_verify_from_agent_url.py tests/test_key_origins.py tests/test_brand_jwks.py tests/test_etld.py tests/test_brand_authz.py tests/conformance/signing/ — 607 passed, 2 skipped
• ruff check src/adcp/signing/ clean
• mypy src/adcp/signing/agent_resolver.py clean

Ready for re-review.

[bokelley]

Re-review: both MUST-FIX items look good

#1 — CVE-2024-3651 pin: idna>=3.7,<4 is correct. The pyproject.toml comment block documents all four attacker-influenceable callsites; the <4 cap with a rationale comment is the right defensive posture for a major-version boundary.

#2 — verify_from_agent_url wiring: the two-pronged fix closes both bypass paths the original review identified:

• _BrandJsonStaticJwksResolver sets jwks_source = "brand_json" at the class level so _maybe_check_key_origin actually engages. The class is private-to-module — adopters wiring custom resolvers set the attribute themselves without inheriting an internal type.
• resolution.key_origins threads through to VerifyOptions.expected_key_origins via _extract_key_origins, which filters non-string entries and returns None on absence so legacy 3.0 operators are back-compat.

Positioning of _maybe_check_key_origin (after key-purpose validation, before crypto verify) matches ADCP #3690 step 7 ordering.

The four deferred items are correctly categorized as non-blocking:

• transitional_processing=False explicit pinning — doc-style, defaults already correct
• UserWarning / DeprecationWarning passes — both warrant their own ergonomics review
• Cold-cache jwks_uri=None path — fails closed (mismatch vs. unavailable is cosmetic), not a security gap

Four test_verify_from_agent_url.py wiring tests + 9 conformance tests + Eszett regression test cover the new behavior well. The test_factory_resolver_carries_brand_json_source_marker test in particular pins the exact bypass class-level vs instance-level distinction.

Aligned on shipping the two MUST-FIX items now. Happy to review the follow-up issues when they're filed.

---

Reviewed by Claude Code. Session: https://claude.ai/code/session_01Y9cTwcXUwzZFYtWmAufJhV

---

Generated by Claude Code

[aao-ipr-bot]

Blocker — the verify_from_agent_url re-wiring engages the spec's consistency check but fails closed on the legitimate path. The marker class threads through; the host it should compare against does not.

MUST FIX

_BrandJsonStaticJwksResolver never carries jwks_uri.

src/adcp/signing/agent_resolver.py:677-694 adds the jwks_source = "brand_json" discriminant but no __init__ — it inherits StaticJwksResolver.__init__(self, jwks) (src/adcp/signing/jwks.py:366-367), which stores only the JWK set. The construction at src/adcp/signing/agent_resolver.py:665 is _BrandJsonStaticJwksResolver(resolution.jwks) — resolution.jwks_uri is dropped.

src/adcp/signing/verifier.py:540 reads jwks_uri = getattr(resolver, "jwks_uri", None) → None → check_key_origin_consistency(jwks_uri="", ...). _origin_host("") returns None (src/adcp/signing/key_origins.py:196-205); the mismatch branch (key_origins.py:141) fires with detail={"actual_origin": ""}.

Trace: operator publishes identity.key_origins = {"request_signing": "https://keys.brand.example"} with jwks_uri = "https://keys.brand.example/.well-known/jwks.json". Buyer calls verify_from_agent_url(...). Resolution succeeds. Signature verifies. Step 7 raises request_signature_key_origin_mismatch with expected_origin=\"keys.brand.example\", actual_origin=\"\".

Net: every operator that publishes identity.key_origins fails verification through the SDK's recommended buyer helper. The shared-tenancy-spoof defense the PR closes #776 to add rejects legitimate signers instead of just adversarial ones. This is the same MUST-FIX surface the prior review flagged — the marker class went in, the URI plumbing did not.

Fix shape (one __init__, one kwarg at the construction site):

class _BrandJsonStaticJwksResolver(StaticJwksResolver):
    jwks_source: ClassVar[Literal[\"brand_json\", \"publisher_pin\"]] = \"brand_json\"

    def __init__(self, jwks: dict[str, Any], *, jwks_uri: str) -> None:
        super().__init__(jwks)
        self.jwks_uri = jwks_uri

And jwks_resolver=_BrandJsonStaticJwksResolver(resolution.jwks, jwks_uri=resolution.jwks_uri) at agent_resolver.py:665.

Test coverage gap that masked it.

tests/test_verify_from_agent_url.py monkeypatches verify_starlette_request in every test (lines 92-93, 215-216, 278-279, 310-311, 344-345, 378-379), so _maybe_check_key_origin is never reached. The one resolver-shape assertion at line 326 (test_factory_resolver_carries_brand_json_source_marker) checks type(resolver).jwks_source but never resolver.jwks_uri. The conformance suite in tests/conformance/signing/test_verifier_key_origins.py:47-64 uses a separate test double that does set self.jwks_uri = jwks_uri, so it passes — but it never exercises the production class. The two surfaces never meet.

Add an integration test in tests/test_verify_from_agent_url.py that does NOT mock verify_starlette_request and runs a real signed request through the production _BrandJsonStaticJwksResolver with key_origins matching the resolved host. That test must be in the same commit as the fix, otherwise the next attempt regresses the same way.

code-reviewer, security-reviewer, and ad-tech-protocol-expert all independently traced the same path. security-reviewer graded it High; code-reviewer Blocker; ad-tech-protocol-expert flagged the diagnostic shape (actual_origin=\"\" leaks empty when actual_host is None) but the underlying defect is the missing jwks_uri.

Things I checked

• IDNA-2008 migration at all four callsites (jwks.py:210, ip_pinned_transport.py:117, revocation_fetcher.py:387, key_origins.py:203) is consistent and uses uts46=True (transitional off) — Eszett regression test at tests/test_key_origins.py:286-309 includes both positive AND negative cases, so a future revert to IDNA-2003 doesn't slip silently
• CVE-2024-3651 floor idna>=3.7,<4 at pyproject.toml:114 is correct per GHSA-jjg7-2v4v-x38h
• VerifyOptions field additions (expected_key_origins, signing_purpose, posture) are dataclass defaults — backwards compatible; feat: (no !) is the right semver signal
• _extract_key_origins (agent_resolver.py:332-357) filters non-string entries and treats empty as None — safe against malformed capabilities
• Verifier step ordering: _maybe_check_key_origin runs after _check_key_purpose and before revocation (verifier.py:274-279) — matches the spec's checklist
• Duck-typed jwks_source preserves the JwksResolver Protocol contract — adopter resolvers without the attribute default to publisher-pin semantics (skip)
• Public-API audit: new field on AgentResolution, new kwargs on verify_from_agent_url, three new fields on VerifyOptions — all additive with defaults, no breaking change

Follow-ups (non-blocking — file as issues after the MUST FIX lands)

• IDNA-2008 + IP literals. idna.encode(\"192.0.2.1\", uts46=True) raises (IDNA-2008 rejects purely-numeric labels); stdlib host.encode(\"idna\") returned the ASCII as-is in some paths. Adopters with allow_private=True dev setups using IP-literal JWKS URIs may now see SSRFValidationError: URI host '...' is not IDNA-valid. Gate the four callsites with an ipaddress.ip_address(host) short-circuit so IP literals skip IDNA entirely
• _origin_host trailing-dot stripping. key_origins.py:199 uses host.rstrip(\".\") (all trailing dots); docstring at lines 186-190 says "single trailing dot." Match the code to the docstring (host[:-1] if host.endswith(\".\") else host) or update the docstring — the asymmetry argument the docstring makes holds for one dot, not for arbitrary chains
• Duck-typed discriminant — silent skip for adopter resolvers. An adopter on the new SDK whose custom resolver IS brand-json-sourced but doesn't advertise jwks_source silently bypasses the check. Document this loudly in the next release note; consider a runtime_checkable BrandSourcedJwksResolver Protocol so the discriminant surfaces as a type contract
• _BrandJsonStaticJwksResolver defined below its caller. agent_resolver.py:665 references the class defined at line 677. Functionally safe (call-time name resolution) but brittle to refactor. Move the class above verify_from_agent_url

Minor nits (non-blocking)

1. _extract_key_origins lacks a per-entry length cap. agent_resolver.py:332-357 is bounded only by the 64KiB capabilities-body cap. A 253-byte (DNS hostname limit) per-value clamp would tighten the surface. Non-exploitable today.
2. expected_origin field on _mismatch falls back to raw URL when canonicalization fails. key_origins.py:155-156 — actual_origin becomes the full URL (not host-only) when _origin_host returns None. Inconsistent with the field name on the success path. Diagnostic-only.

Ship it once the jwks_uri plumbing lands with an integration test that drives the production resolver class through verify_request_signature without mocking the verifier.

[bokelley]

Pushed 7801f612 — Argus was right, real bug, fixed.

_BrandJsonStaticJwksResolver inherited StaticJwksResolver.__init__(self, jwks) which stores only the JWK set. The verifier reads getattr(resolver, "jwks_uri", None) → None → actual_origin="" mismatch on every legitimate signer. My first-pass tests didn't catch it because they all mocked verify_starlette_request, so _maybe_check_key_origin never ran against the production class.

Fix:

• _BrandJsonStaticJwksResolver.__init__(self, jwks, *, jwks_uri) stores jwks_uri on the instance.
• verify_from_agent_url threads jwks_uri=resolution.jwks_uri through at the construction site.

Four new integration tests in test_verify_from_agent_url.py exercise the production resolver class through the real _maybe_check_key_origin step (no verifier mocking):

• test_brand_json_static_resolver_carries_jwks_uri_attribute — pins the new __init__ contract.
• test_maybe_check_key_origin_accepts_brand_json_resolver_with_matching_origin — regression test for the exact bypass you traced; verifier no longer rejects a legitimate signer whose resolved host matches the declared origin.
• test_maybe_check_key_origin_rejects_mismatched_origin_on_brand_json_resolver — negative side; pins the detail-payload host pair.
• test_factory_construction_threads_jwks_uri_into_resolver — factory-level construction-site check.

520 tests pass (test_verify_from_agent_url + test_agent_resolver + test_key_origins + tests/conformance/signing/). ruff + mypy clean.

The non-blocking items from the second review (IDNA + IP literals, trailing-dot stripping, runtime_checkable Protocol for the discriminant, class-definition order) noted for follow-up issues after this lands. Same for the minor nits (per-entry length cap on _extract_key_origins, raw-URL fallback shape on _mismatch).

[bokelley]

Thanks for the detailed write-up. The _BrandJsonStaticJwksResolver fix looks correct — storing jwks_uri on the instance is exactly what _maybe_check_key_origin needs, and the four integration tests exercising the production resolver path are the right coverage. Noted that the non-blocking items (IDNA + IP literals, trailing-dot stripping, runtime_checkable Protocol, class-definition order) are queued for follow-up issues after this lands.

---

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

---

Generated by Claude Code

[aao-ipr-bot]

Approving on the strength of the IDNA migration covering all four callsites cleanly plus the integration regression tests that pin both prior-pass bugs against future drift. Public-API additions are backward-compatible with safe defaults across the board.

Things I checked

• _BrandJsonStaticJwksResolver construction is structurally safe. agent_resolver.py:703-707 defines __init__(self, jwks: dict[str, Any], *, jwks_uri: str) — keyword-only required. The only in-tree call site at agent_resolver.py:655 threads jwks_uri=resolution.jwks_uri, and AgentResolution.jwks_uri is populated from a successful brand.json walk or raises AgentResolverError before reaching that line. The "marker without URI" trap from the second Argus pass cannot reconstitute.
• Order of operations. _maybe_check_key_origin fires at verifier.py:274-279 — after jwks_resolver(keyid) and _check_key_purpose, before revocation, replay cap, and crypto verify. Correct: a misconfigured tuple is rejected cheaply before Ed25519/ECDSA.
• Fail-closed on cold-cache jwks_uri. The jwks_uri or "" path at verifier.py:548 routes through _origin_host("") → None → check_key_origin_consistency raises request_signature_key_origin_mismatch. Comment at verifier.py:543-546 matches the actual trace.
• IDNA-2008 regression test pins both arms. tests/test_key_origins.py:286-316 asserts the positive straße.de ↔ xn--strae-oqa.de matches AND the negative straße.de ↔ strasse.de raises. Without the negative arm a silent IDNA-2003 regression would pass.
• CVE-2024-3651 floor is justified. idna>=3.7,<4 at pyproject.toml:108. All four callsites operate on urlsplit().hostname, which RFC 3986 bounds via DNS label syntax — no unbounded host length reaches idna.encode.
• Public-API surface is backward-compatible. Three new VerifyOptions fields (expected_key_origins, signing_purpose, posture) all carry safe defaults; AgentResolution.key_origins is Optional with None default. feat(signing): is the right conventional-commit prefix — no ! needed.
• Duck-typed protocol stays compatible. Legacy JwksResolver Protocol adopters without jwks_source skip the check (treated as publisher-pin-equivalent). Confirmed in tests/conformance/signing/test_verifier_key_origins.py:774-796.
• All four IDNA callsites converted. No stray host.encode("idna") remains under src/adcp/signing/. Exception handlers are uniform: (idna.IDNAError, UnicodeError, UnicodeEncodeError).
• code-reviewer: sound-with-caveats. security-reviewer: secure (one Low — same unknown-discriminant point). ad-tech-protocol-expert: sound-with-caveats; flags the purpose-enumeration drift question separately.

Follow-ups (non-blocking — file as issues)

• Unknown jwks_source discriminant fail-opens at verifier.py:540. source != \"brand_json\" silently skips on any non-\"brand_json\" value, including typos (\"brand-json\", \"BRAND_JSON\") and future variants. For internal usage this is unreachable (the ClassVar[Literal[...]] constrains it); for adopter-supplied resolvers a fat-finger silently disables the shared-tenancy-spoof defense. Consider tightening to if source not in (\"brand_json\", \"publisher_pin\"): raise or exporting a JwksSource enum with an unknown-value warning. Per security-reviewer: Low severity — adopters who control the resolver also control the trust anchor, and signature verification still gates the request.
• Purpose enumeration drift. key_origins.py documents four purposes (request_signing, webhook_signing, governance_signing, tmp_signing). Confirm signing_purpose validation against this list at a future tightening pass — currently any string flows through. Worth pinning against the upstream spec's normative purpose list before 3.1.
• 3.1 wire-shape forward-compat. _extract_key_origins (agent_resolver.py:332-357) reads identity.key_origins as dict[str, str] under additionalProperties: true. If 3.1 reshapes the field to a list-of-objects with posture/rotation metadata, the isinstance(origin, str) filter would silently drop entries rather than fail closed. Worth a defensive warning on non-string values, not a quiet drop.

Minor nits (non-blocking)

1. Class definition ordering. _BrandJsonStaticJwksResolver is defined after verify_from_agent_url references it (agent_resolver.py:677 vs agent_resolver.py:655). Python's name resolution at call time saves this, but top-down readability suffers. Move the class above the function.
2. Test-double duplicates production class. tests/conformance/signing/test_verifier_key_origins.py:555 defines a local _BrandJsonStaticResolver that re-implements the production _BrandJsonStaticJwksResolver. The new integration tests in tests/test_verify_from_agent_url.py:1107-1205 cover the production class against the real _maybe_check_key_origin — fine — but the test-double name is a near-miss with the production class.
3. Test reads type(resolver).jwks_source, verifier reads resolver.jwks_source. tests/test_verify_from_agent_url.py:1061 mirrors a different access path than verifier.py:539. Both succeed for a ClassVar, but the test should match production access.

Notable that this is the third Argus pass on the same PR; the two prior-pass bugs both picked up dedicated regression tests this time (test_factory_construction_threads_jwks_uri_into_resolver, test_brand_json_static_resolver_carries_jwks_uri_attribute). The fixes themselves landed under their own regressions — which is the right shape.

Ship it.