Résumé

  • La révision 11 de draft-ietf-oauth-attestation-based-client-auth, publiée le 3 septembre 2026, est entrée en dernier appel du groupe OAuth le 8 septembre. Les avis sont attendus avant le 22.
  • Le serveur n’est pas obligé de fournir un défi. S’il le fait, sa durée et son caractère réutilisable ou à usage unique dépendent exclusivement de sa politique locale. Le client doit prendre la dernière valeur reçue et peut s’en servir plusieurs fois.
  • Au deuxième usage, un serveur qui consomme chaque valeur répond use_attestation_challenge, en fournit une nouvelle et ouvre la voie à une seule relance. Le mode combiné DPoP suit, lui, la mécanique de nonce du RFC 9449.
  • Les nouvelles métadonnées décrivent méthodes de preuve et algorithmes, pas la politique de consommation. Daniel Kade propose une déclaration de fraîcheur au niveau du profil ; ce n’est pas une exigence de l’IETF.

Le dernier appel porte sur un texte, pas sur un résultat acquis

Le message de dernier appel demande aux membres du groupe OAuth d’exprimer leur soutien ou de motiver leurs objections d’ici au 22 septembre. La fiche Datatracker place bien la révision 11 au stade « In WG Last Call ». Le document franchit donc une étape de gouvernance réelle, sans être encore un RFC ni une décision de l’ensemble de l’IETF.

Le mécanisme cherche à authentifier non seulement un identifiant de logiciel, mais une instance particulière. Un Client Attester délivre un Client Attestation JWT signé. L’instance présente ensuite une preuve qu’elle détient la clé privée liée à cette attestation. Le serveur d’autorisation ou la ressource protégée vérifie ainsi une chaîne plus fine qu’un secret partagé copié dans toutes les installations.

Dans le mode normal, la preuve est un Client Attestation PoP JWT. Elle contient notamment une date de création et un jti unique. Le serveur peut aussi remettre une valeur opaque destinée à garantir la fraîcheur. Elle arrive dans une réponse d’erreur, dans une réponse antérieure quelconque ou depuis un endpoint consacré aux défis. Dès qu’une valeur existe, le client doit employer la plus récente.

La révision 11 laisse toutefois deux propriétés décisives au serveur : la durée de vie de la valeur et le nombre de preuves dans lesquelles elle peut figurer. Le client a explicitement le droit de réutiliser le même défi. Un serveur a tout aussi explicitement le droit de refuser la seconde utilisation. Chacun respecte le texte ; leur première rencontre peut quand même échouer.

Cette latitude n’est pas un défaut cryptographique. Elle reconnaît que les infrastructures n’ont ni le même budget d’état, ni la même tolérance à la latence, ni les mêmes menaces. Mais la valeur étant opaque, elle ne dit pas au client si elle représente un ticket jetable, une fenêtre courte réutilisable ou une session. La politique locale reste locale jusque dans ses effets les plus visibles.

Une erreur bien définie reste une erreur évitable

Le projet décrit précisément le rattrapage. Un serveur d’autorisation qui exige une autre valeur renvoie un statut 400 et use_attestation_challenge. Une ressource protégée répond 401 dans le cadre de l’authentification. Dans les deux cas, l’en-tête OAuth-Client-Attestation-Challenge doit contenir un nouveau défi. Le client devrait reconstruire sa preuve et recommencer une fois ; il ne doit pas boucler indéfiniment.

Cette borne protège les deux côtés contre une divergence sans fin. Elle ne répond pas à la question d’organisation qui précède la requête. Un service peut avoir récupéré un défi de manière proactive, puis lancer plusieurs demandes de jeton en parallèle. Si le serveur tolère plusieurs usages, le débit reste fluide. S’il consomme la valeur dès la première preuve acceptée, toutes les autres arrivent avec un défi périmé au sens de sa politique, même si elles ont été créées presque simultanément.

Le jti obligatoire évite de confondre systématiquement réutilisation d’un défi et répétition d’une preuve. Le serveur peut mémoriser les jti déjà vus pendant une fenêtre glissante et repérer le rejeu du même PoP JWT. Il peut en plus mémoriser les défis délivrés par l’endpoint : cette valeur choisie côté serveur offre une détection plus forte, au prix d’un aller-retour éventuel et d’une table d’état.

Le chapitre de sécurité accepte aussi un compromis plus léger. Un défi autoportant peut encoder la fraîcheur sans que le serveur tienne la liste des valeurs déjà vues. Il passe mieux à l’échelle, mais n’empêche pas le rejeu à l’intérieur de la fenêtre admise. Une autre option lie une valeur à la session d’une Client Instance. Les mots « défi fourni par le serveur » recouvrent donc au moins trois contrats de sécurité qui ne se valent pas.

Le texte conserve une base commune : les défis sont facultatifs afin de ne pas alourdir l’implémentation minimale, tandis que jti est obligatoire et sert de repli. Il demande aussi de contrôler une fenêtre temporelle acceptable. Rien de cela ne permet à un client de savoir si le serveur garde une liste, consomme au premier succès ou n’assure que la fraîcheur.

Le nonce DPoP n’est pas un alias

Le second mode rassemble deux fonctions dans une même preuve DPoP : possession de la clé de l’instance et contrainte de l’éventuel jeton d’accès. La révision 11 indique désormais que ce mode combiné utilise exclusivement le nonce défini par le RFC 9449.

Un nonce DPoP absent ou refusé déclenche use_dpop_nonce et un en-tête DPoP-Nonce. Il ne passe pas par use_attestation_challenge. L’endpoint commun peut distribuer le nonce de manière proactive, mais cette commodité de transport ne fusionne pas les protocoles. Un SDK doit conserver deux voies distinctes, faute de quoi il détruit la clarification normative apportée par la nouvelle version.

La comparaison officielle avec la révision 10 cite précisément l’exclusivité du nonce DPoP, la possibilité de le remettre par l’endpoint et la clarification de l’erreur associée aux défis facultatifs. Les pièces du comportement réactif s’emboîtent mieux. C’est justement pourquoi l’absence d’annonce préalable ressort davantage.

Les métadonnées annoncent les outils, pas leur règle d’emploi

La révision ajoute des métadonnées client dans le modèle général du RFC 7591. Clients et serveurs peuvent déclarer les algorithmes de signature compris et les méthodes de preuve acceptées, dont attestation_pop_jwt et dpop_combined. L’URL de l’endpoint de défi peut elle aussi figurer dans les métadonnées du serveur.

Avant de signer quoi que ce soit, un client peut donc constater qu’un algorithme ou une méthode est incompatible. Il ne peut pas constater qu’un défi obtenu pour un lot de requêtes sera consommé par la première, que sa durée appartient à une classe courte, que le serveur mémorise les valeurs, ou que le jeton autoportant n’apporte qu’une garantie de fraîcheur. Le coût opérationnel se trouve précisément derrière ce dernier rideau.

Publier chaque seconde d’une fenêtre ne serait pas forcément prudent. La charge et le niveau de risque peuvent faire varier les paramètres. Une information de classe suffit pourtant : single-use, reusable ou session-bound, assortie d’une posture witnessed-state ou freshness-only. Le client n’a pas besoin de connaître l’algorithme interne pour éviter une stratégie de cache incompatible.

Un petit objet de profil freshness-policy pourrait compléter les métadonnées. Il indiquerait, séparément pour le PoP JWT et le mode combiné, si la fraîcheur serveur est prise en charge ou exigée, les canaux de délivrance disponibles, la classe de durée, le mode de consommation, la posture de rejeu, le nombre de relances automatiques et un numéro d’époque. Un reçu signé pourrait lier cette déclaration à la version de métadonnées consultée.

Il s’agit de l’analyse de Daniel Kade, pas d’une règle contenue dans le projet. Le document ouvre déjà la voie à des profils d’écosystème. Ce niveau est le bon : le protocole de base garde sa souplesse, mais une communauté qui attend un comportement déterminé le rend explicite au lieu de l’enfouir dans ses bibliothèques.

Sources