Revoca con Status List spiegata
Un verificatore che ha appena ricevuto una credenziale deve sapere se l'emittente la sostiene ancora. Token Status List risponde a questa domanda senza che il verificatore contatti l'emittente riguardo a quella specifica credenziale: una dichiarazione status all'interno della credenziale punta a un elenco compatto, e un singolo bit di quell'elenco fornisce la risposta.
La dichiarazione status all'interno della credenziale
Un emittente che supporta Token Status List aggiunge una dichiarazione status alla credenziale al momento dell'emissione. Contiene due elementi: idx, l'indice che questa credenziale possiede all'interno dell'elenco, e uri, l'indirizzo dello Status List Token che lo contiene. Nient'altro nella credenziale cambia; la dichiarazione è solo un puntatore.
Emittente
Assegna alla credenziale un indice e vi incorpora una dichiarazione status
La dichiarazione viene aggiunta una sola volta, al momento dell'emissione, e non cambia mai per tutta la durata della credenziale
Dichiarazione status (all'interno della credenziale)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}Recupero dello Status List Token
Al momento della presentazione, il verificatore recupera l'uri indicato nella dichiarazione status. La risposta è uno Status List Token firmato: un JWT con intestazione typ pari a statuslist+jwt (o l'equivalente CWT), servito come application/statuslist+jwt. Il suo payload contiene la stringa di bit compressa e, di norma, un ttl che indica al verificatore per quanto tempo può memorizzare nella cache il risultato prima di recuperarlo di nuovo.
Verificatore
Legge idx e uri dalla dichiarazione status nella credenziale appena presentata
GET uri
Recupera lo Status List Token, memorizzandolo nella cache per un massimo di ttl secondi
Payload dello Status List Token (risposta)
{
"sub": "https://issuer.example/statuslists/employment-2026-q3",
"iat": 1789200000,
"exp": 1789804800,
"ttl": 43200,
"status_list": {
"bits": 2,
"lst": "eNrbuRgAAhcBXQ"
}
}sub ripete l'URI dell'elenco stesso, così un verificatore può confermare di aver recuperato il token corretto. iat ed exp delimitano la validità del token stesso. ttl, in secondi, è il tempo massimo per cui il verificatore può riutilizzare una copia in cache prima di dover recuperare di nuovo l'elenco.
Lettura del bit
lst è un array di byte, codificato in base64url e compresso con DEFLATE nel formato dati zlib, che il verificatore decomprime per primo. bits indica quanti bit occupa ciascuna credenziale nell'elenco: 1, 2, 4 o 8. Con bits: 2, la credenziale numero idx si trova al byte idx * 2 / 8, e il verificatore legge i due bit a quell'offset per ottenere il valore dello stato.
Esempio pratico: idx 4271, bits: 2
- bit_offset = idx * bits = 4271 * 2 = 8542
- byte_index = bit_offset / 8 = 1067
- bit_in_byte = bit_offset % 8 = 6
Il verificatore legge il byte 1067 dell'array decompresso, estrae i due bit a partire dal bit 6 e confronta il risultato con la tabella dei valori riportata di seguito.
| Valore | Significato |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Specifico dell'applicazione / riservato |
I valori mostrati presuppongono bits: 2. Con bits: 1 rientrano solo VALID (0) e INVALID (1); bits: 4 e bits: 8 lasciano più spazio libero per valori specifici dell'applicazione.
Perché l'elenco resta piccolo
Gli elenchi di stato reali sono per lo più composti da zeri, perché la maggior parte delle credenziali mai emesse da un emittente è ancora valida, e una sequenza di bit identici si comprime bene. La compressione DEFLATE applicata alla stringa di bit grezza è ciò che mantiene un elenco che copre centinaia di migliaia di credenziali entro pochi kilobyte in trasmissione, il che rende pratico recuperare l'intero elenco invece di interrogare l'emittente su una singola credenziale.
Aggregazione: scoprire gli elenchi in anticipo
Un emittente può facoltativamente aggiungere aggregation_uri a un oggetto Status List, indicando un endpoint che elenca gli URI di ogni Status List Token che pubblica. Un verificatore che vuole precaricare e memorizzare nella cache gli elenchi prima di averne bisogno, invece di scoprire ciascuno di essi dalla prima credenziale che lo referenzia, può usare quell'endpoint. Questo è facoltativo; nulla nel flusso principale sopra descritto dipende da esso.
Termini correlati
Domande frequenti
Il verificatore recupera un elenco separato per ogni credenziale che controlla?
No, un unico Status List Token copre tutte le credenziali che l'emittente vi ha inserito, potenzialmente centinaia di migliaia. Un verificatore recupera lo stesso token una sola volta e legge un bit diverso per ogni credenziale che controlla, poi riutilizza la copia salvata in cache per un massimo di ttl secondi prima di recuperarlo di nuovo.
L'emittente può sapere quale credenziale ha consultato un verificatore?
No. Il verificatore scarica l'intera stringa di bit compressa in un'unica richiesta e legge localmente il bit di cui ha bisogno, quindi la richiesta vista dall'emittente non contiene alcun indice né alcun identificativo della credenziale, solo una GET per l'elenco stesso.
Qual è la differenza tra suspended e invalid?
INVALID (0x01) è il modo in cui il registro di riferimento della specifica indica una credenziale revocata in modo permanente. SUSPENDED (0x02) è uno stato separato e reversibile che un emittente può anch'esso impostare e successivamente rimuovere, ad esempio mentre è in corso l'esame di una contestazione. Per distinguerli servono almeno due bit per voce (bits: 2), quindi uno Status List Token che usa bits: 1 può distinguere solo valid da invalid.
A cosa serve aggregation_uri?
È un puntatore opzionale all'interno di un oggetto Status List verso un endpoint di aggregazione che elenca gli URI di ogni Status List Token di quell'emittente. Un verificatore che vuole precaricare la propria cache in anticipo, oppure scoprire elenchi che non ha ancora incontrato, può interrogare quell'endpoint invece di aspettare che una credenziale ne indichi uno.
Fonti
Questa pagina è informativa e non costituisce consulenza legale. Per indicazioni autorevoli, consultare direttamente la specifica IETF.