Résumé

  • Déposé le 28 septembre 2026, un Internet-Draft individuel propose un client_instance_id attribué par l'attestateur et conservable lorsque le changement de clé est authentifié. Ni RFC, ni adoption par un groupe de travail, ni déploiement ne sont établis.
  • Le texte ne transfère pas la liaison d'un jeton de rafraîchissement existant vers la nouvelle clé. Selon la règle de base, le renouvellement avec cette clé échoue même si l'instance est reconnue, sauf profil distinct qui modifierait légitimement la liaison.
  • Le serveur doit aussi comparer l'identité de l'instance attestée à celle enregistrée pour l'autorisation. Cette comparaison ne remplace pas la preuve liée à la clé du jeton.

Le piège d'une rotation réussie

La rotation d'une clé est souvent décrite comme une opération de maintenance : retirer l'ancienne, installer la nouvelle, poursuivre le service. Pour un client OAuth muni d'une attestation, l'étape délicate est ailleurs. L'attestateur peut démontrer que la nouvelle clé appartient à la même installation inscrite et conserver son identifiant. Le serveur d'autorisation peut néanmoins détenir un jeton de rafraîchissement délivré sous une règle qui l'attache à l'ancienne clé. Que doit-il faire quand les deux éléments arrivent ensemble ?

Le nouveau projet de K. McGuinness, dans sa section 5.1, refuse d'en faire une seule question. Le profil proposé apporte une identité persistante de l'instance après un changement de clé vérifié. Il ne crée pas pour autant d'autorisations liées à l'identifiant et ne rattache pas les jetons déjà émis à une nouvelle clé. Dans le projet de base sur l'authentification par attestation, la liaison par défaut d'un jeton de rafraîchissement porte sur la clé de l'instance. Après rotation, une tentative utilisant la nouvelle clé échoue donc à ce contrôle. Seul un autre profil applicable pourrait en modifier la règle.

Cette nuance protège la décision contre un raccourci séduisant : « même instance » serait lu comme « même droit d'utiliser l'ancien jeton ». Or l'attestation de continuité et la preuve de possession exigée par le jeton décrivent des faits différents. Le serveur qui accepte l'identifiant comme substitut à la liaison change de politique de sécurité sans l'énoncer. Une migration d'autorisation peut être conçue, mais elle ne découle pas automatiquement de ce texte.

Quelle continuité l'attestateur peut-il certifier ?

Le client_instance_id doit être opaque, difficile à deviner et non réattribué. Par défaut, il est propre à un destinataire, nommé Receiver dans le projet. Un changement de clé authentifié pour la même inscription peut garder l'identifiant. Une réinstallation, un clone indépendant ou une nouvelle unité d'exécution réclament au contraire une nouvelle inscription. Copier une clé, des données ou l'ancien identifiant ne prouve pas la succession ; même une image système restaurée demande une preuve récente et authentifiée. Sans ce seuil, un identifiant stable pourrait servir à maquiller une copie en continuation légitime.

Le périmètre par destinataire est aussi une limite de corrélation. Le texte n'institue pas un numéro global de l'appareil, visible partout. Le client et l'attestateur doivent choisir ce périmètre ; le destinataire ne peut pas déduire d'une attestation présentée que les autres périmètres ont été respectés. Les opérateurs qui mutualisent des identifiants entre services effaceraient une protection de confidentialité conçue par défaut.

Le projet est explicite sur un autre point : identifier une instance n'autorise ni l'utilisateur, ni un acteur délégué. Cette donnée ne suffit pas à établir sub, à allonger une chaîne act ou à remplacer la possession de clé. Le contexte optionnel client_instance d'un jeton ou d'une réponse d'introspection est un moyen de communiquer l'identité d'installation à un serveur de ressources, pas un pouvoir nouveau. La distinction est importante lorsque des équipes différentes exploitent le client, l'attestateur et le serveur d'autorisation.

Pour une autorisation obtenue sous ce profil, la section 5.1 demande au serveur d'enregistrer la Source Instance Identity. Au rafraîchissement, il valide une attestation actuelle et compare cette identité à la valeur enregistrée. Un écart doit arrêter l'opération. Une concordance laisse toujours ouverte la question indépendante de la liaison du jeton à sa clé. Le dossier Datatracker présente aujourd'hui une première version individuelle à l'état I-D Exists. Son statut Standards Track est souhaité, non acquis. Aucun essai d'interopérabilité ou usage réel n'est démontré par ces sources.

Sources