Ir para o conteúdo
Financial Context Wiki

Identidade descentralizada (DID)

Guia prático sobre identificadores descentralizados e credenciais verificáveis: o que comprovam, como emissão e apresentação funcionam e onde permanecem riscos de confiança, privacidade e recuperação.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Identidade descentralizada é uma arquitetura em que um sujeito usa identificadores e credenciais protegidas por criptografia entre serviços sem transformar uma conta de plataforma na fonte universal de identidade. Os blocos comuns são identificadores descentralizados (DIDs), credenciais verificáveis (VCs), software do titular como uma carteira e regras que informam aos verificadores quais emissores, evidências e níveis de garantia aceitar.

Um DID é um URI como did:example:123. Seu método DID define como o identificador é criado, resolvido, atualizado e desativado. A resolução pode retornar um documento DID com métodos de verificação, relações como authentication ou assertionMethod e endpoints opcionais. Controlar a chave correspondente pode provar o controle do DID segundo esse método; por si só, não prova nome legal, idade, unicidade, emprego nem propriedade de conta externa.

Uma credencial verificável leva declarações feitas por um emissor sobre um ou mais sujeitos. O titular a armazena e pode criar uma apresentação verificável para o verificador. Uma verificação criptográfica bem-sucedida estabelece integridade e autoria dos dados protegidos sob o mecanismo escolhido. O verificador ainda precisa decidir separadamente se confia no emissor, se as declarações atendem à política, se a credencial está vigente e se o apresentador pode usá-la.

Logo, “descentralizada” não significa sem confiança, anônima, baseada em blockchain ou livre de intermediários. Significa que identificadores, credenciais, registros, carteiras e políticas de verificação podem ser separados para que um único provedor de login não observe e controle todas as relações. A descentralização real depende de emissores, operadores do método DID, serviços de status, fornecedores de carteira, administradores de recuperação, chaves de governança e políticas dos verificadores.

Como funciona

  1. Definir a declaração e a estrutura de confiança. Especifique sujeito, atributos solicitados, emissores aceitos, processo de comprovação, nível de garantia, retenção, jurisdição e recurso. Um formato criptográfico não decide se universidade, governo, empregador ou comunidade é uma autoridade adequada.
  2. Criar ou obter identificadores e chaves. Emissor e titular podem usar DIDs, URLs HTTPS ou outros identificadores compatíveis. Se usarem DID, o método determina registro e ciclo de vida. O controlador protege a chave privada; o documento resolvido expõe apenas material de verificação e endpoints necessários.
  3. Comprovar e vincular o sujeito. O emissor verifica evidências conforme a política e vincula as declarações ao sujeito da credencial. O vínculo pode apontar para chave controlada pelo titular, conta ou outro identificador. É preciso distinguir evidência sobre uma pessoa de evidência de que o apresentador atual controla uma chave.
  4. Emitir a credencial. O emissor cria declarações, datas de validade, esquema ou tipo e referência de status, e protege a credencial com uma prova aceita. Em credenciais Data Integrity, campos como cryptosuite, verificationMethod, proofPurpose e proofValue identificam como verificar a prova.
  5. Armazenar e selecionar. O titular guarda a credencial em carteira local ou hospedada. A carteira deve explicar o pedido do verificador, divulgar só os dados necessários quando o formato permitir e evitar reutilizar silenciosamente um identificador estável em contextos sem relação.
  6. Apresentar com atualidade e vínculo ao público. O verificador envia solicitação com identidade, propósito, nonce ou desafio e expiração. O titular devolve credencial ou apresentação derivada vinculada ao pedido. Verificações de domínio e desafio impedem que uma apresentação capturada seja repetida para outro verificador ou sessão.
  7. Verificar criptografia e política. Resolva o material do emissor em fonte autenticada; valide suíte, propósito, desafio, domínio, datas, esquema e status; então aplique as regras de negócio. Um resultado como verified: true é uma entrada da autorização, não uma ordem para liberar acesso.
  8. Operar o ciclo de vida. Rotacione chaves comprometidas, suspenda ou revogue credenciais, atualize status, ofereça recuperação e recursos, preserve evidências de auditoria e publique planos de migração ou encerramento. Verificação histórica exige regras claras para chaves, documentos e momento da apresentação antigos.

Os três papéis principais são emissor, titular e verificador; o sujeito da credencial pode diferir do titular. Um responsável pode guardar credencial sobre uma criança, e um agente empresarial pode apresentar credencial sobre uma organização. A implementação não deve presumir que o apresentador é o sujeito sem vínculo estabelecido pela credencial e pelo protocolo.

DIDs e VCs são independentes. Uma VC pode usar identificador de emissor que não seja DID, e um DID pode existir sem VC. Um método DID também pode usar blockchain, banco distribuído, domínio web ou troca ponto a ponto. As propriedades de segurança e governança do método devem ser avaliadas diretamente, não inferidas do prefixo did:.

Exemplo prático

Suponha que um serviço precise confirmar que o cliente tem pelo menos 18 anos sem coletar a data de nascimento. Uma autoridade aceita comprova o cliente e emite uma credencial de idade à carteira. A credencial pode conter a data ou apenas uma declaração ageOver18; as opções têm propriedades diferentes de divulgação e reutilização.

No cadastro, o serviço pede para merchant.example uma apresentação de idade acima de 18, com desafio n-7f3a e janela de 5 minutos. A carteira mostra a solicitação e, se credencial e suíte permitirem, deriva uma apresentação que revela só o predicado necessário. O serviço verifica método, prova, desafio, domínio, janela e status antes de registrar o resultado mínimo necessário à auditoria.

O fluxo reduz a necessidade de reter imagens de documentos ou datas completas, mas não elimina confiança nem risco. A autoridade pode cadastrar a pessoa errada; carteira ou aparelho podem ser comprometidos; identificador estável ou consulta de status pode correlacionar usos; o serviço pode pedir dados demais; suspensão incorreta pode negar acesso. Divulgação seletiva limita os dados da apresentação, não todos os metadados visíveis a emissores, carteiras, redes e verificadores.

A rotação de chaves mostra outro limite. Se o emissor substitui uma chave comprometida, novas credenciais devem usar o novo método. A verificabilidade de uma credencial antiga depende do histórico do método DID, data da prova, política do verificador e status da credencial. Excluir a chave antiga do documento DID atual pode quebrar verificações históricas legítimas ou ocultar qual chave era autorizada quando a prova foi criada.

Riscos e controles

  • Declarações falsas ou amplas: Uma assinatura válida preserva o que o emissor disse; não torna a declaração correta. Defina evidência, responsabilidade, garantia, auditoria, validade e correção.
  • Vínculo fraco com o titular: Credencial copiada pode ser usada por outra pessoa se a apresentação não provar controle da chave ou autenticador pretendido. Quando adequado, vincule prova de posse a verificador, desafio, propósito e sessão.
  • Comprometimento de chave e carteira: Malware, phishing, tomada da carteira em nuvem ou backup inseguro expõem credenciais e chaves. Use autenticação resistente a phishing, proteção por hardware quando cabível, denúncia e recuperação limitada.
  • Centralização da recuperação: Um administrador único pode se tornar o verdadeiro controlador da identidade. Documente quem troca chaves, qual evidência exige, como detectar abuso e como o usuário recorre ou migra.
  • Correlação: Reutilizar DID, método, padrão de assinatura, endpoint ou rota de status pode ligar atividades entre serviços. Use identificadores por par, chaves ou provas separadas por domínio, status privado e testes de metadados.
  • Dados pessoais públicos: Documentos DID e histórico do registro podem ser indexados e difíceis de apagar. Mantenha nomes, números, biometria e outras declarações pessoais fora de documentos DID públicos e registros imutáveis.
  • Privacidade e disponibilidade de status: Contatar o emissor em toda consulta revela onde a credencial é usada; falha do serviço bloqueia usuários válidos. Prefira status privado e armazenável em cache, com limite de atualidade, atualização autenticada e falha aberta ou fechada definida.
  • Abuso de revogação: Emissor ou administrador pode censurar titulares suspendendo credenciais ou alterando status. Limite autoridade, registre mudanças, exponha motivo e recurso e aceite substituição ou emissores alternativos quando possível.
  • Risco de resolução e método: Um resolvedor pode retornar documentos obsoletos ou maliciosos, e um método depender de infraestrutura central ou governança mutável. Autentique resultados e avalie finalidade, autorização de atualização, disponibilidade, governança e versões.
  • Incompatibilidade semântica: Dois sistemas podem analisar os mesmos campos e interpretar diferentemente uma declaração, unidade, jurisdição ou garantia. Use esquemas e vocabulários estáveis, valide contexto e tipo e versione a semântica da política.
  • Repetição e confusão do verificador: Apresentação sem nonce, público, domínio, ação e expiração pode ser reutilizada ou redirecionada. Valide todo vínculo exigido pelo protocolo.
  • Divulgação excessiva: Mesmo com divulgação seletiva, o verificador pode exigir a credencial completa. Imponha minimização na política e interface, registre propósito e impeça que campos opcionais virem obrigatórios por hábito.
  • Aprisionamento no ecossistema: Carteiras, provas, registros ou recuperação proprietários prejudicam portabilidade. Teste conformidade, exportação, várias carteiras, agilidade criptográfica e migração antes da implantação.
  • Captura da governança: Multisig ou registro não garantem controle amplo se um fornecedor escolhe emissores, atualizações, esquemas e status. Mapeie autoridade por componente e publique controles de mudança.

Equívocos comuns

  • “Um DID prova quem uma pessoa é.” O DID identifica um sujeito e pode expor métodos de verificação; atributos exigem declarações, evidências e decisões de confiança adicionais.
  • “Uma credencial válida torna a declaração verdadeira.” A verificação mostra a prova esperada e que os dados não mudaram; não valida a investigação ou julgamento original do emissor.
  • “O titular sempre é o sujeito da credencial.” Os papéis podem diferir; o verificador precisa de vínculo explícito entre sujeito e apresentador quando o caso exigir.
  • “Tudo deve ficar on-chain.” Armazenamento público e imutável amplia riscos de privacidade, correlação, exclusão e governança. Muitos sistemas mantêm credenciais off-chain e publicam só material de verificação ou status.
  • “Divulgação seletiva garante anonimato.” Atributos revelados, identificadores estáveis, impressões da prova, consultas, tempo, IP e logs do emissor ainda podem correlacionar apresentações.
  • “Descentralizado significa sem emissor ou administrador confiável.” A confiança é distribuída e explícita, não removida. Emissão, comprovação, distribuição de carteira, recuperação, status e aceitação continuam governados.
  • “Um DID equivale a uma pessoa.” Uma pessoa controla vários DIDs, e um DID pode identificar organização, aparelho, dados, função ou outro sujeito. Unicidade e humanidade exigem mecanismos separados.
  • “Assinatura de carteira basta para autenticar.” Ela prova controle de chave em condições específicas. A aplicação ainda precisa de resistência a phishing, atualidade, vínculo ao público, autorização e recuperação de conta.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...