Revogação com Status List explicada
Um verificador que acabou de receber uma credencial precisa de saber se o emissor continua a garanti-la. O Token Status List responde a isso sem que o verificador contacte o emissor sobre essa credencial específica: uma declaração status dentro da credencial aponta para uma lista compacta, e um único bit dessa lista contém a resposta.
A declaração status dentro da credencial
Um emissor que suporte o Token Status List adiciona uma declaração status à credencial no momento da emissão. Ela contém duas coisas: idx, o índice que esta credencial ocupa dentro da lista, e uri, o endereço do Status List Token que a contém. Mais nenhum aspeto da credencial muda; a declaração é apenas um ponteiro.
Emissor
Atribui um índice à credencial e incorpora uma declaração status
A declaração é adicionada uma única vez, na emissão, e nunca muda durante o tempo de vida da credencial
Declaração status (dentro da credencial)
{
"status": {
"status_list": {
"idx": 4271,
"uri": "https://issuer.example/statuslists/employment-2026-q3"
}
}
}Obter o Status List Token
No momento da apresentação, o verificador obtém o uri a partir da declaração status. A resposta é um Status List Token assinado: um JWT com um cabeçalho typ de statuslist+jwt (ou um equivalente CWT), servido como application/statuslist+jwt. O seu payload contém a bitstring comprimida e, normalmente, um ttl que indica ao verificador durante quanto tempo pode colocar o resultado em cache antes de o obter novamente.
Verificador
Lê idx e uri a partir da declaração status na credencial que acabou de ser apresentada
GET uri
Obtém o Status List Token, guardando-o em cache durante até ttl segundos
Payload do Status List Token (resposta)
{
"sub": "https://issuer.example/statuslists/employment-2026-q3",
"iat": 1789200000,
"exp": 1789804800,
"ttl": 43200,
"status_list": {
"bits": 2,
"lst": "eNrbuRgAAhcBXQ"
}
}sub repete o próprio URI da lista para que o verificador possa confirmar que obteve o token correto. iat e exp delimitam a validade do próprio token. ttl, em segundos, é o tempo máximo durante o qual o verificador pode reutilizar uma cópia em cache antes de ter de obter a lista novamente.
Descodificar o bit
lst é um array de bytes, codificado em base64url e comprimido com DEFLATE no formato de dados zlib, que o verificador descomprime primeiro. bits indica quantos bits cada credencial na lista ocupa: 1, 2, 4 ou 8. Com bits: 2, a credencial número idx encontra-se no byte idx * 2 / 8, e o verificador lê os dois bits nesse offset para obter o valor de estado.
Exemplo prático: idx 4271, bits: 2
- bit_offset = idx * bits = 4271 * 2 = 8542
- byte_index = bit_offset / 8 = 1067
- bit_in_byte = bit_offset % 8 = 6
O verificador lê o byte 1067 do array descomprimido, extrai os dois bits a partir do bit 6, e compara o resultado com a tabela de valores abaixo.
| Valor | Significado |
|---|---|
| 0x00 | VALID |
| 0x01 | INVALID |
| 0x02 | SUSPENDED |
| 0x03, 0x0C-0x0F | Específico da aplicação / reservado |
Os valores apresentados assumem bits: 2. Com bits: 1 só cabem VALID (0) e INVALID (1); bits: 4 e bits: 8 deixam mais espaço livre para valores específicos da aplicação.
Porque é que a lista se mantém pequena
As listas de status reais são maioritariamente zeros, porque a maioria das credenciais que um emissor já emitiu continua válida, e uma sequência de bits idênticos comprime bem. A compressão DEFLATE sobre a bitstring bruta é o que permite manter uma lista que cobre centenas de milhares de credenciais em apenas alguns kilobytes na rede, o que torna prático obter a lista inteira em vez de perguntar ao emissor sobre uma única credencial.
Agregação: descobrir listas antecipadamente
Um emissor pode, opcionalmente, adicionar aggregation_uri a um objeto Status List, apontando para um endpoint que lista os URIs de todos os Status List Token que publica. Um verificador que queira pré-obter e colocar listas em cache antes de precisar delas, em vez de descobrir cada uma a partir da primeira credencial que a referencia, pode usar esse endpoint. Isto é opcional; nada no fluxo principal acima depende disso.
Termos relacionados
Perguntas frequentes
O verificador obtém uma lista separada para cada credencial que verifica?
Não. Um único Status List Token cobre todas as credenciais que o emissor nele incluiu, potencialmente centenas de milhares. Um verificador obtém o mesmo token uma vez e lê um bit diferente para cada credencial que verifica, reutilizando depois a cópia em cache durante até ttl segundos antes de o obter novamente.
O emissor consegue saber que credencial um verificador consultou?
Não. O verificador transfere toda a bitstring comprimida num único pedido e lê localmente o bit de que necessita, pelo que o pedido que o emissor vê não contém índice nem identificador de credencial, apenas um GET à própria lista.
Qual é a diferença entre suspended e invalid?
INVALID (0x01) é a forma como o registo de referência da especificação identifica uma credencial permanentemente revogada. SUSPENDED (0x02) é um estado distinto e reversível que um emissor também pode definir e mais tarde remover, por exemplo enquanto uma disputa está a ser investigada. Distingui-los exige pelo menos dois bits por entrada (bits: 2), pelo que um Status List Token que utilize bits: 1 só consegue distinguir válido de inválido.
Para que serve o aggregation_uri?
É um ponteiro opcional dentro de um objeto Status List para um endpoint de agregação que lista os URIs de todos os Status List Token desse emissor. Um verificador que queira aquecer a sua cache antecipadamente, ou descobrir listas que ainda não viu, pode obter esse endpoint em vez de esperar que uma credencial indique uma.
Fontes
Esta página tem caráter informativo e não constitui aconselhamento jurídico. Para orientação oficial, consulte diretamente a especificação do IETF.