Status List-återkallelse förklarad
En kontrollant som just tagit emot en legitimation behöver veta om utfärdaren fortfarande står bakom den. Token Status List besvarar detta utan att kontrollanten kontaktar utfärdaren om just den legitimationen: ett status-anspråk inuti legitimationen pekar mot en kompakt lista, och en enda bit i den listan ger svaret.
Status-anspråket inuti legitimationen
En utfärdare som stöder Token Status List lägger till ett status-anspråk i legitimationen vid utfärdandet. Det innehåller två saker: idx, det index som denna legitimation äger i listan, och uri, adressen till den Status List Token som innehåller den. Inget annat i legitimationen ändras; anspråket är bara en pekare.
Utfärdare
Tilldelar legitimationen ett index och bäddar in ett status-anspråk
Anspråket läggs till en gång, vid utfärdandet, och ändras aldrig under legitimationens livstid
Status-anspråk (inuti legitimationen)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}Att hämta Status List Token
Vid uppvisning hämtar kontrollanten uri:n från status-anspråket. Svaret är en signerad Status List Token: en JWT med en typ-header satt till statuslist+jwt (eller en motsvarande CWT), levererad som application/statuslist+jwt. Dess payload innehåller den komprimerade bitsträngen och vanligtvis en ttl som talar om för kontrollanten hur länge den får cacha resultatet innan den hämtar igen.
Kontrollant
Läser idx och uri från status-anspråket i den precis uppvisade legitimationen
GET uri
Hämtar Status List Token och cachar den i upp till ttl sekunder
Status List Token-payload (svar)
{
"sub": "https://issuer.example/statuslists/employment-2026-q3",
"iat": 1789200000,
"exp": 1789804800,
"ttl": 43200,
"status_list": {
"bits": 2,
"lst": "eNrbuRgAAhcBXQ"
}
}sub upprepar listans egen URI så att en kontrollant kan bekräfta att den hämtade rätt token. iat och exp avgränsar tokenens egen giltighet. ttl, i sekunder, är den längsta tid kontrollanten får återanvända en cachad kopia innan den måste hämta listan igen.
Att tolka biten
lst är en bytearray, base64url-kodad och komprimerad med DEFLATE i zlib-dataformatet, som kontrollanten packar upp först. bits anger hur många bitar varje legitimation i listan upptar: 1, 2, 4 eller 8. Med bits: 2 finns legitimation nummer idx i byte idx * 2 / 8, och kontrollanten läser de två bitarna vid den positionen för att få statusvärdet.
Genomräknat exempel: idx 4271, bits: 2
- bit_offset = idx * bits = 4271 * 2 = 8542
- byte_index = bit_offset / 8 = 1067
- bit_in_byte = bit_offset % 8 = 6
Kontrollanten läser byte 1067 i den uppackade arrayen, hämtar ut de två bitarna med start vid bit 6 och jämför resultatet med värdetabellen nedan.
| Värde | Betydelse |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Applikationsspecifik / reserverad |
Värdena som visas förutsätter bits: 2. Med bits: 1 ryms bara VALID (0) och INVALID (1); bits: 4 och bits: 8 lämnar mer utrymme för applikationsspecifika värden.
Varför listan förblir liten
Verkliga statuslistor består till största delen av nollor, eftersom de flesta legitimationer en utfärdare någonsin har utfärdat fortfarande är giltiga, och en följd av identiska bitar komprimeras bra. DEFLATE-komprimering av den råa bitsträngen är det som håller en lista som täcker hundratusentals legitimationer nere på några kilobyte vid överföring, vilket gör det praktiskt att hämta hela listan i stället för att fråga utfärdaren om en enskild legitimation.
Aggregering: att upptäcka listor i förväg
En utfärdare kan valfritt lägga till aggregation_uri i ett Status List-objekt, som pekar mot en slutpunkt som listar URI:erna för varje Status List Token den publicerar. En kontrollant som vill förhämta och cacha listor innan den behöver dem, i stället för att upptäcka var och en från den första legitimation som refererar till den, kan använda den slutpunkten. Detta är valfritt; inget i kärnflödet ovan beror på det.
Relaterade termer
Vanliga frågor
Hämtar kontrollanten en separat lista för varje legitimation den kontrollerar?
Nej, en enda Status List Token täcker alla legitimationer utfärdaren har lagt in i den, potentiellt hundratusentals. En kontrollant hämtar samma token en gång och läser en annan bit för varje legitimation den kontrollerar, och återanvänder sedan den cachade kopian i upp till ttl sekunder innan den hämtar igen.
Kan utfärdaren se vilken legitimation en kontrollant slog upp?
Nej. Kontrollanten laddar ner hela den komprimerade bitsträngen i en enda förfrågan och läser biten den behöver lokalt, så förfrågan som utfärdaren ser innehåller varken index eller legitimationsidentifierare, bara en GET för själva listan.
Vad är skillnaden mellan suspended och invalid?
INVALID (0x01) är hur specifikationens referensregister märker en permanent återkallad legitimation. SUSPENDED (0x02) är ett separat, reversibelt tillstånd som en utfärdare också kan sätta och senare ta bort, till exempel medan en tvist utreds. Att skilja dem åt kräver minst två bitar per post (bits: 2), så en Status List Token som använder bits: 1 kan bara skilja valid från invalid.
Vad används aggregation_uri till?
Det är en valfri pekare inuti ett Status List-objekt till en aggregeringsslutpunkt som listar URI:erna för varje Status List Token från den utfärdaren. En kontrollant som vill värma upp sin cache i förväg, eller upptäcka listor den inte sett ännu, kan hämta den slutpunkten i stället för att vänta på att en legitimation namnger en.
Källor
Denna sida är informativ och utgör inte juridisk rådgivning. För auktoritativ vägledning, se direkt i IETF-specifikationen.