Repository navigation
docs(signing): clarify signing-agent operator key discovery - #1430
Conversation
There was a problem hiding this comment.
Ladon verdict: Approve
Approve — docs + docstring-only clarification, no blocking or Medium findings.
This PR clarifies that signing keys root through the signing agent's operator (brand.json via get_adcp_capabilities / onboarding), closing the #1426 footgun. The reviewer verified every referenced SDK symbol and signature (verify_from_agent_url, async_resolve_agent, JwksUriSignerKeys, StaticSignerKeys, BrandJsonJwksResolver) as accurate. Changes to src/adcp/signing/brand_jwks.py are confined to module and class docstrings — no executable code change, matching the AST claim. Much of agent-resolution-33.md is reorganization of existing prose.
The high_risk flag fired only because brand_jwks.py matches src/adcp/signing/**, but the entry is (modified) with no Medium-or-higher finding, so it is presumed safe (no row-5 trigger). gated_paths is false, and the author matches no no-auto-approve team. No findings of any severity. None of rows 1–8 fire → row 9 approve.
Signing documentation used “operator” without distinguishing the signing agent's operator from the request account's operator or brand. That led sellers to discover signing keys at an agency's account domain and reject legitimate requests.
Clarify the trust source in both signing guides and the resolver docstrings. Lead with agent URL discovery and onboarded key mappings, explain the onboarding refresh responsibility, and present direct
BrandJsonJwksResolverconstruction as a lower-level option. Account and signing-agent operator roles remain distinct even when their domains coincide. Executable code is unchanged.Closes #1426.
Validation:
test_brand_jwks.py,test_agent_resolver.py, andtest_signed_request_verification.py.Open workspace in Conductor