MapGraphSeamsCalendarIntroductionDisclosureMethodFor agents and tools

Updated weekly, new versions on Mondays · Corrections: open an issue

IETF Web Bot Auth (webbotauth WG)

IETFvenuecore entry

Verified 2026-10-13. Status as of 2026-10-13. All entries.

Seams: S3

Status

Active Working Group (WG), listed for coordination by the draft W3C Agentic Web charter; the first WG draft, draft-ietf-webbotauth-httpsig-protocol-00, was adopted on 2026-09-01, and a two-hour session was requested for IETF 127 on 2026-09-15. Implementation reports and proposed edits to the draft were on the list between 2026-10-04 and 2026-10-13. On 2026-10-13 the datatracker still lists draft-ietf-webbotauth-httpsig-protocol-00 (2026-09-01) as the only WG draft, and draft-illyes-webbotauth-cbcp-00 (2026-04-21, expires 23 October 2026) with no later revision. In the thread on updates to the crawler best practices draft a participant posted a revised text proposal on 2026-10-12 for a distinct Signature-Agent URL, key and key directory per crawler purpose, with pull requests in the WG draft repository and as PR #23 of garyillyes/cbcp (open, last update 2026-10-12); PR #22 of the same repository is open (3 comments, last update 2026-10-11). The IETF 127 session is still recorded as requested: no scheduling is found in the list subjects to 2026-10-13.

Relevance

The WG standardises cryptographic authentication of automated clients (HTTP message signatures, key directories), which a seller or its content delivery network (CDN) can use to tell which agent is calling. The chairs wrote on 2026-09-01 "Based on the feedback on the mailing list, the WG decided to adopt this draft as a WG document." Participants wrote of merchant-side verifiers: "We operate a production merchant-side verifier for automated commerce traffic (Web Bot Auth, Visa TAP, Google AP2)" (2026-08-03) and "We have implemented and use WBA for bot auth at Shopify in production, and we landed WBA interop for UCP" (2026-08-19).

On 2026-10-04 a participant from Auth Your Agent reported an implementation in which a user withdraws an agent by serving its key directory with no keys, cut max-age from 3600 to 300 because "an hour is a long time when the agent has just bought something the user disputes", and asked that verifiers respecting Cache-Control become a normative SHOULD in section 5.5.2 (the draft's appendix C.4 says they "should respect Cache-Control"); Thibault Meunier replied on 2026-10-07 "It seems that the simpler solution would be to prevent the agent from making request in the first place." On 2026-10-08 a participant from Akamai, writing as a verifier, supported moving the C.4 guidance into section 5.5.2 as normative text and proposed "Verifiers SHOULD NOT treat a cached directory as fresh beyond its freshness lifetime as defined in Section 4.2 of [HTTP-CACHE], except as permitted by Section", adding that "short signature expires values (Section 6.3) act faster than any directory TTL". The same day a participant, who publishes per-agent keys as a DNSSEC-signed record set and deactivates an agent by removing its key, wrote that "Section 5.5.2 bounds the wrong thing": where the key set reaches a verifier as a signed artifact (section 5.5.3), "the bound is the Appendix B signature's expires rather than any cache lifetime", and he measured on his apex "TTL 300 seconds against a signature window of 14 days and 1 hour". He proposed a sentence for 5.5.2 on the signature's expires and noted that section 6.3 (removal as the only remedy) and appendix C.12 (manual key rotation as the only revocation mechanism, listed as an anti-pattern) read as a contradiction when taken together. that participant answered on 2026-10-08 that his directories sent max-age=300 while the Appendix B proof on each was valid for 7 days, that he had cut the proof to one hour with a re-signature every 15 minutes, and that he supported the text of the participant who publishes per-agent keys.

On 2026-10-09 the same participant wrote that "The revocation thread got me reading the rest of the draft" and proposed for Appendix C.1 to replace "or the key is unknown" with "or the resolved directory does not provide the key", because a verifier could read an unknown key as "the key isn't on my list of bots" and so put a new agent that signs correctly in the same "unverified" outcome as a failed fetch; he also asked whether the draft should say anything about an intermediary that signs all its users' requests with one operator key, where removal under section 6.3 withdraws every user at once.

On 2026-10-07 a participant asked whether two bots with different purposes from one operator should have distinct Signature-Agent values and proposed a statement "So it's clear different Signature-Agents need to be used for different purposes / use cases."; he wrote that section 4.1 makes the Signature-Agent URL the identifier.

A participant from hCaptcha answered that it is similar to an open proposal, pull request #23 of garyillyes/cbcp, and that some crawl operators already do it, and wrote "I would support this proposal." On 2026-10-08 the same participant from Akamai supported a Signature-Agent per crawler purpose on the cbcp thread, citing that section 6.5 of the protocol draft "already says implementations SHOULD NOT reuse a signing key for different purposes and should use distinct keys and directories" and that "A signature that spans several purposes verifies fine but cannot carry that policy."; he asked that the 6.5 example be broadened to "an operator that runs both crawlers and user-directed agents". The crawler best practices draft (draft-illyes-webbotauth-cbcp, individual) was changed on 2026-10-05 (commit cc9942d of garyillyes/cbcp) and announced on the list the same day: a note that the practices "are intended for crawlers" and are "not necessarily appropriate for all automated clients", particularly "user-directed AI agents"; the requirement levels of the recommended practices changed from MUST to SHOULD; the proposal for a central crawler registry removed; and a Security Considerations section written, which says the opt-outs "are voluntary and do not constitute access control or content security measures" and that the User-Agent "is unauthenticated and trivially spoofed". Pull request #22 of garyillyes/cbcp (the author of this map, opened 2026-09-26, 429 and Retry-After in the back-out logic and a 429 on robots.txt read as unreachable) and #23 (opened 2026-10-06 by a participant, distinct subdomains for different crawl types) were both open on 2026-10-09; the only comment on #22 is of 2026-10-06 and reads "Common Crawl has always treated 429 as unreachable.", and in the announcement Gary Illyes wrote "I'm reviewing the pending PR to explicitly cover HTTP 429 and Retry-After". On 2026-10-05 a participant reported that his REDbot implementation emits signatures only when challenged ("the decision to only emit WBA when challenged") and that his agent-census log analyser sees "a reasonable number of bots emitting WBA by default"; he wrote that this is "an interoperability issue" worth highlighting in the document.

Thibault Meunier proposed on 2026-10-07 for section 5.3 "An Origin that expects a signature SHOULD request one from clients that did not provide it." in place of "An Origin MAY choose to request signatures from clients that did not initially provide them.", and a paragraph for appendix C, "Signing conditionally", saying that signing only when an origin asks "adds a round trip, and non-idempotent requests may not be safely retried". On 2026-10-08 a participant answered with text under which an origin that refuses unsigned requests "SHOULD include the Accept-Signature field", and "Origins that do not send Accept-Signature in either of these cases SHOULD NOT rely on the presence of signatures in requests unless there is a"

Committed next

Boundary

A co-chair wrote on 2026-08-10, on a human-principal layer, "Please keep topics within our charter".

Author participation

The author of this map took part in PR #22 and issue #19 of garyillyes/cbcp (crawler best practices), 2026-09-26, and replied on PR #22 on 2026-10-11; see Disclosure.

Sources

Overlaps

W3C Agentic Web Working Group (draft charter), KYAPay (Skyfire), Mastercard Agent Pay

Neighbours in the map

Neighbours of IETF Web Bot Auth (webbotauth WG) in the map Each circle is an entry of the map and links to its page; the colour is the kind of body behind it, a filled circle is a core entry and a dashed circle a context entry. The entry in the middle, with the entries it overlaps and the entries named by the same seams. Overlaps (9)Share a seam (7)W3C AI Agent Protocol Community Group (W3C, core)W3C AI Agent Protocol C… W3C Agent Identity Registry Protocol Community Group (W3C, context)W3C Agent Identity Regi… W3C Agentic Web Working Group (draft charter) (W3C, core)W3C Agentic Web Working… WebMCP (Draft Community Group Report, Web Machine Learning CG) (W3C, context)WebMCP IETF agentproto (Agent Communication Protocols WG) (IETF, core)IETF agentproto DIF Trusted AI Agents Working Group (Linux Foundation, context)DIF Trusted AI Agents W… KYAPay (Skyfire) (Industry, core)KYAPay Mastercard Agent Pay (Industry, core)Mastercard Agent Pay Visa Trusted Agent Protocol (TAP) (Industry, core)Visa Trusted Agent Prot… x402 (Linux Foundation, core)x402 S3 Browser vendor positions on WebMCP (WebKit, Mozilla, Chrome, Edge) (Independent, core)Browser vendor position… S3 OpenID Foundation AuthZEN Working Group (agent authorization drafts AARP and COAZ) (Independent, context)OpenID Foundation AuthZ… S3 Agentic Commerce Protocol (ACP) (Industry, core)Agentic Commerce Protoc… S3 Personal Agent Consent & Trust Protocol (PACT), published by Decagon with Instinct (Industry, core)Personal Agent Consent… S3 Personal Agent Protocol (PAP, "Poppy"), published by Sierra with Meta (Industry, core)Personal Agent Protocol S3 Universal Commerce Protocol (UCP) (Industry, core)Universal Commerce Prot… S3 IETF Web Bot Auth

Solid lines: overlaps declared by one of the two entries. Dashed lines, coloured by seam: entries named by the same seam (S1 to S4) in the seams note. Every node is a link.

Evidence and coverage

Read
WG charter and documents pages, read in full 2026-10-02; web-bot-auth list messages, 2026-08-01 to 2026-09-21, read 2026-10-03; the 11 messages of 2026-10-04 to 2026-10-08, read 2026-10-08; on 2026-10-13 the datatracker pages of the WG documents, of draft-ietf-webbotauth-httpsig-protocol and of draft-illyes-webbotauth-cbcp, the subjects and dates of the 26 latest list messages (2026-10-05 to 2026-10-13) and, in part, four messages of 2026-10-10 to 2026-10-13, and the state of cbcp PRs #19, #22 and #23; on 2026-10-09 the messages of the three threads below and the message of 2026-10-09 on Appendix C.1 (revocation and Cache-Control, signing on request, one Signature-Agent per purpose) and the announcement thread of the crawler best practices, read on mailarchive.ietf.org, and the repository garyillyes/cbcp at commit cc9942d with its pull requests #22 and #23.
Not read
The list messages of 2026-10-10 to 2026-10-13 beyond their subjects and the first lines of four of them, the list before 2026-08-01, issues of the draft repository.
Not found
Not found in datatracker and list (2026-08-01 to 2026-09-21): milestone completion, Know Your Agent (KYA), KYAPay, Mastercard Agent Pay.