Preklic Status List pojasnjen
Preveritelj, ki je pravkar prejel poverilo, mora vedeti, ali izdajatelj še vedno stoji za njim. Token Status List na to odgovori, ne da bi preveritelj kontaktiral izdajatelja glede tega konkretnega poverila: status trditev znotraj poverila kaže na kompakten seznam, en sam bit v tem seznamu pa nosi odgovor.
Status trditev znotraj poverila
Izdajatelj, ki podpira Token Status List, ob izdaji poverilu doda status trditev. Ta nosi dve stvari: idx, indeks, ki pripada temu poverilu znotraj seznama, in uri, naslov Status List Tokena, ki ga hrani. Pri poverilu se nič drugega ne spremeni, trditev je le kazalec.
Izdajatelj
Poverilu dodeli indeks in vgradi status trditev
Trditev je dodana enkrat, ob izdaji, in se nikoli ne spremeni v celotni življenjski dobi poverila
Status trditev (znotraj poverila)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}Pridobivanje Status List Tokena
Ob predložitvi preveritelj pridobi uri iz status trditve. Odgovor je podpisan Status List Token: JWT z glavo typ, nastavljeno na statuslist+jwt (ali enakovreden CWT), posredovan kot application/statuslist+jwt. Njegov payload nosi stisnjen bitni niz in običajno tudi ttl, ki preveritelju pove, kako dolgo lahko rezultat predpomni, preden ga mora znova pridobiti.
Preveritelj
Iz status trditve v pravkar predloženem poverilu prebere idx in uri
GET uri
Pridobi Status List Token in ga predpomni za največ ttl sekund
Payload Status List Tokena (odgovor)
{
"sub": "https://issuer.example/statuslists/employment-2026-q3",
"iat": 1789200000,
"exp": 1789804800,
"ttl": 43200,
"status_list": {
"bits": 2,
"lst": "eNrbuRgAAhcBXQ"
}
}sub ponovi lastni URI seznama, tako da preveritelj lahko potrdi, da je pridobil pravi token. iat in exp omejujeta veljavnost samega tokena. ttl, v sekundah, je najdaljši čas, ko lahko preveritelj ponovno uporabi predpomnjeno kopijo, preden mora seznam znova pridobiti.
Dekodiranje bita
lst je bajtno polje, kodirano v base64url in stisnjeno z DEFLATE v podatkovni obliki zlib, ki ga preveritelj najprej razširi. bits pove, koliko bitov zaseda vsako poverilo v seznamu: 1, 2, 4 ali 8. Pri bits: 2 se poverilo s številko idx nahaja v bajtu idx * 2 / 8, preveritelj pa na tem odmiku prebere dva bita, da dobi vrednost stanja.
Praktičen primer: idx 4271, bits: 2
- bit_offset = idx * bits = 4271 * 2 = 8542
- byte_index = bit_offset / 8 = 1067
- bit_in_byte = bit_offset % 8 = 6
Preveritelj prebere bajt 1067 razširjenega polja, izlušči dva bita, ki se začneta pri bitu 6, in rezultat primerja s spodnjo tabelo vrednosti.
| Vrednost | Pomen |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Aplikacijsko specifično / rezervirano |
Prikazane vrednosti predpostavljajo bits: 2. Pri bits: 1 se prilegata le VALID (0) in INVALID (1); bits: 4 in bits: 8 puščata več prostora za aplikacijsko specifične vrednosti.
Zakaj seznam ostane majhen
Dejanski statusni seznami so večinoma sestavljeni iz ničel, ker je večina poveril, ki jih je izdajatelj kdajkoli izdal, še vedno veljavnih, zaporedje enakih bitov pa se dobro stisne. Stiskanje DEFLATE surovega bitnega niza je tisto, kar ohranja seznam, ki pokriva na stotine tisoč poveril, na le nekaj kilobajtih pri prenosu, zaradi česar je pridobivanje celotnega seznama, namesto spraševanja izdajatelja o enem poverilu, praktično.
Agregacija: vnaprejšnje odkrivanje seznamov
Izdajatelj lahko neobvezno doda aggregation_uri v objekt Status List, ki kaže na končno točko, ki navaja URI-je vseh Status List Tokenov, ki jih objavlja. Preveritelj, ki želi sezname vnaprej pridobiti in predpomniti, preden jih potrebuje, namesto da bi vsakega odkril iz prvega poverila, ki nanj kaže, lahko namesto tega uporabi to končno točko. To je neobvezno, osnovni potek, opisan zgoraj, od tega ni odvisen.
Sorodni izrazi
Pogosta vprašanja
Ali preveritelj za vsako poverilo, ki ga preverja, pridobi ločen seznam?
Ne, en Status List Token pokriva vsa poverila, ki jih je izdajatelj vanj vključil, potencialno na stotine tisoč. Preveritelj enkrat pridobi isti token in za vsako preverjano poverilo prebere drug bit, nato pa do ttl sekund ponovno uporablja predpomnjeno kopijo, preden jo znova pridobi.
Ali lahko izdajatelj ugotovi, katero poverilo je preveritelj preverjal?
Ne. Preveritelj v enem zahtevku prenese celoten stisnjen bitni niz in potreben bit prebere lokalno, zato zahtevek, ki ga vidi izdajatelj, ne vsebuje ne indeksa ne identifikatorja poverila, temveč le GET za sam seznam.
Kakšna je razlika med stanjema suspended in invalid?
INVALID (0x01) je oznaka, s katero referenčni register specifikacije označi trajno preklicano poverilo. SUSPENDED (0x02) je ločeno, povratno stanje, ki ga lahko izdajatelj prav tako nastavi in kasneje odpravi, na primer med obravnavo spora. Za razlikovanje med njima sta potrebna vsaj dva bita na vnos (bits: 2), zato lahko Status List Token z bits: 1 loči le veljavno od neveljavnega.
Čemu služi aggregation_uri?
To je neobvezen kazalec znotraj objekta Status List na agregacijsko končno točko, ki navaja URI-je vseh Status List Tokenov tega izdajatelja. Preveritelj, ki želi vnaprej ogreti svoj predpomnilnik ali odkriti sezname, ki jih še ni videl, lahko namesto čakanja, da mu ga navede poverilo, pridobi to končno točko.
Viri
Ta stran je informativne narave in ne predstavlja pravnega nasveta. Za avtoritativne napotke se obrnite neposredno na specifikacijo IETF.