Zusammenfassung

  • draft-ietf-oauth-status-list-21 lässt ein Referenced Token über URI und Index auf einen Eintrag in einer komprimierten Liste zeigen. Ein geschütztes Status List Token übermittelt für viele Tokens Werte wie VALID, INVALID oder SUSPENDED. Revision 21 ist von der IESG genehmigt und in der Warteschlange des RFC Editor, aber weiterhin ein Internet-Draft und noch kein RFC.
  • Der Eintrag beschreibt standardmäßig den Zustand zum Ausgabezeitpunkt der Liste. iat, exp und ttl begrenzen Ausgabe, Gültigkeit und Cache. Sie dokumentieren nicht automatisch Übergangszeit, verantwortliche Stelle, Grund, erste Bereitstellung oder die spätere Entscheidung des Relying Party.
  • Daniel Kade schlägt außerhalb des Protokolls einen datensparsamen Entscheidungsbeleg vor: Fingerprints von Token und Liste, URI/Index, Ausstellerprüfung, vier getrennte Uhren, decodierte Semantik, lokale Aktualitätsregel, Folge und spätere Korrektur. Das ist keine IETF-Vorgabe und kein Auftrag zur dauerhaften Profilbildung.

Die Token Status List gewinnt ihre Effizienz aus einer bewussten Begrenzung. Viele Berechtigungsnachweise teilen eine Bitfolge. Der Prüfer lädt ein geschütztes Objekt, findet die vom Referenced Token genannte Position und kann dieselbe Liste im Rahmen der Cachevorgaben wiederverwenden. Er muss beim Aussteller nicht für jede Präsentation einen einzelnen, identifizierbaren Status erfragen.

Aus dieser Ökonomie folgt aber keine vollständige Revisionsakte. Wenn der Status eine dauerhafte Sperre, Zahlung oder Ablehnung auslöst, muss die Organisation festhalten, welchen Beleg sie wann und nach welcher Regel nutzte. Sonst wird beim späteren Widerspruch von wenigen Bits eine Beweisleistung erwartet, für die sie nicht gebaut wurden.

Genehmigt, in Produktion, noch ohne RFC-Nummer

Der Datatracker-Eintrag führt Revision 21 vom 21. Juni 2026 als Standards-Track-Internet-Draft der OAuth Working Group. Die Historie verzeichnet die IESG-Genehmigung der Revision 20 am 4. Juni, den Übergang in die RFC-Editor-Warteschlange, Revision 21 am 21. Juni und am 13. August den RPC-Stand Awaiting First editor. Der Text ist institutionell weit fortgeschritten und genehmigt, aber zum Recherchestichtag noch kein RFC.

Der Text der Revision 21 läuft am 23. Dezember 2026 ab. Der offizielle Vergleich 20→21 fixiert die untersuchte Fassung. Aus dem Bearbeitungsstand lassen sich keine Verbreitung, Implementierungsqualität oder Vorfälle ableiten. Die OAuth Working Group verantwortet den Standardtext, nicht die hypothetischen Dienste dieses Artikels.

Der Entwurf umfasst mit JOSE oder COSE geschützte Formate, darunter JWT, SD-JWT, CWT und ISO-mdoc-Anwendungen. JWS und JWT bilden die JSON-Grundlage; CWT und COSE die CBOR-Seite. Das Status List Token ist nicht der Berechtigungsnachweis selbst, sondern ein separates geschütztes Artefakt über einen nach der Ausstellung veränderlichen Zustand.

Ein Locator ist keine Begründung

Beim Listenmechanismus enthält das Referenced Token ein status_list-Objekt mit uri und idx. Die URI identifiziert das Status List Token, der nichtnegative Index die auszulesende Stelle. Dieses Koordinatenpaar beantwortet „wo?“, nicht „warum?“ oder „durch wen?“.

Der Status Issuer wählt ein, zwei, vier oder acht Bits pro Referenced Token, weist getrennte Indizes zu, packt die Werte innerhalb jedes Bytes vom niederwertigsten zum höchstwertigen Bit und komprimiert das Array mit DEFLATE im ZLIB-Format. RFC 1951 und RFC 1950 definieren diese Schichten. Das Ergebnis wird in ein JWT oder CWT eingebettet und mit Signatur oder MAC geschützt.

Drei Rollen umgeben den Vorgang. Der Issuer stellt das Referenced Token aus. Der Status Issuer empfängt Statusinformationen und erzeugt die geschützte Liste. Der Status Provider liefert sie aus. Eine Organisation kann alle Rollen vereinen oder die Zustellung an einen Dritten beziehungsweise ein CDN geben, ohne diesem die Änderung der signierten Inhalte zu erlauben.

Für die Beweisführung sind Signatur und Zustellung nicht dasselbe. Die kryptografische Prüfung belegt Herkunft und Integrität der Listenbytes. Die Netzwerkbeobachtung belegt, welches Objekt der Provider zu einem Zeitpunkt lieferte. Keine davon verrät allein, wann das vorgelagerte Konto geschlossen, die Suspendierung angeordnet oder der Quellenbestand geändert wurde.

Das anfängliche Register setzt 0x00 auf VALID, 0x01 auf INVALID und 0x02 auf SUSPENDED; Bereiche bleiben anwendungsspezifisch oder künftigen Einträgen vorbehalten. Mehrere Bits pro Token bilden gemeinsam genau einen Wert. Sie sind keine Folge mehrerer Ereignisse.

Ebenso ersetzt VALID nicht die Prüfung des Referenced Token. Format, Signatur, notwendige Claims, Ablauf und weitere Beschränkungen kommen zuerst. Ein abgelaufenes Token bleibt abgelaufen, auch wenn die Liste VALID meldet. Danach entscheidet der Relying Party nach seiner Anwendungsregel. Tokenprüfung, Listenprüfung, Statusdecodierung und Autorisierung müssen daher getrennt protokolliert werden.

Vier Uhren mit unterschiedlichem Besitzer

Die erste Uhr gehört zur Statusquelle. Sie würde den realen oder administrativen Übergang markieren: Widerruf, Suspendierung oder Wiederherstellung. Revision 21 definiert diesen vorgelagerten Workflow nicht. Der Bitwert muss weder Entscheider noch Grund noch Ereigniszeit tragen.

Die zweite Uhr gehört der Listenausgabe. iat ist Pflicht und bezeichnet die Ausgabezeit des Status List Token. Das empfohlene exp legt fest, wann der Status Issuer die Liste als abgelaufen betrachtet. Dieses Fenster begrenzt die geschützte Aussage, macht iat aber nicht zum Übergangszeitpunkt jedes Eintrags.

Die dritte Uhr gehört Zustellung und Abruf. Ein externer Provider kann ein früher signiertes Objekt ausliefern. Die Abrufzeit belegt eine Beobachtung, nicht den Zeitpunkt der Erstellung oder der Quellenänderung.

Die vierte Uhr gehört der Entscheidung. Eine Anwendung handelt sofort, nach einer Queue oder in einem Batch. Dann verbindet sie Cachealter, Status und weitere Bedingungen mit einer lokalen Konsequenz.

ttl steuert den Cache, verschmilzt die Uhren jedoch nicht. Der Entwurf beschreibt eine erneute Suche nach Abrufzeit plus ttl, was die Providerlast verteilt, und für kritische Fälle eine Suche um iat + ttl mit kleinem Verteilungspuffer. Bei einem Widerspruch zwischen HTTP-Headern und geschützten Claims gehen exp und ttl des Status List Token vor. RFC 9110 liefert die HTTP-Semantik; die tolerierte Aktualität bleibt eine Entscheidung des Ökosystems und des Relying Party.

Zu lange Intervalle verlängern die Nutzung alter Aussagen. Zu kurze können unvernünftige Abrufmengen erzeugen. Der Sicherheitsteil verlangt deshalb sinnvolle Ober- und Untergrenzen und warnt vor versehentlichen oder böswilligen Werten, die den Status Provider mit Anfragen überziehen. Ein Beleg muss also auch den gewählten Zählbeginn und das tatsächliche Cachealter bewahren.

Historische Auflösung erzeugt Momentaufnahmen

Standardmäßig liefert das Verfahren die jüngste Statusinformation. Optional kann ein Client time=<timestamp> anfügen. Ein unterstützender Server darf ein für diesen Zeitpunkt gültiges Status List Token oder einen Fehler zurückgeben. Ignoriert statisches Hosting den Parameter und liefert die aktuelle Datei, muss der Client sie ablehnen, wenn die angefragte Zeit nicht im geschützten iat/exp-Fenster liegt.

Zwei Momentaufnahmen können eine Änderung eingrenzen. VALID um 10:00 Uhr und INVALID um 10:15 Uhr zeigen, dass die neue Aussage spätestens in der zweiten Liste stand. Sie beweisen nicht, ob ein Mensch um 10:02 entschied, das Quellsystem um 10:07 schrieb oder der Provider um 10:14 veröffentlichte. Für Ursache und Autorität braucht es ein verbundenes Quellprotokoll.

Die Historie hat zudem einen Datenschutzpreis. Der Entwurf empfiehlt, sie ohne starken Grund und gründliche Folgenabschätzung nicht anzubieten. Ein Relying Party, der URI und Index speichert und wiederholt prüft, kann ein Zustandsprofil bilden. Ein Außenstehender kann Listen archivieren und Mengen oder Widerrufsraten abschätzen. Die Erklärung eines konkreten Entscheids rechtfertigt keine vollständige Dauerbeobachtung.

Herd Privacy ist eine Eigenschaft, kein Versprechen absoluter Anonymität

Viele Tokens in einer Liste erschweren dem Issuer die Zuordnung eines Abrufs zu einem bestimmten Nachweis. Der Entwurf nennt dies Herd Privacy. Eine größere Liste verbreitert die Anonymitätsmenge und erhöht zugleich die Datenmenge.

Metadaten können die Herde wieder verkleinern: eine einzigartige URI pro Token, sehr kleine Listen oder unverwechselbare Größen. Auch die HTTP-Anfrage kann die Adresse des Relying Party zeigen. Das URI/Index-Paar ist selbst korrelierbar; zusammenarbeitende Prüfer können Präsentationen desselben Tokens erkennen. RFC 9901 beschreibt den SD-JWT-Kontext selektiver Offenlegung, RFC 9458 Oblivious HTTP als mögliche Relay-Technik.

Zu den Gegenmitteln gehören Drittanbieterhosting, zufällige oder pseudozufällige Indizes, Täuscheinträge, mehrere parallele Listen, Einmal-Batches und ein neuer Eintrag bei Neuausstellung. Auch die Statussemantik kann Informationen verraten. SUSPENDED sagt mehr über eine vorübergehende Phase als eine bloße Nichtzulassung; anwendungsspezifische Werte können noch aussagekräftiger sein.

Der lokale Entscheidungsbeleg muss deshalb datensparsam bleiben. Fingerprints und Zeitangaben können genügen; vollständige Credentials, IP-Adressen und jede Präsentation zu archivieren, schafft eine neue Überwachungsstelle. Historische Abfragen gehören nur hinein, wenn sie tatsächlich verwendet wurden.

Decodierung ist Teil des Ergebnisses

Revision 21 betont die Bitreihenfolge: im Byte vom niederwertigsten zum höchstwertigen Bit, während die Bytes natürlich fortschreiten. Falsche Dekompression, eine fehlerhafte Positionsrechnung oder ein tolerierter Index außerhalb der Liste kann einen unzutreffenden Status ergeben. Der Entwurf stellt Testvektoren bereit.

Der Ablauf muss nachvollziehbar bleiben: zuerst das Referenced Token prüfen; dann URI auflösen; Typ, Signatur oder MAC und Claims des Status List Token validieren; Subject und URI verbinden; iat, exp, ttl und lokale Aktualität anwenden; dekomprimieren; Index lesen; registrierte Bedeutung auslegen; zuletzt die Anwendungsregel ausführen.

Liegt der Index außerhalb des Arrays, kann keine Statusaussage getroffen werden und das Referenced Token muss abgelehnt werden. Schlägt die Listenvalidierung fehl, gibt es ebenfalls keine Aussage; der Entwurf empfiehlt Ablehnung. „Keine Aussage“ ist nicht INVALID. Das eine ist fehlende verwendbare Evidenz, das andere ein expliziter Status des Status Issuer.

Zwei Fingerprints, vier Zeiten, ein begrenzter Beleg

Daniel Kades Vorschlag beginnt mit einem minimalen Fingerprint des Referenced Token und dem exakten Hash des tatsächlich genutzten Status List Token. Er notiert URI/Index, Status Issuer, beobachteten Provider, Schlüsselauflösung, Signatur- oder MAC-Ergebnis und relevante Decoder- beziehungsweise Testvektorversion.

Anschließend trennt er die Quellenübergangszeit, sofern sie wirklich bekannt ist, von iat, exp, ttl, Abrufzeit, Cachealter und Entscheidungszeit. Er hält fest, ob aktuell oder historisch abgefragt wurde, welchen Timestamp, numerischen Wert und registrierte Bedeutung das System nutzte, welche Aktualitätsgrenze und Geschäftsregel galten und wie der Vorgang später korrigiert oder geschlossen wurde. Unbekanntes bleibt unbekannt.

Das ist keine Änderung am Token-Status-List-Protokoll. Es ist ein lokaler, verhältnismäßiger Kontrollbeleg für langfristige Folgen. Hashes, knappe Verweise, Zugriffsschutz und kurze Aufbewahrung sind vorzuziehen. The Policy Mirror liefert die Trennung von erklärter Regel und sichtbarer Entscheidung, Running-Code Primacy den Blick auf den ausgeführten Pfad, Reality, Not Advocacy die Disziplin, Lücken nicht zu erfinden. Keiner dieser Texte belegt einen OAuth-Vorfall.

Quellen