Web Bot Auth is designed to authenticate automated HTTP clients to websites—not to identify the person behind an agent, decide what a bot may access, or certify that it is trustworthy. The IETF charter sets those boundaries explicitly, and the current protocol draft adds that authorization and delegation are not part of the protocol. The draft is still work in progress, not a finalized standard.
What Web Bot Auth is intended to do
The approved IETF charter describes a standards effort for cryptographically authenticating automated clients and giving websites additional information about their operators. The target sites are those whose primary audience is human users. The charter names search crawlers, web archives, link checkers and validators, AI training crawlers, and AI agents retrieving or interacting with content for end users as examples.
As an Amazon Associate I earn from qualifying purchases.
The work is motivated in part by helping sites manage resources and access, reduce impersonation and resulting reputation damage, and differentiate service levels for automated and non-automated traffic. These are reasons a site may want to know which automated client is making a request; they do not make identity verification itself an access-control or reputation decision. See the approved Web Bot Auth charter.
What the charter explicitly excludes
The charter draws a boundary around the work. It excludes:
#1 Best Overall
- Authentication for content not intended for human consumption, with HTTP APIs and agent-to-agent interfaces given as examples.
- Authentication of the end user behind a participating client or agent.
- Authentication for application protocols other than HTTP.
- Non-cryptographic authentication methods.
- A standard vocabulary for bot intents.
- Tracking or assigning reputation to particular bots.
- Methods for distinguishing non-participating bots from ordinary, non-bot clients.
The end-user distinction matters for agents acting on a person’s behalf: the agent’s identity may be in scope, while the person’s identity is not. The charter does not turn an authenticated agent into an authenticated user.
What the current protocol draft adds—and does not add
The current working-group protocol document is titled “HTTP Message Signatures for automated traffic.” Its abstract describes automated HTTP clients signing outbound requests so a server can verify their identity. It specifies a Signature-Agent header for in-band key discovery, a JWKS-based key-directory format, and a well-known URI at which that directory is served.
The document, draft-ietf-webbotauth-httpsig-protocol-00, is an Internet-Draft dated September 1, 2026, with a stated expiry of March 5, 2027. It is not a final standard, and its design boundaries may change as the work progresses.
Free tools Windows power users keep installed
One-click scans. No signup required.
In its out-of-scope section, the draft says it does not authenticate human users, provide anonymous authentication, or define authorization or delegation. It also leaves open how trust is accrued or held. A valid signature can establish an identity association under the protocol’s checks, but the origin decides whether to process the request under its own policy. A signature on additional fields may convey other information; the identity signature alone does not establish what those fields mean or whether the request is permitted.
How to interpret a Web Bot Auth identity signal
| Question | What Web Bot Auth establishes | What it does not establish |
|---|---|---|
| Who is making the request? | An automated client’s cryptographic identity, as checked under the protocol. | The identity of the human for whom an agent may be acting. |
| May the request proceed? | It can provide identity information for the origin to consider. | Permission, authorization, or delegated authority; the origin applies its own policy. |
| Is the client trustworthy? | The protocol draft leaves trust accrual and handling unanswered. | A reputation score, reputation registry, or guarantee of good behavior. |
| What does the bot intend? | The charter allows additional operator information to be conveyed. | A standardized vocabulary of bot intents. |
| What if the bot does not participate? | Nothing in the charter standardizes its identification. | A way to distinguish every non-participating bot from an ordinary client. |
Where the boundary is especially easy to misread
It is about agents, not the people using them
An agent that retrieves or interacts with a human-facing website on behalf of an end user is among the charter’s use cases. That does not mean Web Bot Auth verifies the user, the user’s account, or the user’s authority. It authenticates the automated client within the protocol’s scope.
It is not a substitute for an API authentication scheme
The charter excludes authentication for content not intended for human consumption, including HTTP APIs and agent-to-agent interfaces. The fact that the protocol uses HTTP does not expand it to every HTTP resource: its stated context is automated access to websites primarily intended for people.
It does not label all traffic
The charter covers participating clients and explicitly excludes techniques for identifying bots that do not participate. A site should not treat an absent Web Bot Auth identity as proof that a request came from a human, or as proof that it came from a bot.
Identity is not reputation, intent, or permission
The charter excludes bot reputation tracking and a vocabulary of intents. The protocol draft separately declines to define authorization, delegation, or how trust is established. A site can use identity as one input to its own operational policy, but the protocol does not supply those judgments.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How the work is progressing
The IETF charter calls for standards-track work on authentication, additional information conveyed through a widely used identifier, and operational guidance on lifecycle management, key management, deployment, and effects on the Web’s openness. The IETF Web Bot Auth working-group page lists the group as active and provides its document status. Draft versions, milestones, and working-group status can change; consult the Datatracker for the current state.
The charter’s stated exclusions and the protocol draft’s current limits are complementary: the charter defines the effort’s intended scope, while the draft describes one protocol’s present design. Neither should be read as a promise that an authenticated request will be accepted, that a person has been verified, or that a client’s conduct has been assessed.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
