La clé a changé. La continuité de l’instance dépendait encore d’un registre.

Résumé

• draft-mcguinness-oauth-client-instance-id-00 propose de conserver un client_instance_id lors d’un changement de clé vérifié, mais cette stabilité vaut seulement autant que le dossier d’enrôlement tenu par l’attesteur.
• Continuité de l’instance, continuité de la liaison de clé, confiance dans l’attesteur, autorisation, contexte transmis au serveur de ressources et preuve du présentateur actuel restent des décisions séparées.
• Le reçu exploitable doit nommer l’autorité, la granularité, le Receiver Scope, l’événement de cycle de vie, les anciennes et nouvelles clés, la fraîcheur, le Consumer Scope et la contrainte d’émetteur.

Un terminal géré change de clé. Le nouveau JWT d’attestation porte le même identifiant d’instance. Le serveur d’autorisation retrouve l’historique, y compris une suspension passée, et traite la requête comme celle du même acteur technique.

Rien dans la nouvelle clé ne démontre cette histoire. L’identifiant opaque ne dit pas s’il y a eu mise à jour, réinstallation, clone, restauration ou remplacement. La conclusion vient d’un tiers qui affirme avoir suivi la succession.

La révision 00, publiée le 28 septembre 2026, est un Internet-Draft individuel visant le Standards Track. Elle n’est ni un document adopté par le groupe OAuth, ni un RFC, ni la preuve d’un déploiement. Elle remplace le projet d’assertion d’instance séparée. Le projet de base sur l’authentification par attestation est, lui, en Last Call du groupe de travail ; ce statut distinct n’approuve pas automatiquement ce profil.

La possession présente n’est pas une histoire continue

L’attestation de base peut répondre à une question limitée : cette instance autorisée possède-t-elle cette clé ? Le profil en ajoute une autre : s’agit-il de l’instance déjà rencontrée ? Une nouvelle attestation est nécessaire pour chaque nouvelle clé, mais elle ne suffit pas à distinguer une installation persistante d’une installation nouvelle.

Le client_instance_id sert de repère stable. Son espace de nom appartient à l’attesteur ; l’identité complète est donc le couple exact (iss, client_instance_id). Le client_id désigne le client logique, qui peut réunir de nombreuses installations. Le principal humain ou délégué se situe encore ailleurs.

Cette topologie évite de transformer un succès cryptographique en identité universelle. La possession d’une clé est un fait actuel. La continuité est une affirmation historique. L’autorisation est une décision locale. L’effet métier est une observation ultérieure.

Le registre donne son sens au repère

Le projet exige un identifiant distinct, opaque, imprévisible et jamais réattribué. Il ne doit incorporer ni nom d’hôte, ni utilisateur, ni attribut de l’instance. Une chaîne qui ressemble à une URI n’acquiert aucune sémantique d’URI. Le Receiver compare les octets et ne déduit ni permission ni emplacement de clé.

Ces règles protègent le repère ; elles ne prouvent pas la succession. L’attesteur conserve un enrôlement actif liant l’unité, le client logique, le Receiver Scope, la granularité et les clés déjà validées. Lors d’une rotation, il vérifie la possession fraîche de la nouvelle clé, l’autorisation du transfert de garde, les contrôles de continuité, leur fraîcheur et l’événement de cycle de vie.

Une rotation vérifiée, un redémarrage de processus à granularité « installation » ou une mise à jour en place peuvent conserver l’identité. Une réinstallation, un clone indépendant, un remplacement ou un redémarrage de l’unité à granularité « exécution » exigent un nouvel enrôlement. Une image restaurée ne garde l’identité que si une preuve fraîche montre qu’elle succède au détenteur précédent. La simple copie des clés et des données ne suffit pas.

En cas de fork détecté, les identifiants sont retirés ou les demandeurs sont enrôlés séparément, sauf preuve permettant d’identifier le continuateur. Supprimer les dossiers de continuité impose également un nouvel enrôlement. Le service vendu comme « ID persistant » est donc un automate d’état gouverné.

Le Receiver Scope n’est pas lisible dans l’objet

Par défaut, l’attesteur attribue un identifiant distinct pour chaque Receiver. Pourtant, le Receiver Scope est une entrée d’enrôlement ou d’émission, non un paramètre OAuth ni une audience de l’attestation. Le Receiver ne peut pas contrôler ce périmètre à partir de l’identifiant.

Le client et l’attesteur doivent appliquer une configuration qui n’est pas autoportée par l’objet. Un périmètre partagé nécessite un accord administratif explicite ; le même client logique ou domaine de confiance ne suffit pas. Des clés d’instance distinctes sont également nécessaires entre les périmètres que le déploiement veut séparer, faute de quoi la clé commune rétablit la corrélation.

Présenter l’attestation au mauvais Receiver peut donc produire une fuite que celui-ci ne sait pas détecter. Un audit doit conserver le périmètre prévu, la version de politique et l’acteur chargé de l’appliquer. Le contrôle de syntaxe ne permet pas de reconstruire cette décision.

Accepter l’attesteur demeure une politique locale

Le Receiver associe chaque issuer d’attestation autorisé à ses clés de validation et aux clients logiques pour lesquels il peut parler. La valeur iss, une preuve de possession ou une métadonnée publiée par le client ne crée pas seule cette autorité.

L’article voisin sur Client Attester Endorsement traite de cette double approbation. Ici, le point de départ est postérieur : même un attesteur accepté doit démontrer la continuité selon un niveau d’assurance configuré. Un attesteur compromis peut fabriquer des instances dans son périmètre. Une preuve auto-déclarée, une vérification de plateforme et une racine matérielle ne sont pas interchangeables.

Si le système ne dispose d’aucune observation indépendante, un clone muni des clés et du dossier copié peut rester indiscernable de l’original. Le texte encadre les forks détectés ; il ne promet pas de détecter ce que la plateforme ne voit pas.

L’identité persistante ne déplace pas automatiquement le grant

Le profil mémorise l’identité d’instance associée à un refresh token. Il n’ajoute pas, par lui-même, un mécanisme pour déplacer la liaison cryptographique du refresh token vers la nouvelle clé.

Au rafraîchissement, deux invariants sont contrôlés : la Source Instance Identity doit correspondre à celle enregistrée et la preuve doit satisfaire la liaison de clé d’origine, sauf si un autre profil autorisé redéfinit ce lien. Le premier invariant porte sur la succession historique ; le second sur la clé admise pour ce grant.

Le rapprochement est essentiel. Une ligne stable en base de données ne transfère pas automatiquement un pouvoir à un nouveau secret. Il faut retrouver la décision qui a autorisé la transition et vérifier la possession exigée aujourd’hui.

Une suspension possède plusieurs délais

L’attesteur cesse d’émettre pour un enrôlement suspendu ou retiré. Le serveur d’autorisation peut révoquer les grants et signaler les tokens inactifs. Pourtant, l’attestation déjà émise reste utilisable jusqu’à son expiration et au décalage d’horloge ; le token suit sa propre durée de vie ; un serveur de ressources qui valide hors ligne n’apprend pas une révocation locale.

La distribution du statut demeure hors périmètre. De plus, un nouvel enrôlement ou un Receiver Scope différent peut donner une identité que le Receiver ne sait pas relier à celle suspendue. Un contrôle sérieux précise donc l’admission des enrôlements de remplacement, la propagation de révocation et la fenêtre maximale des artefacts encore valides.

Le contexte aval ouvre un deuxième registre

L’objet facultatif client_instance permet à un émetteur de token de transmettre un contexte à un consommateur. Il ne recopie pas nécessairement l’identifiant de l’attesteur. L’émetteur transforme la Source Instance Identity en son propre couple (iss, id), limité à un Consumer Scope choisi par l’audience du token.

Cette correspondance doit rester stable pendant la validité des grants et tokens. Si elle ne peut plus être reproduite, l’émetteur omet le contexte au lieu d’inventer un remplaçant. Un token sans audience, ou couvrant plusieurs Consumer Scopes, n’a pas de correspondance unique correcte. Un appelant d’introspection extérieur au périmètre ne doit pas la recevoir.

Deux autorités tiennent alors deux registres : l’attesteur conserve la succession de l’enrôlement ; l’émetteur conserve la projection destinée au consommateur. Perdre le premier détruit la continuité source. Perdre le second détruit la continuité de projection. Substituer une nouvelle valeur masquerait cette rupture.

L’instance à l’émission n’est pas forcément le présentateur

Le contexte n’accorde aucun pouvoir. Sans profil consommateur et contrainte d’émetteur vérifiée, il dit seulement quelle instance a participé à l’obtention du token. Il ne prouve pas que la requête HTTP actuelle vient de cette instance.

L’attribution du présentateur requiert DPoP, TLS mutuel ou un mécanisme équivalent, avec une clé associée à l’instance lors de l’émission. Une clé partagée entre plusieurs instances n’individualise personne. Un bearer token non contraint ne peut soutenir cette attribution.

Lors d’un échange de token, valider l’entrée authentifie les assertions de son émetteur, pas toute autorité plus ancienne citée dans le contexte. Le profil consommateur doit définir provenance, association au sujet ou acteur, remapping, conservation et liaison de rafraîchissement. L’objet identifie une instance ; ce n’est ni une chaîne d’acteurs ni un token délégué autonome.

La confidentialité répartit la visibilité

Des identifiants différents par Receiver limitent leur corrélation mutuelle, mais révèlent le Receiver Scope à l’attesteur. Un grand périmètre partagé cache les Receivers individuels à l’attesteur tout en leur permettant de corréler l’instance.

La séparation échoue aussi si la même clé DPoP ou le même certificat est réutilisé. Deux IDs pairwise différents peuvent exposer le même thumbprint. Les autres claims et données applicatives peuvent créer des jointures similaires. Il ne suffit donc pas de qualifier l’identifiant de « respectueux de la vie privée » ; il faut cartographier chaque observateur capable de relier les traces.

Un reçu de continuité exploitable

Le reçu commence par l’attesteur, sa clé de validation, le client logique, l’enrôlement, la granularité, le Receiver Scope et la version de confiance locale. Chaque transition relie les empreintes ancienne et nouvelle, l’événement, la preuve de garde, la fraîcheur et la décision : conserver, réenrôler, suspendre, retirer ou séparer un fork.

Il enregistre séparément l’identité source et la liaison du grant. Pour l’aval, il ajoute l’émetteur, l’entrée de mapping, l’Instance Context, le Consumer Scope, l’audience et la provenance d’un remapping. Pour la requête, il ajoute la preuve du présentateur et la décision d’autorisation du serveur de ressources.

L’exécution et son résultat ferment le dernier lien. Elles ne doivent jamais être déduites de la seule réussite du système d’identité.