Resumo

  • A RFC 9901 permite que o Holder apresente nenhuma, algumas ou todas as Disclosures que recebeu; cada valor apresentado pode ser comparado ao digest dentro do JWT assinado pelo Issuer.
  • Essa comparação autentica o valor apresentado dentro da estrutura emitida. Não transforma a ausência de outra Disclosure em prova de inexistência, atualidade ou direito de agir.

Uma informação protegida pode ser verdadeira e ainda insuficiente. Essa é a disciplina que a divulgação seletiva exige. Um serviço não pode concluir que uma pessoa não possui outro atributo, não enfrenta outra restrição ou satisfaz todas as condições porque só recebeu um atributo favorável.

O SD-JWT definido pela RFC 9901 funciona por compromisso e revelação. O Issuer assina o JWT. Em vez de deixar um claim seletivo em texto claro, insere um digest. A Disclosure traz sal aleatório, nome do claim quando existe e valor. O Holder recebe os materiais de emissão e, em cada apresentação, escolhe quais Disclosures entregar. O Verifier calcula novamente cada digest e confirma sua presença no JWT do Issuer.

O resultado é deliberadamente estreito: o valor entregue é compatível com o compromisso assinado. O Holder pode entregar qualquer subconjunto, inclusive nenhum. O Issuer pode combinar claims permanentes, claims seletivos e digests de engodo. Logo, a tela de apresentação não é uma lista completa de atributos e nem um questionário em que campo ausente vale automaticamente como “não”.

Há quatro transições que relatórios frequentemente escondem. O Issuer faz uma declaração e escolhe sua forma de divulgação. O Holder compõe uma apresentação. O Verifier aplica verificações criptográficas. O sistema de negócio ou operação aplica uma política própria e altera, ou não, um estado. O fato de todas essas transições aparecerem no mesmo fluxo não lhes dá o mesmo dono nem o mesmo significado.

Uma assinatura do Issuer preserva a integridade desde a emissão. Ela não descreve o método de observação do Issuer, não garante que o claim continua atual e não cria uma semântica universal. A RFC 7519 organiza claims; o registro IANA organiza nomes. O requisito de que um claim seja suficiente ou obrigatório nasce no perfil de uso e na política local. A RFC 8725 reforça a necessidade de tipos explícitos e de regras de validação apropriadas a cada uso de JWT.

Key Binding é uma camada opcional, e sua opcionalidade importa. Quando o Verifier exige, o Holder assina um KB-JWT com o hash do SD-JWT, um nonce e uma audiência. Isso pode provar controle da chave privada naquela apresentação. Não prova que todos os dados relevantes foram mostrados, que os dados refletem o presente ou que a ação posterior foi permitida. Se Key Binding não for exigido, a própria RFC observa que alguém que possui o SD-JWT pode encaminhá-lo a outro terceiro e remover Disclosures.

O RFC também impede que controles decisivos sejam tratados como simples preferências de privacidade: conteúdo crítico para avaliar autenticidade ou validade não deve ser seletivamente revelável. O conjunto exato varia conforme o perfil. O Verifier deve validar a assinatura e cada digest. A decisão de suficiência permanece, corretamente, na superfície local em que a ação pode ser negada.

Para auditar uma decisão, registre quem foi o Issuer, como a chave foi aceita, qual tipo e perfil se aplicaram, quais claims eram necessários, quais chegaram, se Key Binding foi exigido, nonce e audiência, versão de regra e resultado final. Uma métrica chamada “token válido” mede pouco e pode esconder um conjunto de evidências ausente.

O enquadramento de Heng Lu ajuda a manter a proporção: representação compartilhada, julgamento local e efeito executado são camadas diferentes. A RFC 9901 torna uma declaração verificável e portátil sem apropriar para ela a autoridade de decidir o que a organização deve fazer depois.

Sources