Objašnjenje opoziva putem Status List
Verifikator koji je upravo primio vjerodajnicu treba znati stoji li izdavatelj i dalje iza nje. Token Status List na to odgovara bez potrebe da verifikator kontaktira izdavatelja o toj konkretnoj vjerodajnici: tvrdnja o statusu unutar vjerodajnice upućuje na kompaktan popis, a jedan bit u tom popisu nosi odgovor.
Tvrdnja o statusu unutar vjerodajnice
Izdavatelj koji podržava Token Status List u trenutku izdavanja dodaje vjerodajnici tvrdnju o statusu. Ona sadrži dvije stvari: idx, indeks koji ta vjerodajnica ima unutar popisa, i uri, adresu Status List Token vrijednosti koja ga sadrži. Ništa se drugo na vjerodajnici ne mijenja; tvrdnja je samo pokazivač.
Izdavatelj
Vjerodajnici dodjeljuje indeks i ugrađuje tvrdnju o statusu
Tvrdnja se dodaje jednom, prilikom izdavanja, i nikada se ne mijenja tijekom vijeka trajanja vjerodajnice
Tvrdnja o statusu (unutar vjerodajnice)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}Dohvaćanje Status List Token vrijednosti
U trenutku predstavljanja verifikator dohvaća uri iz tvrdnje o statusu. Odgovor je potpisani Status List Token: JWT sa zaglavljem typ postavljenim na statuslist+jwt (ili ekvivalent u obliku CWT), poslužen kao application/statuslist+jwt. Njegov sadržaj nosi komprimirani niz bitova i, obično, ttl koji verifikatoru govori koliko dugo smije predmemorirati rezultat prije ponovnog dohvaćanja.
Verifikator
Iz tvrdnje o statusu u upravo predstavljenoj vjerodajnici čita idx i uri
GET uri
Dohvaća Status List Token, spremajući ga u predmemoriju do ttl sekundi
Sadržaj Status List Token vrijednosti (odgovor)
{
"sub": "https://issuer.example/statuslists/employment-2026-q3",
"iat": 1789200000,
"exp": 1789804800,
"ttl": 43200,
"status_list": {
"bits": 2,
"lst": "eNrbuRgAAhcBXQ"
}
}sub ponavlja vlastiti URI popisa kako bi verifikator mogao potvrditi da je dohvatio ispravan token. iat i exp ograničavaju valjanost samog tokena. ttl, u sekundama, najduže je vrijeme tijekom kojeg verifikator smije ponovno koristiti predmemoriranu kopiju prije nego što ponovno mora dohvatiti popis.
Dekodiranje bita
lst je niz bajtova, kodiran u base64url i komprimiran algoritmom DEFLATE u formatu podataka zlib, koji verifikator prvo dekomprimira. bits označava koliko bitova zauzima svaka vjerodajnica na popisu: 1, 2, 4 ili 8. Uz bits: 2, vjerodajnica s brojem idx nalazi se na bajtu idx * 2 / 8, a verifikator čita dva bita na tom pomaku kako bi dobio vrijednost statusa.
Riješeni primjer: idx 4271, bits: 2
- bit_offset = idx * bits = 4271 * 2 = 8542
- byte_index = bit_offset / 8 = 1067
- bit_in_byte = bit_offset % 8 = 6
Verifikator čita bajt 1067 dekomprimiranog niza, izdvaja dva bita počevši od bita 6 i uspoređuje rezultat s tablicom vrijednosti u nastavku.
| Vrijednost | Značenje |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Specifično za aplikaciju / rezervirano |
Prikazane vrijednosti pretpostavljaju bits: 2. Uz bits: 1 stane samo VALID (0) i INVALID (1); bits: 4 i bits: 8 ostavljaju više prostora za vrijednosti specifične za aplikaciju.
Zašto popis ostaje malen
Stvarni popisi statusa uglavnom se sastoje od nula, jer je većina vjerodajnica koje je izdavatelj ikada izdao i dalje valjana, a niz identičnih bitova dobro se komprimira. Upravo DEFLATE kompresija sirovog niza bitova omogućuje da popis koji obuhvaća stotine tisuća vjerodajnica na mreži zauzima svega nekoliko kilobajta, što dohvaćanje cijelog popisa, umjesto pitanja izdavatelju o pojedinoj vjerodajnici, čini praktičnim.
Agregacija: unaprijedno otkrivanje popisa
Izdavatelj može neobavezno dodati aggregation_uri objektu Status List, koji upućuje na krajnju točku koja navodi URI-je svih Status List Token vrijednosti koje objavljuje. Verifikator koji želi unaprijed dohvatiti i predmemorirati popise prije nego što mu zatrebaju, umjesto da svaki otkriva putem prve vjerodajnice koja ga referencira, može umjesto toga koristiti tu krajnju točku. Ovo je neobavezno; ništa u osnovnom tijeku opisanom iznad o tome ne ovisi.
Povezani pojmovi
Često postavljana pitanja
Dohvaća li verifikator zaseban popis za svaku vjerodajnicu koju provjerava?
Ne, jedan Status List Token obuhvaća sve vjerodajnice koje je izdavatelj u njega uključio, potencijalno stotine tisuća. Verifikator jednom dohvati isti token i za svaku vjerodajnicu koju provjerava čita drugi bit, a zatim ponovno koristi predmemoriranu kopiju do ttl sekundi prije nego što je ponovno dohvati.
Može li izdavatelj saznati koju je vjerodajnicu verifikator provjeravao?
Ne. Verifikator preuzima cijeli komprimirani niz bitova u jednom zahtjevu i lokalno čita bit koji mu je potreban, tako da zahtjev koji izdavatelj vidi ne sadrži ni indeks ni identifikator vjerodajnice, već samo GET za sam popis.
Koja je razlika između suspendirano i nevažeće?
INVALID (0x01) je oznaka koju referentni registar specifikacije koristi za trajno opozvanu vjerodajnicu. SUSPENDED (0x02) je zaseban, reverzibilan status koji izdavatelj također može postaviti i kasnije ukloniti, primjerice dok se istražuje spor. Razlikovanje njih dvoje zahtijeva najmanje dva bita po unosu (bits: 2), pa Status List Token koji koristi bits: 1 može razlikovati samo valjano od nevažećeg.
Čemu služi aggregation_uri?
To je neobavezan pokazivač unutar objekta Status List na krajnju točku za agregaciju koja navodi URI-je svih Status List Token vrijednosti tog izdavatelja. Verifikator koji unaprijed želi zagrijati predmemoriju ili otkriti popise koje još nije vidio može, umjesto čekanja na vjerodajnicu koja ga imenuje, dohvatiti tu krajnju točku.
Izvori
Ova stranica ima informativni karakter i ne predstavlja pravni savjet. Za mjerodavne smjernice izravno se obratite IETF specifikaciji.