Zusammenfassung

  • Der am 28. September 2026 erstmals eingereichte individuelle Internet-Draft schlägt eine vom Attester vergebene client_instance_id vor. Sie kann bei nachgewiesenem Schlüsselwechsel fortbestehen; der Text ist weder RFC noch IETF-Beschluss oder Einsatznachweis.
  • Das Profil bindet bereits ausgegebene, schlüsselgebundene Refresh-Tokens nicht an den neuen Schlüssel. Nach der Standardbindung des zugrunde liegenden Entwurfs scheitert der Refresh mit neuem Schlüssel, sofern nicht ein anderes anwendbares Profil die Bindung tatsächlich anders regelt.
  • Zusätzlich muss der Autorisierungsserver eine aktuelle validierte Attestierung mit der für die Berechtigung gespeicherten Source Instance Identity vergleichen. Eine passende Kennung ersetzt die Token- und Schlüsselprüfung nicht.

Warum eine erfolgreiche Rotation trotzdem eine Ablehnung erzeugen kann

Die Schlüsselrotation einer installierten Anwendung soll idealerweise reibungslos verlaufen. Der Attester sieht einen überprüften Übergang vom alten zum neuen Schlüssel und bestätigt dieselbe registrierte Instanz. Beim Autorisierungsserver liegt aber noch ein Refresh-Token, das unter der alten Schlüsselbindung ausgegeben wurde. Wer nur auf die fortbestehende Kennung schaut, behandelt die Rotation als automatische Umschreibung dieser alten Bedingung. Genau das sieht der neue Vorschlag nicht vor.

Abschnitt 5.1 des ersten Entwurfs von K. McGuinness trennt die behauptete Kontinuität von Tokenrechten. Das Identitätsprofil schafft keine instanzgebundenen Grants und bindet vorhandene Refresh-Tokens nicht um. Im Basisentwurf zur attestierungsbasierten Client-Authentifizierung ist ein Refresh-Token standardmäßig an den Client Instance Key gebunden. Der Beweis mit dem neuen Schlüssel erfüllt dann die ursprüngliche Bindung nicht. Nur ein eigenständiges, tatsächlich geltendes Profil könnte für den Token eine andere Bindungsregel definieren. Die bloße Gleichheit der client_instance_id ist keine solche Regel.

So können zwei Prüfungen gleichzeitig korrekt ausfallen: Der Attester erkennt die Installation wieder, der Autorisierungsserver lehnt den alten Token dennoch ab. Die erste Aussage betrifft die Geschichte einer Registrierung. Die zweite betrifft die Nutzung einer konkret ausgegebenen Berechtigung. Wird das Identitätsurteil zur Ersatzprüfung für den Token, entsteht eine stillschweigende Machtübertragung. Ein Verfahren zur Erneuerung der Berechtigung mag sinnvoll sein; es müsste aber gesondert beschlossen und geprüft werden.

Kontinuität verlangt mehr als kopiertes Material

Die vorgeschlagene Kennung soll undurchsichtig, schwer vorhersehbar und nicht wiederverwendet sein. Ein authentifizierter Wechsel innerhalb derselben Registrierung kann sie erhalten. Neuinstallation, unabhängiger Klon und eine neue Ausführungseinheit erfordern hingegen eine neue Registrierung. Kopierte Schlüssel, Dateien oder alte Kennungen belegen keine rechtmäßige Nachfolge. Auch bei einem wiederhergestellten Abbild verlangt der Entwurf frische authentifizierte Evidenz. Diese Anforderung verhindert, dass eine Kopie allein durch den Besitz alter Daten als ursprüngliche Installation erscheint.

Standardmäßig gilt die Kennung nur innerhalb eines Receiver-Bereichs. Das ist kein globales Gerätekennzeichen für beliebige Dienste. Client und Attester müssen diesen Bereich bewusst wählen und die Schlüssel trennen, wenn der Schutz vor dienstübergreifender Zuordnung wirken soll. Ferner soll die Instanzidentität weder einen Nutzer-sub bestimmen noch eine act-Kette verlängern oder einen Besitznachweis ersetzen. Der optional über Token oder Introspektion verfügbare Kontext client_instance kann eine Installation beschreiben, verleiht ihr aber keine zusätzliche Befugnis.

Wird ein Grant unter dem neuen Profil angelegt, speichert der Autorisierungsserver dessen Source Instance Identity. Bei einer Erneuerung validiert er eine aktuelle Attestierung und vergleicht ihre Identität mit dem gespeicherten Wert. Stimmt sie nicht überein, ist die Kontinuitätsbedingung verletzt. Stimmt sie überein, bleibt die Prüfung der geltenden Tokenbindung offen. Ein Protokoll, das beide Ergebnisse getrennt festhält, kann eine berechtigte Ablehnung erklären, obwohl die Installation korrekt wiedererkannt wurde.

Der Datatracker-Eintrag bezeichnet die Vorlage als ersten individuellen Internet-Draft mit Zustand I-D Exists. „Standards Track“ ist sein angestrebter Status, keine Übernahme durch die OAuth-Arbeitsgruppe und kein RFC. Für einen produktiven Einsatz, Interoperabilität oder einen Sicherheitsvorfall liefern die geprüften Primärquellen keinen unabhängigen Beleg.

Quellen