Status List-intrekking uitgelegd
Een verifier die net een credential heeft ontvangen, moet weten of de issuer er nog steeds achter staat. Token Status List beantwoordt dat zonder dat de verifier contact opneemt met de issuer over die specifieke credential: een status claim in de credential verwijst naar een compacte lijst, en één bit in die lijst geeft het antwoord.
De status claim in de credential
Een issuer die Token Status List ondersteunt, voegt bij uitgifte een status claim toe aan de credential. Deze bevat twee dingen: idx, de index die deze credential binnen de lijst heeft, en uri, het adres van de Status List Token waarin die index staat. Verder verandert er niets aan de credential; de claim is slechts een verwijzing.
Issuer
Wijst de credential een index toe en voegt een status claim toe
De claim wordt eenmalig toegevoegd, bij uitgifte, en verandert nooit meer gedurende de levensduur van de credential
Status claim (in de credential)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}De Status List Token ophalen
Bij presentatie haalt de verifier de uri op uit de status claim. Het antwoord is een ondertekende Status List Token: een JWT met een typ header van statuslist+jwt (of een CWT-equivalent), aangeboden als application/statuslist+jwt. De payload bevat de gecomprimeerde bitstring en meestal een ttl die aangeeft hoe lang de verifier het resultaat mag cachen voordat hij opnieuw moet ophalen.
Verifier
Leest idx en uri uit de status claim in de zojuist gepresenteerde credential
GET uri
Haalt de Status List Token op en cachet deze tot ttl seconden
Status List Token payload (antwoord)
{
"sub": "https://issuer.example/statuslists/employment-2026-q3",
"iat": 1789200000,
"exp": 1789804800,
"ttl": 43200,
"status_list": {
"bits": 2,
"lst": "eNrbuRgAAhcBXQ"
}
}sub herhaalt de eigen uri van de lijst, zodat een verifier kan bevestigen dat hij het juiste token heeft opgehaald. iat en exp begrenzen de geldigheid van het token zelf. ttl, in seconden, is de maximale tijd dat de verifier een gecachete kopie mag hergebruiken voordat hij de lijst opnieuw moet ophalen.
Het bit decoderen
lst is een byte-array, base64url-gecodeerd en gecomprimeerd met DEFLATE in het zlib-dataformaat, die de verifier eerst decomprimeert. bits geeft aan hoeveel bits elke credential in de lijst inneemt: 1, 2, 4 of 8. Bij bits: 2 bevindt credential nummer idx zich op byte idx * 2 / 8, en leest de verifier de twee bits op die offset om de statuswaarde te bepalen.
Uitgewerkt voorbeeld: idx 4271, bits: 2
- bit_offset = idx * bits = 4271 * 2 = 8542
- byte_index = bit_offset / 8 = 1067
- bit_in_byte = bit_offset % 8 = 6
De verifier leest byte 1067 van de gedecomprimeerde array, haalt de twee bits vanaf bit 6 eruit en vergelijkt het resultaat met de waardetabel hieronder.
| Waarde | Betekenis |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Applicatiespecifiek / gereserveerd |
De getoonde waarden gaan uit van bits: 2. Met bits: 1 passen alleen VALID (0) en INVALID (1); bits: 4 en bits: 8 laten meer ruimte vrij voor applicatiespecifieke waarden.
Waarom de lijst klein blijft
Praktische status lijsten bestaan grotendeels uit nullen, omdat de meeste credentials die een issuer ooit heeft uitgegeven nog steeds geldig zijn, en een reeks identieke bits comprimeert goed. DEFLATE-compressie over de ruwe bitstring zorgt ervoor dat een lijst met honderdduizenden credentials slechts een paar kilobyte groot blijft op de lijn, wat het praktisch maakt om de hele lijst op te halen in plaats van de issuer over één credential te vragen.
Aggregatie: lijsten vooraf ontdekken
Een issuer kan optioneel aggregation_uri toevoegen aan een Status List object, verwijzend naar een endpoint dat de uri's vermeldt van elk Status List Token dat hij publiceert. Een verifier die lijsten vooraf wil ophalen en cachen voordat hij ze nodig heeft, in plaats van elke lijst pas te ontdekken via de eerste credential die ernaar verwijst, kan dat endpoint gebruiken. Dit is optioneel; niets in de kernflow hierboven is hiervan afhankelijk.
Gerelateerde termen
Veelgestelde vragen
Haalt de verifier voor elke credential die hij controleert een aparte lijst op?
Nee, één Status List Token dekt elke credential die de issuer erin heeft opgenomen, mogelijk honderdduizenden. Een verifier haalt hetzelfde token één keer op en leest voor elke credential die hij controleert een ander bit, waarna hij de gecachete kopie tot ttl seconden hergebruikt voordat hij opnieuw ophaalt.
Kan de issuer zien welke credential een verifier heeft opgezocht?
Nee. De verifier downloadt de volledige gecomprimeerde bitstring in één verzoek en leest het benodigde bit lokaal uit, zodat het verzoek dat de issuer ziet geen index en geen credential-identifier bevat, alleen een GET voor de lijst zelf.
Wat is het verschil tussen suspended en invalid?
INVALID (0x01) is hoe het referentieregister van de specificatie een permanent ingetrokken credential aanduidt. SUSPENDED (0x02) is een aparte, omkeerbare status die een issuer ook kan instellen en later weer kan opheffen, bijvoorbeeld terwijl een geschil wordt onderzocht. Om ze te onderscheiden zijn minstens twee bits per item nodig (bits: 2), dus een Status List Token met bits: 1 kan alleen onderscheid maken tussen valid en invalid.
Waar dient de aggregation_uri voor?
Het is een optionele verwijzing binnen een Status List object naar een aggregatie-endpoint dat de uri's van elk Status List Token van die issuer vermeldt. Een verifier die zijn cache vooraf wil vullen, of lijsten wil ontdekken die hij nog niet heeft gezien, kan dat endpoint raadplegen in plaats van te wachten tot een credential er een noemt.
Bronnen
Deze pagina is informatief en vormt geen juridisch advies. Raadpleeg voor gezaghebbende richtlijnen rechtstreeks de IETF-specificatie.