Résumé

  • AIP procède en deux temps : la signature démontre la possession de la clé présentée ; l’enregistrement du vérificateur ou le document DID résolu doit ensuite montrer que cette clé est bien rattachée à agentDid.
  • La révision 03 sépare l’autorité des identifiants did:web propres à un fournisseur de celle des identifiants did:opena2a de l’écosystème. Le type et l’objet déclarés par l’agent ne valent pas autorisation.

Le centre d’opérations avait reçu une réponse irréprochable en apparence. Le nonce était neuf, l’horodatage valide et la signature correcte sous la clé publique placée dans la réponse. Pourtant, le dossier d’enregistrement attribuait une autre clé à l’agent nommé.

Refuser cette réponse ne revenait pas à contester la cryptographie. Celle-ci avait prouvé exactement ce qu’elle pouvait : le répondant détenait la clé privée correspondant à la clé qu’il présentait. Elle n’avait pas prouvé que cette clé appartenait à l’identité revendiquée.

C’est la frontière essentielle de la révision 03 de l’OpenA2A Agent Identity Protocol (AIP). Publiée le 2 octobre 2026, elle demeure un Internet-Draft individuel, qui expire le 3 avril 2027. Ce n’est ni un RFC, ni un produit de groupe de travail, ni un consensus de l’IETF, ni la preuve d’un déploiement. La mention Standards Track exprime l’intention des auteurs, pas un statut obtenu.

La signature ne couvre pas toute la réponse

Le vérificateur produit un défi comprenant 32 octets aléatoires, l’agentDid revendiqué, un nonce aléatoire de 16 octets, issuedAt, expiresAt et issuerDid. Les heures sont exprimées en UTC selon RFC 3339, dans une fenêtre de cinq minutes.

L’agent signe la chaîne UTF-8 suivante :

<challenge>|<agentDid>|<nonce>|<issuedAt>|<expiresAt>

La réponse ajoute publicKey, keyId, signedAt et algorithm. Ces quatre champs ne figurent pas dans la chaîne signée. Ils peuvent servir à tenter la vérification, mais ne peuvent pas se conférer eux-mêmes une autorité. La règle « accepter l’identité parce que sa signature passe sous la clé qu’elle fournit » est circulaire : tout créateur d’une paire de clés peut la satisfaire.

Le premier résultat doit donc rester précisément libellé : signature valide sous la clé présentée. Le transformer en agent authentifié ferait disparaître une étape de preuve.

Deux contrôles, deux autorités

La procédure AIP commence par vérifier la signature avec la clé de la réponse. Elle établit ainsi la possession. Elle compare ensuite cette clé à celle qui est déjà liée à agentDid, soit dans l’enregistrement du vérificateur, soit dans un document DID résolu. Le texte interdit de faire confiance à la seule publicKey embarquée.

La fraîcheur, l’usage unique du nonce et l’appartenance d’issuerDid à un ensemble approuvé sont d’autres conditions nécessaires. Aucune ne remplace le lien entre clé et identité. Une signature récente et non rejouée sous une clé non attribuée reste une signature sous une clé non attribuée.

Cette séparation doit survivre dans la télémétrie. Le moteur de signature peut être sain alors que le résolveur est indisponible, obsolète ou compromis. Un document DID correct ne répare pas davantage une signature invalide. Un unique voyant « vérifié » rend ces pannes indistinguables lors d’un audit.

Une méthode DID répartit le pouvoir de nommer

La révision 03 clarifie la portée des méthodes. Une identité circonscrite au fournisseur utilise did:web; le fournisseur sert le document DID. La maîtrise du domaine, de TLS, de la publication, des caches et de la reprise devient alors une composante de l’autorité d’identité.

did:opena2a est réservé aux identités de portée écosystémique, dont le document n’est pas servi par le fournisseur d’identité. L’ancienne forme did:aip:aim_ devient un alias déconseillé. Le vérificateur doit traiter l’identifiant comme une valeur opaque et le confier au résolveur approprié, plutôt que d’inférer la confiance de sa seule apparence.

Ce choix de namespace est un choix de gouvernance. Avec did:web, l’identité hérite de la disponibilité et des procédures de récupération du fournisseur. La portée écosystémique requiert une autre autorité de résolution, un autre mécanisme de mise à jour et un autre règlement des litiges. Un repli silencieux de l’une vers l’autre transfère le droit de parler au nom d’un domaine de confiance.

Le draft signale aussi qu’au 8 septembre 2026, le résolveur de l’implémentation de référence ne répondait qu’à l’ancien alias. Cette note ne prouve aucun état de production actuel. Elle indique néanmoins un risque de migration : la méthode écrite dans le protocole et celle réellement comprise par le code peuvent diverger. Il faut conserver la méthode, le résolveur et le document effectivement utilisés au moment de la décision.

Décrire n’est pas autoriser

Le type de l’agent est informatif et ne doit pas fonder une décision de sécurité. Son declaredPurpose facultatif peut enrichir un contexte d’identité ou d’attestation, mais son absence ne justifie pas un rejet et sa présence ne doit pas servir d’entrée d’autorisation.

« Agent d’achat » ou « assistant de recherche » ressemble à un rôle ; sans preuve indépendante et décision d’autorisation, cela reste une déclaration de l’intéressé. De même, les composantes d’un score de confiance doivent être vérifiables indépendamment.

Même une clé correctement rattachée n’autorise pas automatiquement une dépense, une modification réseau ou un engagement contractuel. Identité, capacité annoncée, autorisation, exécution et résultat externe sont cinq faits distincts. Il faut donc séparer les reçus de défi, de signature, de résolution, de confiance de l’émetteur, d’autorisation, d’exécution et de résultat.