Zusammenfassung

  • Der individuelle Entwurf vom 28. September schlägt client_attesters als Metadatum vor: Der Client-Herausgeber benennt gebilligte Attester, während der Autorisierungsserver über deren Annahme und Schlüsselvertrauen selbst entscheidet.
  • Ein Widerruf wirkt auf künftige Authentifizierung, sobald die Änderung beim Server ankommt. Bereits bestehende Grants und Access Tokens werden dadurch nicht automatisch widerrufen.

Vier Zuständigkeiten stecken in einer knappen Betriebsmeldung wie „Attester entfernt“: Wer durfte die Liste ändern? Welche Fassung sieht der Autorisierungsserver? Welche neue Attestation lehnt er nun ab? Und was geschieht mit Tokens, die zuvor ausgegeben wurden? Der Entwurf OAuth 2.0 Client Attester Endorsement legt gerade diese Trennung offen. Ihn als neues Mittel zum sofortigen Abschalten sämtlicher Zugriffe zu bezeichnen, würde seine eigene Reichweite überzeichnen.

K. McGuinness veröffentlichte die Fassung -00 am 28. September 2026 als individuellen Internet-Draft mit angestrebtem Standards-Track-Status. Der IETF-Datatracker weist sie als existierenden Entwurf aus. Das belegt weder einen RFC noch die Annahme durch die OAuth-Arbeitsgruppe, eine produktive Implementierung oder einen Schadensfall. Der Text ergänzt den ebenfalls noch als Entwurf vorliegenden Mechanismus zur attestationsbasierten Client-Authentifizierung. Er schafft kein neues Credential und keine neue Authentifizierungsmethode. Stattdessen definiert er eine publizierbare Zuordnung zwischen einem Client und jenen Attestern, die für ihn aussagen dürfen.

Das Metadatum client_attesters kann in einer Client-Registrierung oder einem Client ID Metadata Document stehen. Der Herausgeber nennt darin Attester und Orte ihrer Verifikationsschlüssel. Damit ist aber nur seine Billigung erklärt. Für eine Anfrage unter diesem Profil muss zugleich der Autorisierungsserver den Aussteller in den maßgeblichen Client-Metadaten als aktuell gebilligt vorfinden und diesen Attester nach eigener Richtlinie für den Client zulassen. Er bestimmt auch, welcher Schlüsselquelle er vertraut. Eine Billigung allein erzwingt kein Server-Vertrauen; Server-Vertrauen allein darf einen nicht gebilligten Attester nicht hinzufügen. Beides ist noch keine Berechtigung eines Nutzers und kein Zugang zu einer Ressource.

Der Herausgeber kann die Zuordnung anschließend zurücknehmen. Eine alte, noch frische Kopie der Metadaten kann aber im Autorisierungsserver weiterverwendet werden. Abschnitt 6.1 verlangt endliche konfigurierte Höchstalter für zwischengespeicherte Billigungen und JWK-Sätze sowie eine erneute Prüfung oder Zurückweisung abgelaufener Kopien. Ein allgemeingültiges Höchstalter nennt der Entwurf nicht. Wer eine vorhersagbare Verzögerungsgrenze braucht, muss sie in der Vertrauensvereinbarung der Beteiligten festhalten. Die Regel betrifft Kopien und nicht die maßgebliche Client-Registrierung selbst.

Sobald der Server eine Änderung abgerufen oder gespeichert hat, muss er sie bei der nächsten Vorlage anwenden. Eine Ablehnung durch seine eigene Richtlinie wirkt dagegen bei nachfolgenden Anfragen ohne Warten auf ein Cache-Ende.

Sogar dann ist nur ein Teil des Endes erreicht. Abschnitt 6.3 nennt den Widerruf ausdrücklich prospektiv: Künftige Client-Authentifizierung über die entfernte Billigung wird verhindert, bestehende Grants und Access Tokens bleiben aber unangetastet. Refresh-Anfragen mit verpflichtender Attestation werden erneut geprüft. Soll der Zugriff enden, müssen betroffene Grants und Tokens separat widerrufen und weitere Refresh-Ausgaben gestoppt werden. Über RFC-7662-Introspection können widerrufene Tokens als inaktiv erscheinen. Ein Resource Server mit lokaler Token-Prüfung braucht einen anderen Widerrufsmechanismus oder wartet auf den Ablauf. Der Rückzug der Billigung ersetzt keine dieser Maßnahmen.

Noch eine Grenze betrifft die Qualität der Aussage. Darf der Herausgeber den Attester und dessen Schlüssel selbst wählen, kann er auch selbst Attester sein. Die Attestation bietet dann keine vom Herausgeber unabhängige Gewähr. Sind andere Client-Authentifizierungsmethoden zulässig und ist die Attestation optional, erzwingt das Metadatum sie nicht. Wer die Veröffentlichungsstelle der Metadaten kompromittiert, könnte Billigungen innerhalb der Server-Richtlinie ändern, ohne dass dieser Entwurf die Böswilligkeit der Änderung unabhängig nachweist. Diese Aussagen stammen aus dem Bedrohungsmodell, nicht aus einem untersuchten Vorfall.

Für eine überprüfbare Beendigung sollte ein Betreiber mehr festhalten als den aktuellen Listenstand: die alte und neue Billigung, die Befugnis des Herausgebers, die Annahme- und Schlüsselrichtlinie des Servers, Cache-Höchstalter und Abrufzeitpunkte, die erste abgewiesene neue Vorlage, betroffene Grants und Tokens, gestoppten Refresh und die tatsächliche Durchsetzung bei jedem Resource Server. Ein solcher Nachweis wäre eine redaktionelle Betriebsempfehlung, kein im Entwurf verlangtes Protokollobjekt. Er verhindert, dass eine saubere Metadatenänderung als Beleg für ein bereits abgeschlossenes Gesamtsystem gilt.

Quellen