Web Bot Auth

Wat Web Bot Auth is

Web Bot Auth is de naam van een IETF-werkgroep en het bijbehorende Internet-Draft-werk over het authenticeren van geautomatiseerd webverkeer. Het idee is eenvoudig: crawlers, AI-assistenten en autonome agents ondertekenen hun HTTP-verzoeken met HTTP Message Signatures (RFC 9421), en publiceren de publieke sleutels die die handtekeningen verifiëren onder een identifier die zij zelf beheren. Een website kan dan bevestigen dat een verzoek echt afkomstig was van de operator die wordt genoemd, in plaats van te vertrouwen op een user-agent string die iedereen kan kopiëren. Voor wat dit betekent voor een productteam, zie Web Bot Auth voor productteams; voor implementatiestappen, zie de gids over hoe je ondertekende AI-agentverzoeken verifieert.

Per november 2026 is het kern document van de werkgroep draft-ietf-webbotauth-httpsig-protocol, dat een Signature-Agent header definieert voor sleutelontdekking in-band, een key directory-formaat op basis van JSON Web Key Sets en een well-known URI waar die directory wordt aangeboden. De pagina met documenten van de werkgroep noemt dit samen met verwante individuele drafts. Dit zijn Internet-Drafts, wat betekent dat het werk in uitvoering is. Details zoals hoe sleutels worden ontdekt, welke verzoekonderdelen moeten worden ondertekend en welke headers operatorinformatie dragen, kunnen tussen versies veranderen. Implementers moeten de actuele drafts volgen in plaats van een willekeurige snapshot.

Waarom het ertoe doet

Websites en APIs identificeren bots al lang via user-agent strings en IP-bereiken. Beide hebben beperkingen: user-agent strings zijn eenvoudig te spoofen (zie user-agent spoofing), en IP-bereiken verschuiven en worden gedeeld tussen cloudproviders. Nu AI-agents beginnen te browsen, APIs aan te roepen en MCP servers te gebruiken namens mensen, hebben applicaties een steviger manier nodig om samenwerkende geautomatiseerde clients te onderscheiden van anonieme clients.

Ondertekende verzoeken bieden dat stevigere fundament. Een geverifieerde handtekening laat een applicatie een bekende operator consistent herkennen, die een gestructureerd pad geven in plaats van een interface in menselijke vorm, en zijn activiteit nauwkeurig meten.

Hoe het op hoofdlijnen werkt

1. De operator genereert een sleutelpaar en publiceert de publieke sleutel op een locatie die aan zijn identiteit is gekoppeld, doorgaans het http-message-signatures-directory well-known pad onder zijn domein.
2. Elk verzoek bevat Signature-Input- en Signature-headers die geselecteerde verzoekonderdelen afdekken, plus een key identifier, en een Signature-Agent-header die naar de key directory verwijst.
3. De ontvangende site haalt de gepubliceerde sleutels van de operator op of cachet ze, bouwt de signature base opnieuw op en verifieert de handtekening.
4. Bij succes weet de site dat het verzoek is geproduceerd door de houder van die sleutel, gekoppeld aan die gepubliceerde identifier.

Wat het vaststelt, en wat het niet doet

Een Web Bot Auth-handtekening authenticeert de geautomatiseerde client. Het beantwoordt niet:

• of de operator gemachtigd is om te doen wat het vraagt (agent authorization),
• of een persoon de actie heeft geïnstrueerd of goedgekeurd (delegated authority),
• of de actie veilig is of de teruggegeven content op de juiste manier zal worden gebruikt.

Dat blijven beslissingen voor de eigen authenticatie, autorisatie en policy van de ontvangende applicatie. Ons blogbericht over wat ondertekende AI-agentverzoeken bewijzen, en wat niet verkent deze grens.

Veelvoorkomende misvattingen

• "Elke bot zal binnenkort ondertekenen." Adoptie groeit client voor client. Applicaties zullen lange tijd een mix zien van ondertekend, gedeclareerd en anoniem verkeer, dus ze hebben een duidelijke manier nodig om met elk type om te gaan.
• "Een handtekening maakt een bot goed." Het maakt een bot bekend. Bekend is het startpunt voor een policy, niet de policy zelf.
• "De draft is definitief." Het is een evoluerende Internet-Draft. Bouw tegen de huidige tekst en verwacht revisies.

Hoe Proof of Actor ermee samenhangt

Proof of Actor behandelt een gevalideerde handtekening als bewijs met de basis Verified, afgebakend tot de sleutel en identifier die het bewijst. Het houdt dat gescheiden van gedeclareerde namen en afgeleide signalen, en het maakt van identiteit nooit toestemming. Proof of Actor is ontworpen om ondertekende verzoeken te verifiëren naarmate deze standaarden zich ontwikkelen; jouw eigen policies in Route bepalen wat een geverifieerde agent mag doen.

Bekijk hoe dit past binnen APIs en MCP servers, of vraag vroege toegang aan.

Bronnen

• IETF Web Bot Auth working group: charter, voorzitters en status
• Web Bot Auth working group documents: huidige werkgroep- en gerelateerde drafts
• draft-ietf-webbotauth-httpsig-protocol: Signature-Agent, de JWKS key directory en de bijbehorende well-known URI (werk in uitvoering per november 2026)
• RFC 9421: HTTP Message Signatures: de handtekeningstandaard waarop Web Bot Auth voortbouwt