Résumé

  • La personne reçoit un sujet pairwise différent sur chaque site ; l’agent conserve le même identifiant de clé, le même handle et la même empreinte de clé.
  • Le projet indique que deux sites peuvent comparer ces champs et relier les sujets de la personne. Son récit de test porte sur un seul site et une connexion humaine.

Le dossier de statut est bref. Datatracker classe le texte comme Internet-Draft individuel, sans statut RFC prévu. La section consacrée à l’implémentation décrit un seul site commercial ayant publié un enregistrement et une personne ayant terminé une connexion par passkey. Elle ne rapporte ni connexion d’agent, ni comparaison entre deux sites, ni corrélation observée. Le projet expose le mécanisme et son risque ; la fréquence d’adoption n’est pas documentée.

L’émetteur constitue un second centre de corrélation. Il garde le secret HMAC et peut calculer le sujet d’une personne pour n’importe quel site ; il voit aussi chaque connexion pour laquelle il émet un jeton. Le sujet pairwise empêche à lui seul la jointure entre sites. L’émetteur peut calculer la correspondance et les sites coopérants peuvent se servir de l’identité itinérante de l’agent comme clé commune.

C’est la couture de confidentialité visible dans Acts-For, un Internet-Draft individuel mis à jour le 21 octobre 2026. La proposition permet à une personne d’utiliser un ~handle et une passkey pour se connecter sans distribuer le même identifiant personnel à tous les sites. Le site publie un enregistrement DNS ; l’émetteur l’inscrit comme client. La personne confirme une nouvelle authentification par passkey et le site reçoit un sujet calculé pour ce seul site.

Le projet dérive ce sujet d’un HMAC détenu par l’émetteur, de l’identifiant interne de la personne et du domaine normalisé du site. La même personne reçoit donc deux sujets distincts sur deux sites. Une comparaison de ces sujets ne suffit pas à réunir les comptes. OpenID Connect appelle ce mécanisme un identifiant pairwise : il est propre au relying party au lieu d’être réutilisé partout.

Le parcours de l’agent transporte d’autres champs. Un agent autorisé demande à l’émetteur un acts-for pass de courte durée. Le pass désigne la personne par son sujet propre au site et identifie l’agent avec acting.kid, son handle de niveau Bot et cnf_jkt, l’empreinte de sa clé de signature. Le site vérifie la signature de l’émetteur, l’audience, l’expiration et une requête signée par la clé de l’agent. Le pass expire au plus cinq minutes après son émission et avant la fin de validité du mandat indiqué.

Ces vérifications encadrent le pass ; elles ne rendent pas l’identité de l’agent propre à chaque site. La section Confidentialité dit que acting.kid, acting.handle et cnf_jkt restent identiques sur tous les sites utilisés par le même agent. Deux sites qui les comparent peuvent rattacher leurs sujets pairwise à une seule personne. Le point ouvert 10 du projet demande précisément si l’agent devrait présenter une clé et un handle par site.

À chaque boutique, la personne change de numéro. L’agent, lui, garde sa carte de fidélité.

Pour les opérateurs qui envisagent la connexion déléguée, « sujet pairwise » décrit un champ, pas l’ensemble des identifiants du justificatif. Il faut examiner tous les champs du pass, les sites qui les reçoivent, l’émetteur capable de calculer les sujets et le mandat qui encadre l’agent. Le projet laisse le mandat lui-même hors périmètre : sa description du pass est plus complète que celle de l’autorité qui l’a produit.

Sources