Agent Card A2A : comment vérifier sa signature et sa clé
Une carte signée peut passer la vérification sans faute et ne rien prouver sur qui est en face. Tout dépend de la clé avec laquelle vous la vérifiez.
EN 30 SECONDES
Vérifier une Agent Card A2A, c’est contrôler sa signature JWS sur une copie canonique reconstruite de la carte. Ma politique : une clé fixée à l’avance, car la spécification vous laisse ce choix.
À RETENIR · 3
- Une Agent Card A2A peut porter une signature JWS. On la vérifie sur une copie reconstruite : signatures retirées, règles de présence appliquées, JSON canonique.
- Vérifiez-la avec une clé enregistrée à l’avance, jamais avec la seule URL de clé choisie par la carte. C’est ma politique : la spécification vous laisse ce choix.
- Même vérifiée, une carte ne prouve ni que son fournisseur existe, ni que l’appelant est cet agent.
Sur cette page
Vérifier la signature d’une Agent Card A2A
EN BREF On vérifie la signature sur une copie reconstruite de la carte, pas sur les octets téléchargés.
LES MOTS À CONNAÎTRE
- Agent Card
- Un petit fichier JSON où l’agent se décrit : nom, compétences, adresse, mode de connexion. Le protocole A2A oblige les serveurs à en publier un.
- Signature
- Une valeur calculée sur un contenu avec une clé privée. Avec la clé publique qui va avec, chacun peut vérifier qui a signé et que rien n’a changé.
- Clé épinglée
- Une clé publique enregistrée à l’avance pour un fournisseur donné, pour qu’une carte ne puisse pas imposer une clé de son choix.
Une Agent Card Un petit fichier JSON où l’agent se décrit : nom, compétences, adresse, mode de connexion. Le protocole A2A oblige les serveurs à en publier un. Voir le glossaire n’a pas à être signée. Une carte non signée reste valide en A2A, mais son contenu n’est qu’une déclaration non vérifiée.
Quand elle l’est, le format est JSON Web Signature (JWS, RFC 7515). Chaque Signature Une valeur calculée sur un contenu avec une clé privée. Avec la clé publique qui va avec, chacun peut vérifier qui a signé et que rien n’a changé. Voir le glossaire se range dans un tableau signatures, à côté du contenu, et la section 8.4.3 d’A2A v1.0.1 fixe l’ordre des contrôles.
A2A V1.0.1, SECTION 8.4.3
Étape 1. Prendre une signature. Prenez une entrée du tableau signatures. Il peut y en avoir plusieurs, pour changer de clé.
- Prendre une signature Prenez une entrée du tableau signatures. Il peut y en avoir plusieurs, pour changer de clé.
- Trouver la clé publique Trouvez-la par son identifiant. Une clé expirée ou révoquée ne doit jamais (MUST NOT) servir.
- Garder les bons champs Section 8.4.1 : champs requis et champs optionnels renseignés restent, même à leur valeur par défaut ; les autres valeurs par défaut et les listes vides optionnelles partent.
- Retirer les signatures Le champ signatures ne fait jamais partie du contenu signé.
- Réécrire sous une forme fixe JSON canonique (RFC 8785) : clés triées, aucun espace superflu, nombres au format fixe.
- Vérifier la signature Vérifiez-la sur cette copie canonique, avec l’algorithme indiqué dans son en-tête.
EN CLAIR
Le signataire a scellé une copie nettoyée de la carte. Vous refaites exactement cette copie, puis vous contrôlez le sceau avec la bonne clé.
L’étape que l’on rate, c’est la reconstruction. La section 8.4.1 ne dit pas « retirer toutes les valeurs par défaut » : un champ optionnel renseigné reste, et streaming: false est conservé. Passez la carte dans votre bibliothèque JSON habituelle, et même une carte valide peut échouer.
Coming up next: La signature se vérifie. Mais qui a signé, au juste ?
Quelle clé a signé la carte ?
EN BREF Une signature valide prouve seulement que quelqu’un a signé : toute la question est de savoir à qui est la clé.
L’en-tête protégé de la signature doit contenir alg (l’algorithme) et kid (l’identifiant de la clé), deux champs qu’A2A exige. Il peut aussi contenir jku, une URL vers un jeu de clés publiques.
Suivez l’URL de clé que donne la carte, et chacun peut publier une carte, héberger ses clés et signer. Ça se vérifie, sans rien prouver sur qui est en face.
C’est pour cela que je vérifie avec une Clé épinglée Une clé publique enregistrée à l’avance pour un fournisseur donné, pour qu’une carte ne puisse pas imposer une clé de son choix. Voir le glossaire, enregistrée pour ce fournisseur avant même que la carte n’arrive.
ATTENTION
Même parfaitement vérifiée, une carte a ses limites. Le nom et l’URL du fournisseur sont de simples chaînes : rien ne prouve que cette organisation existe ni qu’elle a consenti à quoi que ce soit. Et securitySchemes dit comment vous vous connectez à l’agent, pas comment il prouve qui il est.
Contrôler qui appelle vraiment, au moment de la requête, est un autre problème, et cet épisode s’arrête avant.
OBJET OBTENU
Épinglez d’abord la clé
FAQ
Retirez le tableau signatures, mettez le reste sous forme canonique (RFC 8785, JCS) et vérifiez au moins une signature JWS avec une clé publique de confiance, selon la section 8.4.3 de la spécification A2A v1.0.1. La clé devrait venir d’un magasin de clés épinglé ou d’une URL JWKS sur l’origine du fournisseur, pas d’une URL citée par la carte.
Sources, relues le 7 octobre 2026 : spécification A2A v1.0.1, note de version A2A v1.0.1, RFC 7515, RFC 8785. Ceci n’est pas un conseil juridique.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- On vérifie la signature d’une carte sur une copie canonique reconstruite.
- Selon ma politique, une signature ne compte qu’avec une clé choisie à l’avance.
- Même vérifiée, une carte ne prouve ni que son fournisseur existe, ni que l’appelant est l’agent.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Une carte est signée avec une URL de clé sur sa propre origine HTTPS, et la signature passe la vérification. Cela prouve-t-il que l’organisation citée dans provider existe ?
Non. C’est une confiance au niveau du domaine seulement : qui contrôle le domaine contrôle la carte. Le nom du fournisseur n’est qu’une chaîne de caractères.
Ingénieur web3 x IA, ancien CTO d’Integra. Auteur nommé (1 sur 5) d’ERC-3643, premier auteur d’ERC-6960, co-auteur d’ERC-7410 et co-auteur d’ERC-8203, encore à l’état de brouillon.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.