Agentic News

Web Bot Auth became a working group item, and the citation everyone uses is stale

On 1 September 2026 the HTTP-signature bot authentication draft was adopted as draft-ietf-webbotauth-httpsig-protocol-00. The widely-cited draft-meunier-* names are superseded, and the August revision quietly made Signature-Agent mandatory on every signed request.

23 September 2026 ·Agentic News editorial ·624 words ·free
urn:agenticnews:article:2026-09-web-bot-auth-is-now-a-working-group-item
sha256:fe306922a829b89a0c12d5c5ad0d4b47887fd88a52a70f9471208dd7bf80c372

The name changed, which matters more than it sounds

Web Bot Auth is a profile of RFC 9421 HTTP Message Signatures that lets a bot prove which bot it is, cryptographically, on every request. It spent most of its life as an individual draft under the draft-meunier-* name. As of 1 September 2026 it is a working group document: draft-ietf-webbotauth-httpsig-protocol-00.

Adoption is the point at which a specification stops being one company’s proposal and starts being something an origin can plan around. It is also the point at which every blog post written in the previous fifteen months acquires a dead citation. If you are writing a verifier today and your reference is a draft-meunier-* URL, you are reading a document that is no longer the one being revised.

Three headers, and one of them is newly mandatory

A signed request carries Signature-Input, Signature, and Signature-Agent. The third one is the change worth knowing: revision -02, on 18 August 2026, moved the draft to Standards Track and made Signature-Agent mandatory on every signed request. It is a Structured Fields dictionary whose value points at the key material — an origin serving a signature directory, a JWKS URI, or a client ID metadata document.

The rest of the profile is tight in ways that are easy to get wrong:

What an origin should actually do with a verified signature

The interesting question is not how to verify. It is what verification buys.

Gating access on a valid signature is the obvious move and, for most sites, the wrong one in 2026. The majority of agents do not sign. An origin that requires a signature excludes most of its machine audience to exclude a minority of impersonators, and impersonation is not the threat that costs it money.

The proportionate use is tiering. A verified signature is a durable identity, so it is a good basis for higher rate limits, trial access, or a reputation record that survives an IP change. Unsigned traffic keeps the default limits. Nothing is denied, and the incentive to adopt the signature points the right way.

There is also a cost argument on edge platforms. Verification needs an outbound fetch for the key set plus an Ed25519 check, so every verified request is a billed invocation even when the key set is cached. On a free-tier budget that is a real number, and it is a poor trade if the result is only ever advisory.

The asymmetry to watch

Deployment is ahead of standardisation here — Cloudflare has been running this at the edge since 2025, and the IETF process is catching up to an installed base. That ordering usually produces a stable specification, because the rough edges surface in production first.

It also means the interoperability risk sits with verifiers written from documentation rather than against a live signer. The tag check and the @authority coverage requirement are exactly the kind of clause that a from-scratch implementation skips and that never fails a local test.

Sources

This article answers

  • what is the current draft name for web bot auth
  • do I need to send Signature-Agent on every signed bot request
  • how does a server verify a web bot auth signature

Other representations:Markdown ·JSON ·JSON-LD