Web Bot Auth Checker — vérificateur Web Bot Auth
Collez une requête qu’un bot ou un agent d’IA a signée avec HTTP Message Signatures. Le vérificateur lit son champ Signature-Agent, charge l’annuaire de clés ou utilise celui que vous collez, et vérifie la requête comme le ferait un site web.
Les contrôles s’exécutent dans votre navigateur. Ce n’est que lorsque vous appuyez sur « Charger dans le navigateur » que votre navigateur demande l’annuaire de clés publiques du bot, directement à l’origine indiquée dans Signature-Agent ; la requête que vous avez collée ne quitte jamais cette page.
Source : draft-meunier-webbotauth-httpsig-protocol-02, annexe E, avec les clés de test de la RFC 9421 (B.1) ; réponse de l’annuaire tirée de l’annexe E.2.3. Vérification effectuée peu après la création des signatures (2025-01-01).
Annuaires de clés
La requête ne désigne aucun annuaire de clés pouvant être chargé.
Options
Bots that prove who they are
A User-Agent string can say anything, and an IP range changes whenever a crawler moves to another cloud. Web Bot Auth gives automated clients — search crawlers, AI assistants browsing on a user's behalf, monitoring services — a verifiable identity instead: each request is signed with HTTP Message Signatures (RFC 9421) using a key the operator publishes. The protocol is an IETF draft (draft-meunier-webbotauth-httpsig-protocol) already deployed by Cloudflare's verified-bots programme and by agents such as OpenAI's ChatGPT agent.
A signed request carries three fields:
Signature-Agent— a Structured Fields dictionary naming where the signer's keys live, for instancesig1="https://chatgpt.com";Signature-Input— the covered components (at least@authorityand theSignature-Agentmember),created,expires,keyid(the JWK thumbprint of the signing key, RFC 7638) andtag="web-bot-auth";Signature— the signature bytes.
The key directory
The origin named in Signature-Agent publishes its keys at /.well-known/http-message-signatures-directory (directory draft): a JWK Set served as application/http-message-signatures-directory+json, in which each key's kid is its thumbprint. The directory response is itself signed with each key it lists — a signature tagged http-message-signatures-directory over @authority;req and Content-Digest — which proves that whoever serves the directory holds the private keys and cannot list somebody else's key. The member can also point at a JWK Set (type=jwks_uri) or an OAuth client metadata document (type=cimd).
What the checker verifies
- The profile. A
web-bot-authsignature must havecreated,expiresand a thumbprintkeyid, cover@authority(or@target-uri), not be expired or created in the future, and should not live longer than 24 hours. - Signature-Agent. The checker parses the dictionary (and the older single-string form, with a warning), finds which member the signature covers, and works out the URL to resolve. A member that is not https, not a bare origin for a directory, or not covered by the signature is reported.
- The directory. Status 200 without redirects, the right media type, a JWK Set of usable public keys,
kidequal to the thumbprint, no private members,nbfandexprespected — and the directory's own possession-proof signatures with theirContent-Digest. - The request signature with the directory key whose thumbprint is the
keyid, through the same RFC 9421 signature base the HTTP Message Signatures verifier builds. The result says what the request can be attributed to: the directory URL when a directory vouches for the key, or only the key itself when it came from Keys you already trust.
The examples are the test vectors of the protocol draft's Appendix E, signed with the RFC 9421 test keys: an Ed25519 request with the signed directory of E.2.3, an RSA-PSS request with an unsigned directory, and the legacy string form of Signature-Agent. The signature mechanism underneath is explained in HTTP Message Signatures (RFC 9421) for APIs and bots.