Interface AdcpCapabilitiesConfig

Type Declaration

• supported: boolean

  Whether this agent verifies RFC 9421 signatures on incoming requests. When true, signatures present on requests are validated per the AdCP request-signing profile. When false or absent, signatures are ignored (requests are bearer-authenticated only).

• Optionalcovers_content_digest?: "required" | "forbidden" | "either"

  Policy for content-digest coverage in request signatures. 'required': signers MUST cover content-digest (body is bound to the signature); body-unbound signatures rejected with request_signature_components_incomplete. 'forbidden': signers MUST NOT cover content-digest; body-bound signatures rejected with request_signature_components_unexpected. This is an opt-out for the narrow case of legacy infrastructure that cannot preserve body bytes. 'either' (default): signer chooses per-request; verifier accepts both covered and uncovered forms. 'required' is recommended for spend-committing operations in production; 4.0 recommends 'required' for those operations.

• Optionalrequired_for?: string[]

  AdCP protocol operation names (e.g., 'create_media_buy') for which this agent rejects unsigned requests with request_signature_required. Not MCP tool names, A2A skill names, or any transport-specific rename — verifiers MUST NOT accept operation names that are not defined by the AdCP protocol spec. JSON-RPC protocol method names like tasks/cancel belong in protocol_methods_required_for, not here. Empty in 3.0 by default; sellers populate selectively during per-counterparty pilots. In 4.0 this list MUST include all spend-committing operations the agent supports (create_media_buy, acquire_*, etc.). Counterparties MUST sign any listed operation. Every operation listed MUST also appear in supported_for (an operation can't be required without being supported); see x-adcp-validation.

• Optionalwarn_for?: string[]

  AdCP protocol operation names for which this agent verifies signatures when present and logs failures but does NOT reject the request. Used as a shadow-mode bridge between supported_for and required_for: the verifier surfaces failure rates in monitoring before flipping an operation to required. Precedence: required_for > warn_for > supported_for. An operation in required_for ignores warn_for. Counterparties SHOULD sign operations in warn_for; verifiers MUST NOT reject if the signature is missing or invalid. An operation MUST NOT appear in both warn_for and required_for; see x-adcp-validation.

• Optionalsupported_for?: string[]

  AdCP protocol operation names for which this agent verifies signatures when present but does not require them. Counterparties SHOULD sign operations in this list. Typically a superset of required_for and warn_for.

• Optionalprotocol_methods_supported_for?: string[]

  JSON-RPC protocol method names (e.g., 'tasks/cancel', 'tasks/get') for which this agent verifies signatures when present. Disjoint from supported_for, which carries AdCP tool names only. Counterparties SHOULD sign listed methods. The tasks/* family enumerated here matches the A2A 0.3.0 task-lifecycle methods (§7.x); future protocol additions extend this list, not supported_for. Items MUST be wire-format JSON-RPC method strings (containing /); plain AdCP tool names belong in supported_for.

• Optionalprotocol_methods_warn_for?: string[]

  Protocol method names for which this agent verifies signatures when present and logs failures but does NOT reject. Shadow-mode bridge between protocol_methods_supported_for and protocol_methods_required_for, mirroring warn_for semantics in the AdCP-tool namespace. An item MUST NOT appear in both protocol_methods_warn_for and protocol_methods_required_for; see x-adcp-validation.

• Optionalprotocol_methods_required_for?: string[]

  JSON-RPC protocol method names for which this agent rejects unsigned requests with request_signature_required. Separate namespace from required_for (which carries AdCP tool names) so verifiers and storyboard runners don't conflate the two — an AdCP tool name and an A2A method name could in principle collide as bare strings, but the protocol_methods_* bucket binds the match against the JSON-RPC method field, not the tools/call params.name. Every method listed MUST also appear in protocol_methods_supported_for; see x-adcp-validation.