Résumé

  • Publiée le 8 septembre 2026, la révision 01 de draft-wei-aic-jwt reste une soumission individuelle active. Elle n’est ni un travail adopté par l’IETF, ni une norme approuvée, ni la preuve d’un déploiement ; Experimental n’est que le statut visé par l’auteur.
  • Le profil complet place un JWT de DelegationAuthorization signé par le mandant dans un AIC-JWT signé par l’émetteur. Le premier protège l’autorisation et agent_id ; le second recouvre le DA exact ainsi que la claim cnf.
  • Le texte précise que le DA actuel lie la délégation à l’identité de l’agent. La liaison de la clé de l’agent dans le DA est renvoyée à une future version ; aujourd’hui, cnf relie la clé de preuve de possession dans l’enveloppe signée par l’émetteur.
  • Il faut donc conserver un reçu qui attribue chaque liaison à son décideur, au lieu de résumer l’ensemble par « deux signatures valides ». Ce reçu est une proposition de gouvernance de Daniel Kade.

Le changement utile n’est pas un feu vert institutionnel

L’annonce I-D date la nouvelle version du 8 septembre à 14 h 48 UTC. Le Datatracker la classe dans les Individual Submissions et indique I-D Exists. Il ne fournit ni flux RFC, ni Area Director responsable, ni date de telechat. Un Internet-Draft peut être déposé par n’importe qui. Son en-tête annonce un statut souhaité Experimental, mais cela ne vaut ni adoption, ni approbation, ni recommandation de mise en production.

Cette retenue n’enlève rien à l’intérêt de la modification. AIC-JWT se présente comme une représentation applicative du modèle AIC défini séparément pour X.509. L’objectif est de transporter cette structure dans des environnements HTTP, web ou OAuth où le certificat ne peut pas être présenté au niveau transport. JWT et OAuth servent d’enveloppe et de chemin de consommation ; ils ne sont pas censés inventer les droits sous-jacents.

La comparaison officielle avec la révision 00 montre une réécriture substantielle. Le DA passe de la version de claims 1 à 2, reçoit les champs exigés pour l’usage RFC 7523, et la version 01 impose de refuser l’ancien format plutôt que de le convertir silencieusement. Surtout, elle formule explicitement une séparation que les interfaces risquent d’effacer : le nom de l’agent autorisé et la clé qui prouve la possession ne sont pas couverts par le même signataire.

Le DA dit ce que le mandant a autorisé

Dans le scénario PKI décrit, l’agent génère une paire de clés et prépare une demande avec capacités souhaitées, mode de délégation, contraintes et nonce. Le mandant examine la demande, signe le JWT DA et le remet à l’agent. Celui-ci le soumet ensuite à l’autorité de certification. Dans le mode serveur OAuth, le DA signé devient une assertion de grant JWT selon le RFC 7523.

Le contenu signé est détaillé. Outre iss, sub, aud, exp et jti, il contient agent_id, l’ancrage du mandant, la raison, les capacités, le mode, les contraintes, la durée demandée, l’horodatage et le nonce. La clé employée pour vérifier le DA doit correspondre à l’ancrage du mandant. Le jti doit être identique au nonce. Les types distincts aic+da+jwt et aic+jwt empêchent de prendre l’autorisation interne pour le jeton externe.

L’émetteur transporte dans la claim da la chaîne compacte exacte. Le vérificateur ne doit ni la reconstruire ni la resérialiser avant de vérifier le JWS interne. Modifier une capacité, l’audience, le mode ou agent_id casse donc la signature du mandant. De son côté, la clé du mandant ne suffit pas à créer l’AIC-JWT final : l’enveloppe exige la signature de l’émetteur.

Ce mécanisme donne au DA une vraie force probante, mais une force délimitée. Il permet d’affirmer que ce mandant a signé cette délégation pour l’identité agent_id avec ces limites. La révision 01 ne dit pas que la signature interne couvre l’empreinte de la clé de présentation.

cnf documente une autre décision

La clé de présentation est inscrite dans l’enveloppe. La claim cnf, obligatoire, lie le jeton à une clé de preuve de possession selon le RFC 7800. Une empreinte JWK jkt est recommandée. Avec DPoP, elle doit correspondre à l’empreinte de la clé qui signe la preuve ; avec mTLS, un déploiement peut aussi comparer la clé du certificat client.

Le projet répète la frontière dans ses deux chemins d’émission. Une liaison de clé au niveau du DA est réservée à une future révision du jeu de claims. Pour la version actuelle, la clé présentée est liée par cnf au moment de la consommation. Comme cnf se trouve dans le payload externe, c’est la signature de l’émetteur qui la recouvre avec le DA intact.

Il ne faut pas transformer ce constat en accusation. Le flux PKI commence par la génération de la clé par l’agent, et le mandant est invité à examiner la demande. L’émetteur n’a pas le droit de réécrire l’autorisation : il doit vérifier la signature, l’audience, la liaison du mandant, l’expiration, l’unicité du nonce et les contraintes applicables. Le jeton externe ne peut pas vivre plus longtemps que le grant signé par le mandant.

La question apparaît plus tard, lorsqu’il faut reconstruire la décision. Les octets du DA prouvent agent_id, pas une empreinte de clé DA qui n’existe pas encore. Les octets externes prouvent que l’émetteur a signé ce cnf. Si l’interface d’approbation a effectivement montré la clé au mandant, cette preuve appartient au dossier d’émission ; elle ne doit pas être inventée après coup à partir de la signature interne.

Il reste enfin à appliquer la preuve de possession. Le texte avertit qu’AIC-JWT n’est pas automatiquement sender-constrained. Un système qui accepte le jeton sans vérifier DPoP ou un mécanisme équivalent peut encore se comporter comme avec un bearer token volé. La présence de cnf annonce la clé attendue ; la décision du vérificateur montre que la possession a réellement été exigée.

Un reçu peut conserver la jonction sans exposer tout le graphe

Je proposerais un reçu de liaison de clé réunissant le hash exact et la version du DA, l’identifiant de clé du mandant, agent_id, l’émetteur, le hash du jeton externe, la méthode cnf et l’empreinte de clé, la politique d’émission, le résultat de consommation du nonce, l’intersection des expirations, la méthode de preuve de possession et la décision du vérificateur. Une éventuelle confirmation de la clé par le mandant doit occuper son propre champ, avec sa propre provenance.

Le reçu doit aussi séparer deux anti-rejeux. Le nonce du DA est consommé lors de la première émission et ne peut pas produire un deuxième jeton externe. Le jeton déjà émis peut, lui, être présenté plusieurs fois pendant sa durée de vie. La protection requête par requête relève du jti DPoP ou d’un mécanisme comparable. Confondre ces horloges donnerait un audit vert à une défense qui ne porte pas sur le même événement.

Les empreintes et les relations entre mandant et agent peuvent être sensibles. Un reçu protégé peut ne révéler qu’un engagement, un résultat de politique ou une référence d’audit. L’objectif n’est pas de bâtir un registre public d’identités et de clés, mais de permettre au bon contrôleur de retrouver qui a autorisé l’identité, qui a accepté la clé et qui a vérifié sa possession.

Le miroir de politique de Heng Lu aide à lire cette chaîne. Le mandant dispose du choix sur l’identité et les capacités. L’émetteur accepte le DA et recouvre la liaison actuelle de clé. Le vérificateur décide si la preuve et la politique locale suffisent. Le propriétaire de la ressource hérite de l’action. La cryptographie devient gouvernable lorsque ces quatre décisions restent visibles.

Sources