Résumé
- Dans AIC-JWT 02, le mandant signe une Delegation Authorization compacte ; sa version 3 contient l’empreinte SPKI de la clé de l’agent, puis l’émetteur signe le jeton extérieur qui transporte cette chaîne exacte.
- Le vérificateur doit faire correspondre la clé de preuve désignée par
cnfet l’agent_key_bindingsigné par le mandant. Une réémission exige une nouvelle DA et un nouveau nonce, non la prolongation du consentement précédent.
Le certificat avait été émis il y a moins d’une minute. Les deux dates étaient cohérentes, la signature extérieure était valable et la clé cnf répondait à la preuve de possession. Pourtant, le contrôle d’accès refusa le jeton. L’empreinte de cette clé n’était pas celle que le mandant avait placée dans son autorisation.
Cet échec est précisément le résultat recherché par la révision 02 de l’AI Agent Identity Certificate (AIC) JSON Web Token Profile. Publié le 2 octobre 2026, le texte est un Internet-Draft individuel actif, annoncé comme Informational et expirant le 5 avril 2027. Il n’est ni un RFC, ni un consensus ou une approbation de l’IETF, ni la preuve d’un déploiement. Il sert ici de carte des responsabilités, pas de constat sur le marché.
L’octroi reste un objet signé
La première opération appartient au mandant. Celui-ci construit une Delegation Authorization, ou DA, sous la forme d’un JWT compact, puis la signe. L’agent ou l’émetteur place la chaîne compacte entière dans la revendication da du jeton AIC extérieur. La signature de l’émetteur couvre donc le texte exact de la DA : toucher à son en-tête JOSE, à sa charge utile ou à sa signature invalide aussi l’enveloppe.
Le vérificateur ne doit pas reconstruire cet objet à partir de ses champs. Deux JSON peuvent exprimer les mêmes valeurs tout en produisant des octets et une signature différents. La preuve porte sur la sérialisation compacte reçue, non sur la meilleure approximation d’un parseur. Les journaux d’audit doivent conserver cette chaîne et son empreinte, faute de quoi ils ne gardent que l’interprétation ultérieure du message.
Les deux signatures ne confèrent pas le même pouvoir. Celle du mandant atteste l’octroi. Celle de l’émetteur atteste le titre qui le transporte et les affirmations extérieures. Un émetteur reconnu ne peut pas modifier l’octroi sous prétexte qu’il contrôle l’emballage ; inversement, une DA authentique ne suffit pas à rendre fiable n’importe quel émetteur. Leurs clés doivent être validées selon la politique configurée et rattachées au même domaine de confiance accepté.
Les valeurs typ empêchent en outre le glissement entre rôles. Une DA n’est ni un AIC-JWT autonome ni un jeton d’accès. Si un logiciel accepte le même objet comme demande d’autorisation et comme résultat délivré, une signature valide change silencieusement de sens.
La clé choisie par le mandant
La version courante de la DA est ver=3. Elle exige agent_key_binding, l’empreinte de la SubjectPublicKeyInfo DER de la clé publique de l’agent, calculée avec l’algorithme déclaré. Ce champ se trouve à l’intérieur de la partie signée par le mandant. Le jeton extérieur exige de son côté cnf, qui lie le titre à la clé dont l’agent démontre la possession.
La décision dépend de la comparaison. La clé cnf doit correspondre à l’empreinte signée. Il est tout à fait possible que la signature extérieure, la preuve de possession et la DA soient valables séparément alors que leur assemblage est interdit. Une erreur d’association, un intermédiaire ou un émetteur compromis pourrait introduire une autre clé sans casser sa propre signature ; le rapprochement restitue au mandant le choix de l’agent autorisé.
ver=2 ne liait que l’agent_id, pas la clé. Le brouillon ne l’accepte qu’avec les mesures de réduction du risque de substitution qu’il décrit. ver=1 doit être rejeté et toute nouvelle DA doit employer la version 3. Une métrique de compatibilité qui mélange ces versions masque donc une différence de garantie, non un détail de format.
Les en-têtes ne réparent pas ce défaut. kid choisit un candidat dans un ensemble de clés déjà fiable et convenablement délimité ; il ne crée pas cette confiance. La présence de x5c ou x5t n’établit pas à elle seule une chaîne ni une politique. Les ancrages de l’émetteur extérieur et du signataire intérieur doivent satisfaire le domaine configuré. Une référence commode ne constitue jamais son propre mandat.
Une échéance n’est pas une cession de pouvoir
L’émetteur peut réduire la durée demandée, jamais l’allonger. La différence exp - iat du jeton extérieur ne peut dépasser la durée réclamée dans la DA, et son expiration ne peut aller au-delà de celle de la DA.
Le nonce de la DA est aussi son jti. Il est consommé lors de la première émission et ne peut soutenir un deuxième jeton extérieur. Renouveler ou réémettre exige une nouvelle DA, signée à nouveau par le mandant, avec un nonce frais. Le mécanisme transforme ainsi le renouvellement en nouvel acte de consentement.
Il faut distinguer cette protection contre la réémission de la répétition d’une requête. Un même jeton d’accès peut être présenté plusieurs fois pendant sa validité. La prévention du rejeu requête par requête relève, par exemple, du jti d’une preuve DPoP. Le registre de nonce DA répond à la question « un deuxième titre a-t-il été frappé ? » ; le registre DPoP répond à « la même preuve de requête a-t-elle été rejouée ? ».
L’intégrité précède l’autorisation locale
Le profil complet compare également les revendications des deux niveaux : mandant, capacités, mode de délégation, contraintes et position du sujet ou de l’acteur selon le mode. Toute divergence entraîne le rejet. Le système n’est pas censé réécrire ou filtrer silencieusement les capacités pour fabriquer un sous-ensemble plus pratique. Si la relation exigée n’existe pas, le titre est incohérent.
Cette validation ne prend pas la place de la politique locale. L’autorité effective demeure bornée par l’octroi du mandant, les capacités de l’agent, les contraintes AIC et les restrictions supplémentaires de la passerelle. Elle ne prouve ni que l’action demandée était opportune, ni qu’elle a été exécutée, ni que son effet extérieur est arrivé. L’identité, l’autorisation, l’exécution et le résultat gardent leurs reçus propres.
Le profil consommateur allégé peut omettre la DA dans un mode autorisé à faible risque. Il renonce alors explicitement à l’attestation cryptographique complète de l’autorisation du mandant. Ce compromis peut être décidé ; il ne doit pas être présenté comme une garantie identique.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

