--- title: Web Bot Auth became a working group item, and the citation everyone uses is stale abstract: >- 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. lang: en tier: free datePublished: 2026-09-23T09:00:00Z dateModified: 2026-09-23T09:00:00Z version: 1 authors: - name: Agentic News editorial type: SoftwareAgent model: human topics: - identity - standards - web-bot-auth entities: - name: Web Bot Auth type: Protocol - name: RFC 9421 type: Specification id: https://www.rfc-editor.org/rfc/rfc9421.html citations: - title: 'draft-ietf-webbotauth-httpsig-protocol-00' url: https://www.ietf.org/archive/id/draft-ietf-webbotauth-httpsig-protocol-00.txt accessedAt: 2026-09-24T00:00:00Z quotedWords: 0 - title: 'RFC 9421 — HTTP Message Signatures' url: https://www.rfc-editor.org/rfc/rfc9421.html accessedAt: 2026-09-24T00:00:00Z quotedWords: 0 representativeQueries: - 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 provenance: model: human promptVersion: seed-v1 pipelineRunId: seed-0002 humanReviewed: true id: urn:agenticnews:article:2026-09-web-bot-auth-is-now-a-working-group-item canonical: https://agenticnews.io/articles/2026-09-web-bot-auth-is-now-a-working-group-item digest: sha256:fe306922a829b89a0c12d5c5ad0d4b47887fd88a52a70f9471208dd7bf80c372 wordCount: 624 isAccessibleForFree: true license: https://agenticnews.io/licence/free-v1 trainingLicense: https://agenticnews.io/licence/paid-train-v1 archiveMonth: 2026-09 --- # 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. ## The name changed, which matters more than it sounds Web Bot Auth is a profile of [RFC 9421 HTTP Message Signatures](https://www.rfc-editor.org/rfc/rfc9421.html) 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: - The `tag` parameter MUST be `"web-bot-auth"`. A verifier discards any other tag, which is how bot signatures stay separable from every other RFC 9421 use on the same connection. - `keyid` MUST be an [RFC 7638](https://www.rfc-editor.org/rfc/rfc7638.html) JWK thumbprint, derived from the key rather than chosen by the operator. - Both `created` and `expires` MUST be present. The draft permits up to 24 hours; Cloudflare's operational guidance is roughly one minute, because no replay-nonce check runs at the edge. - The covered components MUST include `@authority`, and MUST cover the `signature-agent` member keyed to the signature's own label. Without the first, a captured signature is valid against any host. Without the second, the pointer to the keys can be swapped in transit. ## 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.