Palavras demais sobre DIDs

 (steveklabnik.com)
1 pontos por GN⁺ 5 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Contas do Bluesky não ficam presas a um app específico e podem ser usadas em vários apps baseados em atproto; DIDs (identificadores descentralizados) fornecem uma base de verificação de identidade separada dos apps
  • Um DID tem o formato did:<method>:<identifier> e usa a chave pública e a localização do PDS contidas no DID Document para verificar a associação entre o autor de uma publicação e a conta
  • did:web é uma abordagem simples que consulta /.well-known/did.json de um domínio, mas é vulnerável à dependência de DNS e registradores, à interrupção do servidor web e a atrasos na propagação de alterações no documento
  • O did:plc, criado pelo Bluesky, separa o ID de um domínio específico e transfere a carga operacional para o plc.directory, mas, em vez do DNS, exige confiar no plc.directory; no Bluesky, não é possível usar métodos de DID baseados em blockchain, entre outros
  • Usuários podem registrar chaves adicionais, fazer rotação de chaves e operar seu próprio PDS para remover chaves criadas pelo Bluesky e controlar de fato a própria identidade, oferecendo essa opção a quem quiser sem impor a todos um gerenciamento complexo de chaves

Contas do Bluesky e identidade baseada em DID

  • Uma “conta do Bluesky” não é uma conta usada apenas no Bluesky, mas uma conta que pode ser usada em várias aplicações da ATmosphere
  • O atproto, protocolo-base do Bluesky e de outros apps, usa DID para representar quem é o usuário e para verificar logins ou autores de publicações
  • DID, padronizado pelo W3C em 2022, é um identificador descentralizado que pode ser usado como base de identidade em aplicações
  • A descentralização do DID está no fato de que, em vez de uma única entidade decidir quais tipos de DID são válidos, o usuário pode escolher o método DID para verificar sua própria identidade
  • No entanto, aplicações não conseguem processar automaticamente todos os métodos DID
    • É preciso implementar código de suporte separadamente para cada método
    • Se um app não suporta o método foo, ele não conseguirá interpretar did:foo:1243 mesmo que esse DID seja apresentado

DID e DID Document

  • O DID de exemplo did:plc:3danwc67lo7obz2fmdg6jxcr é composto por três partes separadas por dois-pontos
    • Esquema: did
    • Método: plc
    • Identificador específico do método: 3danwc67lo7obz2fmdg6jxcr
  • Para usar um DID, é preciso resolvê-lo para um DID Document
  • Um DID Document contém dados como chaves públicas criptográficas para que o sujeito do DID ou um delegado possa se autenticar e provar sua associação com aquele DID
  • O documento de exemplo inclui as informações necessárias para a verificação de identidade
    • id: o próprio DID
    • alsoKnownAs: at://steveklabnik.com
    • verificationMethod: tipo Multikey e publicKeyMultibase
    • service: endpoint de PDS do tipo AtprotoPersonalDataServer
  • Quando uma publicação qualquer afirma ter sido escrita por um determinado usuário, é possível verificar a veracidade dessa afirmação usando as informações de verificação do documento
  • O procedimento para resolver um DID em um documento é definido pelo padrão de cada método
    • did:plc segue o padrão PLC
    • Outro método suportado pelo Bluesky, did:web, é resolvido pelo método Web

Como did:web é resolvido

  • Pouquíssimas pessoas usam did:web, mas sua estrutura simples facilita entender o processo de resolução de DID
  • O did:web:lizthegrey.com de Liz Fong-Jones é resolvido inserindo o identificador específico do método, lizthegrey.com, no seguinte template de URL
https://<id>/.well-known/did.json
  • O DID Document recebido nessa URL contém as seguintes informações
    • id: did:web:lizthegrey.com
    • alsoKnownAs: at://web.lizthegrey.com, did:plc:i4tfenpfog244rxry5uz4vtk
    • verificationMethod: chave pública Multikey para atproto
    • serviceEndpoint: https://pds.lizthegrey.com

Limitações do did:web

  • did:web depende de DNS e registradores de domínio
    • Se o registrador tomar de volta o domínio, o controle sobre o DID também é perdido
    • Se o domínio deixar de ser usado ou expirar e outra pessoa o comprar, a identidade também pode ser perdida
    • O mesmo vale caso a conta no registrador seja hackeada e o domínio seja sequestrado
  • É preciso manter em execução o servidor web que fornece o DID Document; se o servidor sair do ar, o documento também não poderá ser obtido
  • Também não há uma forma de avisar imediatamente os clientes de que o DID Document mudou
    • A aplicação pode continuar usando um documento antigo
    • O atraso entre a atualização do documento e sua adoção pela aplicação pode causar problemas temporários até que o documento mais recente seja buscado novamente

Como did:plc muda a manutenção da identidade

  • O Bluesky desenvolveu did:plc para reduzir os problemas do did:web
  • did:plc busca o DID Document inserindo o DID completo no seguinte template de URL
https://plc.directory/<did>;
  • O fato de consultar uma URL é igual ao did:web, mas o modo de operação e de manutenção da identidade é diferente
    • Como o DID não fica preso a um domínio específico, é possível deixar steveklabnik.com expirar e migrar para steve.klabnik.com mantendo o mesmo DID
    • A operação do servidor web fica a cargo do plc.directory em vez do usuário, reduzindo a carga operacional
  • Isso não significa que o alvo de confiança desapareça
    • Em did:web, é preciso confiar no DNS e no registrador de domínio
    • Em did:plc, é preciso confiar que o plc.directory não tomará o ID nem será comprometido
  • Usuários que consideram tanto o DNS quanto o plc.directory não confiáveis podem escolher outros métodos DID que resolvem nomes por blockchain, por exemplo
  • Porém, como o Bluesky não suporta esses métodos, eles não podem ser usados nas aplicações do Bluesky

Problema de acessibilidade e novos métodos DID

  • Configurar did:web diretamente exige tarefas pesadas para usuários não especialistas
    • Registrar um domínio e continuar pagando por ele
    • Configurar um servidor web e escrever o JSON para o DID Document
    • Manter o servidor em funcionamento
    • Armazenar e gerenciar a chave privada com segurança
  • Esse processo é muito mais complexo do que se cadastrar em um app web comum e não combina com o objetivo do Bluesky de permitir que usuários não especialistas também usem a plataforma
  • Se o plc.directory gerencia as tarefas relacionadas, o usuário não precisa executar essas etapas diretamente
  • did:webvh é uma abordagem que estende did:web para corrigir algumas de suas desvantagens e chegou à versão 1.0, mas a comparação não inclui os detalhes específicos da especificação

Como possuir diretamente sua identidade no Bluesky

  • Na configuração padrão, o Bluesky gera o par de chaves do usuário e pode acessar a chave secreta, então, em certo sentido, é possível dizer que o Bluesky possui a identidade
  • did:plc permite registrar pares de chaves adicionais no ID e fazer rotação da chave de assinatura
    • É possível remover a chave gerada pelo Bluesky
    • É possível substituí-la por uma chave criada pelo próprio usuário
  • Trocar a chave por si só não separa totalmente o usuário da infraestrutura do Bluesky
    • Para o PDS assinar publicações, ele precisa usar a chave do usuário
    • Ao usar um PDS gerenciado pelo Bluesky, em geral a chave fica armazenada na infraestrutura do Bluesky
  • Para separar a identidade do Bluesky, é preciso operar um PDS próprio e depois fazer a rotação da chave
    • A chave passa a ficar armazenada na infraestrutura pertencente ao usuário
    • Depois disso, o Bluesky não controla essa chave
  • Mesmo que a maioria dos usuários não escolha operar um PDS próprio nem gerenciar chaves, o fato de usuários motivados poderem possuir de fato sua identidade é uma propriedade de design importante
  • Em vez de obrigar todos os usuários a gerenciar chaves diretamente, permitir que usuários interessados escolham essa opção é o caminho adequado para a maioria

Leituras relacionadas

1 comentários

 
GN⁺ 5 시간 전
Opiniões no Lobste.rs
  • o plc.directory era inicialmente controlado pelo Bluesky, mas atualmente está em processo de se tornar uma entidade sem fins lucrativos suíça independente
  • sinceramente, DID é uma solução melhor do que autenticação unificada (SSO) de grandes empresas de tecnologia. Ainda assim, precisa ser algo que pessoas comuns também consigam usar, como did:plc:, e mesmo sendo de propriedade de uma organização sem fins lucrativos, ainda vale refletir se devemos confiar completamente em uma autoridade central
    Estou desenvolvendo um projeto que reimplementa o Keybase com suporte a W3C DID e W3C Verifiable Credentials (VC). O objetivo é permitir provar, de forma única e privada, que você é humano, e ter uma identidade descentralizada sob seu próprio controle
  • pelo título, achei que levaria para a especificação de DID, mas o texto em si também é curto e útil
    • o primeiro link do texto é justamente o link da especificação
  • fato que descobri hoje: DID não era Docker in Docker
    • foi a primeira vez que descobri que também dá para ler Docker in Docker como DID. Eu sempre ouvi abreviado como DinD ou o ainda mais confuso dind, mas não sei se é um costume do meu trabalho ou uma notação mais geral
    • também não significa Direct Inward Dialing
  • para leitores que não usam Bluesky, você poderia definir o que é PDS?
    • PDS significa Personal Data Server, ou seja, o servidor de origem de conteúdos como posts
    • no Bluesky/AT, em vez de colocar os posts de todos os usuários em um único grande banco de dados, cada usuário tem seu repositório de dados individual chamado PDS. Você pode usar o PDS fornecido pelo Bluesky, hospedar o seu próprio ou usar um serviço de terceiros, e também pode migrar de forma transparente entre PDSs mantendo todo o histórico da conta
      não é a mesma coisa que uma instância do Mastodon, e os conceitos de AT e ActivityPub não correspondem de forma limpa em uma relação de um para um
  • se did:web exige hospedar um servidor .well-known e os dados são quase estáticos, por que não usar DNS diretamente, de uma forma parecida com registros TXT, legível como URL, com alta chance de cache e menor risco de interrupção acidental?
    Ainda restam problemas como a dependência de DNS e a dificuldade de detectar facilmente atualizações em did.json, mas se o objetivo é vincular um domínio específico à identidade de uma pessoa, parece melhor minimizar os componentes e se conectar diretamente à funcionalidade do DNS. Fico curioso se existe algum motivo pelo qual essa abordagem não funciona ou é difícil na prática