did:web explicado
Todo o credential digital é assinado por alguém, e um verificador tem de conseguir descobrir quem é e que chaves essa parte usa hoje. O did:web responde a isso com a infraestrutura que quase todas as organizações já têm: o seu próprio nome de domínio. O identificador diz-lhe a que domínio perguntar, a resposta é um ficheiro comum servido por HTTPS, e não é preciso que exista mais nada para funcionar.
O que é realmente o did:web
Uma DID é um identificador permanente que qualquer pessoa pode consultar para encontrar as chaves públicas de quem a detém. Um método DID é a regra que descreve essa consulta, e existem dezenas. Uns escrevem o assento numa blockchain, outros numa rede construída para o efeito, e cada um obriga o verificador a aprender como funciona esse sistema em particular.
O did:web segue o caminho inverso. A consulta é um pedido HTTPS ao domínio indicado no identificador, e o assento é um ficheiro JSON que o titular do domínio publica e edita como qualquer outra página do seu site. Não há rede a que aderir, registo onde escrever, nem taxa a pagar.
É por isso que aparece tão cedo em quase todos os projetos. Uma equipa capaz de colocar um ficheiro no seu servidor web pode estar a emitir e a verificar credentials nessa mesma tarde, e o identificador que obtém é uma DID verdadeira, aceite por qualquer wallet ou verificador conforme, e não um substituto provisório.
Como o identificador se torna um URL
O mapeamento é mecânico, e é esse o objetivo. Um domínio simples leva a um ficheiro no diretório well-known que os sites já usam para metadados legíveis por máquina. Se acrescentar, depois do domínio, segmentos separados por dois pontos, estes passam a segmentos de caminho, de modo que uma organização pode publicar um identificador distinto por departamento, por ambiente ou por serviço de emissão sem registar nada de novo.
Há dois detalhes que escapam com frequência. Um número de porta obriga a codificar os seus dois pontos em percentagem, porque dois pontos simples já separam as partes do identificador. E o ficheiro tem de ser servido por HTTPS com um certificado que valide, uma vez que o transporte é a única coisa entre um verificador e uma resposta forjada.
O identificador que alguém lhe dá
did:web:example.com:issuer:euO URL HTTPS para o qual é mapeado, sem serviço de pesquisa pelo meio
https://example.com/issuer/eu/did.jsonO DID document devolvido, com as chaves e os endpoints
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Porque é que as organizações o escolhem
A primeira razão é o reconhecimento. Um verificador que vê um identificador a apontar para o domínio de uma empresa pode confirmar, da forma mais simples que existe, que o nome no credential corresponde ao nome do site. Não é preciso explicar a ninguém uma consulta a um registo nem uma cadeia de certificados para que a ideia passe.
A segunda é que operá-lo não custa nada. O documento fica atrás do mesmo alojamento, da mesma monitorização e do mesmo processo de alterações que o resto do site. Não há um sistema à parte para financiar, manter disponível ou explicar a um auditor, e rodar uma chave é um deployment em vez de uma transação.
A terceira é a portabilidade. Como todas as bibliotecas de wallet e de verificação o suportam, o did:web é o método com maior probabilidade de funcionar com um parceiro com quem nunca integrou, o que faz dele a escolha natural para pilotos, ambientes de teste e os eventos de interoperabilidade onde se encontram as implementações europeias de wallet.
Onde o did:web para
Tudo o que o método lhe dá assenta no domínio. Quem controla o registo, os servidores de nomes e o certificado controla o identificador, por isso uma renovação caducada, uma conta de DNS sequestrada ou um certificado emitido por erro bastam para falar em seu nome. Por baixo não existe uma segunda assinatura a que recorrer.
Também não tem memória. Um verificador vê o documento tal como está neste momento e não tem forma de saber o que dizia na semana passada, por isso uma chave substituída é indistinguível de uma chave rodada. O did:webvh existe exatamente para isso: o mesmo alojamento web, mais um registo assinado de cada alteração ao qual só se pode acrescentar, para que um verificador possa seguir o histórico desde a primeira entrada até ao estado atual.
E não é uma verificação de identidade. Publicar um documento sob um domínio prova o controlo desse domínio e mais nada. Quando um verificador precisa de saber que uma pessoa coletiva é quem diz ser, essa garantia vem de uma Trusted List, de um certificado qualificado ou de um Trust Framework construído para o efeito, com o método DID apenas a transportar as chaves por baixo.
O que isto significa para si
Emissor
Trate o documento como infraestrutura de produção desde o primeiro dia. Coloque-o sob controlo de alterações, monitorize se o URL responde e se o certificado é válido, e mantenha uma chave descontinuada listada para verificação enquanto houver algo assinado por ela ainda em uso.
Parte confiante
Obter o documento não é o mesmo que confiar nele. Decida separadamente que domínios aceita, recuse tudo cujo certificado não valide, e use a cache com cuidado: uma cópia desatualizada mantém viva uma chave revogada, e uma cópia em falta derruba o seu serviço juntamente com o do outro lado.
Titular da wallet
O domínio no identificador de um emissor merece um olhar. É a única parte de um credential que consegue ler sem ferramentas, e um nome que não corresponde à organização esperada é motivo para parar em vez de continuar.
Termos relacionados
Perguntas frequentes
Preciso de software especial para resolver um identificador did:web?
Não. O identificador é uma receita para construir um URL, e obter esse URL por HTTPS devolve o documento. Qualquer cliente HTTP consegue fazê-lo, e é por isso que did:web costuma ser o primeiro método que uma equipa põe a funcionar. Ainda assim, em produção vale a pena usar uma biblioteca de resolução genérica, porque aplica as regras de codificação e as verificações sobre o documento de forma consistente em vez de as deixar a cada chamador.
did:web é menos fiável por não existir blockchain?
É fiável de outra maneira. Um método assente num registo distribuído reparte o assento por muitas partes, para que nenhuma o possa reescrever em silêncio. did:web coloca essa responsabilidade no titular do domínio e nas autoridades de certificação por trás do seu TLS. Para uma organização cujo nome e site já são aquilo que os clientes reconhecem, esse é muitas vezes o lugar mais honesto para essa confiança, desde que todos percebam que o domínio é o ponto fraco.
O que acontece aos credentials já emitidos quando as chaves mudam?
Um verificador obtém o documento tal como está agora, por isso um credential assinado com uma chave entretanto removida deixa de se verificar. Mantenha no documento uma chave descontinuada, marcada de modo a poder verificar mas já não assinar, pelo menos enquanto os credentials que assinou continuarem válidos. Se precisar que um verificador consiga provar que chave estava em vigor numa determinada data, é aí que did:webvh justifica a complexidade adicional.
Fontes
Esta página é informativa e não constitui aconselhamento jurídico. Para orientação com valor normativo, consulte diretamente as especificações do W3C.