Who’s on FirstChoose a flow

Flows / Agent to agent, agent to web

Web Bot Auth

An agent that browses the open web signs its requests, so a site can tell which operator it belongs to without trusting a user-agent string.

Based ondraft-ietf-webbotauth-httpsig-protocolWG draft, revision -01Guide reviewedNovember 2026

Sources and review details
This page
Implementation guideAn explanation, not a specification
Primary specification
Web Bot AuthWG draft · Revision -01, October 2026
All 4 specifications
1 published, 3 drafts
Flow maturity
EmergingWhat the rating means
Human involvement
With or without a human
Review
Checked against sources in November 2026How it was checked

Most of this site is about agents calling APIs that expect them. Agents also browse ordinary websites, which were built for people and regard automated traffic with suspicion. Sites have had two bad options for telling good bots from bad: the User-Agent header, which anyone can type, and lists of IP addresses, which break whenever infrastructure moves and say nothing about shared platforms.

Web Bot Auth replaces both with cryptography. The agent’s operator publishes its public keys at a well-known URL. The agent signs each request using HTTP Message Signatures and names the operator in a header. The website, or more usually the CDN in front of it, fetches the keys, verifies the signature, and then applies whatever policy it likes to a caller it can now name.

This is identification, not authorization. A valid signature says “this request came from operator X’s agent.” It does not say a user asked for it or that the site must serve it.

Step by step

8 steps between 4 parties. Each step shows the message and who holds which credential afterward. Use ←→ or select any arrow.

Sequence diagram4 participants, 8 steps
  • Direct call
  • Response
  • Local action

Drag to see every party and step. Tap a step to jump to its explanation.

1Publish key directory2Provisionsigning key3Sign the request4Signed HTTP request5Fetch key directory6Verify signature; apply policy7Forward withverified identity8Response

  1. 1Agent operatorLocal action

    The operator publishes its public keys

    A key directory in JWKS format, served over HTTPS from a well-known path on a domain the operator controls. That domain is the agent’s identity. The path and media type shown are those used in the drafts to date.

    GET /.well-known/http-message-signatures-directory HTTP/1.1
Host: agent.operator.example

HTTP/1.1 200 OK
Content-Type: application/http-message-signatures-directory+json

{ "keys": [ { "kty": "OKP", "crv": "Ed25519", "x": "JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs" } ] }

  2. 2Agent operatorBrowsing agentDirect call

    The agent is given a signing key

    The private key corresponding to an entry in the directory. On a shared agent platform this lives in the platform’s infrastructure, not in the model’s reach.

    Who holds what after this step

    Browsing agent
    newsigning key

    Parties not listed hold none of this flow’s credentials at this point.

  3. 3Browsing agentLocal action

    The agent signs each outgoing request

    An RFC 9421 signature over, at minimum, the target authority and the Signature-Agent header. The signature parameters carry a creation time, a short expiry, the key ID, and a tag that marks the signature’s purpose.

    Who holds what after this step

    Browsing agent
    signing key

    Parties not listed hold none of this flow’s credentials at this point.

  4. 4Browsing agentCDN / verifierDirect call

    The request arrives with three extra headers

    Signature-Agent says where to find the keys. Signature-Input describes what was signed and how. Signature is the signature itself.

    The example shows Signature-Agent in its original string form, which is what most deployed verifiers accept. Later drafts redefine it as a structured dictionary, so check the revision your counterpart implements.

    GET /products/widget HTTP/1.1
Host: shop.example
User-Agent: ExampleAgent/2.1
Signature-Agent: "https://agent.operator.example"
Signature-Input: sig1=("@authority" "signature-agent");created=1794268800;
  expires=1794268860;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";
  alg="ed25519";tag="web-bot-auth"
Signature: sig1=:jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp/EstF4RQTQdi5N5YYKrD+mCT1HA1nZDsi6nJKuHxUi/5Syp3rLWBA==:

    Who holds what after this step

    Browsing agent
    signing key

    Parties not listed hold none of this flow’s credentials at this point.

  5. 5CDN / verifierAgent operatorDirect call

    The verifier looks up the operator’s keys

    Using the URL from Signature-Agent, cached according to HTTP caching headers. A verifier may also keep its own registry of operators it recognizes.

    Who holds what after this step

    Browsing agent
    signing key

    Parties not listed hold none of this flow’s credentials at this point.

  6. 6CDN / verifierLocal action

    The verifier checks the signature and decides

    It rebuilds the signature base from the request, verifies it with the named key, and checks the time window. The request is now attributable to agent.operator.example. What happens next is policy: allow, rate-limit, serve a different representation, charge, or block.

    Who holds what after this step

    Browsing agent
    signing key

    Parties not listed hold none of this flow’s credentials at this point.

  7. 7CDN / verifierWebsiteDirect call

    The origin receives a labeled request

    Typically the CDN passes the verified operator identity to the origin so the site can make its own decisions.

    Who holds what after this step

    Browsing agent
    signing key

    Parties not listed hold none of this flow’s credentials at this point.

  8. 8WebsiteBrowsing agentResponse

    The site responds

    If the site needs to know which person the agent is acting for, to show an account page or take an order, that is a separate step using the site’s own login or an OAuth token.

    Who holds what after this step

    Browsing agent
    signing key

    Parties not listed hold none of this flow’s credentials at this point.

Watch out for

  • It identifies the operator, not the end user and not the individual agent run. Per-user authorization still needs a login or a token.
  • The identity is only as meaningful as the site’s policy for it. Verification proves a name; reputation is a separate matter.
  • The specification is an early working group draft, and the header syntax has changed between revisions. Deployed verifiers may expect an older form.
  • The signature covers selected parts of the request. Know which, and do not assume the body is protected.

Where this is going

The IETF working group has one adopted document and has missed its original milestones, so the details are still moving. The idea has already spread: payment networks have built agent-recognition schemes on the same signatures, adding fields that say whether the agent is browsing or paying and on whose behalf.

Standards in play

See the full tracker for status and links.

WG draftdraft-ietf-webbotauth-httpsig-protocol

Web Bot Auth

The one IETF mechanism for an agent to prove to an arbitrary website which operator it belongs to. Identification only.

RFCRFC 9421

HTTP Message Signatures

The building block under Web Bot Auth, the WIMSE HTTP signature profile, AAuth, and the card networks’ agent protocols.

Individual draftdraft-hardt-httpbis-signature-key

HTTP Signature Keys

Would give signed-request schemes a common way to find the signer’s key.

Agent payments (AP2)

The user signs what the agent may buy. The agent proves, to the merchant and to the payment network, that a purchase falls inside it.

Human reachableExperimental

Agent to agent (A2A)

One agent discovers another, reads what credentials it wants, and presents them. When the remote agent needs more, it says so mid-task.

With or without a humanEmerging

DPoP

Bind a token to a key so that stealing the token is not enough to use it.

With or without a humanStable standards

Workload tokens (WIMSE)

A workload identity that is bound to a key and proven on every request, so it survives the gateways and proxies that agent traffic passes through.

No humanEmerging