Résumé

  • draft-ietf-oauth-transaction-tokens-11 décrit un JWT signé et très bref qui transporte identité et contexte d’une transaction dans le Trust Domain désigné par aud. C’est un Internet-Draft actif, à l’état WG Consensus: Waiting for Write-Up, et non un RFC ou une approbation finale de l’IETF.
  • Le destinataire doit vérifier la signature JWS, l’audience et l’expiration. Ces contrôles protègent le conteneur ; ils ne disent pas à eux seuls si une valeur de rctx ou tctx a été fournie, observée, dérivée ou vérifiée indépendamment.
  • Daniel Kade propose de joindre à la décision une enveloppe d’origine des assertions : source, contrôle réellement effectué, date d’observation, transformation, version de politique, fraîcheur, usage permis, contradictions et résultat. Elle peut garder des empreintes ou des références plutôt que le jeton complet ou des données personnelles. Ce n’est pas une exigence de l’IETF.

Le problème est apparu lors d’une revue banale. Une règle d’autorisation dépendait de managed_device = true. L’équipe montra le jeton signé comme preuve. Elle savait identifier la clé, vérifier l’audience et contrôler exp. Elle ne pouvait plus dire si l’état de l’appareil venait d’un registre de gestion, d’une déclaration de l’appelant ou d’un calcul ancien du service émetteur.

Le jeton prouvait que la valeur n’avait pas été modifiée après la signature. Le dossier ne prouvait plus pourquoi le signataire l’avait retenue.

Cette différence ne diminue ni JWS ni le projet Transaction Tokens. Elle sépare simplement deux niveaux. L’assurance du conteneur répond à « qui a signé ces octets et sont-ils intacts ? ». L’assurance d’une assertion répond à « qui a constaté ce fait, par quel contrôle, à quel moment et pour quel usage ? ». Une architecture saine a besoin des deux réponses lorsqu’une valeur déclenche une conséquence.

La onzième révision n’est pas encore un standard achevé

La fiche Datatracker date la révision 11 du 30 juillet 2026 et la présente comme un Internet-Draft actif du groupe OAuth, sur la voie Standards Track. À la clôture de la recherche, le groupe affichait WG Consensus: Waiting for Write-Up et l’IESG I-D Exists. Aucun Area Director responsable ni calendrier de téléconférence n’était indiqué. Il s’agit d’une étape avancée, mais pas d’un RFC ni d’une décision finale de l’IETF.

L’historique et le diff officiel 10→11 limitent encore mieux la nouveauté : la modification corrige une coquille dans l’historique du document. Le modèle d’assurance analysé ici existait déjà dans la révision 10. L’annonce de publication atteste la nouvelle version, non son adoption définitive.

Le besoin technique reste convaincant. Une transaction entrée par une passerelle appelle souvent plusieurs services. Faire circuler à chaque saut le justificatif externe d’origine oblige chaque composant à comprendre ce justificatif et multiplie les interprétations. Le projet propose donc un Transaction Token : un JWT signé, valable peu de temps, qui accompagne le Call Chain à l’intérieur d’un Trust Domain défini par aud.

Chaque Trust Domain dispose d’un seul Transaction Token Service logique, même si plusieurs instances l’exécutent. Le TTS authentifie la charge de travail qui demande un jeton, vérifie qu’elle est autorisée à le recevoir, sélectionne le contexte et signe une représentation commune. JWT définit le cadre des assertions ; JWS fournit la signature ; le groupe OAuth porte les travaux.

Trois vérifications obligatoires, puis une décision locale

Une charge de travail destinataire doit valider la signature JWS, vérifier que aud correspond à son Trust Domain et s’assurer que le jeton n’est pas expiré. Aucun de ces verbes n’est facultatif. Ensemble, ils indiquent que le bon domaine reçoit un objet intact pendant sa période de validité.

Ils ne dictent pas l’autorisation finale. Le destinataire peut exploiter le contenu pour décider d’exécuter l’activité demandée, mais la méthode de cette décision reste hors du périmètre du projet. Le dernier service ne peut donc pas déléguer sa responsabilité à l’icône « signature valide ». Il doit connaître le sens opérationnel des champs qu’il utilise.

Le texte interdit aussi d’employer le Transaction Token comme justificatif d’authentification ou comme jeton d’accès OAuth. Dans OAuth 2.0, le jeton d’accès représente une délégation d’autorité. Le Transaction Token transporte le contexte de la transaction. Employer l’un comme l’autre transformerait une information utile en permission implicite.

Enfin, le jeton n’est pas résistant au rejeu. L’identifiant unique txn peut permettre une détection ou une règle d’usage unique, mais une garantie stricte dans un système distribué réclame parfois un état partagé peu réaliste. La signature ne rend pas une séquence d’octets impossible à présenter deux fois.

Autorité sur l’ensemble ne signifie pas origine uniforme

L’assertion scope est obligatoire et déterminée par le TTS. Celui-ci ne doit pas élargir le périmètre du subject token d’origine. Si ce périmètre lui est inconnu, il doit refuser la demande plutôt que traduire « inconnu » par « illimité ». Cette règle apporte une assurance substantielle sur la borne d’action.

rctx, recommandé, accueille du contexte de requête ou d’environnement. Quand l’appelant fournit ce contexte, le TTS devrait l’évaluer. Mais la valeur finale peut suivre au moins trois chemins prévus par le texte : reproduction exacte de l’entrée, dérivation à partir d’elle, ou assertion indépendante du TTS. Le TTS est l’autorité sur l’ensemble des assertions rendues disponibles. Il ne s’ensuit pas que chaque membre de l’ensemble a reçu le même contrôle.

tctx, également recommandé, conserve les détails destinés à rester immuables tout au long du Call Chain. Là encore, le TTS peut recopier des détails, les transformer ou ajouter ses propres assertions. La signature rend cette version immuable après émission. Elle ne reconstitue pas son acquisition en amont.

Prenons un jeton qui porte l’adresse de requête mesurée par une passerelle, un code pays dérivé de cette adresse et un plafond de paiement fourni dans un objet JSON non signé. Ces valeurs peuvent toutes être légitimes pour une opération donnée. Pourtant l’adresse dépend de la confiance dans la passerelle, le pays dépend aussi de la base et de la version du calcul, et le plafond dépend de la personne autorisée à renseigner l’objet. Le même sceau ne remplace pas ces trois raisonnements.

Il serait tout aussi faux d’en conclure que rctx et tctx sont peu fiables par nature. Leur assurance peut être excellente. Elle est simplement conditionnée par la source et le traitement de chaque champ. Une assertion dérivée d’un justificatif signé et revérifié n’est pas diminuée parce qu’une autre assertion du même objet est déclarative ; elle doit seulement rester distinguable.

La diversité des subject tokens appelle une trace précise

Le subject token admis par le TTS peut être un jeton OAuth ou SAML, un JWT auto-signé, un objet JSON sans signature ou tout autre format compris par le service. Le TTS doit le valider, y compris la signature lorsqu’il est signé. Cette phrase commune recouvre donc des opérations différentes : vérifier l’émetteur, la clé, l’algorithme, l’audience, les dates, le schéma ou le contrat de transport.

Les bonnes pratiques JWT montrent notamment pourquoi la clé et l’algorithme ne peuvent pas être acceptés sur la seule foi du contenu. Le token exchange OAuth offre un cadre voisin d’échange, tandis que le projet Transaction Tokens vise le contexte interne. Un JSON non signé peut être un apport convenu et utile ; il ne possède pas pour autant la preuve cryptographique d’un justificatif signé.

Le TTS contrôle en outre l’identité de la charge de travail demanderesse et son droit d’obtenir le jeton. Les règles métier d’émission restent propres au déploiement et hors spécification. Cette marge est nécessaire, mais elle rend la provenance locale importante : deux entreprises conformes au même projet peuvent attribuer une assurance différente au même nom de champ.

L’expiration du jeton ne décrit pas toute la fraîcheur

La durée attendue se compte en minutes ou moins, limitée à l’invocation. Le projet permet néanmoins au Transaction Token de dépasser la fin du subject token présenté, selon la politique du TTS, lequel devrait en apprécier le risque. Une chaîne courte peut ainsi se terminer proprement sans renouvellement externe. Mais exp certifie la fenêtre choisie pour le nouveau jeton ; il ne certifie pas que chaque information amont vient d’être revalidée.

Un jeton d’accès peut aussi être invalidé avant sa date. Selon le risque, le TTS peut interroger son état actuel par introspection ou moyen analogue. Le projet ne rend pas ce contrôle en direct universel. Un dossier sérieux doit donc noter « invalidation consultée à telle heure » au lieu de laisser « non expiré » en tenir lieu.

Les jetons de remplacement conservent txn, sub et aud et ne peuvent élargir les actions. Ils peuvent réduire le scope, ajouter des assertions et, si la politique le permet, prolonger la durée. Ils doivent préserver le Call Chain des charges demandeuses, sans que le mécanisme soit imposé. Si une assertion ajoutée au troisième saut paraît ensuite avoir existé dès le premier, la signature finale aura aplati une chronologie pertinente.

La frontière aud compte également. Un Transaction Token n’est valable que dans son Trust Domain. Le prolongement vers un autre domaine relève des travaux séparés d’enchaînement d’identité et d’autorisation OAuth. Une signature techniquement vérifiable n’autorise pas un domaine étranger à adopter les significations locales du premier.

Un avis de relecture, pas une statistique

Dans un message WGLC du 8 août 2026, un relecteur favorable à l’avancement et ne formulant pas d’objection bloquante demande une meilleure auditabilité des chaînes de remplacement. Il relève aussi le risque que des implémenteurs confondent une information transportée dans un jeton signé avec une information indépendamment attestée par son émetteur.

Il faut conserver la mesure de cette source. C’est le souci d’un relecteur, accompagné d’un retour d’expérience revendiqué. Ce n’est ni un consensus du groupe, ni un incident confirmé, ni une mesure de fréquence, ni la preuve que la révision 11 est défectueuse. Il signale simplement une ambiguïté opérationnelle plausible.

L’enveloppe d’origine porte sur ce qui décide

La proposition éditoriale de Daniel Kade consiste à créer, à côté de la décision, une enveloppe d’origine pour chaque assertion effectivement utilisée. Elle note la classe et l’identifiant de la source, le contrôle réellement exécuté, l’observateur et l’instant, les transformations et leur version de politique, l’émetteur ou la clé pertinents, la frontière de Trust Domain, le contrôle de fraîcheur ou d’invalidation, les usages permis, la sensibilité, les contradictions, la décision aval, l’expiration et la clôture.

Cette enveloppe n’a pas besoin d’alourdir le token ni d’imposer un schéma universel. Elle peut référencer le reçu d’émission, garder une empreinte ou pointer vers une preuve expurgée. Le projet interdit de journaliser le jeton complet tel quel, en raison du rejeu et des données sensibles. Une empreinte peut servir à retrouver le reçu du TTS ; la charge JWS non signée peut parfois être conservée. Elle peut toutefois contenir des données personnelles, notamment une adresse IP selon le contexte juridique. Cet article ne formule aucune conclusion de conformité légale.

La discipline est donc double : ne pas perdre la preuve utile et ne pas transformer l’audit en copie de tous les bearer tokens. L’enveloppe décrit la filiation du fait ; elle ne duplique pas le secret.

Sources