Status List-Widerruf erklärt
Ein verifier, der gerade eine credential erhalten hat, muss wissen, ob der issuer noch dafür einsteht. Token Status List beantwortet das, ohne dass der verifier den issuer wegen dieser konkreten credential kontaktiert: ein status claim in der credential verweist auf eine kompakte Liste, und ein einzelnes Bit dieser Liste trägt die Antwort.
Der status claim in der credential
Ein issuer, der Token Status List unterstützt, fügt der credential bei der Ausstellung einen status claim hinzu. Er enthält zwei Dinge: idx, den Index, den diese credential in der Liste innehat, und uri, die Adresse des Status List Token, der ihn enthält. Ansonsten ändert sich an der credential nichts; der claim ist lediglich ein Verweis.
Issuer
Weist der credential einen Index zu und bettet einen status claim ein
Der claim wird einmalig bei der Ausstellung hinzugefügt und ändert sich während der gesamten Lebensdauer der credential nie mehr
Status claim (in der credential)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}Abrufen des Status List Token
Bei der Präsentation ruft der verifier die uri aus dem status claim ab. Die Antwort ist ein signierter Status List Token: ein JWT mit einem typ-Header von statuslist+jwt (oder einem CWT-Äquivalent), ausgeliefert als application/statuslist+jwt. Sein Payload enthält die komprimierte Bitfolge und meist einen ttl, der angibt, wie lange der verifier das Ergebnis cachen darf, bevor er es erneut abruft.
Verifier
Liest idx und uri aus dem status claim in der gerade präsentierten credential
GET uri
Ruft den Status List Token ab und cacht ihn bis zu ttl Sekunden
Status List Token Payload (Antwort)
{
"sub": "https://issuer.example/statuslists/employment-2026-q3",
"iat": 1789200000,
"exp": 1789804800,
"ttl": 43200,
"status_list": {
"bits": 2,
"lst": "eNrbuRgAAhcBXQ"
}
}sub wiederholt die eigene uri der Liste, sodass ein verifier bestätigen kann, dass er den richtigen Token abgerufen hat. iat und exp begrenzen die Gültigkeit des Tokens selbst. ttl gibt in Sekunden die maximale Zeit an, in der der verifier eine zwischengespeicherte Kopie wiederverwenden darf, bevor er die Liste erneut abrufen muss.
Das Bit dekodieren
lst ist ein Byte-Array, base64url-kodiert und mit DEFLATE im zlib-Datenformat komprimiert, das der verifier zuerst dekomprimiert. bits gibt an, wie viele Bits jede credential in der Liste belegt: 1, 2, 4 oder 8. Bei bits: 2 liegt credential Nummer idx bei Byte idx * 2 / 8, und der verifier liest die beiden Bits an diesem Offset, um den Statuswert zu erhalten.
Durchgerechnetes Beispiel: idx 4271, bits: 2
- bit_offset = idx * bits = 4271 * 2 = 8542
- byte_index = bit_offset / 8 = 1067
- bit_in_byte = bit_offset % 8 = 6
Der verifier liest Byte 1067 des dekomprimierten Arrays, extrahiert die beiden Bits ab Bit 6 und vergleicht das Ergebnis mit der folgenden Wertetabelle.
| Wert | Bedeutung |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Anwendungsspezifisch / reserviert |
Die gezeigten Werte gehen von bits: 2 aus. Mit bits: 1 passen nur VALID (0) und INVALID (1); bits: 4 und bits: 8 lassen mehr Raum für anwendungsspezifische Werte.
Warum die Liste klein bleibt
In der Praxis bestehen status lists größtenteils aus Nullen, weil die meisten credentials, die ein issuer je ausgestellt hat, noch immer gültig sind, und eine Folge identischer Bits sich gut komprimieren lässt. DEFLATE-Komprimierung der rohen Bitfolge sorgt dafür, dass eine Liste mit Hunderttausenden von credentials auf der Leitung nur wenige Kilobyte groß bleibt, was es praktikabel macht, die gesamte Liste abzurufen, statt den issuer nach einer einzelnen credential zu fragen.
Aggregation: Listen im Voraus entdecken
Ein issuer kann einem Status List-Objekt optional aggregation_uri hinzufügen, das auf einen Endpunkt verweist, der die uris aller von ihm veröffentlichten Status List Token auflistet. Ein verifier, der Listen vorab abrufen und cachen möchte, statt jede erst über die erste credential zu entdecken, die auf sie verweist, kann stattdessen diesen Endpunkt nutzen. Dies ist optional; nichts im oben beschriebenen Kernablauf hängt davon ab.
Verwandte Begriffe
Häufig gestellte Fragen
Ruft der verifier für jede geprüfte credential eine eigene Liste ab?
Nein, ein einziger Status List Token deckt jede credential ab, die der issuer darin aufgenommen hat, möglicherweise Hunderttausende. Ein verifier ruft denselben Token einmal ab und liest für jede geprüfte credential ein anderes Bit, bevor er die zwischengespeicherte Kopie bis zu ttl Sekunden lang wiederverwendet und dann erneut abruft.
Kann der issuer erkennen, welche credential ein verifier nachgeschlagen hat?
Nein. Der verifier lädt die gesamte komprimierte Bitfolge in einer einzigen Anfrage herunter und liest das benötigte Bit lokal aus, sodass die Anfrage, die der issuer sieht, weder einen Index noch eine credential-Kennung enthält, sondern nur ein GET für die Liste selbst.
Was ist der Unterschied zwischen suspended und invalid?
INVALID (0x01) ist die Bezeichnung, mit der das Referenzregister der Spezifikation eine dauerhaft widerrufene credential kennzeichnet. SUSPENDED (0x02) ist ein separater, reversibler Status, den ein issuer ebenfalls setzen und später wieder aufheben kann, etwa während ein Streitfall geprüft wird. Um sie zu unterscheiden, sind mindestens zwei Bits pro Eintrag nötig (bits: 2); ein Status List Token mit bits: 1 kann daher nur zwischen valid und invalid unterscheiden.
Wofür dient aggregation_uri?
Es handelt sich um einen optionalen Verweis innerhalb eines Status List-Objekts auf einen Aggregations-Endpunkt, der die uris aller Status List Token dieses issuers auflistet. Ein verifier, der seinen Cache vorab füllen oder Listen entdecken möchte, die er noch nicht kennt, kann diesen Endpunkt abfragen, statt zu warten, bis eine credential eine davon nennt.
Quellen
Diese Seite dient nur zur Information und stellt keine Rechtsberatung dar. Für maßgebliche Hinweise konsultieren Sie bitte direkt die IETF-Spezifikation.