[bokelley]

Problem

generate_signing_keypair, pem_to_adcp_jwk and adcp-keygen --purpose narrowed purpose to Literal["request-signing", "webhook-signing"] and raised on anything else. That set is narrower than the spec vocabulary and than the SDK's own internals:

• response-signing (the designated-task response JWS profile, core/response-payload-jws-envelope.json) could not be minted or published.
• governance-signing is what adcp.governance already requires of a governance JWK, but keygen could not produce one.
• A surface the vocabulary does not name yet (e.g. an agent signing its own OAuth access tokens) had no way to set adcp_use.

The helpers underneath (generate_ed25519, generate_es256, _adcp_public_jwk) already took a plain str.

Fix

• purpose is validated syntactically: a lowercase hyphenated token ([a-z0-9]+(-[a-z0-9]+)*), at most 64 characters. Empty, upper-case, underscore, whitespace, leading/trailing/double-hyphen and non-str values still raise ValueError; the CLI exits 2 before writing a file.
• Constants: adcp.signing now exports ADCP_USE_REQUEST, ADCP_USE_WEBHOOK (commented as deprecated upstream, adcp#5555), and the new ADCP_USE_RESPONSE and ADCP_USE_GOVERNANCE. governance.py uses the constant.
• Docstrings say why an open vocabulary is safe (purpose matching is fail-closed) and no longer claim every verifier refuses a request-signing key on webhooks: 3.3 webhook verifiers accept {request-signing, webhook-signing}, and new webhook signers publish request-signing.

The signature is widened from a Literal to str, so existing callers are unaffected. This isn't a breaking change.

Tests

• response-signing, governance-signing and an unregistered token round-trip into adcp_use, through both entry points and the CLI.
• Malformed purposes raise.
• Fail-closed property: a key minted under response-signing, governance-signing or an unregistered purpose is refused by the request verifier (request_signature_key_purpose_invalid) and by the webhook verifier's accepted-uses set.

Not changed: WebhookSender.from_jwk still requires adcp_use == "webhook-signing" even though 3.3 says new webhook signers use request-signing. That's a sender-policy question, separate from what keygen can express, so I left it as a follow-up.

Closes #1677

🤖 Generated with Claude Code

[aao-secretariat]

Ladon verdict: Approve

Approve — clean PR, no blocking or medium findings.

Checked: widening keygen purpose from a closed Literal to a syntactically-validated open str is a contravariant input change (non-breaking, correctly shipped under feat(signing):). Reviewer verified the fail-closed claim holds against the real verifier (membership-checked adcp_use), re.fullmatch anchors token validation, and the CLI exits 2 before writing. Tests cover every new branch.

High-risk flag is true only because three src/adcp/signing/** files were modified, but no medium-or-higher finding attaches to them, so the modification is presumed safe (no deletions). No gated paths, no author team gate, no escalation trigger. Falls through the decision table to row 9.

[aao-secretariat]

Ladon verdict: Approve

Approve.

Delta since the prior approve is a single additive change: tests/fixtures/public_api_snapshot.json gains four adcp.signing constants (ADCP_USE_GOVERNANCE/REQUEST/RESPONSE/WEBHOOK). Values match constants.py and the __all__ additions verbatim, ordering is consistent, and the feat(signing): prefix is correct for additive exports plus a non-breaking Literal→str widening of purpose.

Checks:

• No critical/high/medium findings in this run.
• high_risk is true only due to (modified) entries under src/adcp/signing/**, but the reviewer found no medium-or-higher concerns on those files — modifications presumed safe. No (deleted) reasons, so row 3 does not fire.
• gated_paths: false; review_decision: APPROVED — no gate blocks.
• No no-auto-approve team match.
• Prior decision was approve, so no sticky escalation applies.

No escalation trigger, no team gate, zero medium findings → falls through to row 9 (approve).