mcptest docs GitHub

Web Bot Auth conformance corpus (draft)

Status: v1.1+, draft, not yet implemented.

This file lists the rules we expect to ship in Phase 2 of the Web Bot Auth engagement plan (ADR 0021). None of the rules below are in compliance/registry.yml yet. Nothing in mcptest verifies them today. v1.0 ships without this corpus.

The rules are scoped to the classical bot surface that the WG charter covers: an HTTP client that signs selected request components with an Ed25519 key, publishes the public key through a discoverable directory, and asks an origin to verify the signature. Agent-to-agent extensions (delegation, "on behalf of" semantics, fan-out) are out of scope for this draft; they will land in a separate profile once the WG re-charters or a successor effort produces a spec.

Rule shape

Each rule, when implemented, will get:

Draft rule list

WEBBOT-001: Server accepts a valid signed request

The server processes a request signed per draft-meunier-web-bot-auth with a directory-discoverable key. The signature covers at minimum the mandatory components defined by the wire-format draft.

References: RFC 9421 sections on canonicalization and verification; draft-meunier-web-bot-auth wire format.

WEBBOT-002: Server rejects an unsigned bot request

The server distinguishes an unsigned request that claims bot identity (via User-Agent or a similar header) from a signed one. The unsigned path either denies the request, downgrades it to a lower trust tier, or emits a clear telemetry signal, per origin policy. The rule asserts that the server does not silently accept the unsigned request as if it were signed.

References: draft-meunier-web-bot-auth-architecture trust model.

WEBBOT-003: Server rejects a forged signature

The server rejects a request whose signature does not verify against the declared key. The rejection is observable in the response (status code, header, or body) so an upstream proxy can react.

References: RFC 9421 verification semantics.

WEBBOT-004: Server fetches the key directory at the documented URI

When presented with a signature whose key it has not seen, the server fetches the operator's directory at the well-known URI defined by draft-meunier-http-message-signatures-directory. The rule covers the fetch behavior, not the policy decision that follows.

References: draft-meunier-http-message-signatures-directory directory location and discovery.

WEBBOT-005: Server caches keys with the documented rotation semantics

The server honors the directory draft's cache TTL and rotation hints. A key marked superseded is not used for new verifications after its retirement timestamp. A key under rotation is accepted during the overlap window.

References: draft-meunier-http-message-signatures-directory rotation section.

WEBBOT-006: Server handles directory fetch failure gracefully

When the directory fetch fails (network error, malformed JSON, missing key), the server denies the affected request and emits a diagnostic. It does not fall back to accepting the request as signed.

References: draft-meunier-http-message-signatures-directory error handling.

WEBBOT-007: Server enforces signature freshness

The server rejects a signature whose created parameter is too old or too far in the future, per the wire-format draft's clock-skew tolerance. The default tolerance is the draft default; configuration that tightens the window is allowed.

References: draft-meunier-web-bot-auth freshness requirements; RFC 9421 created and expires parameters.

WEBBOT-008: Server normalizes structured fields before verification

Structured-field components (per RFC 8941) are canonicalized exactly per RFC 9421 before they enter the signature input. The rule guards against implementations that accept a signature computed over a different serialization of the same value.

References: RFC 9421 canonicalization; RFC 8941 structured fields.

WEBBOT-009: Server emits a verifiable Signature-Input on response

When the architecture draft recommends signed responses (informational rule today; may upgrade to required), the server emits a Signature-Input header whose covered components match the response body it returned. The rule lets a verifying client confirm provenance.

References: draft-meunier-web-bot-auth-architecture response signing section.

WEBBOT-010: Server exposes a stable signature-agent identifier

The server advertises a stable identifier for the signature agent it operates (its own bot identity, if it issues requests, or the identity of the operator on whose behalf it runs). The identifier is reachable via the directory.

References: draft-meunier-web-bot-auth-architecture agent identity section.

WEBBOT-011: Server respects the deny-by-default fallback

Where the spec is silent or ambiguous, the server's default is to deny the request rather than accept it. The rule formalizes that posture so a later spec update does not turn an ambiguous spot into a silent acceptance.

References: draft-meunier-web-bot-auth-architecture security considerations.

Out of scope for this draft

These cases will get their own profile, layered on top of the rules above, in a successor document:

The agent-to-agent profile depends on either the WG re-chartering or a successor effort producing a credible spec. Until then, the surface is out of scope.

Open questions

The corpus is a draft. We expect the following to change before Phase 2 implementation begins:

We track answers as the drafts advance. The corpus version pin happens when the drafts hit WG-LC.

References