Zusammenfassung

  • Der vorgeschlagene client_instance_id darf nach einem verifizierten Schlüsselwechsel gleich bleiben; glaubwürdig wird er erst durch das Enrollment-Register des Attesters.
  • Instanzkontinuität, Schlüsselbindung, Attester-Autorität, Grant-Bindung, Token-Mapping und die Zuschreibung des aktuellen Präsentierenden sind getrennte Entscheidungen.
  • Ein belastbarer Kontinuitätsbeleg nennt Issuer, Enrollment, Granularität, Receiver Scope, alte und neue Schlüssel, Lebenszyklusereignis, Evidenzalter, Consumer Mapping und Sendernachweis.

Der alte Schlüssel ist außer Betrieb, der neue korrekt attestiert. Im Claim steht derselbe Identifikator wie vor der Rotation. Für das Autorisierungssystem sieht die Fortsetzung beinahe wie eine Eigenschaft des neuen Artefakts aus.

Doch der neue Schlüssel kennt seinen Vorgänger nicht. Der opake Identifikator verrät weder, ob ein Update, eine Neuinstallation, ein Klon, ein Rollback noch ein zweiter Anspruchsteller vorliegt. Die entscheidende Arbeit geschah außerhalb des Claims: Eine Instanz wurde als legitime Nachfolgerin eines früheren Enrollments anerkannt, und jemand bewahrte die Belege für dieses Urteil.

draft-mcguinness-oauth-client-instance-id-00 wurde am 28. September 2026 veröffentlicht. Es ist ein aktiver individueller Internet-Draft, dessen Text Standards Track anstrebt, ohne Working-Group-Status, verantwortlichen AD, Telechat-Termin oder RFC-Stream im Datatracker. Er ersetzt den früheren Entwurf einer separaten Instance Assertion. Das verwandte Basisdokument zur attestation-basierten Client-Authentifizierung ist OAuth-WG-Arbeit im Working Group Last Call; dieser Status bedeutet keine Annahme des individuellen Profils. Die eingefrorenen Quellen belegen weder Implementierung noch Interoperabilität, Deployment oder Wirkung.

Gegenwart und Geschichte verlangen unterschiedliche Beweise

Die Basismethode beantwortet, ob eine autorisierte Client Instance einen bestimmten Schlüssel besitzt. Das Profil stellt eine historische Zusatzfrage: Ist das dieselbe Instanz, die dieser Receiver schon kennt? Nach einer Rotation kann eine frische Attestation allein eine fortgesetzte Installation nicht von einer neuen Installation unterscheiden.

Der client_instance_id dient als stabiler Verweis. Die genaue Source Instance Identity ist jedoch das Paar (iss, client_instance_id): derselbe Text unter einem anderen Issuer ist keine Kontinuität. Auch der Logical Client hinter client_id ist nicht die Instanz. Viele Installationen, Container oder Agenten können zu demselben Logical Client gehören. Das autorisierte Subjekt ist wiederum eine andere Ebene.

Diese Trennung hält Beweise in ihrem Zuständigkeitsbereich. Schlüsselbesitz ist eine gegenwärtige Tatsache. Instanzkontinuität ist eine historische Nachfolgeaussage. Autorisierung ist lokale Policy. Ausführung und Ergebnis sind Beobachtungen. Wer daraus einen einzigen Vertrauensstatus macht, überträgt Macht ohne den dazugehörigen Beleg.

Die Zeichenfolge bezeichnet die Evidenz, sie ersetzt sie nicht

Der Draft verlangt eindeutige, opake, unvorhersehbare und niemals neu vergebene Identifikatoren. Hostname, Benutzerkennung und Instanzattribute gehören nicht hinein. Selbst eine URI-förmige Darstellung besitzt keine URI-Semantik; der Receiver vergleicht exakt und darf Scope, Granularität oder Schlüsselort nicht herauslesen.

Diese Regeln verbessern die Kennung, erzeugen aber keine Geschichte. Der Attester muss ein aktives Enrollment führen, das Instanz, Logical Client, Receiver Scope, Granularität und zuvor validierte Schlüssel verbindet. Beim Wechsel prüft er frischen Besitz des neuen Schlüssels sowie authentisierte Evidenz für einen erlaubten Custody-Übergang. Er hält Kontinuitätsprüfungen, Frische und Lebenszyklusbeobachtungen fest.

Die Übergangsregeln sind der eigentliche Sicherheitsgegenstand. Verlängerung, verifizierte Rotation, Prozessneustart bei Installationsgranularität und In-place-Update können die Kennung behalten. Neuinstallation, unabhängiger Klon, Ersatz, Neustart bei Ausführungsgranularität und Granularitätswechsel brauchen ein neues Enrollment. Restore und Rollback benötigen frische Nachfolgeevidenz; kopierte Schlüssel und Daten reichen nicht. Bei einem erkannten Fork müssen die Anspruchsteller getrennt oder stillgelegt werden, sofern kein authentisierter Nachweis den legitimen Fortsetzer bestimmt.

Wer die Kontinuitätsdaten löscht, muss neu enrollen. Ein plattformstabiler Eingangswert darf die alte Kennung nicht allein regenerieren, weil eine Neuinstallation sonst eine pensionierte Identität wiederbeleben könnte. Die dauerhafte Einheit ist folglich kein „persistent identifier“, sondern eine regierte Zustandsmaschine.

Receiver Scope bleibt für den Receiver unsichtbar

Standardmäßig ist die Kennung an einen Receiver gepaart. Receiver Scope ist jedoch eine administrative Eingabe bei Enrollment oder Ausstellung, kein OAuth-Parameter und keine Attestation Audience. Der Receiver kann aus der Kennung nicht prüfen, ob der beabsichtigte Scope stimmt.

Der Attester soll deshalb pro Receiver verschiedene Kennungen vergeben, außer eine ausdrückliche Vereinbarung definiert einen gemeinsamen Scope. Der Client muss ebenso unterschiedliche Client Instance Keys in Bereichen einsetzen, die tatsächlich getrennt sein sollen. Ein gemeinsam benutzter Schlüssel kann die Korrelation wiederherstellen, die paarweise IDs verhindern wollten.

Wird eine scoped Attestation dem falschen Receiver gezeigt, ist der Fehler nicht im String erkennbar. Die Kontrolle hängt an Konfiguration, die das Artefakt nicht selbst beschreibt. Ein Auditbeleg braucht deshalb den konfigurierten Scope, die Policy-Version und die verantwortliche Durchsetzungsstelle.

Das ist auch die zentrale Datenschutzentscheidung. Paarweise IDs erschweren die Korrelation zwischen Receivern, offenbaren dem Attester aber den Receiver Scope. Ein breiter gemeinsamer Scope verschleiert einzelne Receiver gegenüber dem Attester, ermöglicht jedoch deren gegenseitige Korrelation. Wiederverwendete Instanz- oder DPoP-Schlüssel können beide Modelle unterlaufen.

Attester-Autorität ist konfiguriert, nicht selbstbehauptet

Der Receiver muss einen zugelassenen Attester Issuer mit dessen Verifikationsschlüsseln und den Logical Clients verbinden, für die er sprechen darf. Ein iss-String, ein Besitznachweis oder vom Client veröffentlichte Metadaten schaffen diese Autorität nicht. Client Attester Endorsement kann ein Eingang für den Authorization Server sein; direkt prüfende Resource Server brauchen trotzdem eine vertrauenswürdige Zuordnung.

Zwei Freigaben bleiben getrennt: Der Attester erklärt den Nachfolger zum selben Enrollment. Der Receiver entscheidet, ob dieser Attester in diesem Kontext für diesen Logical Client sprechen darf. Eine korrekte Signatur eines nicht zugelassenen Issuers ist unzureichend. Ein zugelassener Issuer kann seinerseits kompromittiert sein oder die Güte seiner Evidenz überzeichnen.

Selbstauskunft, Plattformprüfung und hardwareverankerte Evidenz sind nicht gleichwertig. Ohne unabhängige Plattformsignale können kopierte Schlüssel und Enrollment-Daten wie das Original wirken. Automatisierung darf diese Unsicherheit nicht hinter „Attestation valid“ verschwinden lassen.

Eine kontinuierliche Identität verschiebt nicht die Tokenbindung

Das Profil erlaubt dem Enrollment, eine verifizierte Schlüsselrotation zu überleben. Es bindet deshalb nicht automatisch einen bestehenden Refresh Token an den neuen Schlüssel. Die Standardbindung bleibt beim alten Client Instance Key, sofern kein anderes autorisiertes Profil die Umbindung definiert.

Beim Refresh sind zwei Invarianten zu prüfen: Die Source Instance Identity stimmt mit der gespeicherten Identität überein, und der aktuelle Proof erfüllt die Schlüsselbindung des Grants oder ein erlaubtes Rebinding-Verfahren. Der erste Test betrifft historische Gleichheit, der zweite die aktuelle Nutzungsbefugnis.

Das verhindert einen verbreiteten Kurzschluss: Ein Datenbanksatz bleibt bestehen, ein Zertifikat rotiert, also müsse die alte Autorität automatisch folgen. Die bessere Frage lautet, welche Entscheidung den Credential-Übergang für genau diesen Grant autorisierte, unter welcher Policy und mit welchem heutigen Besitznachweis.

Eine Suspension läuft auf mehreren Uhren

Der Attester muss die Ausstellung für ein suspendiertes oder pensioniertes Enrollment stoppen. Der Authorization Server kann Grants widerrufen oder Token inaktiv setzen. Das System wird dadurch nicht sofort konsistent.

Eine früher ausgestellte Attestation kann bis zu Ablauf und Clock Skew akzeptabel bleiben. Access Tokens besitzen eigene Laufzeiten. Ein lokaler Widerruf informiert keinen offline prüfenden Resource Server; Statusverteilung liegt außerhalb des Profils. Neues Enrollment oder anderer Receiver Scope kann zudem eine Identität hervorbringen, die sich nicht mit der suspendierten verbinden lässt.

Containment braucht daher Zeitbudget und Admission Policy. „Suspended“ ist ohne entscheidende Autorität, Wirksamkeitszeitpunkt, betroffenes Enrollment, Token-Menge und Benachrichtigungsreichweite nur der Zustand einer lokalen Zeile.

Downstream entsteht ein zweites Identitätsregister

Das optionale client_instance-Objekt kann validierten Kontext an einen Resource Server tragen. Es muss nicht die rohe Kennung des Attesters sein. Der Token Issuer bildet die Source Instance Identity in einen eigenen (iss, id)-Namensraum innerhalb eines von der Audience bestimmten Consumer Scope ab.

Dieses Mapping hat eine eigene Kontinuitätspflicht. Es muss verschiedene Instanzen auseinanderhalten, Rotation und Erneuerung überstehen und reproduzierbar bleiben, solange relevante Grants oder Token gültig sind. Geht die Zuordnung verloren, muss der Issuer den Kontext weglassen statt Ersatz zu erfinden. Ein Token ohne Audience oder mit Audiences über mehrere Consumer Scopes besitzt keine eindeutige Abbildung. Ein Introspection Caller außerhalb des Scope darf sie nicht sehen.

Damit existieren zwei Register: Enrollment zu Source Identity beim Attester und Source Identity zu Consumer Identity beim Token Issuer. Verantwortliche und Retentionsfristen sind verschieden. Verlust darf zu fehlendem Kontext führen; ein stiller Neuwert würde Geschichte falsch zusammenführen oder teilen.

Beteiligung an der Ausstellung ist keine aktuelle Präsentation

Instance Context verleiht keine Autorität. Ohne consuming profile und validierten Sender Constraint beschreibt er nur die Instanz, die am Token-Erwerb beteiligt war. Er beweist nicht, dass dieselbe Instanz die aktuelle HTTP-Anfrage stellt.

DPoP, Mutual TLS oder ein anderer definierter Constraint kann bei direkter Ausstellung den Presenter binden. Ein gemeinsamer Binding Key unterscheidet keine Instanzen. Ein Bearer Token trägt den Nachweis nicht. Ist Zuschreibung erforderlich und fehlt die Bindung, muss der Kontext entfallen und eine verpflichtende Consumer Policy ablehnen.

Token Exchange verschärft die Herkunftsfrage. Die Prüfung des Input Tokens authentisiert Aussagen seines Issuers, nicht jede frühere Autorität in einem erhaltenen Kontext. Ein consuming profile muss bestimmen, ob die Kennung den aktuellen oder einen vorgelagerten Akteur meint und wie Assoziation, Erhalt und Remapping bewiesen werden. Der Kontext benennt eine Instanz, keine Actor Chain und kein separates Token.

Ein typisierter Kontinuitätsbeleg

Ein belastbarer Beleg beginnt mit Attester Issuer, Verifikationsschlüssel, Logical Client, Enrollment, Granularität, Receiver Scope und Version der Receiver-Trust-Policy. Für jeden Übergang verbindet er Fingerprints des alten und neuen Schlüssels, Lebenszyklusereignis, Custody-Evidenz, Kontinuitätsprüfungen, Frische, Zeitpunkt und Entscheidung: beibehalten, neu enrollt, pensioniert, suspendiert oder geforkt.

Für Grants hält er Source Instance Identity, Schlüsselbindung und ein mögliches Rebinding-Profil getrennt. Downstream erfasst er Token Issuer, Mapping-Eingang, Instance Context, Consumer Scope, Audience, Retentionsepoche und Herkunft einer Bewahrung oder Neuabbildung. Pro Request dokumentiert er Sender Constraint und lokale Autorisierungsentscheidung.

Erst danach folgt die Verbindung zur geschützten Operation und zum beobachteten Ergebnis. Ein erfolgreicher Rotationsbeleg schließt nur den bezeichneten Kontinuitätsübergang. Gegenwärtige Softwareintegrität, Autorisierung, Presenter, Ausführung und Wirkung bleiben eigene Nachweise.