Zusammenfassung

  • Die Fassung -02 eines individuellen Internet-Drafts verlangt nach ihrem eigenen Vorschlag, dass ein Verifikator sämtliche vorgelegten authorization_details auswertet oder das Token ablehnt. Unbekannte Typen einfach zu übergehen, wäre eine unvollständige Prüfung mit Erfolgsmeldung.
  • Der Aufrufer soll erkennen können, dass ein erneutes Senden desselben Tokens zwecklos ist. Welche Berechtigung, welcher Pfad oder welcher übergeordnete Grant scheiterte, gehört dagegen in das geschützte Audit des Betreibers, nicht in die Antwort über die Vertrauensgrenze.

Eine brauchbare Fehlermeldung kann zu brauchbar sein. Ein fremder Agent sendet einen Delegationsnachweis an einen Dienst. Dessen Verifikator entdeckt, dass ein Eintrag nicht bewertet werden kann. Für den Betrieb wäre es hilfreich, genau zu erfahren, welcher Eintrag oder welche übergeordnete Freigabe den Ausschlag gab. Für den fremden Agenten könnte dieselbe Auskunft eine unerlaubte Karte interner Berechtigungen darstellen. Verschweigt der Dienst wiederum jede Unterscheidung zwischen vorübergehender Störung und dauerhaft unbrauchbarem Token, wird das identische Token möglicherweise immer wieder gesendet.

Wes Jacksons Verifier-Side Evaluation Semantics for Delegated Authority Chains, Fassung -02 vom 29. September 2026, macht aus diesem Konflikt eine ausdrückliche Grenze. Der IETF Datatracker führt das Dokument als individuellen Internet-Draft mit dem Status I-D Exists; ein Standardisierungs-Stream ist nicht zugeordnet. Der Entwurf ist weder vom WIMSE-Arbeitskreis angenommen noch ein RFC. Seine normativen Verben beschreiben den Anspruch des Autors, nicht schon geltendes IETF-Recht oder einen nachgewiesenen Betriebseinsatz.

Die Änderung gegenüber -01 zeigt den präzisen Gegenstand. Die Überschrift von Regel 4.1 lautete zunächst „Process Every Entry or Reject“, jetzt „Process Every Entry or Refuse“. Der neue Text unterscheidet die Ablehnung durch den Verifikator eines Tokens oder Datensatzes von der endgültigen Zurückweisung durch einen Genehmiger bei einem angehaltenen Aufruf. Im einen Fall geht es darum, ob die vorgelegte Autorität überhaupt zuverlässig bewertet werden kann; im anderen entscheidet ein Mensch über eine konkrete Handlung. Die Vokabeln markieren unterschiedliche Akteure und Folgen.

Für den ersten Fall verlangt der Autor eine vollständige Prüfung der authorization_details. Kann der Verifikator einen Typ nicht beurteilen, darf er diesen Eintrag nicht lautlos entfernen und den Rest als vollständige Berechtigung ausgeben. Die neue Fassung nennt die Ablehnung dauerhaft für das vorgelegte Token. Wiederholung macht den unbekannten Typ nicht plötzlich verständlich. Diese Aussage ist enger als ein generelles Verbot, sich ein anderes Token ausstellen zu lassen; auch besagt sie nicht, jeder Fehler sei auf dieselbe Weise zu beheben.

In Abschnitt 5 wird daraus eine Informationsregel. Der Aufrufer sollte erkennen können, dass eine Wiederholung mit genau diesem Token keine Aussicht auf Erfolg hat. Zugleich soll die Antwort weder den fehlgeschlagenen Eintrag noch den Pfad oder den Zustand eines Grants preisgeben, soweit diese Informationen nicht ohnehin als Eigenschaft des Verifikators öffentlich sind. Detaillierte Fehlermeldungen könnten ein fremdes System dazu befähigen, eine Delegationsstruktur durch gezielte Anfragen zu vermessen. Den genauen Befund sieht der Betreiber in seinem Auditdatensatz.

Die Entscheidung, außen nur den nötigen Ausgang und innen die Diagnose vorzuhalten, ist Daniel Kades organisatorische Schlussfolgerung; der Entwurf führt dafür kein verbindliches Belegformat ein.

Auch die genannten OAuth-Codes sind keine austauschbaren Bausteine. RFC 9396 beschreibt invalid_authorization_details am Autorisierungsserver und registriert den Fehler für Autorisierungs- und Token-Endpunkte. RFC 6750 behandelt invalid_token am Ressourcenserver für Bearer-Token; ein Client darf ein neues Zugriffstoken anfordern und die Anfrage erneut stellen. Jackson verweist auf beide Kontexte, legt aber weder einen neuen Code noch ein übergreifendes Antwortschema fest. „Dauerhaft“ für die wiederholt eingereichte identische Zeichenfolge darf daher nicht zu „nie wieder versuchen“ verkürzt werden.

Der Entwurf liefert keine Messung von Wiederholungswellen und keinen Beleg für eine bereits erfolgte Preisgabe von Delegationspfaden. Nach seiner eigenen Einordnung verarbeitet die Referenzimplementierung keine authorization_details-Einträge. Er ist trotzdem berichtenswert, weil er die Fehlerantwort als Teil der Autoritätskontrolle erkennbar macht: Nicht nur die Prüfung selbst, auch die Grenze zwischen äußerem Signal und innerem Wissen muss halten.

Quellen