Révocation Status List expliquée
Un verifier qui vient de recevoir une credential doit savoir si l'issuer la soutient toujours. Token Status List répond à cela sans que le verifier contacte l'issuer au sujet de cette credential précise : un status claim à l'intérieur de la credential pointe vers une liste compacte, et un seul bit de cette liste porte la réponse.
Le status claim à l'intérieur de la credential
Un issuer qui prend en charge Token Status List ajoute un status claim à la credential au moment de l'émission. Il comporte deux éléments : idx, l'index que possède cette credential dans la liste, et uri, l'adresse du Status List Token qui le contient. Rien d'autre ne change dans la credential ; le claim n'est qu'un pointeur.
Issuer
Attribue un index à la credential et y intègre un status claim
Le claim est ajouté une seule fois, à l'émission, et ne change jamais pendant toute la durée de vie de la credential
Status claim (à l'intérieur de la credential)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}Récupération du Status List Token
Au moment de la présentation, le verifier récupère l'uri indiquée dans le status claim. La réponse est un Status List Token signé : un JWT avec un en-tête typ égal à statuslist+jwt (ou un équivalent CWT), servi en tant que application/statuslist+jwt. Son payload contient la chaîne de bits compressée et, en général, un ttl qui indique combien de temps le verifier peut mettre le résultat en cache avant de le récupérer à nouveau.
Verifier
Lit idx et uri dans le status claim de la credential qui vient d'être présentée
GET uri
Récupère le Status List Token et le met en cache jusqu'à ttl secondes
Payload du Status List Token (réponse)
{
"sub": "https://issuer.example/statuslists/employment-2026-q3",
"iat": 1789200000,
"exp": 1789804800,
"ttl": 43200,
"status_list": {
"bits": 2,
"lst": "eNrbuRgAAhcBXQ"
}
}sub reprend l'uri propre de la liste afin qu'un verifier puisse confirmer qu'il a récupéré le bon token. iat et exp délimitent la validité du token lui-même. ttl, en secondes, est le temps maximal pendant lequel le verifier peut réutiliser une copie en cache avant de devoir récupérer la liste à nouveau.
Décodage du bit
lst est un tableau d'octets, encodé en base64url et compressé avec DEFLATE au format de données zlib, que le verifier décompresse en premier. bits indique combien de bits chaque credential occupe dans la liste : 1, 2, 4 ou 8. Avec bits : 2, la credential numéro idx se trouve à l'octet idx * 2 / 8, et le verifier lit les deux bits à cet offset pour obtenir la valeur de statut.
Exemple détaillé : idx 4271, bits : 2
- bit_offset = idx * bits = 4271 * 2 = 8542
- byte_index = bit_offset / 8 = 1067
- bit_in_byte = bit_offset % 8 = 6
Le verifier lit l'octet 1067 du tableau décompressé, en extrait les deux bits à partir du bit 6, puis compare le résultat au tableau de valeurs ci-dessous.
| Valeur | Signification |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Spécifique à l'application / réservé |
Les valeurs indiquées supposent bits : 2. Avec bits : 1, seuls VALID (0) et INVALID (1) sont possibles ; bits : 4 et bits : 8 laissent plus de place libre pour des valeurs spécifiques à l'application.
Pourquoi la liste reste petite
En pratique, les status lists sont majoritairement composées de zéros, car la plupart des credentials qu'un issuer a délivrées restent valides, et une suite de bits identiques se compresse bien. La compression DEFLATE appliquée à la chaîne de bits brute est ce qui permet à une liste couvrant des centaines de milliers de credentials de ne peser que quelques kilo-octets sur le réseau, ce qui rend pratique la récupération de la liste entière plutôt que d'interroger l'issuer au sujet d'une seule credential.
Agrégation : découvrir les listes à l'avance
Un issuer peut, en option, ajouter aggregation_uri à un objet Status List, pointant vers un endpoint qui liste les uris de tous les Status List Token qu'il publie. Un verifier qui souhaite précharger et mettre en cache des listes avant d'en avoir besoin, plutôt que de découvrir chacune via la première credential qui la référence, peut utiliser cet endpoint à la place. Ceci est facultatif ; rien dans le flux principal décrit ci-dessus n'en dépend.
Termes associés
Questions fréquentes
Le verifier récupère-t-il une liste distincte pour chaque credential qu'il vérifie ?
Non, un seul Status List Token couvre toutes les credentials que l'issuer y a placées, potentiellement des centaines de milliers. Un verifier récupère le même token une seule fois et lit un bit différent pour chaque credential qu'il vérifie, puis réutilise la copie mise en cache pendant jusqu'à ttl secondes avant de la récupérer à nouveau.
L'issuer peut-il savoir quelle credential un verifier a consultée ?
Non. Le verifier télécharge l'intégralité de la chaîne de bits compressée en une seule requête et lit localement le bit dont il a besoin, de sorte que la requête vue par l'issuer ne contient ni index ni identifiant de credential, seulement un GET pour la liste elle-même.
Quelle est la différence entre suspended et invalid ?
INVALID (0x01) est la façon dont le registre de référence de la spécification désigne une credential révoquée de façon permanente. SUSPENDED (0x02) est un état distinct et réversible qu'un issuer peut aussi définir puis lever ultérieurement, par exemple pendant l'instruction d'un litige. Les distinguer nécessite au moins deux bits par entrée (bits : 2), donc un Status List Token utilisant bits : 1 ne peut distinguer que valid et invalid.
À quoi sert aggregation_uri ?
Il s'agit d'un pointeur facultatif à l'intérieur d'un objet Status List vers un endpoint d'agrégation qui liste les uris de tous les Status List Token de cet issuer. Un verifier qui souhaite préchauffer son cache à l'avance, ou découvrir des listes qu'il n'a pas encore vues, peut interroger cet endpoint plutôt que d'attendre qu'une credential en désigne une.
Sources
Cette page est informative et ne constitue pas un avis juridique. Pour des indications faisant autorité, consultez directement la spécification de l'IETF.