Tim Berners-Lee anunciou a decisão de tornar a especificação que define identificadores descentralizados para o status da Web (DID, Identificador Descentralizado) como um padrão recomendado. As objeções levantadas pelo Google e pela Mozilla são rejeitadas.
A especificação DID introduz um novo tipo de identificador global exclusivo que não está vinculado a serviços e organizações centralizadas individuais, como registradores de domínio e autoridades de certificação. Um identificador pode ser associado a um recurso arbitrário e gerado usando sistemas confiáveis pelo proprietário do recurso. Para verificar a autenticidade de um identificador, é utilizada a autenticação de prova de propriedade com base em mecanismos criptográficos, como assinaturas digitais. A especificação permite o uso de vários métodos para controle distribuído e obtenção de informações sobre identificadores, incluindo métodos baseados em blockchain.
O formato do novo URI é formado como "did:method:unique_identifier", onde "did" especifica o novo esquema de URI, "method" indica o mecanismo para processamento do identificador e "unique_identifier" é um identificador de recurso específico para o selecionado. método, por exemplo, "did:example" :123456789abcdefghi.” O campo com o método indica o nome do serviço de armazenamento de dados verificado utilizado, que garante a exclusividade do identificador, determina seu formato e garante a vinculação do identificador ao recurso para o qual foi criado. O identificador URI é convertido em um documento JSON com metadados que descrevem o objeto solicitado e incluem chaves públicas para verificar o proprietário.
As implementações de métodos estão fora do escopo do padrão DID, definidas em suas próprias especificações e mantidas em um registro separado. Atualmente, foram propostos 135 métodos baseados em vários blockchains, algoritmos criptográficos, tecnologias distribuídas, bancos de dados descentralizados, sistemas P2P e mecanismos de identificação. Também é possível criar ligações DID em sistemas centralizados, por exemplo, o método web permite usar uma ligação para nomes de host tradicionais (por exemplo, “did:web:example.com”).
As objeções do Google estão relacionadas à separação da especificação do mecanismo geral de identificadores descentralizados das especificações das implementações finais dos métodos, o que não permite analisar a exatidão da especificação principal sem estudar as especificações dos métodos. Publicar uma especificação principal quando as especificações do método não estão prontas dificulta a revisão por pares, e o Google sugeriu adiar a padronização da especificação DID geral até que várias práticas recomendadas estejam prontas para padronização, uma vez que no processo de padronização de métodos podem surgir questões sutis que exigem refinamento da especificação principal.
A objeção da Mozilla é que a especificação não promove adequadamente a portabilidade, deixando esse problema para o lado do registro do método. O registro já propôs mais de uma centena de métodos, criados sem levar em conta a compatibilidade e unificação de soluções padrão. Na sua forma atual, incentiva a criação de um novo método para cada tarefa, em vez de tentar adaptar os métodos existentes para atender às suas necessidades.
A posição do W3C é que a padronização da especificação DID, que define uma nova classe extensível de identificadores e sintaxe associada, estimulará o desenvolvimento de métodos e o consenso sobre a padronização de métodos. Tal como está, há amplas evidências de que a especificação principal é aplicável às necessidades da comunidade tecnológica descentralizada. As implementações propostas de métodos não devem ser julgadas por analogia com novos esquemas de URL, e a criação de um grande número de métodos pode ser vista como uma satisfação das especificações básicas com as necessidades dos desenvolvedores.
A padronização de certos métodos é vista como uma tarefa mais difícil, em termos de obtenção de consenso entre os desenvolvedores, do que a padronização de uma classe geral de identificadores. Portanto, aprovar uma especificação comum antes de padronizar métodos é visto como uma solução que poderia causar menos danos potenciais à comunidade que implementa identificadores descentralizados.
Fonte: opennet.ru