Status List-tilbakekalling forklart
En kontrollør som nettopp har mottatt en legitimasjon trenger å vite om utstederen fortsatt står bak den. Token Status List svarer på dette uten at kontrolløren kontakter utstederen om nettopp den legitimasjonen: et status-krav i legitimasjonen peker til en kompakt liste, og én enkelt bit i den listen gir svaret.
Status-kravet i legitimasjonen
En utsteder som støtter Token Status List legger til et status-krav i legitimasjonen ved utstedelse. Det inneholder to ting: idx, indeksen denne legitimasjonen eier i listen, og uri, adressen til Status List Token som inneholder den. Ellers endres ingenting ved legitimasjonen; kravet er bare en peker.
Utsteder
Tildeler legitimasjonen en indeks og bygger inn et status-krav
Kravet legges til én gang, ved utstedelse, og endres aldri i legitimasjonens levetid
Status-krav (inne i legitimasjonen)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}Henting av Status List Token
Ved fremvisning henter kontrolløren uri-en fra status-kravet. Svaret er en signert Status List Token: en JWT med typ-header satt til statuslist+jwt (eller et CWT-tilsvar), servert som application/statuslist+jwt. Nyttelasten inneholder den komprimerte bitstrengen og som regel en ttl som forteller kontrolløren hvor lenge den kan mellomlagre resultatet før den må hente på nytt.
Kontrollør
Leser idx og uri fra status-kravet i legitimasjonen som nettopp ble fremvist
GET uri
Henter Status List Token og mellomlagrer den i opptil ttl sekunder
Nyttelast for Status List Token (svar)
{
"sub": "https://issuer.example/statuslists/employment-2026-q3",
"iat": 1789200000,
"exp": 1789804800,
"ttl": 43200,
"status_list": {
"bits": 2,
"lst": "eNrbuRgAAhcBXQ"
}
}sub gjentar listens egen URI slik at kontrolløren kan bekrefte at den hentet riktig token. iat og exp avgrenser tokenets egen gyldighet. ttl, i sekunder, er maksimal tid kontrolløren kan gjenbruke en mellomlagret kopi før den må hente listen på nytt.
Tolke biten
lst er et bytearray, base64url-kodet og komprimert med DEFLATE i zlib-dataformatet, som kontrolløren dekomprimerer først. bits angir hvor mange bit hver legitimasjon i listen opptar: 1, 2, 4 eller 8. Med bits: 2 ligger legitimasjon nummer idx i byte idx * 2 / 8, og kontrolløren leser de to bitene på den posisjonen for å få statusverdien.
Eksempel: idx 4271, bits: 2
- bit_offset = idx * bits = 4271 * 2 = 8542
- byte_index = bit_offset / 8 = 1067
- bit_in_byte = bit_offset % 8 = 6
Kontrolløren leser byte 1067 i det dekomprimerte arrayet, henter ut de to bitene fra og med bit 6, og sammenligner resultatet med verditabellen under.
| Verdi | Betydning |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Applikasjonsspesifikk / reservert |
Verdiene som vises forutsetter bits: 2. Med bits: 1 er det bare plass til VALID (0) og INVALID (1); bits: 4 og bits: 8 gir mer plass til applikasjonsspesifikke verdier.
Hvorfor listen forblir liten
Reelle statuslister består stort sett av nuller, fordi de fleste legitimasjonene en utsteder noensinne har delt ut fortsatt er gyldige, og en rekke identiske biter komprimeres godt. DEFLATE-komprimering av den rå bitstrengen er det som holder en liste som dekker hundretusener av legitimasjoner nede på noen få kilobyte ved overføring, noe som gjør det praktisk å hente hele listen i stedet for å spørre utstederen om én legitimasjon.
Aggregering: oppdage lister på forhånd
En utsteder kan valgfritt legge til aggregation_uri i et Status List-objekt, som peker til et endepunkt som lister opp URI-ene til alle Status List Token den publiserer. En kontrollør som ønsker å forhåndshente og mellomlagre lister før den trenger dem, i stedet for å oppdage hver enkelt fra den første legitimasjonen som refererer til den, kan bruke det endepunktet i stedet. Dette er valgfritt; ingenting i kjerneflyten over avhenger av det.
Relaterte begreper
Ofte stilte spørsmål
Henter kontrolløren en egen liste for hver legitimasjon den sjekker?
Nei, én Status List Token dekker alle legitimasjoner utstederen har lagt inn i den, potensielt hundretusener. En kontrollør henter det samme tokenet én gang og leser en annen bit for hver legitimasjon den sjekker, og gjenbruker deretter den mellomlagrede kopien i opptil ttl sekunder før den henter på nytt.
Kan utstederen se hvilken legitimasjon en kontrollør slo opp?
Nei. Kontrolløren laster ned hele den komprimerte bitstrengen i én forespørsel og leser biten den trenger lokalt, så forespørselen utstederen ser inneholder verken indeks eller identifikator for legitimasjonen, bare en GET for selve listen.
Hva er forskjellen mellom suspended og invalid?
INVALID (0x01) er slik spesifikasjonens referanseregister merker en permanent tilbakekalt legitimasjon. SUSPENDED (0x02) er en separat, reversibel tilstand som en utsteder også kan sette og senere fjerne, for eksempel mens en tvist etterforskes. Å skille dem krever minst to bit per oppføring (bits: 2), så en Status List Token som bruker bits: 1 kan bare skille valid fra invalid.
Hva brukes aggregation_uri til?
Det er en valgfri peker inne i et Status List-objekt til et aggregeringsendepunkt som lister opp URI-ene til alle Status List Token fra den utstederen. En kontrollør som ønsker å varme opp cachen sin på forhånd, eller oppdage lister den ikke har sett ennå, kan hente det endepunktet i stedet for å vente på at en legitimasjon nevner en.
Kilder
Denne siden er informativ og utgjør ikke juridisk rådgivning. For autoritativ veiledning, se direkte i IETF-spesifikasjonen.