Demasiadas palabras sobre los DID

 (steveklabnik.com)
1 puntos por GN⁺ 5 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Una cuenta de Bluesky no está atada a una app específica y puede usarse en varias apps basadas en atproto; los DID (identificadores descentralizados) proporcionan una base de identidad separada de la app
  • Un DID tiene el formato did:<method>:<identifier>, y usa la clave pública y la ubicación del PDS contenidas en el DID Document para verificar la relación entre la cuenta y el autor de una publicación
  • did:web es un método simple que consulta /.well-known/did.json del dominio, pero es vulnerable a la dependencia de DNS y del registrador, a caídas del servidor web y a retrasos al reflejar cambios del documento
  • did:plc, creado por Bluesky, separa el ID de un dominio específico y deja la carga operativa en plc.directory, pero requiere confiar en plc.directory en lugar de DNS, y en Bluesky no se pueden usar métodos DID basados en blockchain u otros similares
  • Los usuarios pueden registrar claves adicionales, rotar claves y operar su propio PDS para eliminar la clave creada por Bluesky y controlar realmente su identidad por sí mismos, sin imponer a todo el mundo una gestión compleja de claves y dando esa opción a quien la quiera

La cuenta de Bluesky y la identidad basada en DID

  • Una “cuenta de Bluesky” no es una cuenta que solo se use en Bluesky, sino una cuenta que puede usarse en varias aplicaciones de ATmosphere
  • atproto, el protocolo base de Bluesky y de otras apps, usa DID para representar quién es un usuario y para verificar inicios de sesión o autores de publicaciones
  • El DID estandarizado por el W3C en 2022 es un identificador descentralizado que puede usarse como base de identidad en aplicaciones
  • La descentralización de los DID consiste en que, en vez de que una sola entidad decida qué tipos de DID son válidos, el usuario puede elegir el método DID con el que verificará su identidad
  • Aun así, una aplicación no puede procesar automáticamente todos los métodos DID
    • Hay que implementar por separado el código de soporte para cada método
    • Si una app no soporta el método foo, no podrá interpretar did:foo:1243 aunque se le presente

DID y DID Document

  • El DID de ejemplo did:plc:3danwc67lo7obz2fmdg6jxcr está compuesto por tres partes separadas por dos puntos
    • Esquema: did
    • Método: plc
    • Identificador específico del método: 3danwc67lo7obz2fmdg6jxcr
  • Para usar un DID, hay que resolverlo a un DID Document
  • Un DID Document contiene datos como claves públicas criptográficas para que el sujeto del DID o un delegado puedan autenticarse y demostrar su relación con ese DID
  • El documento de ejemplo incluye la información necesaria para verificar la identidad
    • id: el propio DID
    • alsoKnownAs: at://steveklabnik.com
    • verificationMethod: tipo Multikey y publicKeyMultibase
    • service: endpoint de PDS del tipo AtprotoPersonalDataServer
  • Cuando una publicación cualquiera afirma haber sido escrita por un usuario específico, se puede usar la información de verificación del documento para comprobar si esa afirmación es verdadera
  • El procedimiento para resolver un DID a un documento lo define el estándar de cada método
    • did:plc sigue el estándar PLC
    • did:web, otro método soportado por Bluesky, se resuelve con el método Web

Cómo se resuelve did:web

  • Muy poca gente usa did:web, pero su estructura es simple y facilita entender el proceso de resolución de DID
  • El did:web:lizthegrey.com de Liz Fong-Jones se resuelve insertando el identificador específico del método, lizthegrey.com, en la siguiente plantilla de URL
https://<id>/.well-known/did.json
  • El DID Document recibido en esa URL contiene la siguiente información
    • id: did:web:lizthegrey.com
    • alsoKnownAs: at://web.lizthegrey.com, did:plc:i4tfenpfog244rxry5uz4vtk
    • verificationMethod: clave pública Multikey para atproto
    • serviceEndpoint: https://pds.lizthegrey.com

Limitaciones de did:web

  • did:web depende de DNS y del registrador de dominios
    • Si el registrador recupera el dominio, también se pierde el control del DID
    • También se puede perder la identidad si el dominio deja de usarse o expira y otra persona lo compra
    • Lo mismo ocurre si la cuenta del registrador es hackeada y el dominio es secuestrado
  • También hay que mantener en funcionamiento el servidor web que entrega el DID Document; si el servidor cae, el documento deja de poder obtenerse
  • Tampoco hay forma de avisar de inmediato a los clientes cuando cambia el DID Document
    • Las aplicaciones pueden seguir usando un documento viejo
    • Puede haber problemas temporales hasta que vuelvan a obtener el documento más reciente, debido al retraso entre la actualización del documento y su reflejo en la aplicación

Cómo did:plc cambia la forma de mantener la identidad

  • Bluesky desarrolló did:plc para reducir los problemas de did:web
  • did:plc obtiene el DID Document insertando el DID completo en la siguiente plantilla de URL
https://plc.directory/<did>;
  • Igual que en did:web, se consulta una URL, pero la operación y el mantenimiento de la identidad funcionan distinto
    • Como el DID no está atado a un dominio específico, se puede dejar expirar steveklabnik.com y mudarse a steve.klabnik.com manteniendo el mismo DID
    • plc.directory se encarga del servidor web en lugar del usuario, lo que reduce la carga operativa
  • Eso no significa que desaparezca por completo la necesidad de confiar en algo
    • En did:web, hay que confiar en DNS y en el registrador del dominio
    • En did:plc, hay que confiar en que plc.directory no va a quitarte el ID ni será comprometido
  • Los usuarios que consideren que ni DNS ni plc.directory son confiables pueden elegir otros métodos DID que resuelvan nombres mediante blockchain u otros sistemas
  • Sin embargo, como Bluesky no soporta esos métodos, no pueden usarse en la aplicación de Bluesky

Problemas de accesibilidad y nuevos métodos DID

  • Configurar did:web directamente exige tareas que son una carga para usuarios no especializados
    • Registrar un dominio y pagar por él de forma continua
    • Configurar un servidor web y escribir el JSON para el DID Document
    • Mantener el servidor funcionando
    • Guardar una clave privada y administrarla de forma segura
  • Este proceso es mucho más complejo que registrarse en una app web común, y no encaja con el objetivo de Bluesky de hacer que también usuarios no técnicos usen la plataforma
  • Si plc.directory gestiona esas tareas, el usuario no necesita hacer esos pasos por su cuenta
  • did:webvh amplía did:web para compensar algunas de sus desventajas y ya llegó a la versión 1.0, pero no se entra a comparar sus especificaciones en detalle

Cómo poseer directamente tu identidad en Bluesky

  • En la configuración predeterminada, Bluesky genera el par de claves del usuario y puede acceder a la clave privada, así que en cierto sentido puede decirse que Bluesky posee la identidad
  • did:plc permite registrar pares de claves adicionales y rotar las claves de firma
    • Se puede eliminar la clave generada por Bluesky
    • Se puede reemplazar por una clave creada directamente por el usuario
  • Cambiar la clave por sí solo no separa por completo la identidad de la infraestructura de Bluesky
    • El PDS necesita usar la clave del usuario para firmar publicaciones
    • Si se usa un PDS administrado por Bluesky, por lo general la clave queda almacenada en la infraestructura de Bluesky
  • Para separar la identidad de Bluesky, hay que operar un PDS propio y luego rotar la clave
    • La clave queda almacenada en infraestructura controlada por el usuario
    • Después de eso, Bluesky ya no puede controlar esa clave
  • Aunque la mayoría de los usuarios no elijan operar su propio PDS ni gestionar sus claves, es una propiedad de diseño importante que los usuarios con motivación sí puedan poseer realmente su identidad
  • En lugar de obligar a todos los usuarios a administrar sus claves directamente, parece más adecuado permitir que lo haga quien así lo desee

Lecturas relacionadas

1 comentarios

 
GN⁺ 5 시간 전
Comentarios en Lobste.rs
  • plc.directory al principio estaba controlado por Bluesky, pero actualmente está en proceso de independizarse como organización sin fines de lucro suiza.
  • Sinceramente, DID es una mejor solución que la autenticación integrada (SSO) de las grandes empresas tecnológicas. Pero debería poder usarlo también la gente común, como con did:plc:, y aun si pertenece a una organización sin fines de lucro, hay que pensar si conviene confiar por completo en una autoridad central.
    Estoy desarrollando un proyecto que reimplementa Keybase y da soporte a W3C DID y a las credenciales verificables (VC) de W3C. El objetivo es demostrar de forma única pero privada que alguien es humano, y que cada persona tenga una identidad descentralizada bajo su control.
  • Por el título pensé que llevaría a la especificación DID, pero el artículo en sí también es breve y útil.
    • El primer enlace del artículo es justamente el enlace a la especificación.
  • Lo que aprendí hoy: DID no era Docker in Docker.
    • Recién me entero de que Docker in Docker también podría leerse como DID. Siempre lo había oído abreviado como DinD o como el todavía más confuso dind, aunque no sé si es una práctica de mi trabajo o la forma común de escribirlo.
    • Tampoco significa Direct Inward Dialing.
  • Para los lectores que no usan Bluesky, ¿podrían definir qué es un PDS?
    • PDS significa Personal Data Server, y se refiere al servidor de origen de contenido como las publicaciones.
    • Bluesky/AT, en lugar de meter las publicaciones de todos los usuarios en una única gran base de datos, usa una estructura en la que cada usuario tiene un almacén de datos individual llamado PDS. Puedes usar el PDS que ofrece Bluesky, alojar el tuyo propio o usar un servicio de terceros, y también puedes migrar de forma transparente entre PDS manteniendo todo el historial de la cuenta.
      No es lo mismo que una instancia de Mastodon, y los conceptos de AT y ActivityPub no se corresponden limpiamente uno a uno.
  • Si did:web tiene que alojar un servidor .well-known y los datos además son casi estáticos, ¿por qué no usar DNS directamente, algo que puede leerse de forma parecida a una URL, como un registro TXT, que probablemente se cachee y tenga menos probabilidades de caerse accidentalmente?
    Siguen existiendo el problema de la dependencia de DNS y el de no poder detectar fácilmente actualizaciones de did.json, pero si el objetivo es vincular un dominio específico con la identidad de una persona, parece mejor minimizar los componentes y conectarse directamente a la funcionalidad de DNS. Me pregunto si hay alguna razón por la que este enfoque no funcione o sea difícil en la práctica.