Resumo

  • draft-ietf-oauth-status-list-21 permite que um Referenced Token aponte, por URI e índice, para uma entrada de uma lista compactada. Um Status List Token protegido carrega os estados VALID, INVALID, SUSPENDED ou valores de aplicação para muitos tokens. A revisão 21 foi aprovada e está na fila do RFC Editor, mas continua sendo Internet-Draft, não RFC.
  • Por padrão, a entrada descreve o estado afirmado quando a lista foi emitida. iat, exp e ttl delimitam emissão, validade e cache; não registram automaticamente quando ocorreu a transição, quem a autorizou, a causa, a primeira entrega do Provider ou a decisão do relying party.
  • Daniel Kade propõe um recibo mínimo fora do protocolo: impressões digitais do token e da lista, URI/índice, validação do emissor, quatro relógios separados, significado decodificado, política local de atualidade, ação e correção posterior. É orientação editorial, não requisito do IETF nem licença para vigiar apresentações.

O mérito da Token Status List está na recusa de transformar cada consulta em uma conversa individual sobre uma credencial identificável. Muitos tokens compartilham um vetor; o cliente busca um objeto protegido, localiza alguns bits e reaproveita a mesma cópia conforme as regras de cache. Escala e privacidade de grupo dependem dessa economia.

Por isso, exigir que a própria entrada contenha motivo, operador, evento, propagação e decisão local seria compreender mal a arquitetura. A obrigação institucional é diferente: se um estado temporário produz uma consequência duradoura, a organização precisa guardar o elo entre o que leu e o que fez, sem aumentar o protocolo nem criar um arquivo de comportamento do titular.

A aprovação veio antes do número de RFC

O registro no Datatracker identifica a revisão 21, de 21 de junho de 2026, como Internet-Draft Standards Track do OAuth Working Group. O histórico registra a aprovação da revisão 20 pelo IESG em 4 de junho, a entrada na fila do RFC Editor, a revisão 21 em 21 de junho e o estado Awaiting First editor do RFC Production Center em 13 de agosto. O documento está aprovado e avançado, mas ainda não é RFC.

O texto da revisão 21 expira em 23 de dezembro de 2026. A comparação oficial 20→21 fixa a versão analisada. A posição na fila não mede adoção, conformidade ou incidentes de campo. O OAuth Working Group governa a especificação, não opera os exemplos hipotéticos deste artigo.

O escopo inclui tokens protegidos por JOSE ou COSE, como JWT, SD-JWT, CWT e usos de ISO mdoc. JWS e JWT sustentam a representação JSON; CWT e COSE, a representação CBOR. O Status List Token é um artefato protegido separado, destinado a falar sobre uma condição que pode mudar depois da emissão da credencial.

O endereço encontra a afirmação; não encontra a causa

No mecanismo de lista, o Referenced Token inclui status_list com uri e idx. A URI identifica o Status List Token; o inteiro não negativo seleciona a posição. Essa coordenada é suficiente para a leitura, mas não contém o processo administrativo que produziu o valor.

O Status Issuer escolhe um, dois, quatro ou oito bits por Referenced Token. Ele atribui índices distintos, empacota os valores do bit menos significativo para o mais significativo dentro de cada byte e compacta o vetor com DEFLATE no formato ZLIB. Os RFCs 1951 e 1950 definem essas camadas. O resultado entra em JWT ou CWT, protegido por assinatura ou MAC.

A arquitetura separa Issuer, Status Issuer e Status Provider. O primeiro emite a credencial referenciada. O segundo recebe a informação de estado e produz a lista protegida. O terceiro a entrega. Uma organização pode acumular os papéis; também pode usar terceiro ou CDN para a distribuição sem transferir o poder de alterar os bytes assinados.

Para uma auditoria, assinatura e resposta HTTP não são o mesmo recibo. A proteção criptográfica sustenta origem e integridade do conteúdo. A observação da resposta sustenta que um Provider entregou certo objeto em certo momento. Nenhuma dessas provas, isoladamente, diz quando o fato de origem ocorreu ou quem autorizou uma suspensão.

O registro inicial atribui 0x00 a VALID, 0x01 a INVALID e 0x02 a SUSPENDED, além de reservar faixas para aplicações e futuros registros. Quando há mais de um bit por token, o conjunto inteiro forma um só valor. Não existe ali uma sequência de eventos.

O estado também não substitui a validade do Referenced Token. A especificação manda validar primeiro formato, assinatura, claims e expiração. Um token expirado continua expirado mesmo com entrada VALID. Depois da lista, o relying party ainda decide conforme políticas próprias. Validar a credencial, validar a lista, decodificar o estado e autorizar são quatro passos diferentes.

A operação tem quatro relógios

O primeiro é o relógio da fonte. Ele marcaria quando a condição real ou administrativa mudou: revogação, suspensão, restauração. O rascunho não define esse workflow anterior e o bit não precisa carregar autor, motivo ou hora do evento.

O segundo é o relógio da emissão. iat é obrigatório e registra quando o Status List Token foi emitido. exp, recomendado, informa quando o Status Issuer considera o objeto expirado. Essa janela limita a afirmação; não transforma iat na hora da revogação individual.

O terceiro é o relógio de entrega. O Provider pode servir por infraestrutura própria ou externa. O cliente observa a lista na hora do fetch, talvez muito depois da assinatura. A observação é relevante, mas não equivale à criação nem à mudança na fonte.

O quarto é o relógio da decisão. A aplicação pode agir imediatamente, após fila ou numa revisão em lote. Nesse instante ela aplica limite de atualidade, status e demais requisitos da credencial.

ttl governa o cache sem fundir os quatro tempos. A revisão 21 descreve nova busca depois de «hora de fetch + ttl», opção que distribui carga, e verificação em iat + ttl, mais atual para usos críticos com pequena margem de distribuição. Se headers HTTP divergem dos claims protegidos, exp e ttl do Status List Token prevalecem. O RFC 9110 dá a semântica HTTP; a tolerância continua sendo uma escolha do ecossistema e do relying party.

Intervalos extremos criam riscos opostos. Um cache longo amplia a idade do status. Um curto demais pode produzir requisições irracionais e concentrar carga no Provider. A seção de segurança recomenda limites superiores e inferiores razoáveis e alerta para valores acidentais ou maliciosos que induzam tráfego excessivo. Portanto, o recibo deve dizer qual regra de contagem foi aplicada e qual era a idade efetiva no momento da ação.

Uma fotografia antiga não é o ato de revogação

O modo padrão entrega a informação mais recente. Opcionalmente, a requisição pode trazer time=<timestamp>. Um servidor compatível pode responder com lista válida para aquele instante ou com erro. Se hospedagem estática ignora o parâmetro e devolve a lista atual, o cliente deve rejeitá-la quando o tempo pedido não cai na janela iat/exp protegida.

Duas fotografias podem delimitar uma mudança. Se a entrada estava VALID às 10h e INVALID às 10h15, existe evidência de que a nova afirmação apareceu até a segunda emissão. Não há evidência automática de que alguém tomou a decisão às 10h02, o sistema de origem mudou às 10h07 ou o Provider a publicou às 10h14. Essas etapas precisam de outra fonte.

A função histórica tem custo de privacidade. O rascunho recomenda não oferecê-la sem motivo forte e compreensão das consequências. Um relying party que guarda URI/índice e consulta repetidamente pode montar o perfil de estado de uma credencial. Um observador externo pode arquivar listas e inferir volumes ou taxas. A prova de uma decisão específica não exige, por definição, uma linha do tempo permanente de todos.

A privacidade de manada não cobre toda a rede

Agrupar muitos Referenced Tokens impede que uma única busca revele necessariamente qual deles interessa. A especificação chama isso de herd privacy. Listas maiores aumentam o conjunto de anonimato, mas aumentam o volume transferido.

Metadados podem reduzir a proteção. Uma URI única por token, uma lista muito pequena ou tamanho singular identificam melhor o alvo. A requisição HTTP pode expor o endereço do relying party. O par URI/índice é dado correlacionável; verificadores que cooperam podem reconhecer o mesmo token. O RFC 9901 oferece o contexto de divulgação seletiva do SD-JWT, e o RFC 9458 define Oblivious HTTP, exemplo de relay citado para reduzir observabilidade.

Hospedagem externa, índices aleatórios ou pseudoaleatórios, entradas-isca, múltiplas listas, lotes de uso único e índice novo na reemissão são opções. A própria semântica pode vazar dados: SUSPENDED revela uma fase temporária que o binário permitir/negar não mostra. Valores de aplicação podem ser ainda mais informativos.

O recibo local deve obedecer à mesma minimização. Impressões digitais e horários bastam em muitos casos; copiar credencial integral, IP e todas as apresentações cria outro centro de poder. Uma consulta histórica só deve aparecer quando realmente aconteceu.

O erro de um bit é um erro de decisão

A ordem de bits vai do menos significativo ao mais significativo dentro do byte; os bytes avançam na ordem natural. Descompactar o fluxo errado, calcular posição incorreta ou tolerar índice fora dos limites pode produzir outro status. O texto fornece vetores de teste e recomenda que as implementações os usem.

O caminho verificável é sequencial: validar o Referenced Token; resolver a URI; validar tipo, assinatura/MAC e claims do Status List Token; conferir o vínculo entre sujeito e URI; aplicar iat, exp, ttl e política local; descompactar; extrair a posição; interpretar o valor registrado; aplicar a regra da aplicação.

Índice fora da lista significa que nenhuma afirmação de status pode ser feita, e o Referenced Token deve ser rejeitado. Falhas nas verificações da lista também deixam o status sem afirmação, com rejeição recomendada. Isso não é INVALID: um caso é um estado expresso; o outro é incapacidade de obter evidência válida.

Duas impressões digitais e quatro tempos

O recibo proposto por Daniel Kade começa com uma identificação mínima do Referenced Token e o hash exato do Status List Token efetivamente usado. Registra URI/índice, Status Issuer, Provider observado, resolução de chave, resultado de assinatura ou MAC e a versão relevante do decodificador ou seus testes.

Depois preserva o tempo da mudança na fonte apenas se conhecido; caso contrário, escreve desconhecido. Mantém iat, exp, ttl, hora do fetch, idade do cache e hora da decisão. Declara busca atual ou histórica, timestamp solicitado, valor numérico, semântica registrada, limite local, regra de negócio, ação e posterior substituição, recurso ou encerramento.

Não é proposta de extensão do protocolo. É controle proporcional para efeitos que sobrevivem ao objeto efêmero. Hashes, referências, acesso restrito e retenção curta são preferíveis. The Policy Mirror inspira a comparação entre regra e decisão observável; Running-Code Primacy mantém o caminho executado em foco; Reality, Not Advocacy preserva a incerteza. Nenhum desses textos prova falha real em OAuth.

Fontes