Zusammenfassung

  • draft-li-oauth-delegated-authorization-03 beschreibt eine geordnete Kette: Der Autorisierungsserver signiert die Wurzel, ein Client darf innerhalb des verbleibenden Rahmens ein engeres Kind für einen weiteren Client signieren. Es ist ein individueller Internet-Draft mit Standards-Track-Absicht, kein RFC, Konsens- oder Einsatznachweis.
  • Die Signatur eines Kindes beweist nur, dass der zum unmittelbaren Vorgänger gebundene Schlüssel dieses Kind signierte. Sie beweist weder eine vertrauenswürdige Wurzel noch semantische Verengung, besondere Delegationseinwilligung oder aktuelle Widerrufslage.
  • Der Ressourcenserver muss die exakten geordneten Token, den DPoP-Nachweis des Blatts, jede Schlüsselverknüpfung, alle Einschränkungen und seine eigene Richtlinie prüfen. Eine gültige Kette erzwingt keinen Zugriff.

Der gefährlichste Satz in einer Freigabeprüfung lautet oft: „Das Token ist gültig.“ Er verdichtet mehrere unabhängige Fragen zu einem grünen Symbol. War der Aussteller vertrauenswürdig? Durfte er weiterdelegieren? Hat das Kind nur Rechte verloren oder unbemerkt hinzugewonnen? Ist ein Vorgänger inzwischen widerrufen? Passt die konkrete Operation noch zur Richtlinie des Zielsystems?

Der Entwurf zur delegierten OAuth-Autorisierung versucht nicht, diese Fragen mit einer stärkeren Einzelsignatur zu lösen. Er macht aus ihnen eine geordnete Beweiskette. Der Autorisierungsserver stellt ein Wurzel-Token aus und bindet dessen Befugnis über cnf.jkt an den Schlüssel von Client A. Solange eine positive Delegationstiefe verbleibt, kann A ein engeres Kind erzeugen, das an den Schlüssel von Client B gebunden ist. B darf die Befugnis nutzen oder, falls noch Tiefe übrig ist, erneut verengen und weitergeben.

Das spart einen Rückweg zum Autorisierungsserver bei jedem lokalen Übergang. Es verlagert aber weder die ursprüngliche Autorität auf das Blatt noch beseitigt es die Verantwortung des Ressourcenservers. Die Abwesenheit des Servers bei einer Kind-Ausstellung wurde in der Wurzel begrenzt vorab erlaubt. Der Prüfer muss diese Grenze später vom Anfang bis zum Ende rekonstruieren.

Revision 03 bleibt ein Arbeitsentwurf. Der Kopf nennt Standards Track als Ziel; die Datatracker-API weist derzeit weder Stream noch vorgesehenen Standardisierungsgrad aus. Vorgeschlagene Medien-, Token-, Authentisierungsschema-, Claim- und Metadaten-Registrierungen sind noch keine IANA-Quittungen. Das Dokument liefert auch keinen Beleg für interoperable Implementierungen oder Produktivbetrieb.

Die Wurzel bezieht Vertrauen von außerhalb der Kette

Das erste Token ist anders als alle folgenden. Es muss unter einem Schlüssel des Autorisierungsservers verifiziert werden, der durch vertrauenswürdige Konfiguration oder authentisierte Metadaten bekannt ist. Ein im Token selbst präsentierter Schlüssel darf dieses Vertrauen nicht selbst erzeugen. Sonst könnte jeder Angreifer seine eigene Wurzel und gleich den dazu passenden Vertrauensanker liefern.

Bei einem Kind liegt der öffentliche Schlüssel des Delegierenden im geschützten Header. Der Prüfer bildet dessen RFC-7638-Thumbprint, vergleicht ihn mit cnf.jkt des unmittelbaren Eltern-Tokens und prüft anschließend die Kind-Signatur. Ein positives Ergebnis belegt eine präzise Kante: Der Inhaber des Schlüssels, den der Vorgänger autorisierte, signierte dieses Kind.

Es belegt nicht, wie dieser Inhaber den öffentlichen Schlüssel des Empfängers erhielt oder ob der Schlüssel wirklich dem beabsichtigten Dienst, Mandanten oder Betreiber gehörte. Diese Zuordnung liegt außerhalb des Entwurfs. Eine Kette kann daher einen falschen Onboarding-Entscheid kryptografisch makellos fortschreiben. Schlüsselkontinuität, Identitätszuordnung und Geschäftsbefugnis brauchen getrennte Quittungen.

Auch ein korrekt signiertes Client-Token darf nicht an erster Stelle stehen. Der Prüfer darf nicht in der Mitte beginnen und später nach einer passenden Wurzel suchen. Autorität verläuft gerichtet. Eine starke Signatur kann den fehlenden vertrauenswürdigen Anfang nicht nachträglich herstellen.

Verengung ist eine semantische Rechnung

Der Entwurf verlangt monotone Abschwächung: Ein Kind darf die wirksame Befugnis seiner gesamten Vorgeschichte nicht erweitern. Bei scope lässt sich das als Mengeninklusion ausdrücken. Jeder Wert des Kindes muss bereits in der wirksamen Elternmenge liegen. Bei authorization_details reicht Zeichen- oder JSON-Gleichheit dagegen nicht.

Jeder Detailtyp benötigt eine eigene Teilmengenregel. Sie muss Ressourcen, Aktionen, Wildcards, Standardwerte, Arrays und ausgelassene Felder verstehen. Ein kürzeres Objekt kann breiter sein, wenn ein fehlendes Feld „beliebig“ bedeutet. Zwei Objekte mit gleichem type können andere Konten oder Operationen benennen. Kann der Prüfer die Verengung nicht deterministisch feststellen, soll er ablehnen.

Auslassungen tragen ebenfalls Autorität. Lässt ein Kind scope oder authorization_details weg, verschwindet diese Berechtigungskomponente und darf in einem Enkel nicht wiederkehren. Eine ausgelassene Audience fügt hingegen keine neue Einschränkung hinzu; die wirksame Vorgabe des Elternpfads bleibt. Erweiterungs-Claims brauchen deshalb Regeln für Einführung, Vererbung, Auslassung und mögliche Wiedereinführung.

Diese Unterscheidung schützt eine institutionelle Grenze. Eine zentrale Bibliothek soll nicht spontan die Bedeutung neuer Fach-Claims erfinden. Das Prinzip der minimalen Anfangsspezifikation aus docs/heng-lu-note.md verlangt einen kleinen, deterministischen gemeinsamen Kern. Unbekannte Semantik wird lokal und ausdrücklich profiliert oder abgelehnt, nicht durch großzügige Heuristik in allgemeine Autorität umgewandelt.

Der Ressourcenserver muss den Pfad in Reihenfolge auswerten. Neun für sich gültige JWTs ergeben nicht automatisch eine gültige Kette. Auslassung, Vererbung und Einschränkung sind pfadabhängig; die eigentliche Quittung ist die nachvollzogene Traversierung.

Die Tiefe begrenzt den Pfad, nicht den Schaden

Jede Wurzel trägt eine endliche max_delegation_depth. Hat der wirksame Elternwert m, muss ein ausdrücklich genannter Kindwert zwischen null und m-1 liegen; fehlt er, gilt m-1. Ein Blatt mit null darf zugreifen, aber nicht weiterdelegieren.

Das begrenzt die Länge eines Beweispfads. Es begrenzt nicht automatisch die Zahl der Geschwister, die ein Schlüssel ausstellt, den Wert der erreichbaren Ressourcen oder die Lebensdauer der Wirkung. Tiefe drei kann bei hohem Fan-out sehr viele Nachfahren erzeugen. Ein enger Scope-Name kann weiterhin eine kritische Zahlung oder einen Massendatenexport erlauben.

Deshalb gehören Tokenzahl, serialisierte Größe und Prüfaufwand zu den technischen Limits. Betriebliche Regeln sollten zusätzlich Fan-out, Nachfahreninventar, Schlüsselnutzung und Aufgabenlaufzeit begrenzen. Weil Kind-Ausstellungen ohne Autorisierungsserver erfolgen, kann dieser aus seiner Wurzel-Datenbank nicht automatisch alle Abkömmlinge aufzählen.

Das ist der Preis der lokalen Autonomie. Weniger zentrale Rundreisen reduzieren Latenz und Abhängigkeit, entfernen aber einen natürlichen Beobachtungspunkt. Wer nach einem Vorfall alle Nachfahren finden muss, braucht eine eigene Belegebene. Ein Log macht eine nicht protokollierte Kette nicht automatisch ungültig; es bestimmt jedoch, welche Wiederherstellung der Betreiber glaubwürdig versprechen kann.

Einwilligung zur Nutzung ist keine Einwilligung zur Ernennung

Bei Grants mit Resource Owner verlangt Revision 03, Zugriffseinwilligung und Einwilligung zur clientseitigen Delegation zu unterscheiden. „Dieser Client darf Berichte lesen“ ist nicht dieselbe Entscheidung wie „dieser Client darf weitere Clients ernennen, die Berichte lesen“.

Die Oberfläche sollte Berechtigungen, Audience, Laufzeit und maximale Tiefe verständlich machen. Ebenso wichtig ist die negative Aussage: Der Autorisierungsserver sieht oder genehmigt nicht zwingend jedes Kind. Die Wurzel kann einen begrenzten Ernennungsraum vorab freigeben, beweist aber nicht, dass der Resource Owner den konkreten späteren Dienst, Betreiber oder Auftrag gesehen hat.

Ein gebundener privater Schlüssel hat damit zwei mögliche Funktionen: DPoP-Nachweise für eigene Requests und, bei verbleibender Tiefe, Signaturen für neue Kinder. Ein generischer Signierdienst kann aus einer Kompromittierung der Request-Nutzung eine Delegationskompromittierung machen. Schnittstellen und HSM-Richtlinien sollten diese Operationen trennen.

Die Autoritätsaufteilung bleibt dreiteilig. Der Autorisierungsserver setzt die maximal übertragbare Hülle. Der Delegierende wählt darin einen Empfänger und muss dessen Schlüsselzuordnung belegen. Der Ressourcenserver entscheidet, ob der konkrete Request unter heutigen lokalen Bedingungen zulässig ist. Keiner dieser Akteure kann die Quittung eines anderen ersetzen.

Reihenfolge und exakte Bytes gehören zum Nachweis

Das vorgeschlagene DA-Credential serialisiert kompakte JWTs von der Wurzel zum Blatt, getrennt durch ~. Leere Elemente, falsche Reihenfolge, defekte Token und übergroße Ketten sind abzulehnen. Der ath-Wert des DPoP-Nachweises am Blatt bindet die exakte präsentierte Serialisierung. Vor dem Hashen darf der Prüfer nicht dekodieren, normalisieren und neu serialisieren.

Diese Byte-Bindung verhindert, dass ein Beobachter Elemente eines erfassten Requests entfernt, hinzufügt oder verschiebt, ohne einen neuen Blatt-Nachweis zu erzeugen. Sie erklärt die Elemente nicht nachträglich für gültig. DPoP bestätigt, dass der Blatt-Schlüssel diesen Request mit genau diesen Bytes band; Wurzel, jede Signatur, jede cnf.jkt-Kante und jede Einschränkung bleiben eigenständige Prüfungen.

Damit unterscheidet sich der Gegenstand vom bestehenden BTW-Beitrag über RFC 9449. DPoP behandelt Senderbindung, Methode und URI, Frische, Replay und Token-Hash. Der neue Entwurf verwendet diese Mechanik nur für die letzte Kante eines größeren Autoritätsgraphen. Sein eigener Einsatz ist die monotone Befugnis über clientseitig ausgestellte Vorfahren hinweg.

Ein Kind enthält keine Eltern-ID. Es kann unter einer anderen kompatiblen Kette gültig sein, wenn der unmittelbar vorherige Schlüssel derselbe ist und alle kumulativen Einschränkungen das Kind umfassen. Ein Schlüssel pro Token begrenzt diese Portabilität; Schlüsselwiederverwendung vergrößert sie. ath verhindert die Mutation eines vorgelegten Requests, hindert den rechtmäßigen Blattinhaber aber nicht daran, einen neuen Nachweis über eine andere kompatible Kette zu erzeugen.

Widerruf ist ein Verteilungsproblem

Der Entwurf erweitert den OAuth-Widerrufs-Endpunkt: Die vollständige exakte Kette wird eingereicht und das letzte Token zum Ziel. Der Halter des gebundenen Zielschlüssels oder bei einem clientseitigen Kind dessen direkter Delegierender muss die Befugnis zum Widerruf beweisen. Das bloße Beobachten der Kette oder gewöhnliche Client-Authentisierung reicht nicht.

Der Effekt folgt der Struktur. Der Widerruf der Wurzel invalidiert alle darauf beruhenden Ketten. Der Widerruf eines Kindes invalidiert Ketten, die dieses Kind enthalten, und angehängte Nachfahren; Eltern, Geschwister und andere Token am selben Schlüssel bleiben unberührt.

Ein HTTP-200 des Endpunkts ist weder ein Offenlegungskanal noch eine globale Abschlussquittung. Er kann auch bei ungültiger Eingabe erscheinen. Vor allem schreibt der Autorisierungsserver einen Status. Der Entwurf definiert keinen Mechanismus, der ihn zu offline prüfenden Ressourcenservern verteilt. Ein Verifier kann einen widerrufenen Vorfahren weiter akzeptieren, bis der Status eintrifft oder das Token abläuft.

Wer schnellen Widerruf verspricht, braucht kurze Laufzeiten, Introspection, synchronisierte Statusfeeds oder einen anderen aktuellen Kanal. Jede lokale Entscheidung sollte Quelle, Versionsstand oder Beobachtungszeit des Status belegen. Sonst lassen sich „um 10:01 widerrufen“ und „um 10:04 akzeptiert“ nicht ehrlich zusammenführen.

Lokale Autorisierung bleibt lokal

Nach erfolgreicher Kryptografie entscheidet der Ressourcenserver weiterhin über die Operation. Er kombiniert wirksamen Scope, Authorization Details, Audience, Zeit und Anwendungs-Claims mit Mandantenregeln, Ressourcenzustand, Widerruf und weiteren lokalen Kontrollen.

Eine gültige Kette plus privater Schlüssel garantiert laut Entwurf keinen Zugriff. Ein Konto kann gesperrt, ein Export durch Legal Hold blockiert oder eine Ressource in einen anderen Mandanten verschoben worden sein. Die Wurzel ist eine Obergrenze, kein Fernbefehl. Jedes Kind senkt diese Obergrenze; der Wirkungspunkt darf noch weiter reduzieren oder verweigern.

Auch ein positiver Autorisierungsentscheid ist nicht die Quittung der Geschäftswirkung. Datenbankkonflikt, Queue-Ausfall, Teilwirkung oder Retry können folgen. DPoP-Replay-Schutz verspricht keine genau-einmalige Buchung. Transaktions- und Idempotenzbelege gehören hinter die Autorisierung.

Zehn Quittungen statt eines Ereignisses „Delegation erfolgreich“

Quittung Mindestbeleg Beweist nicht
Wurzeleinwilligung Grant, getrennte Delegationszustimmung, Tiefe Zustimmung zu einem später benannten Kind
Wurzelausstellung Issuer, Hash, Audience, Rechte, Zeit, cnf.jkt heutigen Ressourcen-Zugriff
Empfängerzuordnung Workload, Mandant, Schlüssel-Thumbprint, Kanal semantische Verengung
Kind-Ausstellung Elternkante, Kind-Hash, Limits, Resttiefe vertrauenswürdige Wurzel
Kettenprüfung Signaturen, Kanten, Zeiten, Containment Blattbesitz oder lokale Freigabe
Blatt-Nachweis Methode, URI, exakter ath, Nonce, Replay gültige Vorfahren
Status Status jedes Vorfahren und Frische Verteilung an jeden Prüfer
Lokale Entscheidung Policy-Version, Operation, Ergebnis Anwendungs-Commit
Wirkung Transaktion/Idempotenz und Zustand gewünschtes externes Resultat
Abgleich benannte Beobachtung und Ausnahmen Befugnis für weitere Aktionen

Die Trennung macht Fehler diagnostizierbar. Ein ungültiges Kind kompromittiert nicht automatisch den Autorisierungsserver. Eine lokale Ablehnung trotz gültiger Kette ist kein Signaturfehler. Eine falsche Geschäftswirkung wird nicht durch erneute JWT-Prüfung repariert.

Der Entwurf ist deshalb nicht bloß „Delegation ohne Zentralserver“. Der Server darf bei Kind-Ausstellungen fehlen, weil er diese Abwesenheit vorher begrenzte und der Ressourcenserver jede Grenze später lokal wiederherstellt. Das Kind kann gültig sein. Die Befugnis gehört der ganzen Kette und dem letzten Entscheidungspunkt.