Skip to content
↑↓ to move · Enter to openEsc to close
Glossary · Agents and ecosystems

Web Bot Auth

Updated

The Web Bot Auth working group charter notes that IP allowlisting, User-Agent strings and shared API keys have significant limitations for identifying automated clients, and commits the group to standardizing cryptographic authentication for them.

Its protocol draft, draft-ietf-webbotauth-httpsig-protocol, describes clients signing outbound requests with HTTP Message Signatures (RFC 9421), using a Signature-Agent header for key discovery and a key directory served at a well-known URI. It is an Internet-Draft, not an RFC.

Definition

Web Bot Auth is an IETF working group, and the family of drafts it develops, for cryptographically authenticating automated clients such as crawlers and agents when they access websites.

Also known as: webbotauth, HTTP message signatures for bots

How it relates to AgenID

Web Bot Auth works at the request layer: this HTTP request was signed by this key. AgenID works at the operator layer: this agent was declared by this operator, in a manifest bound by an operator-signed proof that anyone can resolve. AgenID does not authenticate individual requests today, so the two are complementary rather than competing.

The working group also lists related drafts, including one on a registry and a Signature Agent card and one on use cases. These are Internet-Drafts whose scope may change, so this page does not describe their details.

Why it matters

A website that can verify a request signature knows the traffic came from a particular key holder. Pairing that with a resolvable operator identity would tell the site who is accountable for the agent behind the key. Request signatures say this request came from this key; an operator identity says which accountable party stands behind the agent.

The reference deployment at agenid.com issues nothing above L1_REGISTERED today. L2 and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet.

What it does not mean

A signed request authenticates the sender; it does not decide what the bot is allowed to do. Access policy remains the site's choice. AgenID makes no claim about any site's support for these drafts.

Frequently asked questions

Is Web Bot Auth a finished standard?

No. The working group's protocol document is an Internet-Draft. RFC 9421, which it builds on, is a published Standards Track RFC.

Does AgenID sign HTTP requests?

No. Request-level authentication is planned, not implemented.

Could one key serve both?

This page makes no claim about that. The AgenID key format is defined in the spec.

What agenid.com issues today

The reference deployment at agenid.com issues DECLARED and L1_REGISTERED only. L2_DOMAIN_VERIFIED and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L5 is reserved by the specification and is not issuable at all.

Identity is not permission

Which agent is acting and who declared it is one question. What that agent is allowed to do is another, and it stays with the party on the other side and with the operator. Protocol v1.1.1 defines no signed authorization object.

Sources

  1. IETF Web Bot Auth working group charter
  2. Web Bot Auth working group documents
  3. RFC 9421: HTTP Message Signatures

Give your agent an identity

Register an agent in the browser — the signing key is generated on your device and never sent to AgenID — or resolve an existing AgenID and re-check its signature yourself.