A Especificação dos Identificadores Descentralizados (DIDs) do W3C (PT-PT)

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 tornou-se uma Recomendação 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 numa fase de normalização diferente.

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

Principais conclusões

• Um DID é um URI, não uma credencial. A 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 torna-se 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 registo, 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, gerir chaves e histórico, proteger a privacidade e aplicar a política da aplicação.

O que é um identificador descentralizado?

Um identificador descentralizado é um identificador projetado para que o controlo possa ser estabelecido sem a necessidade de um provedor de identidade central ou autoridade de certificação para emitir e manter cada identificador. A palavra “descentralizado” descreve a capacidade da arquitetura de separar o controlo do identificador de um único emissor central; não significa que cada implementação seja anónima, pública, imutável ou armazenada num livro-razão distribuído.

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

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

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

Estes 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 acedido através de um serviço;
• uma versão ou opção definida pelo método.

O fragmento #key-1 geralmente identifica um método de verificação. Não significa que a chave privada esteja no documento. Os documentos DID publicam material de verificação pública ou referências; material secreto deve permanecer protegido noutro local.

A arquitetura DID

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

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 para 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
Registo de dados verificáveis	Infraestrutura que um método usa para criar, ler, atualizar ou desativar o estado DID
Resolvedor DID	Software ou hardware que executa a resolução DID para métodos suportados
Desreferenciador de URL DID	Software ou hardware que obtém um recurso identificado por um URL DID

Sujeito versus controlador

O sujeito e o controlador podem ser a mesma entidade, mas não precisam de 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 DID Core. O 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 exemplos 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; os sistemas de produção devem usar um método real e os seus requisitos atuais de suite 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 parser.

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 se afirma identificar o mesmo sujeito.
• verificationMethod: mecanismos de verificação pública 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 a emissão de credenciais.
• keyAgreement: métodos destinados à derivação de material secreto partilhado.
• 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. As aplicações devem verificar independentemente a relação exigida pelo 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. A 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 central para application/did. A 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 canonicalização e mecanismo de segurança definidos não é equivalente 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. Requer:

• um id expresso como um 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 de métodos de verificação. Um JWK num 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 fins. A autorização provém das cinco relações de verificação explícitas.

Relação	Propósito de prova pretendido
authentication	Autenticar como o sujeito DID através de desafio-resposta ou outro mecanismo aceite
assertionMethod	Expressar reivindicações, incluindo assinar uma Credencial Verificável onde o mecanismo de segurança escolhido a utiliza
keyAgreement	Estabelecer material criptográfico partilhado, frequentemente para encriptação
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 sob authentication não está automaticamente autorizada para asserções de credenciais ou acordo de chaves.

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 comunicar ou interagir com o sujeito DID. Cada entrada de serviço tem:

• 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, pelo que as aplicações devem compreender o tipo escolhido.

A publicação de um endpoint não prova que o seu servidor, operador, transporte, conteúdo ou destino sejam confiáveis.

A aplicação deve autenticar o estado DID resolvido através do método, validar o tipo de serviço, aplicar controlos de segurança de URL e rede, e usar um protocolo de aplicação com as suas próprias propriedades de segurança.

Os endpoints de serviço públicos também podem criar correlação. A reutilização de um endpoint em DIDs emparelhados 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 submetidas e verificadas;
• como um DID é desativado;
• como a resolução comunica com o registo;
• como a autenticidade e integridade dos resultados são estabelecidas;
• como a rotação de chaves, recuperação, versionamento e histórico funcionam;
• considerações de segurança e privacidade específicas do método.

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

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

Antes de selecionar um método, teste:

• maturidade e governação 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 fuga de metadados;
• disponibilidade do registo 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 pega num DID e opções de resolução e retorna:

1. metadados de resolução DID;
2. um documento DID, fluxo de documentos 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 resultado comuns; a comunicação e autenticação específicas do método permanecem com o método.

A desreferenciação de URL DID pega num URL DID completo 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. A sua última publicação é um W3C Working Draft datado de 24 de julho de 2026, e a desreferenciação de URL DID é marcada como uma funcionalidade em risco. Permanece um trabalho em fase de normalização, em vez de parte da Recomendação DID Core 1.0 de 2022, por isso fixe o rascunho antes de reivindicar conformidade.

Confiança e caching 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;
• frescura e invalidação da cache;
• opções de versão e tempo;
• tratamento de erros e comportamento de degradação;
• fuga de privacidade através de pesquisas;
• comportamento durante falha de registo 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 credenciais;
• um sujeito de credenciais;
• um titular.

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

O Modelo de Dados de Credenciais Verificáveis W3C 2.0 define credenciais, apresentações, emissor, titular, sujeito, validade, status, esquemas e mecanismos de segurança. Não exige que cada 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 cada reivindicação de credencial é verdadeira;
• que o emissor é confiável para essa reivindicação;
• que a credencial é atual ou aceitável;
• que o seu status, esquema ou evidência cumpre a 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, dados biométricos, credenciais ou outros dados pessoais apenas porque o modelo é extensível. A encriptação não é uma resposta duradoura para criptogramas permanentemente públicos.

Evite a correlação

DIDs emparelhados 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 registo podem ligar DIDs supostamente separados.

Rode e recupere chaves

Planeie o compromisso 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 só 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 já não conter uma chave antiga. A verificação de uma prova histórica pode exigir uma versão histórica suportada pelo método e evidências confiáveis 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 blockchain

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

Tratar o DID como prova de identidade legal

Um DID suporta o controlo de identificadores e a verificação criptográfica. A vinculação da identidade do mundo real requer evidência separada, asserções do emissor ou uma estrutura de confiança.

Usar qualquer chave listada para qualquer finalidade

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

Confiar nos endpoints de serviço automaticamente

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

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

A atividade do registo, resolução, material reutilizado e serviços podem expor correlação duradoura.

Uma checklist de implementação

Antes da produção, confirme que:

• a versão do DID Core e as especificações do método DID selecionadas 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 aceites 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;
• caching, versionamento, verificação histórica e desativação são testados;
• atualização, rotação, compromisso, recuperação e migração têm procedimentos ensaiados;
• documentos públicos não contêm dados pessoais ou correlacionados desnecessários;
• os endpoints de serviço recebem revisão de segurança de camada de aplicação separada;
• a confiança, status, esquema e verificações de 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 de uma decisão governada antes de emitir ou aceitar reivindicações. A Verificação de Identidade 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 produto 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 controlo 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 define a especificação W3C DID?

Define a sintaxe DID e URL DID, um modelo de dados comum, propriedades centrais do documento 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 livro-razão, base de dados, sistema peer-to-peer, sistema de ficheiros descentralizado ou outra arquitetura de registo.

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 os 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 um URL DID completo, potencialmente após resolver o 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 inviolável e verificável por máquina sob o modelo de dados VC e um mecanismo de segurança. As VCs podem usar DIDs, mas não os exigem universalmente.

Controlar um DID prova quem é uma pessoa?

Não. Pode provar o controlo de autoridade criptográfica ou específica do método associada ao DID. A vinculação desse controlo 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ública ou referências. O material de chave privada não deve aparecer e deve permanecer protegido pelo sistema de gestão 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 a sua reivindicação permanece precisa. Ele padroniza identificadores, documentos, propósitos de verificação, serviços e interfaces de método. A confiança ainda provém da governação do método, resolução autenticada, chaves protegidas, propósito explícito da prova, design consciente da privacidade e da decisão da aplicação sobre que evidência aceitar.