Identidade descentralizada e verifiable credentials

2026-08-24

A identidade descentralizada separa identificação, emissão de credenciais, armazenamento e verificação para que nenhum provedor de login precise ser o guardião permanente de cada interação. Os decentralized identifiers, ou DID, ajudam uma entidade a provar o controle de um identificador, enquanto as verifiable credentials, ou VC, carregam afirmações assinadas por um emissor. O modelo mental útil não descreve uma identidade mágica pertencente a uma carteira, e sim um fluxo de confiança: o issuer faz uma afirmação, o holder a guarda e apresenta, e o verifier confere a prova, o status, o contexto e a política. Este artigo explica esse fluxo, mostra onde a blockchain se encaixa e por que gestão de chaves, revogação, divulgação seletiva e proteção de dados continuam essenciais.

O que significa decentralized identity explained

A expressão decentralized identity explained fica mais fácil quando a identidade é dividida em camadas. Um DID é um identificador que pode ser resolvido, por meio de um DID method, para um DID document ou recurso relacionado. Esse documento pode descrever métodos de verificação, serviços e as relações nas quais uma chave pode ser usada. Uma VC é outra coisa: um conjunto de afirmações que um emissor faz sobre um subject, embalado para que um verifier confira autoria e integridade. Um DID pode identificar pessoa, organização, dispositivo ou serviço, mas sozinho não prova idade, formação, emprego nem situação legal.

Essa separação evita um exagero comum. Descentralizado não significa anônimo, não rastreável ou fora da regulação. Uma credential pode estar fortemente ligada a um processo real de verificação de identidade, e ainda se pode exigir que o verifier aplique suas próprias regras de elegibilidade, fraude, sanções ou acesso. Um DID method também pode depender de um serviço centralizado, de um sistema federado, de um banco de dados, de um livro distribuído ou de outro registry. A pergunta de projeto é quem controla o identificador, quem faz a afirmação, quem pode atualizar as chaves associadas e qual parte tem permissão para confiar no resultado.

DID, issuer, holder e verifier em um fluxo de confiança

Os quatro termos descrevem tarefas diferentes. O issuer é a autoridade ou organização que afirma algo e cria uma credential. O holder possui a credential, normalmente em uma wallet ou outro repositório protegido, e decide quando apresentá-la. O verifier recebe uma credential ou verifiable presentation e confere o mecanismo de proteção, o issuer, o subject, o período de validade, o status e a finalidade comercial do pedido. O subject é a entidade sobre a qual a afirmação trata. Holder e subject costumam ser a mesma pessoa, mas um responsável pode guardar uma credential sobre uma criança, ou uma organização credenciais sobre um dispositivo.

Um DID document pode ajudar o verifier a descobrir o material público de verificação associado a um issuer ou holder. Provas Data Integrity podem ligar uma prova a um método de verificação e a uma finalidade declarada, mas conferir a assinatura com sucesso não equivale a aceitar cada afirmação. O verifier ainda precisa de uma decisão de confiança: este issuer é reconhecido para esse tipo de afirmação, o schema da credential é adequado, a apresentação é recente e a divulgação pedida é proporcional? O NIST descreve isso como separar a verificação criptográfica da validação e da avaliação das afirmações.

O ciclo de vida da VC, do proofing à apresentação

O ciclo de vida começa antes da criptografia. Durante o cadastro ou o proofing de identidade, o issuer decide quais evidências bastam e qual nível de assurance o caso de uso exige. Em seguida cria afirmações sobre um subject, adiciona metadados como tipo e validade e protege a credential com um mecanismo compatível. A wallet ou o repositório protege a cópia do holder. No momento da apresentação, o holder cria uma presentation para um verifier específico, usando uma credential ou um conjunto delas e revelando talvez apenas algumas afirmações.

A verificação é uma sequência, não um único sinal verde. O verifier analisa o documento, confere o modelo de dados e o mecanismo de proteção, resolve o material de verificação pertinente, valida a finalidade da prova e qualquer vínculo com o holder, checa o período de validade da credential e executa uma checagem de status quando ela existe ou quando a política a exige. Só depois avalia se o issuer e as afirmações atendem à regra de negócio. Uma credential pode ser criptograficamente autêntica e mesmo assim falhar porque expirou, foi revogada, veio de uma autoridade não confiável, se refere ao subject errado ou não serve para a finalidade pedida. Renovação, atualização, suspensão, revogação e exclusão final são eventos do ciclo de vida, não propriedades que uma blockchain administra automaticamente.

Keys, DID documents e revocation são controles diferentes

Chaves privadas ou secretas são a autoridade de assinatura. Uma chave pública ou outro método de verificação deixa o verifier testar um proof, mas não deixa criar um proof válido novo. O issuer precisa proteger suas chaves de assinatura, definir qual relação de verificação cada chave sustenta, monitorar comprometimento e ter um plano de rotação e recuperação. O holder também precisa de acesso seguro ao dispositivo, procedimentos de backup ou recuperação e um jeito de distinguir uma apresentação de credential de um pedido para entregar o segredo da wallet. Perder uma chave pode afetar o acesso; expor uma chave secreta permite personificação até o ecossistema detectar e reagir.

Três relógios não podem ser confundidos. Uma prova pode ter horários de criação e expiração, uma credential pode ter validFrom e validUntil, e um verification method pode ser rotacionado, revogado ou deixado expirar porque sua chave foi comprometida. O credential status é outro sinal: pode indicar que o privilégio ou a afirmação representada pela credential não está mais vigente. Por isso o verifier precisa checar o mecanismo de status e sua atualidade, e não apenas se a assinatura fecha matematicamente. Listas de status, registros ou endpoints do emissor melhoram o controle operacional, mas também exigem garantias de disponibilidade, privacidade, integridade e governança.

Selective disclosure e o limite da minimização de dados

Divulgação seletiva significa que o holder consegue decidir com granularidade quais informações compartilhar. Se um serviço só precisa saber se alguém passa de um limite, a data de nascimento completa pode ser dispensável. Uma presentation às vezes pode carregar uma afirmação abstrata ou uma prova de conhecimento zero em vez do atributo original. Outros perfis usam tokens de divulgação seletiva ou suítes de prova. A propriedade exata de privacidade depende do formato da credential, da suíte criptográfica, da wallet, do pedido do verifier e de as apresentações repetidas poderem ser ligadas.

O limite importante é que um DID e uma VC não entregam privacidade automaticamente. Um identificador estável, uma assinatura repetida, uma consulta de status, um evento de telemetria da wallet ou um registro em livro público podem criar correlação. Por isso a minimização de dados começa pela pergunta do verifier: qual é a menor afirmação necessária para essa decisão, por quanto tempo e quem precisa vê-la? Quem projeta deve evitar colocar dados pessoais em um registro público imutável, preferir identificadores em pares ou adequados ao contexto quando houver suporte, reduzir a retenção, proteger logs e fazer o usuário entender a parte e a finalidade antes de compartilhar. Privacidade é resultado de arquitetura, não um rótulo colado numa wallet.

Onde a blockchain entra em self sovereign identity blockchain

A expressão self sovereign identity blockchain costuma sugerir que todo registro de identidade precisa estar on-chain. O DID Core não exige isso. Um DID method define como identificadores e seus documentos são criados, resolvidos, atualizados ou desativados, e um verifiable data registry pode ser um livro distribuído, um banco de dados, um sistema de arquivos descentralizado ou outro sistema confiável. A blockchain pode ser útil como registro público e resistente a adulteração das operações do método, dos metadados de confiança do issuer, dos eventos de rotação de chaves ou de status compacto. Também facilita a descoberta compartilhada quando os participantes não querem um único operador no controle do registro.

A blockchain também traz custos e riscos. Registros públicos podem ser copiados e correlacionados e são difíceis de remover; disponibilidade de transações e governança podem mudar; um hash não prova que o dado original estava correto; e uma âncora imutável não conserta uma chave de issuer comprometida. Um projeto sólido guarda afirmações pessoais e documentos grandes em armazenamento protegido adequado, publica apenas os dados mínimos de registro e documenta como funcionam atualização, recuperação, migração e pedidos legais. Controle autossoberano é melhor entendido como um conjunto de capacidades do usuário e da organização do que como promessa de que uma cadeia torna alguém independente de emissores, verificadores ou da lei.

Fluxo de issuer, holder, verifier e registry para DID e verifiable credentials

Compliance e lista prática de verificação

Sistemas de identidade continuam com obrigações legais e operacionais. Conforme a jurisdição e o caso de uso, um operador pode precisar de base legal, limitação de finalidade, minimização de dados, controles de retenção, processos de acesso e correção, salvaguardas de segurança, resposta a incidentes, controles de transferência internacional e uma estrutura de confiança auditável. Os materiais da European Digital Identity Wallet enfatizam compartilhar apenas as informações acordadas, enquanto a orientação do NIST sobre proofing mostra que validação, checagens de revogação quando disponíveis e assurance de autenticação são etapas separadas. São exigências de governança em torno de uma credential técnica, não recursos que um DID ou blockchain possa dispensar.

Para uma integração real, faça sete perguntas. Qual DID method e qual registry são usados e como falhas de resolução são tratadas? Em qual issuer se confia para essa afirmação e como o subject foi verificado? Qual mecanismo de proteção, cryptosuite, relação de chave e vínculo de apresentação são exigidos? Como se checam validade, status, rotação, comprometimento e recuperação? O pedido busca mais dados do que a decisão precisa e a apresentação resiste a repetição e correlação? Onde ficam guardados credentials, logs e registros de status e por quanto tempo? Por fim, qual regulador, contrato, lista de confiança ou política interna define se o verifier pode confiar na afirmação? A expressão verifiable credentials blockchain descreve possibilidades de infraestrutura, não uma garantia de verdade, privacidade ou conformidade.

Leituras relacionadas

Outros artigos da Bitbase sobre este tema:

- Airdrops e farming

- Mixers de cripto e privacy pools

- O que é Billions Network: uma plataforma de identidade com privacidade

Aviso: Este artigo é conteúdo educacional da Bitbase Academy, fornecido apenas para fins informativos. Não constitui aconselhamento de investimento, negociação, tributário ou financeiro. Criptoativos são voláteis; avalie seu próprio risco. Escrito em agosto de 2026; consulte as informações oficiais mais recentes.