Revocarea prin Status List explicată
Un verificator care tocmai a primit o acreditare trebuie să știe dacă emitentul încă o susține. Token Status List răspunde la aceasta fără ca verificatorul să contacteze emitentul cu privire la acea acreditare specifică: o declarație status din interiorul acreditării indică o listă compactă, iar un singur bit din acea listă poartă răspunsul.
Declarația status din interiorul acreditării
Un emitent care acceptă Token Status List adaugă o declarație status acreditării în momentul emiterii. Aceasta conține două elemente: idx, indexul pe care această acreditare îl deține în listă, și uri, adresa Status List Token care o conține. Nimic altceva legat de acreditare nu se schimbă; declarația este doar un pointer.
Emitent
Atribuie acreditării un index și încorporează o declarație status
Declarația este adăugată o singură dată, la emitere, și nu se schimbă niciodată pe durata de viață a acreditării
Declarația status (în interiorul acreditării)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}Preluarea Status List Token
În momentul prezentării, verificatorul preia uri din declarația status. Răspunsul este un Status List Token semnat: un JWT cu un header typ de statuslist+jwt (sau un echivalent CWT), livrat ca application/statuslist+jwt. Payload-ul său conține șirul de biți comprimat și, de obicei, un ttl care indică verificatorului cât timp poate păstra rezultatul în cache înainte de a-l prelua din nou.
Verificator
Citește idx și uri din declarația status a acreditării tocmai prezentate
GET uri
Preia Status List Token, păstrându-l în cache timp de până la ttl secunde
Payload-ul Status List Token (răspuns)
{
"sub": "https://issuer.example/statuslists/employment-2026-q3",
"iat": 1789200000,
"exp": 1789804800,
"ttl": 43200,
"status_list": {
"bits": 2,
"lst": "eNrbuRgAAhcBXQ"
}
}sub repetă propriul URI al listei, astfel încât un verificator poate confirma că a preluat tokenul corect. iat și exp delimitează valabilitatea proprie a tokenului. ttl, în secunde, este timpul maxim în care verificatorul poate reutiliza o copie din cache înainte de a trebui să preia din nou lista.
Decodarea bitului
lst este un array de octeți, codificat base64url și comprimat cu DEFLATE în formatul de date zlib, pe care verificatorul îl decomprimă mai întâi. bits indică câți biți ocupă fiecare acreditare din listă: 1, 2, 4 sau 8. Cu bits: 2, acreditarea cu numărul idx se află la octetul idx * 2 / 8, iar verificatorul citește cei doi biți de la acel offset pentru a obține valoarea stării.
Exemplu rezolvat: idx 4271, bits: 2
- bit_offset = idx * bits = 4271 * 2 = 8542
- byte_index = bit_offset / 8 = 1067
- bit_in_byte = bit_offset % 8 = 6
Verificatorul citește octetul 1067 din array-ul decomprimat, extrage cei doi biți începând de la bitul 6, și compară rezultatul cu tabelul de valori de mai jos.
| Valoare | Semnificație |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Specific aplicației / rezervat |
Valorile afișate presupun bits: 2. Cu bits: 1 încap doar VALID (0) și INVALID (1); bits: 4 și bits: 8 lasă mai mult spațiu liber pentru valori specifice aplicației.
De ce lista rămâne mică
În practică, listele de status sunt în mare parte zerouri, deoarece majoritatea acreditărilor pe care un emitent le-a eliberat vreodată sunt încă valide, iar o secvență de biți identici se comprimă bine. Compresia DEFLATE aplicată șirului brut de biți este cea care menține o listă ce acoperă sute de mii de acreditări la doar câțiva kilobytes pe rețea, ceea ce face practică preluarea întregii liste, în loc să se întrebe emitentul despre o singură acreditare.
Agregare: descoperirea listelor din timp
Un emitent poate adăuga opțional aggregation_uri unui obiect Status List, indicând un punct final care listează URI-urile tuturor Status List Token pe care le publică. Un verificator care dorește să preia și să pună în cache liste din timp, înainte de a avea nevoie de ele, în loc să descopere fiecare listă din prima acreditare care o referențiază, poate folosi acel punct final. Acest lucru este opțional; nimic din fluxul principal de mai sus nu depinde de el.
Termeni conexi
Întrebări frecvente
Verificatorul preia o listă separată pentru fiecare acreditare pe care o verifică?
Nu, un singur Status List Token acoperă toate acreditările pe care emitentul le-a inclus în el, potențial sute de mii. Un verificator preia același token o singură dată și citește un bit diferit pentru fiecare acreditare pe care o verifică, apoi reutilizează copia din cache timp de până la ttl secunde înainte de a o prelua din nou.
Emitentul poate afla ce acreditare a verificat un verificator?
Nu. Verificatorul descarcă întregul șir de biți comprimat într-o singură cerere și citește local bitul de care are nevoie, astfel încât cererea văzută de emitent nu conține niciun index și niciun identificator de acreditare, ci doar un GET către lista în sine.
Care este diferența dintre suspended și invalid?
INVALID (0x01) este modul în care registrul de referință al specificației marchează o acreditare revocată permanent. SUSPENDED (0x02) este o stare separată, reversibilă, pe care un emitent o poate seta și, ulterior, elimina, de exemplu în timp ce se investighează o dispută. Diferențierea lor necesită cel puțin doi biți per intrare (bits: 2), astfel încât un Status List Token care folosește bits: 1 poate distinge doar valid de invalid.
La ce folosește aggregation_uri?
Este un pointer opțional în interiorul unui obiect Status List către un punct final de agregare care listează URI-urile tuturor Status List Token ale emitentului respectiv. Un verificator care dorește să își încălzească din timp cache-ul sau să descopere liste pe care nu le-a văzut încă poate prelua acel punct final în loc să aștepte ca o acreditare să indice una.
Surse
Această pagină are caracter informativ și nu constituie consultanță juridică. Pentru îndrumări autorizate, consultați direct specificația IETF.