Summary

  • draft-li-oauth-delegated-authorization-03 verbindet einen vom Authorization Server signierten Root Token mit lokal signierten Child Tokens; jeder Hop bindet den nächsten Schlüssel, der Leaf Client beweist Besitz per DPoP.
  • Eine Prüfung kann Schlüsselkontinuität und die Verengung von Berechtigungen, Audience, Gültigkeit und Delegationstiefe belegen. Sie belegt weder den konkreten menschlichen Auftrag noch den beim Resource Server angekommenen Widerruf oder das Ergebnis.
  • Daniel Kade schlägt einen getrennten Delegationsabsichtsbeleg vor: Root-Mandat, Hop-Custody, Task- und Wirkungsgrenze, Widerrufsfrische, Ressourcenentscheidung und Abschluss — ohne Tokens oder Geheimnisse zu speichern.

Ein überprüfbarer Weg für enger werdende Autorität

Ein Orchestrator darf mehrere Systeme ansprechen, benötigt für eine Teilaufgabe aber nur einen spezialisierten Client. Den ursprünglichen Access Token weiterzugeben, würde unnötige Rechte übertragen. Den privaten Schlüssel zu teilen, würde Zurechnung und Schutz auflösen. Jede Unteraufgabe erneut über den Authorization Server abzuwickeln, würde lokale Delegation wieder zentralisieren.

Revision 03 definiert deshalb den Delegated Authorization Token. Der Authorization Server signiert den Root und bindet ihn über cnf.jkt an den Public-Key-Thumbprint des ersten Clients. Dieser Client kann den Token selbst verwenden oder, solange Delegation zulässig ist, mit dem gebundenen Private Key einen Child Token signieren und ihn an den Schlüssel des nächsten Clients binden.

Der Resource Server erhält die vollständige geordnete Kette. Den Root-Schlüssel nimmt er aus vertrauenswürdiger Konfiguration oder authentisierten Metadaten. Bei jedem Child muss der RFC-7638-Thumbprint des JWK im geschützten Header dem cnf.jkt des Parents entsprechen. Der Leaf Client signiert zusätzlich einen DPoP Proof, der Methode, Ziel-URI, die exakte Kettenserialisierung und Frische an seinen Schlüssel bindet.

Die bloße Kette ist also kein Trägerrecht. Der Entwurf schlägt das HTTP-Schema DA vor und untersagt, einen Delegated Authorization Token als Bearer Token zu akzeptieren. Wer zugreift, muss den Leaf-Schlüssel besitzen.

Das Ergebnis beantwortet eine scharf begrenzte Frage: Hat der jeweils gebundene Schlüssel den nächsten Schlüssel unter prüfbaren Einschränkungen autorisiert, und kontrolliert der Requester den letzten? Eine Organisationserzählung oder menschliche Zwecksetzung folgt daraus nicht.

Downscoping ist eine semantische Operation

Ein Child darf Permissions, Audience, Zeitfenster oder verbleibende Tiefe nicht erweitern. Für scope kann der Prüfer Mengen vergleichen. Ein Child-Wert, der nicht im effektiven Parent-Scope liegt, macht die Kette ungültig. Wird der Claim ausgelassen, fällt diese Berechtigungskomponente weg.

Bei authorization_details reicht Formvergleich nicht. Betragsgrenzen, Ressourcenkennungen, Aktionen, Arrays, Wildcards und Defaults bestimmen die effektive Macht. Ein kürzeres JSON kann breiter sein, wenn das Weglassen eines Feldes eine großzügige Voreinstellung aktiviert.

Der Entwurf verlangt daher für jeden Detailtyp ein deterministisches Containment-Verfahren. Rohtextgleichheit oder derselbe type-Name genügt ausdrücklich nicht. Kann ein Verifier nicht feststellen, dass jeder Child-Wert vom effektiven Parent-Wert umfasst wird, muss er ablehnen.

Authorization-relevante Extension Claims benötigen ebenso gemeinsame Delegationssemantik. Eine angebliche Einschränkung, die ein Resource Server nicht versteht, darf nicht dekorativ in einem signierten Token stehen und anschließend ignoriert werden.

Die Monotonie liegt folglich nicht nur in Kryptografie. Sie hängt an Vokabular, Regelversion und Implementierung. Der Auditbeleg muss erfassen, welcher semantische Comparator Defaults, Wildcards und Aktionen bewertet hat.

Eine Zahl begrenzt Hops, nicht Folgen

Jeder Root enthält ein endliches max_delegation_depth. Bei null ist kein Child gültig. Bei einem positiven Wert m darf das Child null bis m-1 setzen; Auslassen ergibt m-1. Der Authorization Server setzt zusätzlich ein konfiguriertes Maximum. Parser und Verifier begrenzen unabhängig davon Tokenzahl, Gesamtgröße, Einzelgröße und Signaturkosten.

Die Tiefe zählt künftige Kanten. Sie ist kein Risk Score. Ein terminaler Hop kann eine irreversible Schreiboperation ermöglichen; drei Hops können in einer harmlosen Lesefunktion enden. Null bedeutet nur „nicht weiter delegierbar“, nicht „vom Menschen gesehen“, „geringes Risiko“ oder „für diese Transaktion genehmigt“.

Bei einem Resource-Owner-Grant muss die ursprüngliche Entscheidung die Fähigkeit umfassen, später ohne neue Interaktion Child Tokens auszustellen, einschließlich der maximalen Tiefe. Eine gewöhnliche Access-Zustimmung darf nicht als Delegationszustimmung gelesen werden. Wird eine ausdrücklich beantragte Tiefe abgelehnt, darf der Server nicht still einen kleineren Wert ausstellen und dies als Zustimmung behandeln.

Wie diese Fähigkeit dargestellt wird, lässt der Entwurf offen. „Zwei weitere Ebenen“ kann formal korrekt und praktisch unverständlich sein. Die Zahl nennt weder künftige Delegate Clients noch deren Key Discovery, konkrete Tasks oder die Wirkungen, die eine neue Bestätigung erfordern.

Wo der generische Token bewusst endet

Nicht definiert sind unter anderem Client-Key-Discovery, Out-of-Band-Verhandlung, Mehrfachkettenübermittlung, Bindung einer gelieferten Kette an einen bestimmten Request oder Task, typenspezifisches Containment und Verteilung von Widerrufsstatus.

Gerade dort wird generische Befugnis zu betrieblichem Zweck.

Ein Research Agent kann Leserechte für eine Knowledge API, zehn Minuten Laufzeit, eine Audience und Tiefe null erhalten. Eine perfekte Kette unterscheidet noch nicht „fasse das freigegebene Projektdokument zusammen“ von „durchsuche alle erreichbaren Personalakten“. Application Policy und Request Context können das zweite Vorhaben sperren; die menschliche Begründung steckt dennoch nicht in der Schlüsselkontinuität.

Der Entwurf sagt ausdrücklich, dass Chain Validation allein den Protected Resource Request nicht autorisiert. Der Resource Server prüft zusätzlich DPoP, Request Binding, Audience und anwendungsspezifische Permissions. Auch ein positives Allow ist kein Erfolgsnachweis. Der Vorgang kann scheitern oder einen nachgelagerten Effekt auslösen.

Root-Mandat, Hop-Custody, Task-Absicht, aktueller Gültigkeitsstand und beobachtete Wirkung bleiben getrennte Fragen.

Widerruf wird geschrieben und später wirksam

Der Root-Widerruf invalidiert alle von ihm ausgehenden Ketten. Der Widerruf eines Child invalidiert jede Kette, die ihn enthält, sowie seine Descendants, nicht jedoch Parent, Siblings oder andere Tokens mit demselben Key.

Eine erfolgreiche Revocation Request schreibt Zustand beim Authorization Server. Ein offline prüfender Resource Server erhält ihn dadurch nicht. Revision 03 definiert keinen Status-Distributionsmechanismus. Kurze Lifetimes begrenzen die unbekannte Zeitspanne, belegen aber keinen Zustellzeitpunkt.

Ein Audit braucht deshalb zwei Uhren: wann der Widerruf registriert wurde und welche Statusversion, welches Alter und welche Failure Policy der Resource Server bei seiner Entscheidung hatte. Der zentrale Eintrag um 10 Uhr beweist keine periphere Kenntnis um 10:01 Uhr.

Caching hebt den Unterschied nicht auf. Signaturen und effektive Restrictions dürfen per Digest der exakten Kette gecacht werden, müssen aber Expiration, Key Status, Local Policy und tatsächlich empfangene Revocation Information beachten. DPoP-Frische und Replay-Prüfung bleiben requestbezogen.

Privacy hängt vom Beobachtungspunkt ab

Lokale Delegation verhindert, dass der Authorization Server automatisch jeden Delegate, jedes Ziel, jeden Zeitpunkt und jedes Multi-Hop-Muster sieht. Das kann zentrale Datensammlung reduzieren.

Der Resource Server sieht dagegen die vollständige geordnete Kette. Root- und Intermediate-Claims können Issuer, Subject, Client-Beziehungen, Audiences, Permissions und Workflow-Struktur offenlegen. Stabile cnf.jkt- oder jti-Werte ermöglichen Korrelation.

Audit Visibility verschwindet nicht, sie zieht um. Root Issuance liegt beim Authorization Server, Local Delegation beim signierenden Client, Validation und Resource Decision beim Resource Server. Der Entwurf empfiehlt One-Way-Digests für Kettenreferenzen und das Redigieren von Authorization- und DPoP-Headern aus Routine-Logs.

Die Lösung ist kein zentraler Credential-Speicher, sondern eine datensparsame Reconciliation verteilter Beobachtungen.

Derselbe Schlüssel kann nutzen und weitergeben

Der gebundene Private Key beweist Besitz für die aktuelle Nutzung und kann, wenn Tiefe bleibt, das nächste Child signieren. Eine Kompromittierung ermöglicht daher sowohl Zugriff mit gültiger Autorität als auch das Erzeugen engerer Descendants.

Der Text empfiehlt nicht exportierbare Keys und schmale Signing APIs, die Token-Signing- von Proof-Signing-Inputs unterscheiden. Unterschiedliche Keys pro Token verringern Korrelation und Incident Radius.

Ein Child Token trägt außerdem keinen Parent Identifier. Er kann in einer anderen Kette gültig sein, wenn deren vorangehender Token denselben Signing Key bindet und die effektiven Restrictions das Child umfassen. Das ist eine beabsichtigte Eigenschaft des ersten Formats. Wer Bindung an genau eine Parent Chain benötigt, muss Parent Keys trennen oder eine Application Restriction einsetzen.

Ein Thumbprint bezeichnet einen Key. Er beweist nicht, welcher Prozess ihn kontrollierte, welche Policy seine Signing API durchsetzte oder welchen betrieblichen Auftrag er erfüllen sollte.

Ein Delegationsabsichtsbeleg

Ich schlage einen Delegationsabsichtsbeleg vor. Er ist Daniel Kades Governance-Entwurf, kein Pflichtfeld des Internet-Drafts und kein neuer OAuth Claim.

Der Root-Teil speichert sichere Digests von Authorization Event und Consent-Presentation-Version, Issuer und Trusted-Metadata-Snapshot, Delegationsfähigkeit, effektive Permissions, Audiences, Lifetime und Tiefe. Token, Private Key, DPoP Proof, rohe Header und unnötige Subject-Daten bleiben ausgeschlossen.

Jeder lokale Hop verbindet Exact-Chain-Digest, Parent- und Child-Thumbprints, Restrictions vorher und nachher, Containment-Regel samt Version, Signing-Service-Identität und minimale Evidenz der Client-Auswahl. Key Reuse und One-Parent-Anforderung werden markiert.

Dann folgt, was ein generischer Credential nicht trägt: Digest von Task, akzeptablem Output und Wirkungsgrenze; Decision Owner; Environment-, Transaktions- oder Aktionslimit; Bedingungen für erneute menschliche Interaktion. Sensitiver Task-Inhalt wird nicht kopiert.

Am Resource Server hält der Beleg Policy Version, Semantic Comparator, empfangene Revocation-Version und Frische, DPoP-Ergebnis, effektive Autorität und Allow/Deny fest. Der Abschluss nennt Operationsklasse, Erfolg oder Fehlschlag, wesentliche Folgewirkungen und Rollback- oder Incident-Referenz.

Die kleinste brauchbare Fassung enthält Root-Mandat, Hop-Digest, Task-/Effect-Digest, Revocation Freshness und Resource Decision. Sie soll keine philosophische Absicht beweisen, sondern die betriebliche Evidenz erhalten, die der Token bewusst nicht trägt.

Die Aussagekraft nicht aufblasen

Revision 03 ist ein am 24. Juli 2026 aktualisierter individueller Internet-Draft. Sie ist kein vom OAuth WG angenommenes Dokument, kein IETF-Konsens, Last Call, IESG Approval, RFC oder aktive IANA-Registrierung. Aus Detailgrad folgt kein Deployment.

Innerhalb dieser Grenze ist der Vorschlag stark. Er gibt lokaler Delegation überprüfbare Key Lineage, erzwingt enger werdende Autorität und benennt die externen Abhängigkeiten von Semantik und Revocation Distribution.

Eine valide Kette erlaubt die Aussage, dass bestimmte Schlüssel unter berechneten Grenzen Autorität weiter einschränken und ausüben durften. Sie erlaubt nicht die Aussage, dass ein Mensch genau diesen Delegate, Task und Effekt wollte.

Sind Daten offengelegt oder Systeme verändert, kann eine spätere Signatur fehlende Absicht nicht rekonstruieren. Befugnis gehört in die Kette. Absicht muss vor der Wirkung daneben festgehalten werden.

Quellen

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption
  3. Lu Heng — Why BTW Media Exists
  4. OAuth 2.0 Delegated Authorization, Revision 03
  5. Datatracker-Eintrag des Entwurfs
  6. Versionsgeschichte des Delegated-Authorization-Entwurfs
  7. OAuth-Working-Group-Charter
  8. RFC 6749: OAuth 2.0 Authorization Framework
  9. RFC 7009: OAuth 2.0 Token Revocation
  10. RFC 7638: JSON Web Key Thumbprint
  11. RFC 8414: OAuth 2.0 Authorization Server Metadata
  12. RFC 8707: Resource Indicators for OAuth 2.0
  13. RFC 8725: JSON Web Token Best Current Practices
  14. RFC 9396: OAuth 2.0 Rich Authorization Requests
  15. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession
  16. RFC 9700: Best Current Practice for OAuth 2.0 Security
  17. RFC 9728: OAuth 2.0 Protected Resource Metadata