Zusammenfassung

  • Eine Person erhält je Website ein anderes Pairwise-Subject; Schlüsselkennung, Handle und Schlüssel-Fingerabdruck des Agenten bleiben websiteübergreifend gleich.
  • Der Entwurf sagt, dass zwei Websites diese Agentenfelder vergleichen und die getrennten Personenkennungen verbinden können. Der dokumentierte Test betraf eine menschliche Anmeldung auf einer Website.

Diese Prüfungen begrenzen die Verwendung des Passes. Die Agentenkennung bleibt auf allen Websites gleich. Im Datenschutzabschnitt steht, dass acting.kid, acting.handle und cnf_jkt bei jeder Website dieselben Werte haben, auf der sich derselbe Agent anmeldet. Vergleichen zwei Websites diese Felder, können sie erkennen, dass zwei Pairwise-Subjects zu derselben Person gehören. Die offene Frage 10 des Entwurfs fragt, ob Agenten je Website einen eigenen Schlüssel und ein eigenes Handle verwenden sollten.

Beim Agenten kommen weitere Felder ins Spiel. Ein bevollmächtigter Agent fordert beim Aussteller einen kurzlebigen Acts-For-Pass an. Dieser nennt die Person über das websiteeigene Subject und den Agenten über acting.kid, sein Bot-Tier-Handle und cnf_jkt, den Fingerabdruck seines Signaturschlüssels. Die Website prüft die Signatur des Ausstellers, die Zielgruppe, den Ablaufzeitpunkt und eine mit dem Agentenschlüssel signierte Anfrage. Der Pass läuft spätestens fünf Minuten nach Ausstellung ab und nie später als die im Grant angegebene Gültigkeit.

Der Entwurf berechnet diese Kennung aus einem HMAC-Geheimnis des Ausstellers, einer internen Personenkennung und der normalisierten Domain der Website. Dieselbe Person erhält bei zwei Websites verschiedene Werte. Ein Vergleich dieser Werte allein verbindet die Konten nicht. OpenID Connect bezeichnet das als Pairwise-Subject: Die Kennung gilt für die jeweilige relying party, statt überall wiederverwendet zu werden.

Das ist die Datenschutznaht in Acts-For, einem individuellen Internet-Draft mit Stand vom 21. Oktober 2026. Der Vorschlag lässt Menschen mit einem ~handle und einem Passkey anmelden, ohne jeder Website dieselbe Personenkennung zu geben. Eine Website veröffentlicht dafür einen DNS-Eintrag; der Aussteller registriert sie damit als Client. Die Person bestätigt bei jeder Anmeldung eine frische Passkey-Authentisierung und erhält eine Kennung, die nur für diese Website berechnet wird.

Auch beim Aussteller laufen zentrale Informationen zusammen. Er hält das HMAC-Geheimnis und kann das Subject jeder Person für jede Website berechnen. Außerdem sieht er jede Anmeldung, für die er ein Token ausstellt. Das Pairwise-Subject erschwert eine direkte Zuordnung durch die Websites; der Aussteller kann die Zuordnung berechnen. Kooperierende Websites können die gemeinsame Agentenkennung als Vergleichsschlüssel nutzen.

Der dokumentierte Status ist knapp. Datatracker führt den Text als individuellen Internet-Draft ohne vorgesehenen RFC-Status. Im Implementierungsabschnitt steht, dass eine kleine Unternehmenswebsite einen Eintrag veröffentlicht hat und eine Person die Passkey-Anmeldung abschloss. Ein Agenten-Login, ein Vergleich über zwei Websites und ein beobachteter Abgleich werden nicht berichtet. Der Entwurf beschreibt Mechanismus und Risiko; eine Verbreitungszahl liegt nicht vor.

In jedem Laden trägt die Person eine andere Nummer. Der Agent zeigt überall dieselbe Kundenkarte.

Wer delegierte Anmeldungen bewertet, sollte „Pairwise-Subject“ als ein einzelnes Feld lesen, nicht als Datenschutzgarantie für den gesamten Berechtigungsnachweis. Relevant sind alle Kennungen im Pass, alle Websites, die sie erhalten, der Aussteller, der Subjects nachberechnen kann, und der Grant, der den Agenten begrenzt. Der Entwurf klammert den Grant selbst aus; der Pass ist genauer beschrieben als die Befugnis, die ihn erzeugt.

Quellen