Grade tools: add OAuth and request signing setup evaluation

[bokelley]

Summary

The grade/compliance evaluation tools should be able to assess an agent's OAuth and RFC 9421 request signing setup. It's unclear whether current grading capabilities cover these, and the affordances aren't surfaced clearly to operators trying to validate their security posture.

Context

AdCP 3.0 includes:

• RFC 9421 request signing profile — Ed25519 HTTP Message Signatures, optional in 3.0, mandatory under AdCP Verified. Published test vectors at static/compliance/source/test-vectors/request-signing/.
• OAuth 2.1 + OIDC for authentication (authorization servers via RFC 8414, protected resource metadata via RFC 9728, dynamic client registration via RFC 7591).
• Signing is required for mutating operations under AdCP Verified; webhook callbacks have their own signing rules.

Operators setting these up need a way to verify their implementation is correct end-to-end: keys discoverable, canonical inputs producing bit-identical signatures, OAuth metadata properly published, scopes correct, etc.

Proposed evaluation surfaces

OAuth setup:

• /.well-known/oauth-authorization-server (RFC 8414) — present, well-formed, declares supported grants/scopes
• /.well-known/oauth-protected-resource/... (RFC 9728) — present, points to correct AS
• 401 responses include WWW-Authenticate: Bearer resource_metadata=… where appropriate
• DCR endpoint behavior (if exposed)
• Token validation roundtrip against a registered client

Request signing setup:

• Signing keys discoverable
• Test vectors at static/compliance/source/test-vectors/request-signing/ produce bit-identical canonical inputs
• request_signature_required returned correctly when unsigned mutating request is sent
• Webhook callback signing matches push_notification_config declaration
• Covered-components list, sf-binary encoding, URL canonicalization all conform

Asks

1. Confirm whether existing grade/comply tools already cover these — if so, document the affordance and how to invoke it.
2. If not, scope the work to add OAuth and request-signing evaluation as part of the security baseline storyboard (S6 specialist track per Add S6: Security mastery specialist module #2369).
3. Surface the capability so an Addie tool surface or CLI invocation can run it on demand against a target agent URL.

References

• Security implementation guide: https://docs.adcontextprotocol.org/docs/building/implementation/security
• Prerelease upgrade notes (3.0 signing profile): https://docs.adcontextprotocol.org/docs/reference/migration/prerelease-upgrades
• Related: S6 security specialist (Add S6: Security mastery specialist module #2369), request signing RFC (Mandatory request signing for mutating calls (RFC 9421 HTTP Signatures or JWS) #2307)

[bokelley]

Triage

Classification: Feature request
Bucket(s): compliance suite, security-sensitive
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: The gap is smaller than the issue implies. universal/security.yaml (security_baseline) already probes RFC 9728 PRM, RFC 8414 AS metadata, and token validation; universal/signed-requests.yaml covers signing key discovery, URL canonicalization test vectors, and the request_signature_required rejection path. What's genuinely absent: DCR probing, an on-demand CLI/Addie surface to invoke these storyboards against an arbitrary target URL, and the push_notification_config-to-declaration match (blocked on @adcp/client#2423). A new test-kits/security-baseline-runner.yaml (not a new specialism) is the right structural addition.
• security-reviewer: The passive half (endpoint discovery, static test-vector replay) is safe to surface now, provided every URL extracted from fetched documents (e.g., jwks_uri inside the AS metadata response) is re-validated through validateFetchUrl before following. The DCR roundtrip is a blocker on the active half: it requires active credential issuance against an external AS inside a multi-tenant context, and needs a design doc covering credential lifecycle, per-org isolation, and an explicit consent gate before any code is written.

My take: Ask 1 is answered — the storyboards exist; what's missing is an invocation surface. The unresolved design question is whether to ship passive surfacing now and put DCR behind a separate design doc, or scope everything together.

@bokelley, your call: Option A or Option B?

Option A — Surface passive evaluation now; DCR as follow-up design doc:

# New: test-kits/security-baseline-runner.yaml (modeled on signed-requests-runner.yaml)
# Addie on-demand tool invokes comply() with security_baseline + signed_requests
# DCR added as optional experimental phase:
- phase: dcr_probe
  x-status: experimental
  required_for: [adcp_verified]
  optional: true
  skip_if: "!test_kit.auth.dcr_endpoint"

Ships the on-demand surface and canonicalization vector runner quickly; gates DCR behind x-status: experimental until the credential-isolation design is reviewed.

Option B — Design-first for the full active + passive scope:

# Design doc covers before any PR:
# - passive/active mode split at the API level
# - DCR ephemeral-credential lifecycle and per-org isolation
# - explicit consent gate for active probing
# - push_notification_config match (unblocks after @adcp/client#2423)

Slower to ship, but passive and active surfaces land together with a coherent security model.

---

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

---

Generated by Claude Code