@adcp/sdk 6.8.0 → 6.10.0

package/compliance/cache/3.0.6/universal/security.yaml

@@ -0,0 +1,431 @@
+id: security_baseline
+version: "1.0.0"
+title: "Authentication baseline"
+category: security
+summary: "Every AdCP agent MUST require authentication on protected operations. At least one of API key or OAuth MUST be implemented and correctly advertised."
+track: security
+required_tools: []  # protocol-level, not tool-level
+
+narrative: |
+  Every AdCP agent handles data belonging to publishers or buyers that other parties
+  should not see or modify. Without authentication on protected operations, a seller
+  agent would leak media buys, creative libraries, or account-level reports to anyone
+  who knew the URL. Without correct authentication metadata, buyers cannot obtain
+  tokens with the right audience and every authenticated request fails with 401 — an
+  agent-side misconfiguration that looks identical to "my client is broken".
+
+  AdCP uses a tiered model: discovery operations (`get_adcp_capabilities`,
+  `list_creative_formats`, `get_products` without pricing) are public; operations
+  that return tenant-scoped data or modify state (`list_creatives`, `create_media_buy`,
+  `get_media_buy_delivery`, `sync_creatives`, etc.) require credentials. See
+  [/docs/building/integration/authentication](/docs/building/integration/authentication).
+
+  AdCP accepts two credential mechanisms: static API keys (Authorization: Bearer <key>)
+  or OAuth 2.0 + RFC 8707 resource indicators. An agent MUST implement at least one.
+  It MAY implement both. This storyboard verifies that (a) a protected operation is
+  rejected when called without credentials, (b) a deliberately invalid key is also
+  rejected (an agent that 200s on an unauth call and 200s on a bad-key call is
+  ignoring credentials entirely), and (c) at least one auth mechanism is present and
+  correctly advertised.
+
+  Pass semantics are encoded in the step flow: the unauth probe and invalid-key
+  probe (when a test-kit key is present) are always required, and at least one of
+  the API key phase or the OAuth discovery phase must contribute
+  `auth_mechanism_verified`. Agents that fail any required phase, or advertise no
+  working auth mechanism, are non-conformant.
+
+  **API-key-only agents (no OAuth).** An agent with no OAuth issuer — sandbox,
+  staging, or any production deployment that chose Bearer-only auth — does NOT
+  need to advertise RFC 9728 protected-resource metadata. Declare
+  `auth.api_key` in the test-kit and do not serve
+  `/.well-known/oauth-protected-resource/...`. The `api_key_path` phase
+  contributes `auth_mechanism_verified` and `oauth_discovery` is allowed to fail
+  silently as an optional phase — no fake issuer URL or stub RFC 8414 metadata
+  document is required. Agents that DO advertise `authorization_servers` in
+  their PRM MUST stand up the RFC 8414 auth-server metadata document to match;
+  advertising an issuer without serving its metadata is the failure mode this
+  storyboard was written to catch.
+
+  For local debugging before re-running compliance, use `adcp diagnose-auth <alias>`
+  (see adcp-client#563) to trace the full OAuth handshake and surface ranked
+  hypotheses about what's wrong.
+
+agent:
+  interaction_model: "*"  # applies to every agent regardless of specialism
+  examples:
+    - "Any AdCP agent (seller, signals, creative, retail media, SI, governance)"
+
+caller:
+  role: buyer_agent
+  example: "Compliance test harness"
+
+prerequisites:
+  description: |
+    The test kit declares the agent's **protected probe task** at `auth.probe_task`
+    — an auth-required, read-only task the agent supports (`list_creatives`,
+    `get_media_buy_delivery`, `get_signals`, etc.). The runner defaults to
+    `list_creatives` if unspecified. This is the task used for both the unauth and
+    invalid-key probes, since public tasks like `get_adcp_capabilities` return 200
+    without credentials by design.
+
+    The test kit MAY also provide an API key at `auth.api_key`. If absent, the API
+    key phase is skipped and the OAuth discovery phase MUST succeed instead. OAuth
+    discovery probes the well-known endpoint directly and does not require any
+    test-kit input.
+
+    Agent URLs MUST use `https://` in production compliance runs. The runner rejects
+    `http://` agent URLs outright unless invoked with `--allow-http` for local dev.
+  test_kit: "test-kits/acme-outdoor.yaml"
+
+phases:
+  - id: unauth_rejection
+    title: "Unauthenticated requests on protected operations are rejected"
+    narrative: |
+      The baseline conformance bar. A compliant agent MUST NOT serve protected
+      operations without credentials. 401 is the semantically correct response
+      (no/invalid credentials, retry with auth); 403 is accepted for pragmatic
+      reasons (many production gateways conflate them behind path-based ACLs)
+      but is suboptimal — 403 means "authenticated but forbidden" and should not
+      apply to an anonymous caller. Anything else (200, 500, network hang) is
+      non-conformant.
+
+      On 401, the response MUST include a `WWW-Authenticate` header per RFC 6750 §3
+      so clients know how to authenticate. A correct example:
+
+      ```
+      WWW-Authenticate: Bearer realm="https://agent.example.com/mcp", as_uri="https://auth.example.com"
+      ```
+
+    steps:
+      - id: probe_unauth
+        title: "Call the protected probe task with no credentials"
+        narrative: |
+          Send the test kit's declared protected task (`auth.probe_task`, default
+          `list_creatives`) with no Authorization header and no API key. The runner
+          forces credentials to be stripped via `auth: none` even when the transport
+          has a valid token configured. Expect 401 or 403.
+
+          If this probe returns 200 the agent is ignoring credentials on protected
+          operations — the most serious conformance failure this storyboard catches.
+        task: "$test_kit.auth.probe_task"
+        task_default: list_creatives
+        doc_ref: "/protocol/authentication"
+        comply_scenario: security_unauth_rejection
+        stateful: false
+        auth: none
+        expect_error: true
+        negative_path: schema_invalid
+        expected: |
+          The agent rejects the request with:
+          - http_status: 401 (preferred) or 403
+          - On 401, a `WWW-Authenticate: Bearer ...` header per RFC 6750 §3
+          - Example: `WWW-Authenticate: Bearer realm="<agent-url>", as_uri="<auth-server>"`
+
+        sample_request:
+          context:
+            correlation_id: "security_baseline--probe_unauth"
+
+        validations:
+          - check: http_status_in
+            allowed_values: [401, 403]
+            description: "Agent returned 200 or 5xx on an unauthenticated protected call — it MUST reject with 401 (and send WWW-Authenticate) or 403"
+          - check: on_401_require_header
+            value: "www-authenticate"
+            description: "401 responses MUST include a WWW-Authenticate header per RFC 6750 §3 (e.g. `Bearer realm=\"<agent-url>\", as_uri=\"<auth-server>\"`)"
+
+  - id: api_key_path
+    title: "API key mechanism"
+    narrative: |
+      **This phase OR `oauth_discovery` MUST pass — see `mechanism_required`.**
+
+      If the test kit provides an API key, the agent MUST accept it on the protected
+      probe task AND MUST reject a deliberately invalid key. Both checks together
+      prove the key is actually enforced — a 200 response with a valid key means
+      nothing if the agent returns 200 with an obviously bad key too. If no key is
+      provided the phase is skipped and OAuth discovery must succeed instead.
+
+    optional: true
+    skip_if: "!test_kit.auth.api_key"
+    branch_set:
+      id: auth_mechanism_verified
+      semantics: any_of
+
+    steps:
+      - id: probe_api_key
+        title: "Call the protected probe task with the provided API key"
+        narrative: |
+          Authenticate with the API key supplied by the test kit (as a Bearer token
+          in the Authorization header) and expect a normal 200 response on the
+          declared protected task. This confirms the static-credential path works
+          end to end.
+        task: "$test_kit.auth.probe_task"
+        task_default: list_creatives
+        doc_ref: "/protocol/authentication"
+        comply_scenario: security_api_key
+        stateful: false
+        auth:
+          type: api_key
+          from_test_kit: true
+        expected: |
+          The agent accepts the API key and returns a well-formed response with
+          http_status 200.
+
+        sample_request:
+          context:
+            correlation_id: "security_baseline--probe_api_key"
+
+        validations:
+          - check: http_status
+            value: 200
+            description: "Agent accepts the provided API key on the protected probe task"
+          - check: field_present
+            path: "context"
+            description: "Response echoes back the context object"
+          - check: field_value
+            path: "context.correlation_id"
+            value: "security_baseline--probe_api_key"
+            description: "Context correlation_id returned unchanged"
+
+      - id: probe_invalid_api_key
+        title: "Reject a deliberately invalid API key"
+        narrative: |
+          Send the same protected task with a Bearer token the runner generates
+          per-run from 32 random bytes (prefix `invalid-` for log readability,
+          e.g. `invalid-8e4a2c1f...`). A conformant agent rejects this with
+          401/403. An agent that returns 200 here is ignoring credentials entirely
+          and falsely appeared to pass `probe_api_key` — only the pair of (200 with
+          valid key, 401/403 with random-invalid key) proves the key is actually
+          checked. The token is randomized per run so no allowlist can collide
+          with it by accident.
+
+          Contributes `auth_mechanism_verified` only when *both* this step and
+          `probe_api_key` succeed.
+        task: "$test_kit.auth.probe_task"
+        task_default: list_creatives
+        doc_ref: "/protocol/authentication"
+        comply_scenario: security_invalid_key_rejection
+        stateful: false
+        auth:
+          type: api_key
+          value_strategy: random_invalid
+        contributes: true
+        contributes_if: "prior_step.probe_api_key.passed"
+        expect_error: true
+        negative_path: schema_invalid
+        expected: |
+          The agent rejects the random-invalid key with:
+          - http_status: 400 (if the agent enforces a key format the random token
+            doesn't match), 401 (preferred), or 403
+          - On 401, a `WWW-Authenticate: Bearer ... error="invalid_token"` header
+
+        sample_request:
+          context:
+            correlation_id: "security_baseline--probe_invalid_api_key"
+
+        validations:
+          - check: http_status_in
+            allowed_values: [400, 401, 403]
+            description: "Agent returned 200 on a known-bad API key — credentials are not being validated. MUST reject with 400 (key-format validation failure per RFC 6750 §3.1), 401 (preferred), or 403"
+          - check: on_401_require_header
+            value: "www-authenticate"
+            description: "401 responses on invalid credentials MUST include WWW-Authenticate with `error=\"invalid_token\"` per RFC 6750 §3"
+
+  - id: oauth_discovery
+    title: "OAuth discovery and audience binding"
+    narrative: |
+      **This phase OR `api_key_path` MUST pass — see `mechanism_required`.**
+
+      **Skip for API-key-only agents.** If your agent has no OAuth issuer,
+      declare `auth.api_key` in the test-kit and do not serve PRM. This phase
+      will fail its probes (404 on the well-known path), but failures inside
+      an `optional: true` phase do not fail the storyboard — the api_key path
+      carries `auth_mechanism_verified` on its own. Do NOT serve PRM pointing
+      at a fake issuer to "pass" this phase; that triggers the
+      advertised-but-unserved failure mode below.
+
+      OAuth-enabled agents advertise their auth server at the well-known path defined
+      by RFC 9728 §3. For an agent at `https://agent.example.com/mcp`, metadata lives
+      at `https://agent.example.com/.well-known/oauth-protected-resource/mcp` — the
+      agent's resource path is appended after the well-known segment. The metadata
+      MUST include a `resource` URL that matches the full URL being called (including
+      path) so clients issue RFC 8707 `resource` parameters that result in tokens
+      bound to the correct audience.
+
+      The canonical failure this phase catches: an agent advertising the auth
+      server's origin as its own `resource`, causing issued tokens to have the
+      wrong audience and every request to 401 for reasons the buyer cannot
+      diagnose from the error message alone (see adcp-client#563). Fix the metadata
+      document, not the OAuth config.
+
+      Contribution to `auth_mechanism_verified` is gated on the pair of
+      `probe_protected_resource` (advertises OAuth correctly) AND
+      `probe_invalid_oauth_token` (actually validates inbound tokens), symmetric
+      with the API key path. Metadata alone is not sufficient — an agent that
+      advertises OAuth but accepts any Bearer is broken in the same way an
+      agent that ignores API keys is broken.
+
+    optional: true
+    branch_set:
+      id: auth_mechanism_verified
+      semantics: any_of
+
+    steps:
+      - id: probe_protected_resource
+        title: "GET /.well-known/oauth-protected-resource/<path>"
+        narrative: |
+          Fetch the protected-resource metadata document for the agent's URL per
+          RFC 9728. Verify it returns 200, contains `resource` and
+          `authorization_servers`, and — the critical check — that the `resource`
+          value equals the agent URL under test. A mismatched `resource` silently
+          breaks every OAuth client.
+        task: protected_resource_metadata
+        doc_ref: "/protocol/authentication"
+        comply_scenario: security_oauth_discovery
+        stateful: false
+        expected: |
+          A 200 response with a JSON document. Example for an agent at
+          `https://agent.example.com/mcp`:
+
+          ```json
+          {
+            "resource": "https://agent.example.com/mcp",
+            "authorization_servers": ["https://auth.example.com"],
+            "bearer_methods_supported": ["header"]
+          }
+          ```
+
+          Required fields:
+          - `resource`: MUST equal the agent URL being called (including path)
+          - `authorization_servers`: MUST be a non-empty array of issuer URLs
+
+        sample_response:
+          resource: "https://agent.example.com/mcp"
+          authorization_servers:
+            - "https://auth.example.com"
+          bearer_methods_supported:
+            - "header"
+
+        validations:
+          - check: http_status
+            value: 200
+            description: "Protected-resource metadata is served at the well-known path per RFC 9728 §3"
+          - check: field_present
+            path: "resource"
+            description: "Metadata declares the protected resource URL"
+          - check: field_present
+            path: "authorization_servers"
+            description: "Metadata declares at least one authorization server issuer URL"
+          - check: resource_equals_agent_url
+            description: "The `resource` field in your metadata MUST equal the full URL clients call (including path). A common mistake: advertising the auth server's origin as `resource`. Fix the metadata document, not the OAuth config. Runner normalizes: scheme+host lowercased, default ports (443/80) elided; path is case-sensitive."
+
+      - id: probe_auth_server_metadata
+        title: "Verify authorization_servers[0] resolves (RFC 8414)"
+        narrative: |
+          Fetch the OAuth authorization-server metadata for the first issuer listed,
+          per RFC 8414 §3. The path is `<issuer>/.well-known/oauth-authorization-server`
+          — NOT `/.well-known/openid-configuration` (that's OIDC Discovery, a
+          different spec). Confirm the document is reachable and exposes the minimum
+          fields clients need to request a token (`issuer` and `token_endpoint`).
+
+          The runner applies SSRF guardrails on this outbound fetch: HTTPS only,
+          no RFC 1918 / loopback / link-local hosts, bounded response size and
+          time. If you are testing locally against a localhost auth server, run
+          the compliance runner with `--allow-http` to relax these guards for dev.
+        task: oauth_auth_server_metadata
+        doc_ref: "/protocol/authentication"
+        comply_scenario: security_oauth_discovery
+        stateful: false
+        expected: |
+          A 200 response from `<issuer>/.well-known/oauth-authorization-server` per
+          RFC 8414 §3 with at least `issuer`, `token_endpoint`, and one of
+          `grant_types_supported` or `response_types_supported` present.
+
+        validations:
+          - check: http_status
+            value: 200
+            description: "Authorization server metadata is reachable at <issuer>/.well-known/oauth-authorization-server (RFC 8414 §3) — not /.well-known/openid-configuration"
+          - check: field_present
+            path: "issuer"
+            description: "Authorization server declares its issuer"
+          - check: field_present
+            path: "token_endpoint"
+            description: "Authorization server exposes a token endpoint"
+
+      - id: probe_invalid_oauth_token
+        title: "Reject a bogus Bearer token on the protected task"
+        narrative: |
+          Metadata correctness proves the agent *advertises* OAuth correctly. It
+          does NOT prove the agent actually validates inbound tokens. An agent
+          that accepts any Bearer token on protected operations is broken in
+          exactly the same way an agent that ignores API keys is broken — this
+          step closes that loophole symmetrically.
+
+          The runner sends a JWT-shaped token generated per run: the header and
+          payload are well-formed base64url-encoded JSON objects
+          (`{"alg":"RS256","typ":"JWT"}` / `{"sub":"invalid","aud":"<agent-url>"}`)
+          so the agent's JWT parser succeeds, and the signature segment is
+          random base64url bytes so signature verification fails. Well-implemented
+          validators will return 401 `invalid_token` per RFC 6750 §3.1. Strict
+          validators that reject at parse time may return 400 `invalid_request`
+          per RFC 6750 §3.1 — both outcomes are conformant (the agent rejected
+          the bogus token). Minimal validators that don't parse at all should
+          still return 401 because the Bearer string doesn't match any issued
+          token. The token is randomized per run so no allowlist can collide
+          with it.
+        task: "$test_kit.auth.probe_task"
+        task_default: list_creatives
+        doc_ref: "/protocol/authentication"
+        comply_scenario: security_oauth_token_rejection
+        stateful: false
+        auth:
+          type: oauth_bearer
+          value_strategy: random_invalid_jwt
+        contributes: true
+        contributes_if: "prior_step.probe_protected_resource.passed"
+        expect_error: true
+        negative_path: schema_invalid
+        expected: |
+          The agent rejects the bogus Bearer with:
+          - http_status: 400 (syntactic parse-time rejection), 401 (preferred —
+            signature/audience/expiry failure), or 403
+          - On 401, a `WWW-Authenticate: Bearer ... error="invalid_token"` header
+
+        sample_request:
+          context:
+            correlation_id: "security_baseline--probe_invalid_oauth_token"
+
+        validations:
+          - check: http_status_in
+            allowed_values: [400, 401, 403]
+            description: "Agent returned 200 on a bogus Bearer token — OAuth validation is not running on protected operations. MUST reject with 400 (parse-time rejection per RFC 6750 §3.1), 401 (preferred — signature/audience failure), or 403"
+          - check: on_401_require_header
+            value: "www-authenticate"
+            description: "401 responses on invalid tokens MUST include WWW-Authenticate with `error=\"invalid_token\"` per RFC 6750 §3"
+
+  - id: mechanism_required
+    title: "At least one mechanism must be verified"
+    narrative: |
+      Logical check — not a network call. The storyboard runner fails this phase
+      if neither `api_key_path` nor `oauth_discovery` contributed
+      `auth_mechanism_verified`. An agent that rejects unauthenticated requests
+      but advertises no working auth mechanism cannot actually be called by a
+      compliant buyer, so it does not pass the baseline.
+
+    steps:
+      - id: assert_mechanism
+        title: "Require auth_mechanism_verified from at least one path"
+        narrative: |
+          Synthetic assertion over accumulated flags from prior phases. Passes
+          if any prior optional phase contributed `auth_mechanism_verified`.
+        task: assert_contribution
+        comply_scenario: security_mechanism_required
+        stateful: false
+        expected: |
+          At least one of the API key path (both valid-key and invalid-key steps
+          must succeed) or the OAuth path (correct metadata AND token validation
+          both must succeed) contributed `auth_mechanism_verified`.
+
+        validations:
+          - check: any_of
+            allowed_values: ["auth_mechanism_verified"]
+            description: "No auth mechanism was verified. Three things to check: (1) your test kit declares `auth.probe_task` pointing at a read-only authenticated task your agent supports (defaults to `list_creatives`); (2) you provide `auth.api_key` in your test kit AND the agent both accepts it and rejects a random-invalid key; OR (3) you serve protected-resource metadata at /.well-known/oauth-protected-resource/<path> with `resource` equal to your agent URL."

package/compliance/cache/3.0.6/universal/signed-requests.yaml

@@ -0,0 +1,205 @@
+id: signed_requests
+version: "1.0.0"
+title: "Signed requests — RFC 9421 transport-layer verification"
+category: signed_requests
+summary: "Agent verifies RFC 9421 HTTP Signatures on incoming AdCP requests per the transport-layer profile. Universal capability-gated storyboard — runs for any agent advertising `request_signing.supported: true` regardless of `supported_protocols`. Graded against conformance vectors covering every checklist step and canonicalization-edge rule."
+track: security_transport
+required_tools:
+  - get_adcp_capabilities
+  # Additional tool families are exercised transport-layer only — the runner signs
+  # requests targeting any mutating AdCP operation (create_media_buy, update_media_buy,
+  # acquire_*, activate_signal, sync_creatives) and grades the verifier's response.
+  # The runner picks operations available given the agent's `supported_protocols`;
+  # operations the agent does not implement are skipped, not failed. Runner
+  # implementation tracked at adcontextprotocol/adcp#2331.
+
+narrative: |
+  Request signing is a transport-layer claim that applies to every AdCP agent regardless
+  of which protocols it speaks. RFC 9421 verification behavior is identical whether the
+  agent is a media-buy seller, a signals agent, a governance agent, a creative agent, or
+  a brand agent. This universal storyboard certifies that an agent correctly implements
+  the AdCP RFC 9421 request-signing verifier per
+  [`docs/building/implementation/security.mdx#signed-requests-transport-layer`](/docs/building/implementation/security#signed-requests-transport-layer).
+
+  **Gating.** This storyboard runs for any agent advertising `request_signing.supported: true`
+  in `get_adcp_capabilities`. Agents that do not advertise support are not tested against
+  this storyboard — absence of advertisement is not a failure, it is a declaration that
+  the agent does not offer verified signed requests. Same gating model as
+  `deterministic_testing` (gated on `compliance_testing.supported: true`).
+
+  **Backward-compatible specialism claims.** The deprecated `signed-requests` specialism
+  enum value remains in the schema for back-compat (see
+  [#3075](https://github.com/adcontextprotocol/adcp/issues/3075)). Agents that still
+  advertise `specialisms: ["signed-requests"]` are graded via this universal storyboard;
+  the runner SHOULD emit an informational notice (not a failure) advising the agent to
+  drop the now-redundant specialism claim and rely solely on `request_signing.supported: true`.
+  4.0 removes the enum value entirely — see
+  [#3078](https://github.com/adcontextprotocol/adcp/issues/3078).
+
+  **Composition with other storyboards.** This storyboard runs independently of any
+  specialism a seller also claims. A seller advertising `request_signing.supported: true`
+  AND `specialisms: ["sales-guaranteed"]` is graded on both — universal failure does not
+  exempt the specialism's pass, and a specialism pass does not paper over universal
+  failure. The overall AAO Verified verdict requires all gated storyboards to pass; the
+  runner reports per-storyboard outcomes so operators can isolate failures.
+
+  **Grading.** Observable-behavior only. The runner constructs signed HTTP requests
+  exactly as documented in the conformance vectors at
+  `/compliance/{version}/test-vectors/request-signing/` and sends them to the agent. The
+  agent's responses are compared against the vectors' `expected_outcome`:
+
+  - Positive vectors MUST produce a non-4xx response — the agent accepted the signed request.
+  - Negative vectors MUST produce `401` with `WWW-Authenticate: Signature error="<code>"`,
+    where the `<code>` matches the vector's `expected_outcome.error_code` byte-for-byte.
+    The checklist step number is informational; grading is on the stable error code only.
+
+  The runner supplies signed requests; the agent is the verifier. A separate signer-side
+  storyboard may follow but is out of scope here — signers are easier to get right, and a
+  signer that produces valid signatures is proven correct by a conformant verifier
+  accepting them.
+
+  **Stateful vectors.** Three negative vectors — 016 (replayed nonce), 017 (key revoked),
+  and 020 (per-keyid cap) — assert verifier state the runner cannot set from the outside.
+  Those vectors declare `requires_contract` and are gated on the `signed_requests_runner`
+  test-kit contract at `test-kits/signed-requests-runner.yaml`, which specifies the
+  runner's signing keyids, a dedicated pre-revoked keyid (`test-revoked-2026`), and the
+  grading-time per-keyid cap the runner will target. Agents advertising
+  `request_signing.supported: true` MUST pre-configure their verifier per that contract
+  before the negative phase runs. If the agent does not satisfy the contract (e.g., the
+  runner can't coordinate the pre-state), the affected vectors grade as FAIL, never as
+  SKIP — the contract is a prerequisite for the capability claim, not an optional
+  extension.
+
+agent:
+  interaction_model: request_verifier
+  capabilities:
+    - verifies_request_signatures
+  examples:
+    - "Any AdCP agent advertising `request_signing.supported: true` — sales agent, signals agent, governance agent, creative agent, or brand agent"
+
+caller:
+  role: compliance_runner
+  example: "AdCP Verified runner (or equivalent signed-request grader)"
+
+prerequisites:
+  description: |
+    The agent MUST advertise `request_signing.supported: true` in `get_adcp_capabilities`.
+    The agent's verifier MUST be configured to accept requests signed by the test keypairs
+    published in `keys.json` alongside the conformance vectors — specifically, the runner's
+    signing keys (`test-ed25519-2026`, `test-es256-2026`) should be treated as coming from
+    a registered test counterparty whose JWKS contains those public keys with
+    `adcp_use: "request-signing"`.
+  test_kit: "test-kits/signed-requests-runner.yaml"
+
+phases:
+  - id: capability_discovery
+    title: "Capability discovery"
+    narrative: |
+      Confirm the agent advertises request-signing support before grading the verifier.
+
+    steps:
+      - id: get_capabilities
+        title: "Verify the agent declares request_signing.supported"
+        narrative: |
+          The runner calls `get_adcp_capabilities` and confirms that the agent declares
+          support for the request-signing capability. Absence of `request_signing.supported: true`
+          means the agent has not opted into this storyboard; the runner SHOULD skip the
+          remaining phases.
+        task: get_adcp_capabilities
+        schema_ref: "protocol/get-adcp-capabilities-request.json"
+        response_schema_ref: "protocol/get-adcp-capabilities-response.json"
+        doc_ref: "/protocol/get_adcp_capabilities"
+        comply_scenario: capability_discovery
+        stateful: false
+        expected: |
+          Return capabilities declaring request_signing.supported: true. If false or absent,
+          this storyboard does not apply and grading skips to a non-applicable outcome.
+        sample_request:
+          context:
+            correlation_id: "signed_requests--get_capabilities"
+        validations:
+          - check: field_present
+            path: "request_signing"
+            description: "Agent declares request_signing capability block"
+          - check: field_value
+            path: "request_signing.supported"
+            value: true
+            description: "Agent verifies request signatures"
+
+  - id: positive_vectors
+    title: "Positive conformance vectors"
+    narrative: |
+      The runner sends each positive vector as a signed HTTP request to the agent and
+      expects the agent to accept it. Vectors exercise the happy path plus every
+      canonicalization-edge rule in the profile:
+
+        001 basic Ed25519 POST
+        002 Ed25519 POST with content-digest covered
+        003 ES256 POST (edge-runtime profile)
+        004 multiple Signature-Input labels (verifier processes sig1 only)
+        005 default-port strip (URL has :443)
+        006 dot-segment path normalization
+        007 query-string byte preservation (no alphabetization)
+        008 percent-encoded path normalization (lowercase → uppercase hex)
+
+      Vectors and test keys live at
+      `/compliance/{version}/test-vectors/request-signing/positive/` and
+      `/compliance/{version}/test-vectors/request-signing/keys.json`.
+
+    $comment: |
+      Step-level YAML entries for each positive vector will be generated from the vector
+      fixtures at runtime by the compliance runner; we do not duplicate them in this file.
+      The runner loads the vector, constructs the HTTP request, sends it to the agent,
+      and validates the response against expected_outcome.success. Runner implementation
+      tracked at adcontextprotocol/adcp#2331.
+
+  - id: negative_vectors
+    title: "Negative conformance vectors"
+    narrative: |
+      The runner sends each negative vector and expects the agent to reject with the
+      stable error code in `expected_outcome.error_code`. Negative vectors cover every
+      failure mode in the verifier checklist (13 numbered steps plus sub-step 9a for
+      the per-keyid cap) plus the pre-check:
+
+        001 unsigned + required_for           → request_signature_required
+        002 wrong tag                         → request_signature_tag_invalid
+        003 expired signature                 → request_signature_window_invalid
+        004 window > 300s                     → request_signature_window_invalid
+        005 alg not allowed                   → request_signature_alg_not_allowed
+        006 missing covered component         → request_signature_components_incomplete
+        007 missing content-digest (required) → request_signature_components_incomplete
+        008 unknown keyid                     → request_signature_key_unknown
+        009 wrong adcp_use                    → request_signature_key_purpose_invalid
+        010 content-digest mismatch           → request_signature_digest_mismatch
+        011 malformed Signature-Input         → request_signature_header_malformed
+        012 missing expires param             → request_signature_params_incomplete
+        013 expires ≤ created                 → request_signature_window_invalid
+        014 missing nonce param               → request_signature_params_incomplete
+        015 signature cryptographically invalid → request_signature_invalid
+        016 replayed nonce                    → request_signature_replayed
+        017 key revoked                       → request_signature_key_revoked
+        018 content-digest when forbidden     → request_signature_components_unexpected
+        019 Signature without Signature-Input → request_signature_header_malformed
+        020 per-keyid replay cache cap        → request_signature_rate_abuse
+
+      Vectors live at `/compliance/{version}/test-vectors/request-signing/negative/`.
+      Grading requires byte-for-byte match on the error code; the failed_step value is
+      informational. The runner reads the error code from the agent's
+      `WWW-Authenticate: Signature error="<code>"` response header on 401.
+
+    $comment: |
+      As with positive_vectors, step-level entries are synthesized by the runner from
+      the vector fixtures. Runner implementation at adcontextprotocol/adcp#2331.
+
+grading:
+  pass_criteria: |
+    All vectors in positive/ produce 2xx, and all vectors in negative/ produce 401 with
+    the expected error code byte-for-byte. Any single vector's failure to produce its
+    expected outcome fails the storyboard. Vectors that declare `requires_contract`
+    whose contract the runner cannot satisfy grade as FAIL, never as SKIP — the
+    signed-requests-runner contract is a prerequisite for the capability claim, not an
+    optional extension.
+  report_format: |
+    Pass/fail per vector, with the response's error code (if any) and a diff against
+    the vector's expected_outcome. Operators receive specific per-vector diagnostics
+    so they can debug without re-running the full suite.