Pular para o conteúdo principal

Credenciais verificáveis e SD-JWT

Credenciais verificáveis permitem que um emissor formule claims resistentes a adulteração, que podem ser mantidos e posteriormente apresentados a um verificador. SD-JWT adiciona um mecanismo padronizado para divulgar seletivamente elementos individuais de uma estrutura JSON assinada.

A UbID usa esses conceitos para separar a evidência assinada pelo emissor, a decisão do titular sobre o que apresentar e a decisão do verificador sobre se a evidência é suficiente.

O modelo de confiança das credenciais​

Uma interação com credenciais normalmente envolve:

  • um emissor que formula e assina claims;
  • um titular que recebe e controla a credencial;
  • uma Wallet ou serviço do titular que a protege e apresenta;
  • um verificador que valida a evidência e aplica política;
  • um sujeito, que pode ou não ser o mesmo que o titular.

Uma assinatura válida estabelece integridade e procedência da chave do emissor. Por si só, não estabelece que o emissor é confiável para o claim, que a evidência está atual ou que a transação deve ser aprovada.

Semântica de Verifiable Credentials​

O W3C Verifiable Credentials Data Model define modelo conceitual comum para emissores, titulares, sujeitos, credenciais, apresentações, claims, schemas e status. Ele não exige um único formato universal de prova criptográfica.

Um perfil de credencial ainda deve definir:

  • tipo de credencial e significado dos claims;
  • campos obrigatórios e opcionais;
  • identificadores de emissor e sujeito;
  • comportamento de validade e status;
  • envelope criptográfico e algoritmos permitidos;
  • requisitos de holder binding;
  • regras de apresentação e verificação.

A UbID trata o VC Data Model 2.0 como referência semântica importante. Os caminhos atuais de credenciais UbID também usam formatos JWT de divulgação seletiva, e cada perfil de credencial deve declarar seu modelo exato de conformidade.

Divulgação seletiva com SD-JWT​

SD-JWT permite que um emissor assine commitments para valores selecionados de claims, em vez de colocar todos os valores diretamente no payload assinado visível. O titular mantém as disclosures associadas e revela somente as necessárias para uma apresentação.

O verificador reconstrói a visão divulgada e valida que cada disclosure corresponda a um commitment protegido pela assinatura do emissor.

Isso apoia minimização, mas não impede automaticamente correlação. Identificadores estáveis, combinações únicas de claims, timestamps, identificadores de credenciais, comportamento do verificador e padrões repetidos de apresentação ainda podem criar vinculação.

SD-JWT e SD-JWT VC não são a mesma coisa​

A distinção é importante:

TermoEscopo
SD-JWTMecanismo IETF de divulgação seletiva para dados JSON e claims JWT.
SD-JWT VCPerfil de credencial que define formato e regras de processamento para credenciais digitais verificáveis baseadas em SD-JWT.
W3C VC Data ModelModelo semântico para credenciais e apresentações, independente de um único formato de prova.
VC protegida com JOSE/COSEAbordagem W3C para aplicar mecanismos JOSE, SD-JWT ou COSE a credenciais conformes ao modelo de dados VC.

Na baseline editorial deste portal, SD-JWT é um RFC do IETF Standards Track, enquanto o perfil IETF SD-JWT VC continua em desenvolvimento. A documentação da UbID deve fixar a versão de perfil usada por cada deployment e não descrever suporte a draft como conformidade universal com padrão final.

Holder binding​

Uma credencial pode ser vinculada criptograficamente a material de chaves controlado pelo titular. Durante a apresentação, o titular pode provar controle da chave relevante e vincular a apresentação ao verificador, audiência, nonce ou transação.

Holder binding pode reduzir risco de roubo e replay de credenciais, mas não substitui consentimento, segurança do dispositivo, verificações de status ou política do verificador. Alguns casos podem exigir modelo bearer ou delegado; o perfil deve tornar essa escolha explícita.

Status e ciclo de vida​

Uma credencial pode continuar corretamente assinada e, ainda assim, estar expirada, suspensa, revogada, substituída ou fora da política aceita. A verificação considera:

  • confiança do emissor e material de assinatura;
  • assinatura e política de algoritmos;
  • período de validade;
  • status da credencial;
  • versão de schema e perfil;
  • holder binding quando necessário;
  • atualidade e audiência da apresentação;
  • claims solicitados e finalidade;
  • política do verificador.

Minimização de dados e comprovantes​

Um verificador deve solicitar somente os claims necessários para a finalidade declarada. Também deve minimizar o comprovante retido após a verificação. Manter a apresentação completa apenas porque divulgação seletiva foi usada pode anular o benefício de privacidade.

Posição da UbID​

Credenciais JWT de divulgação seletiva fazem parte da baseline implementada e de transição da UbID. Semântica W3C VC, perfis SD-JWT VC, mecanismos de status e contratos de apresentação são governados por tipo de credencial e perfil de parceiro.

Nenhum exemplo público neste portal representa credencial de produção, schema de cliente, chave real ou política completa de aceitação.

Padrões-fonte​

Consulte Divulgação seletiva, Ciclo de vida das credenciais e Verificação e política.