Zusammenfassung

  • draft-mcguinness-oauth-client-attesters-00 schlägt client_attesters mit exakt benanntem issuer und jwks_uri vor. Revision 00 ist ein individueller Internet-Draft, kein RFC und kein angenommener IETF-Standard.
  • Publisher-Endorsement und Vertrauen des Authorization Servers sind zwei unabhängige Bedingungen. Das eine erlaubt die Aussage für einen Client, das andere bestimmt akzeptierte Schlüssel und Assurance.
  • Das Entfernen eines Endorsements wirkt nach Cache-Konvergenz auf künftige Authentisierung. Bestehende Grants und Tokens sowie direkt prüfende Resource Server bleiben getrennte Aufgaben.

Ein Change-Ticket meldet den Attester als entfernt, während ein zuvor ausgestelltes Token weiter funktioniert. Technisch können beide Aussagen stimmen. Die veröffentlichte Client-Metadatei, ihre frische Cache-Kopie, die Lebensdauer des Tokens und die Konfiguration eines direkten Verifiers sind verschiedene Zustände.

Der Entwurf OAuth 2.0 Client Attester Endorsement ergänzt ATTEST um die fehlende Zuordnung: Wer darf für diesen konkreten client_id attestieren? client_attesters legt die Antwort in autoritative Client-Metadaten. Jeder Eintrag verbindet den erwarteten iss-Wert über issuer mit einer HTTPS-Adresse für das öffentliche JWK Set.

Damit erklärt der Publisher seine Absicht. Er setzt keinen universellen Trust Anchor, authentisiert keine Instanz und erteilt weder Benutzerdelegation noch Ressourcenzugriff.

Nur die Schnittmenge ist gültig

Die Metadaten müssen den Attester aktuell endorsen. Zusätzlich muss die Policy des Authorization Servers diese Client-Attester-Beziehung erlauben und die Schlüsselquelle bestimmen. Der Server darf die veröffentlichte Menge einschränken, aber keinen nicht endorseten Attester ergänzen. Der Publisher darf seinen Vertreter benennen, aber Vertrauen nicht erzwingen.

Bei publisher-authorized key selection hat der Server dem Publisher vorab erlaubt, Attester und Schlüsselquelle auszuwählen. Das publizierte jwks_uri wird unter HTTPS-, Origin-, Pfad- und Netzrestriktionen abgerufen. Das skaliert, bietet aber keine vom Publisher unabhängige Assurance: Wer den CIMD-Host kontrolliert, kann auch einen eigenen Attester und dessen Schlüssel wählen.

Bei AS-configured attester trust konfiguriert der Server die Quelle für den exakten issuer selbst. Das veröffentlichte URI muss dieser Quelle oder einem expliziten Alias entsprechen und wird nicht als Fallback abgerufen. Ein Widerspruch führt zum Fehler.

Die Präzedenz ist issuer-weit. Sobald für einen exakten issuer irgendwo configured trust existiert, gilt er für alle Clients. Seine Entfernung überträgt die Auswahl nicht automatisch an Publisher. Auch Aliase gelten issuer-weit. Eine scheinbar einzelne Änderung kann daher viele Endorsements beeinflussen.

Die Reihenfolge bindet Bedeutung an den Schlüssel

Zuerst wählt der Server genau eine autoritative Metadatenquelle für client_id; Registrierung und CIMD werden nicht vermischt. Danach folgen der eindeutige Treffer issuer == iss, die Association-Policy, die Schlüsselquelle und genau ein geeigneter asymmetrischer Schlüssel für kid.

Der Schlüssel ist an Client, issuer, Quelle und Policy gebunden. Ein kid allein oder die Vereinigung mehrerer JWK Sets reicht nicht. Die Header jku, x5u, x5c und jwk steuern die Auswahl nicht. Erst dann werden Signatur, Proof, sub == client_id und ATTEST geprüft. Grant und Ressourcenberechtigung bleiben anschließend eigenständige Entscheidungen.

Rücknahme, Rotation und Entzug haben eigene Uhren

Ein Publisher entfernt den Eintrag, doch eine noch frische Cache-Kopie darf bis zur konfigurierten Höchstdauer gelten. Der Draft verlangt eine endliche Dauer, schreibt aber keinen Wert vor. Ein messbares Limit gehört in die Trust-Vereinbarung.

Beobachtete Antworten 404 oder 410 beenden die Nutzung früherer Dokumente; Timeout oder 5xx entwerten einen frischen Cache nicht. Bei Rotation wird zuerst der neue Schlüssel veröffentlicht, dann die Cache-Laufzeit abgewartet, danach mit ihm signiert und der alte bis zum Ablauf seiner Attestations behalten.

Das Endorsement wirkt nur prospektiv. Es widerruft keine Grants, Access Tokens oder Refresh Tokens. Für echte Beendigung müssen Grants und Tokens gesperrt, Refresh verhindert, Introspection auf inactive gesetzt und offline validierte Tokens bis zu ihrem Ende behandelt werden. Ein Resource Server, der Client Attestations direkt prüft, nutzt seine eigene konfigurierte Vertrauensbasis und erhält diese Rücknahme nicht über das Profil.

Ein Receipt für alle Entscheidungen

Die Betriebsakte hält client_id, die eine Metadatenquelle, Hash, Abrufzeit, Cache-Status und Ablauf fest. Sie dokumentiert das genaue Endorsement und die Berechtigung des Publishers. Danach folgen Trust-Modus und Präzedenz, Source oder Alias, JWK-Set-Hash und Frische, kid, Algorithmus und eindeutiger Schlüssel.

Sie nennt außerdem, ob Attestation am Endpoint verpflichtend war. client_attesters allein erzwingt sie nicht; als optionales Signal kann sie scheitern, während eine andere Client-Authentisierung fortgesetzt wird. Die Grant-Entscheidung bekommt ein separates Ergebnis.

Beim Rückzug kommen Beobachtungszeit, Cache-Konvergenz, letzte Annahme, Attestation-Ablauf, Token-Entzug, Refresh, Introspection, Offline-Fenster und direkte Verifier hinzu. Dieses Modell ist Analyse von Daniel Kade, keine normative Vorgabe des Drafts.

Der öffentliche Fehler invalid_client_attestation verrät die Ursache absichtlich nicht. Intern muss Telemetrie fehlendes Endorsement, Source-Konflikt, mehrdeutiges kid und temporären Abruffehler unterscheiden. Eine neue Attestation repariert keinen Policy-Konflikt.