Revocación de Status List explicada
Un verifier que acaba de recibir una credential necesita saber si el issuer sigue respaldándola. Token Status List responde a eso sin que el verifier contacte al issuer sobre esa credential en concreto: un status claim dentro de la credential apunta a una lista compacta, y un único bit de esa lista lleva la respuesta.
El status claim dentro de la credential
Un issuer que admite Token Status List añade un status claim a la credential en el momento de la emisión. Contiene dos cosas: idx, el índice que esta credential posee dentro de la lista, y uri, la dirección del Status List Token que la contiene. Nada más de la credential cambia; el claim es solo un puntero.
Issuer
Asigna a la credential un índice e incorpora un status claim
El claim se añade una sola vez, en la emisión, y nunca cambia durante toda la vida de la credential
Status claim (dentro de la credential)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}Descarga del Status List Token
En el momento de la presentación, el verifier descarga la uri del status claim. La respuesta es un Status List Token firmado: un JWT con una cabecera typ de statuslist+jwt (o un equivalente CWT), servido como application/statuslist+jwt. Su payload contiene la cadena de bits comprimida y, normalmente, un ttl que indica cuánto tiempo puede el verifier almacenar el resultado en caché antes de volver a descargarlo.
Verifier
Lee idx y uri del status claim en la credential que se acaba de presentar
GET uri
Descarga el Status List Token y lo almacena en caché hasta ttl segundos
Payload del Status List Token (respuesta)
{
"sub": "https://issuer.example/statuslists/employment-2026-q3",
"iat": 1789200000,
"exp": 1789804800,
"ttl": 43200,
"status_list": {
"bits": 2,
"lst": "eNrbuRgAAhcBXQ"
}
}sub repite la propia uri de la lista para que un verifier pueda confirmar que descargó el token correcto. iat y exp delimitan la validez del propio token. ttl, en segundos, es el tiempo máximo que el verifier puede reutilizar una copia en caché antes de tener que descargar la lista de nuevo.
Decodificación del bit
lst es un array de bytes, codificado en base64url y comprimido con DEFLATE en el formato de datos zlib, que el verifier descomprime primero. bits indica cuántos bits ocupa cada credential en la lista: 1, 2, 4 u 8. Con bits: 2, la credential número idx se sitúa en el byte idx * 2 / 8, y el verifier lee los dos bits en ese offset para obtener el valor de estado.
Ejemplo resuelto: idx 4271, bits: 2
- bit_offset = idx * bits = 4271 * 2 = 8542
- byte_index = bit_offset / 8 = 1067
- bit_in_byte = bit_offset % 8 = 6
El verifier lee el byte 1067 del array descomprimido, extrae los dos bits a partir del bit 6 y compara el resultado con la tabla de valores siguiente.
| Valor | Significado |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Específico de la aplicación / reservado |
Los valores mostrados asumen bits: 2. Con bits: 1 solo caben VALID (0) e INVALID (1); bits: 4 y bits: 8 dejan más margen libre para valores específicos de la aplicación.
Por qué la lista se mantiene pequeña
En la práctica, las status lists son mayormente ceros, porque la mayoría de las credentials que un issuer ha emitido siguen siendo válidas, y una secuencia de bits idénticos se comprime bien. La compresión DEFLATE sobre la cadena de bits en bruto es lo que permite que una lista que cubre cientos de miles de credentials ocupe solo unos pocos kilobytes en la red, lo que hace práctico descargar toda la lista en lugar de preguntar al issuer por una sola credential.
Agregación: descubrir listas con antelación
Un issuer puede añadir opcionalmente aggregation_uri a un objeto Status List, apuntando a un endpoint que lista las uris de todos los Status List Token que publica. Un verifier que quiera precargar y cachear listas antes de necesitarlas, en lugar de descubrir cada una a partir de la primera credential que la referencia, puede usar ese endpoint. Esto es opcional; nada en el flujo principal descrito arriba depende de ello.
Términos relacionados
Preguntas frecuentes
¿El verifier descarga una lista distinta para cada credential que comprueba?
No, un único Status List Token cubre todas las credentials que el issuer incluyó en él, potencialmente cientos de miles. Un verifier descarga el mismo token una vez y lee un bit distinto para cada credential que comprueba, y reutiliza la copia en caché hasta ttl segundos antes de volver a descargarlo.
¿Puede el issuer saber qué credential ha consultado un verifier?
No. El verifier descarga toda la cadena de bits comprimida en una sola solicitud y lee localmente el bit que necesita, de modo que la solicitud que ve el issuer no contiene ningún índice ni identificador de credential, solo un GET para la lista en sí.
¿Cuál es la diferencia entre suspended e invalid?
INVALID (0x01) es la forma en que el registro de referencia de la especificación etiqueta una credential revocada de forma permanente. SUSPENDED (0x02) es un estado distinto y reversible que un issuer también puede establecer y luego anular, por ejemplo mientras se investiga una disputa. Distinguirlos requiere al menos dos bits por entrada (bits: 2), por lo que un Status List Token con bits: 1 solo puede distinguir entre valid e invalid.
¿Para qué sirve el aggregation_uri?
Es un puntero opcional dentro de un objeto Status List hacia un endpoint de agregación que lista las uris de todos los Status List Token de ese issuer. Un verifier que quiera precalentar su caché con antelación, o descubrir listas que aún no conoce, puede consultar ese endpoint en lugar de esperar a que una credential le indique una.
Fuentes
Esta página tiene fines informativos y no constituye asesoramiento legal. Para obtener orientación oficial, consulte directamente la especificación del IETF.