Web Bot Auth Signs the Sender, Not the Errand

That was the state of the art for deciding whether a 3 AM traffic spike was a partner's crawler or somebody scraping us into gravel. Web Bot Auth turns the guess into arithmetic. It does not turn it into judgment, and the spec is unusually upfront about which one it's handing you.

Underneath sits RFC 9421, the approved standard for signing HTTP messages. The bot-specific profile on top of it is an individual Internet-Draft from June 2026, active work not yet adopted by the working group. Know that before it lands on a roadmap next to a date.

The client chooses which parts of its request to cover, signs them, and sends two headers: Signature-Input, which enumerates exactly what was covered and in what order, and Signature, carrying the bytes. What the profile pins down, and what it leaves to taste:

The origin runs that arithmetic backwards. Reassemble the signature base (the exact string the client says it signed) from the request that actually showed up, fetch the operator's public keys (usually a key set at /.well-known/http-message-signatures-directory), pick the one matching the thumbprint, verify.

A pass covers what Signature-Input names and not one byte more. At the profile's floor that's the host plus four parameters; the draft's own example signs @authority and a single discovery header. So a verified request of that shape tells you a key holder sent something to this host inside a time window — not that they asked for this path, not that this body is theirs. RFC 9421 says it flatly: a valid signature does not by itself establish that the appropriate party signed the message, and applications should trust only covered components.

What the charter refuses to define

The working group charter puts two items out of scope:

The protocol draft pushes the first one further, advising that signing keys stand for a role, a company, or an automation identity rather than any specific human.

Work out what that means at your door. One verified key can front an operator's own indexing crawler, or a service running errands for thousands of unrelated people. Both produce a valid signature, byte-identical on the wire. Nobody ever encoded the difference between "this company is doing this" and "this company is doing this on somebody's instruction," which means no amount of logging discipline gets it back later. The information was never in the stream. You verified an operator, and that's the whole of the claim.

Intent isn't a cryptography problem. An agent can add a purpose header, cover it in the signature, and the purpose becomes tamper-evident. What's missing is agreement about what goes in it. Any purpose field you honor is a bilateral deal, negotiated one operator at a time, and whatever your parser accepts becomes the standard for everyone who wants through.

What lands on you

Two chores come back unannounced. Key discovery means an inbound verification now depends on an outbound fetch to a server you don't run, so caching, timeouts, and failure behavior are yours to design. And while created and expires are mandatory, with a window under 24 hours recommended, whether a replayed request actually gets refused depends on state you choose to keep.

Then the rollout trap. An unsigned request gives you no positive result — not human, not malicious, not lying. Same for a signature you couldn't check because discovery failed. Those go back to whatever bot management you already run, untouched, or you will spend a quarter explaining a partner's outage.

What you get is a stable, verifiable address for a counterparty. Mandate, purpose, and limits stay on your desk. I've argued in "False Precision" that we keep mistaking mechanical confirmation for authorization. The difference here is that the boundary was drawn deliberately, by people who bothered to write down where they stopped.