Zusammenfassung

  • Revision 01 von draft-zehavi-oauth-authz-req-del-chain wurde am 10. September 2026 als individueller Internet-Draft angekündigt; sie ist weder vom OAuth-Arbeitskreis übernommen noch ein RFC.
  • Abgesetzte JWS-Signaturen, Vorgänger-Hashes, Positionsnummern und Audience-Kontinuität sichern die Integrität des sichtbaren Brokerpfads.
  • Am Ende oder in der Mitte entfernte Knoten sollten die Prüfung brechen. Ein Broker kann jedoch eine neue gültige Kette mit sich selbst als chain[0] beginnen.
  • Ob dieser erste sichtbare Aussteller für Client, Ressource und Einsatzkontext zulässig ist, muss die lokale Richtlinie entscheiden.

Eine fehlerlose Spur kann ein fehlendes Vorher haben

Beim vermittelten OAuth-Redirect wandert eine Autorisierungsanfrage über mehrere Stellen. Jeder Broker ist für seine nachgelagerte Partei Autorisierungsserver und gegenüber der nächsten Stelle OAuth-Client. Der Server, der am Ende Einwilligung einholt und Tokens ausstellt, kennt unter Umständen nur den unmittelbar vorgelagerten Broker.

Der Entwurf OAuth Authorization Request Delegation Chain schlägt dafür einen RAR-authorization_details-Eintrag vor. Jeder JSON-Knoten nennt Aussteller, Empfänger, Position und bestätigten Client. Eine abgesetzte JWS schützt die deterministische Knotendarstellung; p_hash bindet sie an das vorherige signierte Ereignis.

Die Prüfung läuft vom Ende rückwärts. Der letzte Knoten muss an den empfangenden Server adressiert sein. Sein Aussteller muss zum authentifizierten OAuth-Client passen, der die Anfrage einreicht. Danach folgen Schlüssel, Signaturen, Nummern, Namensräume, Hashes und die Kontinuität von Audience zu Aussteller.

Besteht die Kette alle Prüfungen, ist der vorgelegte Pfad konsistent. Daraus folgt nicht, dass der Pfad die früheste beteiligte Stelle enthält.

Zwei Schnitte reißen die Verknüpfung, einer setzt sie neu

Revision 01 unterscheidet drei Arten der Verkürzung. Wird das Ende entfernt, zeigt der verbleibende letzte Empfänger nicht auf den prüfenden Server. Fehlt ein mittlerer Knoten, stimmen der im Nachfolger gespeicherte Hash und die benachbarte Aussteller-Audience-Beziehung nicht mehr.

Am Kopf kann ein Broker dagegen früheren Kontext verwerfen und eine neue Kette anlegen. Er trägt sich als Position null ein und setzt den Vorgänger-Hash auf null. Von dort an können sämtliche Unterschriften und Übergänge echt sein. Der Entwurf nennt dies Re-origination und hält fest, dass Kryptografie keinen fehlenden Kontext vor chain[0] ausschließen kann.

Das ist kein gemeldeter Angriff, sondern eine erklärte Beweisgrenze. Eine Hashkette schützt die Geschichte ab dem behaupteten Anfang. Ohne unabhängigen Zeugen beglaubigt sie nicht, dass der behauptete Anfang historisch vollständig ist.

Deshalb muss der empfangende Server per lokaler Richtlinie bestimmen, ob dieser Aussteller für den betreffenden Client, die Ressource und den Einsatz als erster sichtbarer Aussteller auftreten darf. Auch eine richtige Signatur verleiht keine Brokerbefugnis. client_roles kann zwar oauth_broker angeben, doch selbst behauptete Metadaten sind laut Entwurf kein Vertrauensbeweis. Die normale Authentifizierung des unmittelbaren Clients bleibt bestehen.

Kontrolliertes Weglassen wirkt nur auf die nächste Etappe

Die neue Fassung ergänzt die Erkennung der Unterstützung über RFC-8414-Metadaten. Versteht der nächste Server den Kettentyp nicht, darf ein Broker eine bereits vorhandene Kette nicht geräuschlos entfernen.

Er muss abbrechen, den Kontext mit einem anderen vertrauenswürdigen Verfahren bewahren oder nur dann ohne Kette weiterleiten, wenn lokale Politik und signierte Kette dies erlauben. Das optionale omit_chain kennt allowed und forbidden; fehlt es, gilt ein Verbot. Sämtliche validierten Knoten müssen dem Weglassen zustimmen.

So wird späterer Beweisverlust zu einer ausdrücklichen Entscheidung. Über einen möglicherweise vor dem neuen Start entfernten Kontext sagt das Feld nichts aus. Die Freigabe eines künftigen Downgrades und die Anerkennung eines frisch deklarierten Ursprungs sind getrennte Kontrollen.

Revision 01 beantragt außerdem die IANA-Registrierung von client_roles. Noch handelt es sich um Vorschläge eines individuellen Entwurfs, nicht um Zuteilung, IETF-Konsens, Arbeitsgruppenübernahme, Implementierung, Einsatz oder Vorfall.

Quellen