If you want AI agents to prove who they are on your store, the newest Web Bot Auth draft changes the division of labour: the origin is now told to ask for a signature, and the agent signs only when asked. On 2026-10-28 the working group’s spec repository logged draft-ietf-webbotauth-httpsig-protocol-01, the first revision after the group adopted the draft. It is still an Internet-Draft, not a standard.

What the -01 changelog says

The spec’s own changelog lists five changes for -01:

  • Every Signature-Agent value becomes a direct JWK Set URI. The directory, jwks_uri and cimd types are removed.
  • An origin that expects a signature is recommended to request one with Accept-Signature. Signing is described only on request.
  • The JWK alg is separated from the signature alg.
  • A crawler and a user-directed agent use distinct Signature-Agent URLs.
  • The draft states that identifiers allow correlation across origins.

The origin now speaks first

The draft’s section on requesting a signature says an origin that expects one SHOULD request it from clients that did not provide it, using Accept-Signature from RFC 9421. Concretely:

  • If you refuse unsigned requests, usually with 403, you SHOULD include Accept-Signature in that response to state your requirement.
  • If you accept an unsigned request, you can still send Accept-Signature on the success response to signal that a signed one would be treated differently.
  • If you send neither, you SHOULD NOT rely on clients signing unless you have a private arrangement with them.
  • A valid signature does not guarantee acceptance. That stays your policy.

Agents, for their part, MAY ignore a signature request that does not fit their signing policy.

Crawler and agent get separate identities

The security section says implementations SHOULD NOT reuse a signing key for different purposes. An operator that wants origins to tell a crawler from a user-directed agent should use distinct Signature-Agent URLs, signing keys and key directories. For a store this makes a rule like “allow the shopping agent, rate-limit the crawler” expressible per identity instead of per vendor.

The draft also states the cost plainly: it lets receivers recognise requests carrying the same identifier and correlate them, including across origins, and rotating keys does not prevent that. It calls the protocol unsuitable for agents that need to avoid identification.

What to check on your store

  • Your bot rules. If a WAF rule blocks unsigned automated traffic, see whether it returns an Accept-Signature hint. Under -01 that header is how a compliant agent learns to retry signed.
  • Your Signature-Agent parsing. The draft already requires the dictionary form, and we reported Cloudflare’s verifier rejecting it in September, so re-test before assuming signed traffic reaches you.
  • Your policy wording. Decide whether you admit a verified agent identity, a verified crawler identity, both or neither, since they should now arrive as different URLs.

FAQ

What is Accept-Signature in Web Bot Auth?

It is the HTTP header from RFC 9421 that a server uses to tell a client which signature it wants. Draft -01 of the Web Bot Auth protocol recommends that an origin expecting a signature send it, either on a refusal response or on a successful one. An agent that supports Web Bot Auth can then sign its next request.

Is Web Bot Auth draft -01 a standard?

No. It is a working group Internet-Draft, and the spec’s own front matter still carries the keyword “not-yet”. Details can change before any publication as an RFC, so treat it as direction, not a finished contract.

Why does a crawler need a different Signature-Agent from a shopping agent?

The draft says a key should not be reused for different purposes and that an operator who wants origins to distinguish a crawler from a user-directed agent should use distinct Signature-Agent URLs, keys and directories. That lets a store set different rules for each.

Sources

Verifying who an agent is only matters if the agent can then complete a purchase, which is the part AgentReady audits.