Status List-tilbagekaldelse forklaret
En verifikator, der lige har modtaget en credential, skal vide, om udstederen stadig står bag den. Token Status List besvarer det, uden at verifikatoren kontakter udstederen om netop den credential: et status-claim inde i credentialen peger på en kompakt liste, og en enkelt bit i den liste bærer svaret.
Status-claimet inde i credentialen
En udsteder, der understøtter Token Status List, tilføjer et status-claim til credentialen på udstedelsestidspunktet. Det indeholder to ting: idx, det indeks, denne credential har i listen, og uri, adressen på det Status List Token, der indeholder det. Ellers ændres intet ved credentialen; claimet er blot en pointer.
Udsteder
Tildeler credentialen et indeks og indlejrer et status-claim
Claimet tilføjes én gang, ved udstedelsen, og ændres aldrig i credentialens levetid
Status-claim (inde i credentialen)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}Hentning af Status List Token
På fremvisningstidspunktet henter verifikatoren uri'en fra status-claimet. Svaret er et signeret Status List Token: en JWT med en typ-header på statuslist+jwt (eller et CWT-tilsvarende), leveret som application/statuslist+jwt. Dets payload indeholder den komprimerede bitstring og som regel en ttl, der fortæller verifikatoren, hvor længe den må cache resultatet, før den skal hente igen.
Verifikator
Læser idx og uri fra status-claimet i den netop fremviste credential
GET uri
Henter Status List Token og cacher det i op til 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 gentager listens egen URI, så en verifikator kan bekræfte, at den hentede det rigtige token. iat og exp afgrænser tokenets egen gyldighed. ttl, i sekunder, er den maksimale tid, verifikatoren må genbruge en cachet kopi, før den skal hente listen igen.
Afkodning af bitten
lst er et byte-array, base64url-kodet og komprimeret med DEFLATE i zlib-dataformatet, som verifikatoren først dekomprimerer. bits angiver, hvor mange bits hver credential i listen fylder: 1, 2, 4 eller 8. Med bits: 2 ligger credential nummer idx i byte idx * 2 / 8, og verifikatoren læser de to bits på det offset for at få statusværdien.
Gennemregnet 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
Verifikatoren læser byte 1067 i det dekomprimerede array, udtrækker de to bits fra bit 6, og sammenligner resultatet med værditabellen nedenfor.
| Værdi | Betydning |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Applikationsspecifik / reserveret |
Værdierne vist forudsætter bits: 2. Med bits: 1 er der kun plads til VALID (0) og INVALID (1); bits: 4 og bits: 8 giver mere plads til applikationsspecifikke værdier.
Hvorfor listen forbliver lille
Status lister i praksis er for det meste nuller, fordi de fleste credentials, en udsteder nogensinde har udstedt, stadig er gyldige, og en række ens bits komprimerer godt. DEFLATE-komprimering af den rå bitstring er det, der holder en liste, der dækker hundredtusindvis af credentials, nede på et par kilobyte på ledningen, hvilket er det, der gør det praktisk at hente hele listen i stedet for at spørge udstederen om én credential.
Aggregering: at opdage lister på forhånd
En udsteder kan valgfrit tilføje aggregation_uri til et Status List-objekt, der peger på et endpoint, som lister URI'erne for hvert Status List Token, den udgiver. En verifikator, der vil forudhente og cache lister, før den får brug for dem, i stedet for at opdage hver enkelt fra den første credential, der refererer til den, kan bruge det endpoint i stedet. Dette er valgfrit; intet i kerneflowet ovenfor afhænger af det.
Relaterede begreber
Ofte stillede spørgsmål
Henter verifikatoren en separat liste for hver credential, den kontrollerer?
Nej, ét Status List Token dækker alle credentials, udstederen har lagt i det, potentielt hundredtusindvis. En verifikator henter det samme token én gang og læser en anden bit for hver credential, den kontrollerer, og genbruger derefter den cachede kopi i op til ttl sekunder, før den henter igen.
Kan udstederen se, hvilken credential en verifikator har slået op?
Nej. Verifikatoren downloader hele den komprimerede bitstring i én forespørgsel og læser den bit, den har brug for, lokalt, så den forespørgsel, udstederen ser, hverken indeholder indeks eller credential-id, kun et GET til selve listen.
Hvad er forskellen på suspended og invalid?
INVALID (0x01) er den måde, specifikationens referenceregister markerer en permanent tilbagekaldt credential på. SUSPENDED (0x02) er en separat, reversibel tilstand, som en udsteder også kan sætte og senere fjerne igen, for eksempel mens en tvist undersøges. At skelne mellem dem kræver mindst to bits pr. post (bits: 2), så et Status List Token, der bruger bits: 1, kan kun skelne mellem gyldig og ugyldig.
Hvad bruges aggregation_uri til?
Det er en valgfri pointer inde i et Status List-objekt til et aggregeringsendpoint, der lister URI'erne for hvert Status List Token fra den pågældende udsteder. En verifikator, der vil varme sin cache op på forhånd eller opdage lister, den endnu ikke har set, kan hente det endpoint i stedet for at vente på, at en credential angiver et.
Kilder
Denne side er informativ og udgør ikke juridisk rådgivning. For autoritativ vejledning, se specifikationen fra IETF direkte.