Résumé

  • Le projet individuel draft-tulshi-oauth-transactional-access-tokens-00, daté du 29 septembre, propose un jeton d’accès OAuth bref, limité à un serveur de ressources et lié à une transaction que le serveur d’autorisation réexamine à chaque demande. Ce texte n’est ni une norme adoptée ni la preuve d’un déploiement.
  • Pour une opération touchant deux serveurs, les valeurs txn seraient différentes, tandis que le serveur d’autorisation conserverait la possibilité de les rapprocher. Le projet reconnaît que client_id, le contexte ou les horaires peuvent malgré tout créer d’autres liens.

Un assistant logiciel peut consulter plusieurs services pour accomplir une tâche autorisée. L’étendue d’un jeton d’accès classique renseigne sur des permissions, mais pas toujours sur la transaction qui motive cette invocation précise. Le nouveau projet propose de replacer la décision au serveur d’autorisation, qui remettrait un jeton de type txnat+jwt après évaluation de la demande. L’exemple d’un agent d’IA éclaire l’usage envisagé; il ne limite pas le mécanisme à l’IA. Datatracker classe encore le document comme projet individuel en état I-D Exists, avec une ambition Standards Track, non comme RFC.

Le cœur du choix se trouve dans la construction des identifiants. Le serveur d’autorisation crée un identifiant interne qu’il ne divulgue pas, puis attribue au premier serveur de ressources une valeur txn propre à son audience. Un client muni d’un handle opaque peut demander un deuxième jeton pour la même transaction. Le deuxième serveur reçoit une autre valeur, que les deux destinataires ne doivent pas pouvoir rapprocher par les seuls identifiants. À l’inverse, l’autorité qui les a émis conserve la vue d’ensemble nécessaire à un audit transversal. La frontière technique attribue ainsi le pouvoir de rapprochement.

Cette frontière reste partielle. La section consacrée à la vie privée signale que client_id est commun aux serveurs et rend une partie de la corrélation inhérente. Elle recommande des sujets distincts selon le destinataire et un contexte limité au nécessaire, tout en reconnaissant que des émissions très rapprochées peuvent trahir une même opération. Changer txn supprime une clé de jointure, non toutes les empreintes. Le serveur d’autorisation, seul détenteur de la jointure prévue, doit lui-même décider qui peut consulter ses traces et combien de temps les conserver.

La brièveté du jeton ne règle pas non plus la question de l’autorité durable. Le projet conseille un intervalle de validité d’au plus 300 secondes entre iat et exp; le refresh token ou l’identifiant de client à l’origine de la demande peut pourtant rester valable plus longtemps. Le bénéfice dépend d’une véritable décision de politique à chaque émission, capable de refuser une transaction même si la délégation générale reste valide. Un jeton porteur peut être rejoué pendant sa durée de vie. La contrainte d’émetteur est conseillée, sans être une obligation universelle du projet.

Il faut distinguer cette proposition du projet OAuth sur les Transaction Tokens utilisés à l’intérieur d’un domaine de confiance. Un article antérieur de BTW examinait l’origine des affirmations placées dans ce jeton interne signé. Ici, l’objet est le jeton d’accès remis à un serveur externe précis et le chemin de rapprochement entre plusieurs destinataires. La signature et l’identifiant local ne répondent pas, à eux seuls, à la question de savoir qui pourra reconstituer la transaction entière lors d’une enquête.

Sources