Entendendo os Identificadores Descentralizados (DIDs) do W3C (PT-BR)

A especificação W3C Decentralized Identifiers (DIDs) define uma sintaxe URI, um modelo de dados comum, documentos DID, propriedades centrais, representações, requisitos de método e interfaces abstratas para resolução e desreferenciação de URL DID. O DID Core 1.0 se tornou uma Recomendação do W3C em 19 de julho de 2022. O DID Core 1.1 foi publicado como um Snapshot de Recomendação Candidata em 5 de março de 2026; é um trabalho mais recente em um estágio de padronização diferente.

O DID Core não exige uma blockchain, não prova a identidade legal de uma pessoa, não armazena credenciais dentro de cada documento DID, nem torna todo endpoint resolvido confiável. Ele padroniza a arquitetura de identificador e documento. Um método DID separado define como um DID específico é criado, lido, atualizado e desativado em sua infraestrutura escolhida.

Principais pontos

• Um DID é um URI, não uma credencial. Sua forma genérica é did:<method-name>:<method-specific-id>.
• Sujeito e controlador são papéis diferentes. O sujeito é o que o DID identifica; o controlador é autorizado pelo método a alterar o documento DID.
• As chaves precisam de propósitos explícitos. Um método de verificação se torna utilizável para autenticação, asserção, acordo de chave, invocação de capacidade ou delegação apenas através da relação de verificação correspondente.
• O método fornece as regras operacionais. O DID Core é tecnologicamente neutro; o método define a interação do registro, autorização, atualização, desativação e resolução específica do método.
• A resolução não cria confiança por si só. Os implementadores devem autenticar os resultados do método, impor o propósito da prova, gerenciar chaves e histórico, proteger a privacidade e aplicar a política do aplicativo.

O que é um identificador descentralizado?

Um identificador descentralizado é um identificador projetado para que o controle possa ser estabelecido sem exigir que um provedor de identidade central ou autoridade de certificação emita e mantenha cada identificador. A palavra “descentralizado” descreve a capacidade da arquitetura de separar o controle do identificador de um único emissor central; não significa que toda implementação seja anônima, pública, imutável ou armazenada em um razão distribuída.

Um DID pode identificar:

• uma pessoa;
• uma organização ou grupo;
• um dispositivo ou objeto físico;
• um recurso digital;
• um modelo de dados;
• um conceito abstrato.

A entidade identificada é o sujeito DID. A string por si só não revela o tipo de sujeito.

Sintaxe DID

A sintaxe genérica é:

did:<method-name>:<method-specific-id>

Por exemplo:

did:example:123456789abcdefghi

did é o esquema URI. example é o nome do método DID. A string restante é o identificador específico do método. A especificação do método define o que esse valor significa e como o software o processa.

Um DID com aparência válida não é necessariamente utilizável. O método deve existir e o resolvedor deve suportá-lo.

URLs DID: caminhos, consultas e fragmentos

Uma URL DID começa com um DID e pode adicionar um caminho, consulta ou fragmento:

did:example:123456789abcdefghi/path?service=messages#key-1

Esses componentes podem identificar ou ajudar a selecionar:

• um método de verificação dentro do documento DID;
• uma entrada de serviço;
• outro fragmento de documento DID;
• um recurso acessado por meio de um serviço;
• uma versão ou opção definida pelo método.

O fragmento #key-1 comumente identifica um método de verificação. Isso não significa que a chave privada está no documento. Os documentos DID publicam material de verificação público ou referências; o material secreto deve permanecer protegido em outro lugar.

A arquitetura DID

Os principais conceitos estão relacionados, mas não são intercambiáveis:

n>

Conceito	Função
DID	Identificador globalmente único em conformidade com a sintaxe DID
Sujeito DID	Pessoa, organização, coisa, recurso ou conceito identificado
Controlador DID	Entidade autorizada sob o método DID a alterar o documento DID
Documento DID	Dados associados ao sujeito, incluindo métodos de verificação e serviços permitidos
Método DID	Especificação separada para sintaxe e operações específicas do método
Registro de dados verificáveis	Infraestrutura que um método usa para criar, ler, atualizar ou desativar o estado do DID
Resolvedor DID	Software ou hardware que realiza a resolução DID para métodos suportados
Desreferenciador de URL DID	Software ou hardware que obtém um recurso identificado por uma URL DID

Sujeito versus controlador

O sujeito e o controlador podem ser a mesma entidade, mas não precisam ser. Um pai pode controlar um DID para um filho, uma organização pode controlar um DID para um dispositivo, ou vários fiduciários podem controlar um arranjo de recuperação.

O controller de nível superior identifica um ou mais controladores DID. O controller exigido por um método de verificação identifica quem controla esse método; não é automaticamente o controlador DID de nível superior. Confundi-los pode conceder autoridade não intencional.

O que é um documento DID?

Um documento DID são os dados associados a um sujeito DID sob o modelo de dados do DID Core. Seu id raiz é o DID. Propriedades centrais opcionais podem descrever controladores, identificadores alternativos, métodos de verificação, relações de verificação e serviços.

Este exemplo simplificado usa material público do espaço de exemplo da especificação:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ"
      }
    }
  ],
  "authentication": [
    "did:example:123#key-1"
  ],
  "assertionMethod": [
    "did:example:123#key-1"
  ]
}

did:example é reservado para exemplos; sistemas de produção devem usar um método real e seus requisitos atuais de suíte de métodos de verificação. O JSON acima é intencionalmente JSON válido. Muitos exemplos impressos dentro de especificações técnicas contêm comentários ou elipses para legibilidade e não devem ser copiados diretamente para um analisador.

Propriedades centrais

• id: o DID para o sujeito; obrigatório na raiz do documento.
• controller: um ou mais DIDs autorizados a fazer alterações sob o método.
• alsoKnownAs: outros URIs que afirmam identificar o mesmo sujeito.
• verificationMethod: mecanismos de verificação públicos que podem ser referenciados por relações explícitas.
• authentication: métodos autorizados para autenticação como sujeito.
• assertionMethod: métodos autorizados a expressar reivindicações, como emissão de credenciais.
• keyAgreement: métodos destinados à derivação de material secreto compartilhado.
• capabilityInvocation: métodos autorizados a invocar capacidades.
• capabilityDelegation: métodos autorizados a delegar capacidades.
• service: endpoints ou mecanismos de interação associados ao sujeito.

alsoKnownAs é uma asserção, não uma prova criptográfica de que dois identificadores são equivalentes. Os aplicativos devem verificar independentemente a relação exigida por seu modelo de confiança.

Modelo de dados e representações

O DID Core define um modelo de dados abstrato e regras para produzir e consumir representações. O modelo de dados não é idêntico a uma serialização JSON.

Os requisitos de representação são específicos da versão:

• A Recomendação DID Core 1.0 de 2022 define application/did+json e application/did+ld+json. Sua representação JSON-LD começa com o contexto base https://www.w3.org/ns/did/v1.
• A Recomendação Candidata DID Core 1.1 consolida o tipo de mídia principal para application/did. Sua representação JSON-LD começa com https://www.w3.org/ns/did/v1.1.

Não misture o tipo de mídia ou o contexto base de uma versão com reivindicações de conformidade com a outra. Fixe a versão da especificação que produtores e consumidores implementam.

Os implementadores devem negociar e validar a representação explicitamente. Assinar bytes JSON serializados arbitrários sem uma canonização definida e mecanismo de segurança não equivale a processar o modelo de dados DID corretamente.

Métodos de verificação e relações de verificação

Um método de verificação descreve como uma prova pode ser verificada. Ele requer:

• um id expresso como uma URL DID;
• um type;
• um controller;
• material de verificação apropriado para esse tipo.

O material público pode ser representado através de uma propriedade definida, como publicKeyJwk, ou outra forma permitida pela suíte do método de verificação. Um JWK em um documento DID não deve incluir material de chave privada. O mesmo material de verificação não deve ser duplicado em várias propriedades de material dentro de um método.

Definir um método de verificação não o autoriza para todos os propósitos. A autorização vem das cinco relações de verificação explícitas.

Relação	Propósito da prova pretendido
authentication	Autenticar como o sujeito DID através de desafio-resposta ou outro mecanismo aceito
assertionMethod	Expressar reivindicações, incluindo a assinatura de uma Credencial Verificável onde o mecanismo de segurança escolhido a utiliza
keyAgreement	Estabelecer material criptográfico compartilhado, frequentemente para criptografia
capabilityInvocation	Invocar uma capacidade de objeto
capabilityDelegation	Delegar uma capacidade de objeto

Um verificador deve verificar a relação exigida para a prova. Uma chave listada apenas em authentication não é automaticamente autorizada para asserções de credenciais ou acordo de chave.

As relações podem incorporar um método de verificação completo ou referenciar um por URL DID. As referências melhoram a reutilização, mas exigem desreferenciação correta e comparação exata de identificadores.

Serviços e endpoints de serviço

A propriedade opcional service pode anunciar formas de se comunicar ou interagir com o sujeito DID. Cada entrada de serviço possui:

• um id único;
• um type;
• um serviceEndpoint.

O endpoint pode ser um URI ou outra estrutura permitida. As definições de serviço são extensíveis, então os aplicativos devem entender o tipo escolhido.

Publicar um endpoint não prova que seu servidor, operador, transporte, conteúdo ou destino é confiável.

O aplicativo deve autenticar o estado DID resolvido por meio do método, validar o tipo de serviço, aplicar controles de segurança de URL e rede e usar um protocolo de aplicativo com suas próprias propriedades de segurança.

Endpoints de serviço públicos também podem criar correlação. Reutilizar um endpoint em DIDs pareados pode anular o benefício de privacidade de identificadores separados.

O que um método DID define

O DID Core fornece a arquitetura comum. Um método DID em conformidade define as regras específicas do método necessárias para implementá-lo, incluindo:

• nome do método e sintaxe do identificador específico do método;
• como um DID e o documento DID inicial são criados;
• como o estado atual é lido;
• como as atualizações autorizadas são enviadas e verificadas;
• como um DID é desativado;
• como a resolução se comunica com o registro;
• como a autenticidade e integridade dos resultados são estabelecidas;
• como funcionam a rotação de chaves, recuperação, versionamento e histórico;
• considerações de segurança e privacidade específicas do método.

O registro de dados verificáveis pode ser um razão distribuída, sistema de arquivos descentralizado, rede peer-to-peer, banco de dados ou outro sistema. A arquitetura deve ser avaliada com base na governança, disponibilidade, autorização, privacidade, custo, histórico e resistência a ataques, em vez da palavra “descentralizado”.

Critérios de seleção de método

Antes de selecionar um método, teste:

• maturidade e governança da especificação;
• interoperabilidade do resolvedor e da biblioteca;
• autorização de atualização e desativação;
• rotação e recuperação de chaves;
• suporte a estados históricos;
• privacidade e vazamento de metadados;
• disponibilidade do registro e risco de censura;
• custos de transação ou operacionais;
• agilidade criptográfica;
• migração e falha do método.

Mudar de métodos geralmente significa introduzir um novo identificador e um caminho de migração confiável.

Resolução DID versus desreferenciação de URL DID

A resolução DID recebe um DID e opções de resolução e retorna:

1. metadados de resolução DID;
2. um documento DID, fluxo de documento ou nenhum documento;
3. metadados do documento DID.

O resolvedor usa a operação de “leitura” definida pelo método. O DID Core define interfaces abstratas e conceitos de resultados comuns; a comunicação e autenticação específicas do método permanecem com o método.

A desreferenciação de URL DID recebe uma URL DID completa e retorna:

1. metadados de desreferenciação;
2. o recurso identificado, se disponível;
3. metadados de conteúdo.

A desreferenciação pode primeiro resolver o DID base e depois selecionar um fragmento, serviço ou recurso externo. Não é um sinônimo de resolução.

A especificação W3C DID Resolution separada desenvolve algoritmos detalhados de resolução e desreferenciação. Sua publicação mais recente é um Rascunho de Trabalho do W3C datado de 24 de julho de 2026, e a desreferenciação de URL DID é marcada como um recurso em risco. Permanece um trabalho em andamento de padronização, e não faz parte da Recomendação DID Core 1.0 de 2022, então fixe o rascunho antes de reivindicar conformidade.

Confiança e cache do Resolvedor

Um resolvedor é um limite de segurança e privacidade. Ele vê os identificadores solicitados e pode retornar um estado obsoleto ou manipulado. Avalie:

• verificação de resultados do método;
• autenticação de transporte e resolvedor;
• atualização e invalidação de cache;
• opções de versão e tempo;
• tratamento de erros e comportamento de downgrade;
• vazamento de privacidade por meio de pesquisas;
• comportamento durante falha de registro ou rede.

DIDs e Credenciais Verificáveis

DIDs e Credenciais Verificáveis são especificações complementares, não o mesmo objeto.

Um DID base pode identificar:

• um emissor de credencial;
• um sujeito de credencial;
• um titular.

Um método de verificação usado por um mecanismo de segurança é, em vez disso, identificado por uma URL DID, comumente um DID seguido por um fragmento como #key-1.

O Modelo de Dados de Credenciais Verificáveis 2.0 do W3C define credenciais, apresentações, emissor, titular, sujeito, validade, status, esquemas e mecanismos de segurança. Não exige que todo identificador seja um DID.

Quando um DID é usado para um emissor, um verificador pode resolver o DID do emissor, localizar o método de verificação da prova e confirmar que o método está autorizado sob assertionMethod. Essa verificação criptográfica ainda não estabelece:

• que toda reivindicação de credencial é verdadeira;
• que o emissor é confiável para essa reivindicação;
• que a credencial é atual ou aceitável;
• que seu status, esquema ou evidência atende à política;
• que o sujeito da credencial é a pessoa que a apresenta.

Essas verificações pertencem ao mecanismo de segurança, sistema de status, estrutura de confiança, vinculação de apresentação e política do verificador.

Considerações de privacidade e segurança

Evite dados pessoais em documentos públicos

Os documentos DID podem ser amplamente replicados. Não publique nomes, identificadores governamentais, biometria, credenciais ou outros dados pessoais apenas porque o modelo é extensível. A criptografia não é uma resposta duradoura para textos cifrados permanentemente públicos.

Evite a correlação

DIDs pareados ou específicos do contexto podem reduzir a correlação apenas se outros dados também forem separados. Chaves reutilizadas, endpoints de serviço, identificadores de rede, atributos de credenciais, tempo e atividade de registro podem vincular DIDs supostamente separados.

Gire e recupere chaves

Planeje o comprometimento antes do lançamento. Defina a autorização de atualização, controladores de recuperação, regras de limiar, rotação, tratamento de chaves antigas e desativação. A autoridade de recuperação precisa de separação e auditoria.

Valide o propósito da prova

Verifique não apenas se uma assinatura verifica, mas se o método de verificação foi autorizado para a relação exigida no momento relevante. Evite a substituição entre usos de autenticação, asserção, acordo e capacidade.

Lide com o histórico cuidadosamente

Um documento DID atual pode não conter mais uma chave antiga. A verificação de uma prova histórica pode exigir uma versão histórica suportada pelo método e evidência confiável do tempo da prova. “Chave não presente agora” e “prova nunca foi válida” não são conclusões equivalentes.

Erros comuns na implementação de DID

Chamar o DID Core de especificação de blockchain

O DID Core é tecnologicamente neutro. Blockchains são uma arquitetura de registro possível.

Tratar o DID como prova de identidade legal

Um DID suporta controle de identificador e verificação criptográfica. A vinculação de identidade no mundo real precisa de evidências separadas, asserções do emissor ou uma estrutura de confiança.

Usar qualquer chave listada para qualquer propósito

Aplique a relação de verificação explícita e o propósito da prova.

Confiar automaticamente nos endpoints de serviço

Valide o estado do método e aplique segurança de aplicativo, transporte, URL e conteúdo.

Assumir que todos os DIDs são privados ou anônimos

A atividade de registro, resolução, material reutilizado e serviços podem expor correlação durável.

Uma lista de verificação de implementação

Antes da produção, confirme que:

• as especificações do DID Core e do método DID selecionados estão fixadas;
• a análise de identificadores e URLs DID usa tratamento de URI em conformidade com os padrões;
• as representações e tipos de mídia aceitos são explícitos;
• cada prova impõe a relação de verificação pretendida;
• os resultados do método são autenticados, em vez de confiados a qualquer resolvedor;
• o cache, versionamento, verificação histórica e desativação são testados;
• atualização, rotação, comprometimento, recuperação e migração têm procedimentos ensaiados;
• documentos públicos não contêm dados pessoais ou correlacionados desnecessários;
• endpoints de serviço recebem revisão de segurança da camada de aplicação separada;
• as verificações de confiança, status, esquema e apresentação de Credenciais Verificáveis permanecem separadas.

Onde os DIDs encontram a verificação de identidade

Os DIDs podem identificar sujeitos e material de verificação, mas não realizam a prova de identidade. Um sistema de identidade reutilizável ainda precisa de evidências confiáveis e uma decisão governada antes de emitir ou aceitar reivindicações. A Verificação de ID da Didit pode fornecer evidências de identidade para tal decisão, enquanto o KYC Reutilizável suporta a reutilização de uma verificação anterior em serviços participantes e é listado como gratuito.

Essa adjacência de produtos não implica que toda verificação Didit seja um DID ou que a resolução DID substitua o KYC. As taxas atuais dos módulos estão disponíveis na página de preços. A arquitetura deve manter o controle do identificador, evidências de identidade, emissão de credenciais, apresentação e política da parte confiável como limites de confiança separados.

Perguntas frequentes

O que a especificação W3C DID define?

Ela define a sintaxe de DID e URL DID, um modelo de dados comum, propriedades centrais de documentos DID, representações, requisitos de método e interfaces abstratas de resolução e desreferenciação.

Todo DID usa uma blockchain?

Não. Um método DID pode usar um razão, banco de dados, sistema peer-to-peer, sistema de arquivos descentralizado ou outra arquitetura de registro.

Qual a diferença entre um DID e um documento DID?

O DID é o identificador. O documento DID são dados associados que podem descrever controladores, métodos de verificação e seus propósitos, serviços e outras propriedades definidas.

Qual a diferença entre resolução e desreferenciação?

A resolução obtém um documento DID e metadados para um DID. A desreferenciação obtém o recurso identificado por uma URL DID completa, potencialmente após resolver seu DID base.

Um DID é o mesmo que uma Credencial Verificável?

Não. Um DID é um identificador. Uma Credencial Verificável é um conjunto de reivindicações à prova de adulteração e verificável por máquina sob o modelo de dados VC e um mecanismo de segurança. VCs podem usar DIDs, mas não os exigem universalmente.

Controlar um DID prova quem uma pessoa é?

Não. Pode provar o controle de autoridade criptográfica ou específica do método associada ao DID. Vincular esse controle a uma identidade legal ou do mundo real requer evidências adicionais ou asserções confiáveis.

Um documento DID pode conter chaves privadas?

Não. Os documentos DID contêm material de verificação público ou referências. O material de chave privada não deve aparecer e deve permanecer protegido pelo sistema de gerenciamento de chaves do controlador.

Referências primárias

• W3C Decentralized Identifiers (DIDs) v1.0
• W3C Decentralized Identifiers (DIDs) v1.1
• W3C Decentralized Identifier Resolution
• W3C DID Specification Registries
• W3C Verifiable Credentials Data Model v2.0

O DID Core é mais útil quando sua afirmação permanece precisa. Ele padroniza identificadores, documentos, propósitos de verificação, serviços e interfaces de método. A confiança ainda vem da governança do método, resolução autenticada, chaves protegidas, propósito de prova explícito, design consciente da privacidade e da decisão do aplicativo sobre quais evidências aceitar.