Resumo

  • A RFC 9901 é uma especificação IETF Standards Track para divulgação seletiva de elementos individuais em payloads JSON de objetos JWS, tendo JWT como principal caso de uso. As RFCs 7515 e 7519 entram apenas como base de JWS e JWT incorporada pela especificação.
  • O controle passa por uma cadeia: o emissor desenha o que pode ser ocultado, o titular escolhe Disclosures, o verificador define a evidência exigida e a política pode exigir, ou não, prova de posse da chave.
  • SD-JWT não é criptografia, prova de conhecimento zero nem credencial anônima, e não oferece uma garantia automática de não correlação.

A cadeia técnica

Para uma propriedade de objeto, o emissor substitui o valor em claro por um digest no payload assinado e entrega separadamente uma Disclosure contendo salt, nome do claim e valor. Para um elemento de array, a Disclosure contém salt e valor. O array JSON é codificado em UTF-8 e depois em base64url antes do cálculo do hash. Cada salt deve ser criptograficamente aleatório, independente e único para cada claim divulgado seletivamente; a recomendação é ter ao menos 128 bits aleatórios. Até a divulgação, o salt deve permanecer oculto de todos, exceto do titular.

O claim de topo _sd_alg seleciona o hash das Disclosures. Ele não pode ser usado de forma aninhada; se estiver ausente, o padrão é sha-256, que toda implementação deve suportar. O JWT assinado pelo emissor precisa ter uma assinatura válida e não pode usar o algoritmo none. O verificador valida a assinatura, recalcula o digest de cada Disclosure apresentada e o compara ao payload assinado antes de reconstruir o payload processado. Assinatura inválida, digest sem correspondência, formato incorreto, algoritmo não aceito ou claim obrigatório ausente devem levar à rejeição.

A estrutura pode ser aninhada e recursiva. Uma Disclosure de filho oculto pode depender da Disclosure do pai; por isso, o titular precisa preservar toda a cadeia de dependências válida na apresentação. Decoy digests podem esconder o número original ou a existência de claims ocultos, mas aumentam o tamanho do token. São uma mitigação de canal lateral, não uma forma de impedir correlação.

Key Binding é opcional, salvo quando um perfil do verificador ou um caso de uso o exige. Quando exigido, o SD-JWT transporta a chave pública do titular ou uma referência a ela, e o titular assina um KB-JWT com typ igual a kb+jwt e os campos iat, aud, nonce e sd_hash. O sd_hash vincula o KB-JWT ao JWT exato assinado pelo emissor e às Disclosures selecionadas. O verificador que exigir essa vinculação deve validar a chave do titular, a assinatura, o algoritmo, o tipo, a janela de tempo de emissão, a audiência, o nonce e o sd_hash.

Claims que controlam validade, como exp, exigem decisão de perfil. Se forem seletivamente divulgáveis, o verificador pode ficar sem a informação necessária para rejeitar a apresentação. A aplicação deve definir os claims obrigatórios e rejeitar sua ausência. A RFC 9901 depende do protocolo de transporte para confidencialidade e não especifica um mecanismo de criptografia; quando privacidade ou correlação passiva forem relevantes, o transporte confidencial é necessário. JWE pode encapsular um SD-JWT em canais sujeitos a vazamento. Salt não substitui transporte confidencial, e valores não divulgados não podem ser recuperados do token.

O limite de privacidade

Divulgação seletiva não equivale à não correlação de uma credencial anônima. Uma credencial estável assinada pelo emissor pode permitir que emissores e verificadores em conluio reconheçam a mesma credencial. Emissão em lote com salts e chaves novas do titular pode melhorar a não correlação entre verificadores e apresentações, mas não entrega não correlação contra conluio entre emissor e verificador. A RFC não permite inferir adoção, incidentes, desempenho, conformidade legal, comportamento de emissores, contenção por verificadores ou usabilidade de carteiras.

Fontes