HTTP Message Signatures (RFC 9421)

Ce que sont les HTTP Message Signatures

Les HTTP Message Signatures sont définies dans RFC 9421, une norme IETF destinée à créer et vérifier des signatures numériques sur des parties d'une requête ou d'une réponse HTTP. Un client choisit les composants à couvrir (par exemple la méthode, l'URI cible, l'autorité et certains en-têtes), construit à partir d'eux une base de signature canonique, puis la signe avec une clé privée. Le résultat est transmis dans deux en-têtes : Signature-Input (Section 4.1), qui liste les composants couverts et des paramètres tels que created, expires, keyid et alg, et Signature (Section 4.2), qui transporte la valeur de la signature elle-même. Les deux utilisent la syntaxe Structured Field Values de RFC 9651.

Le destinataire reconstruit la même base de signature (Section 2.5) à partir de la requête qu'il a effectivement reçue, recherche la clé publique référencée par keyid, puis vérifie la signature. Si quoi que ce soit couvert par la signature a changé en transit, la vérification échoue.

Pourquoi cela compte pour les apps, API et MCP server

La plupart du trafic automatisé s'identifie avec une chaîne user-agent ou un nom de client choisi librement. Les deux sont triviales à copier. Une signature de message est différente : elle lie une requête à une clé, et seul le détenteur de la clé privée peut produire une signature valide. Pour une application recevant du trafic de crawlers, d'assistants et d'agents autonomes, cela transforme « ce client dit qu'il est X » en « cette requête a été signée par la clé que X publie ».

Cette distinction est la base pour traiter des clients automatisés coopératifs comme des participants connus plutôt que comme du trafic anonyme. Elle permet à une API d'orienter un crawler signé vers un endpoint structuré, d'appliquer une limite de débit différente à un opérateur connu, ou de donner à un MCP server davantage de contexte sur l'auteur d'un appel à un outil.

Comment la vérification fonctionne en pratique

1. Analysez Signature-Input et Signature et confirmez que les composants attendus sont bien couverts. Une signature qui ne couvre rien d'utile prouve peu de choses.
2. Vérifiez les paramètres created et expires pour rejeter les requêtes périmées ou rejouées dans la limite de tolérance définie (voir Section 7.2.2 sur la répétition de signature).
3. Résolvez keyid vers une clé publique provenant d'une source de confiance, comme un annuaire de clés publié par l'opérateur à un emplacement connu. Le brouillon IETF Web Bot Auth protocol draft définit un tel annuaire pour les clients automatisés.
4. Reconstruisez la base de signature exactement comme spécifié et vérifiez-la avec l'algorithme déclaré.
5. Enregistrez ce qui a été vérifié et dans quel contexte, afin que les décisions ultérieures puissent s'y référer.

En production, utilisez une implémentation RFC 9421 maintenue plutôt qu'un parsing fait à la main : les détails de canonicalisation sont faciles à mal faire. Le guide sur how to verify signed AI agent requests passe en revue chaque étape avec du code.

Ce qu'une signature valide prouve et ne prouve pas

Une signature valide prouve que la requête a été signée par une clé et, si la clé est publiée sous un domaine, que la requête est associée à l'opérateur de ce domaine. Elle ne prouve pas :

• que l'opérateur est honnête ou que l'action est sûre,
• qu'une personne a instruit ou approuvé la requête (voir delegated authority),
• que le client est autorisé à faire ce qu'il demande (voir agent authorization).

Les preuves d'identité et l'autorisation sont des questions distinctes. L'authentification et l'autorisation propres à votre application décident toujours de ce qu'un client peut faire. Notre article de blog sur what signed AI agent requests prove, and what they don't approfondit ce sujet.

Idées reçues fréquentes

• « Signé veut dire digne de confiance. » Signé veut dire attribuable. La confiance est une décision de politique que vous prenez à propos de la partie attribuée.
• « Les signatures remplacent les API keys. » Elles répondent à une autre question. Une API key dit quel compte appelle ; une signature dit quel client a produit la requête. Beaucoup de déploiements bénéficient des deux.
• « Un trafic non signé est malveillant. » Aujourd'hui, la plupart du trafic automatisé n'est pas signé. L'absence de signature réduit ce qui peut être établi, rien de plus. C'est pourquoi Unknown est un résultat de premier ordre.

Comment Proof of Actor traite les signatures

Dans Proof of Actor, une signature qui se valide contre une clé publiée est enregistrée avec la base verified, limitée exactement à ce que le contrôle a établi : la clé et l'identifiant auquel elle appartient. La classe résultante (généralement Agent) n'implique jamais une autorisation. Les résultats alimentent Understand pour l'analyse, puis Route, où vos propres politiques décident si un client signé obtient un chemin structuré, une limite différente ou aucun changement. Les standards pour les agents signés, comme Web Bot Auth, évoluent, et Proof of Actor est conçu pour vérifier les requêtes signées au fur et à mesure de leur maturation.

Lisez-en plus sur what the evidence can establish, ou apply for early access.

Sources

• RFC 9421: HTTP Message Signatures: la norme IETF qui définit les composants de signature, les paramètres et la vérification
• RFC 9651: Structured Field Values for HTTP: la syntaxe de Signature-Input et Signature
• draft-ietf-webbotauth-httpsig-protocol: brouillon IETF Web Bot Auth appliquant RFC 9421 aux clients automatisés (travaux en cours en novembre 2026)