Trop de mots sur les DID

 (steveklabnik.com)
1 points par GN⁺ 5 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Un compte Bluesky n’est pas lié à une application précise : il peut être utilisé dans plusieurs applications basées sur atproto, et les DID (identifiants décentralisés) fournissent une base de vérification d’identité séparée des applications
  • Un DID a la forme did:<method>:<identifier> ; les clés publiques et l’emplacement du PDS contenus dans le DID Document permettent de vérifier le lien entre l’auteur d’une publication et son compte
  • did:web est une méthode simple qui consulte /.well-known/did.json sur un domaine, mais elle est vulnérable à la dépendance au DNS et aux bureaux d’enregistrement, aux interruptions du serveur web et aux délais de prise en compte des modifications du document
  • did:plc, créé par Bluesky, sépare l’ID d’un domaine donné et confie la charge d’exploitation à plc.directory, mais il faut faire confiance à plc.directory plutôt qu’au DNS, et Bluesky ne permet pas d’utiliser des méthodes de DID basées sur la blockchain, par exemple
  • En enregistrant des clés supplémentaires, en effectuant une rotation des clés et en exploitant leur propre PDS, les utilisateurs peuvent retirer la clé créée par Bluesky et contrôler effectivement eux-mêmes leur identité, tout en offrant ce choix à ceux qui le souhaitent sans imposer à tout le monde une gestion complexe des clés

Comptes Bluesky et identité basée sur les DID

  • Un « compte Bluesky » n’est pas un compte utilisable uniquement sur Bluesky, mais un compte utilisable dans plusieurs applications de l’ATmosphere
  • atproto, le protocole sous-jacent de Bluesky et d’autres applications, utilise les DID pour représenter qui est l’utilisateur et pour vérifier les connexions ou l’auteur des publications
  • Les DID standardisés par le W3C en 2022 sont des identifiants décentralisés pouvant servir de base à l’identité dans les applications
  • Le caractère décentralisé des DID tient au fait que, plutôt qu’une seule organisation décide des types de DID valides, l’utilisateur peut choisir la méthode DID qui servira à vérifier son identité
  • En revanche, les applications ne peuvent pas traiter automatiquement toutes les méthodes DID
    • Chaque méthode nécessite une implémentation de support distincte
    • Si une application ne prend pas en charge la méthode foo, elle ne pourra pas résoudre did:foo:1243, même si on la lui présente

DID et DID Document

  • L’exemple de DID did:plc:3danwc67lo7obz2fmdg6jxcr se compose de trois parties séparées par des deux-points
    • Schéma : did
    • Méthode : plc
    • Identifiant propre à la méthode : 3danwc67lo7obz2fmdg6jxcr
  • Pour utiliser un DID, il faut le résoudre en DID Document
  • Un DID Document contient des données comme des clés publiques cryptographiques, afin que le sujet du DID ou son délégataire puisse s’authentifier et prouver son lien avec ce DID
  • Le document d’exemple contient les informations nécessaires à la vérification d’identité
    • id : le DID lui-même
    • alsoKnownAs : at://steveklabnik.com
    • verificationMethod : un type Multikey et publicKeyMultibase
    • service : un endpoint PDS de type AtprotoPersonalDataServer
  • Lorsqu’une publication arbitraire affirme avoir été écrite par un utilisateur donné, les informations de vérification du document permettent de vérifier la véracité de cette affirmation
  • La procédure de résolution d’un DID en document est définie par le standard propre à chaque méthode
    • did:plc suit le standard PLC
    • did:web, une autre méthode prise en charge par Bluesky, est résolue selon la méthode Web

Mode de résolution de did:web

  • Très peu de personnes utilisent did:web, mais sa structure est simple, ce qui facilite la compréhension du processus de résolution des DID
  • Le did:web:lizthegrey.com de Liz Fong-Jones est résolu en insérant l’identifiant propre à la méthode, lizthegrey.com, dans le modèle d’URL suivant
https://<id>/.well-known/did.json
  • Le DID Document reçu à cette URL contient les informations suivantes
    • id : did:web:lizthegrey.com
    • alsoKnownAs : at://web.lizthegrey.com, did:plc:i4tfenpfog244rxry5uz4vtk
    • verificationMethod : clé publique Multikey pour atproto
    • serviceEndpoint : https://pds.lizthegrey.com

Les limites de did:web

  • did:web dépend du DNS et des bureaux d’enregistrement de domaines
    • Si le bureau d’enregistrement reprend le domaine, on perd aussi le contrôle du DID
    • Si l’on n’utilise plus le domaine, ou si quelqu’un d’autre l’achète après son expiration, on peut également perdre son identité
    • Il en va de même si le compte auprès du bureau d’enregistrement est piraté et que le domaine est détourné
  • Il faut continuer à faire tourner le serveur web qui fournit le DID Document ; si le serveur tombe, le document ne peut plus être récupéré
  • Il n’existe pas non plus de moyen d’informer immédiatement les clients qu’un DID Document a changé
    • Les applications peuvent continuer à utiliser un document obsolète
    • Le délai entre la mise à jour du document et sa prise en compte par l’application peut provoquer des problèmes temporaires jusqu’à ce que le document le plus récent soit récupéré

Ce que did:plc change dans la conservation de l’identité

  • Bluesky a développé did:plc pour réduire les problèmes de did:web
  • did:plc récupère le DID Document en insérant le DID complet dans le modèle d’URL suivant
https://plc.directory/<did>;
  • Comme did:web, il repose sur la consultation d’une URL, mais son mode d’exploitation et de conservation de l’identité diffère
    • Comme le DID n’est pas lié à un domaine précis, il est possible de laisser expirer steveklabnik.com et de passer à steve.klabnik.com tout en conservant le même DID
    • L’exploitation du serveur web étant prise en charge par plc.directory à la place de l’utilisateur, la charge d’exploitation diminue
  • L’entité de confiance ne disparaît pas pour autant
    • Avec did:web, il faut faire confiance au DNS et aux bureaux d’enregistrement de domaines
    • Avec did:plc, il faut faire confiance à plc.directory pour ne pas confisquer les ID et ne pas se faire compromettre
  • Les utilisateurs qui estiment que ni le DNS ni plc.directory ne sont dignes de confiance peuvent choisir une autre méthode DID résolvant les noms via une blockchain, par exemple
  • Cependant, comme Bluesky ne prend pas en charge ces méthodes, elles ne peuvent pas être utilisées dans l’application Bluesky

Problème d’accessibilité et nouvelle méthode DID

  • Configurer directement did:web impose des tâches difficiles aux utilisateurs non spécialistes
    • Enregistrer un domaine et continuer à payer les frais associés
    • Configurer un serveur web et rédiger le JSON du DID Document
    • Maintenir le serveur en fonctionnement
    • Stocker et gérer de manière sûre une clé privée
  • Ce processus est bien plus complexe que l’inscription à une application web ordinaire, et ne correspond donc pas à l’objectif de Bluesky consistant à rendre la plateforme accessible aussi aux utilisateurs non spécialistes
  • Si plc.directory gère les tâches associées, l’utilisateur n’a pas besoin d’effectuer lui-même ces étapes
  • did:webvh est une méthode qui étend did:web afin de corriger certains de ses défauts et a atteint la version 1.0, mais ses spécifications détaillées ne sont pas incluses dans la comparaison

Comment posséder directement son identité sur Bluesky

  • Dans la configuration par défaut, Bluesky génère la paire de clés de l’utilisateur et peut accéder à la clé secrète ; en un sens, on peut donc dire que Bluesky possède l’identité
  • did:plc permet d’enregistrer des paires de clés supplémentaires sur l’ID et d’effectuer une rotation des clés de signature
    • Il est possible de retirer la clé générée par Bluesky
    • Il est possible de la remplacer par une clé créée directement par l’utilisateur
  • Changer de clé ne suffit pas à se séparer complètement de l’infrastructure de Bluesky
    • Pour qu’un PDS signe des publications, il doit utiliser la clé de l’utilisateur
    • Si l’on utilise un PDS géré par Bluesky, la clé est généralement stockée dans l’infrastructure de Bluesky
  • Pour séparer son identité de Bluesky, il faut exploiter son propre PDS puis effectuer une rotation des clés
    • La clé est stockée dans une infrastructure possédée par l’utilisateur
    • Ensuite, Bluesky ne contrôle plus cette clé
  • Même si la plupart des utilisateurs ne choisiront pas d’exploiter leur propre PDS ni de gérer leurs clés, le fait que les utilisateurs motivés puissent effectivement posséder leur identité est une propriété de conception importante
  • Plutôt que d’imposer à tous les utilisateurs la gestion directe des clés, permettre à ceux qui le souhaitent d’en faire le choix est une approche adaptée à la plupart des utilisateurs

À lire aussi

1 commentaires

 
GN⁺ 5 시간 전
Avis sur Lobste.rs
  • plc.directory était au départ contrôlé par Bluesky, mais est actuellement en cours d’autonomisation en tant qu’organisation à but non lucratif suisse
  • Honnêtement, les DID sont une meilleure solution que l’authentification unifiée (SSO) des grands groupes tech. Encore faut-il qu’ils soient utilisables par le grand public, comme did:plc:, et il faut aussi se demander si l’on peut faire entièrement confiance à une autorité centrale, même si elle appartient à une organisation à but non lucratif
    Je développe un projet qui réimplémente Keybase tout en prenant en charge les DID du W3C et les Verifiable Credentials (VC) du W3C. L’objectif est de permettre de prouver de manière unique mais privée qu’on est un humain, et de disposer d’une identité décentralisée que l’on contrôle soi-même
    • Es-tu en train de développer FOKS, ou s’agit-il d’un autre projet ?
      https://foks.pub/
  • En voyant seulement le titre, je pensais que cela renverrait à la spécification DID, mais en réalité l’article est aussi court qu’utile
    • Le premier lien de l’article est justement le lien vers la spécification
  • Chose apprise aujourd’hui : DID ne signifiait pas Docker in Docker
    • C’est la première fois que j’apprends qu’on peut lire Docker in Docker comme DID. Je l’ai toujours entendu abrégé en DinD ou en dind, ce qui prête encore plus à confusion, mais je ne sais pas si c’est un usage propre à mon entreprise ou une notation courante
    • Cela ne veut pas non plus dire Direct Inward Dialing
  • Pour les lecteurs qui n’utilisent pas Bluesky, pourriez-vous définir ce qu’est un PDS ?
    • PDS signifie Personal Data Server, c’est-à-dire le serveur d’origine où sont stockés les contenus comme les publications
    • Dans Bluesky/AT, au lieu de mettre les publications de tous les utilisateurs dans une seule grande base de données, chaque utilisateur dispose de son propre stockage de données individuel appelé PDS. On peut utiliser le PDS fourni par Bluesky, l’héberger soi-même ou passer par un service tiers, et il est aussi possible de migrer de manière transparente d’un PDS à un autre tout en conservant l’historique complet du compte
      Ce n’est pas la même chose qu’une instance Mastodon, et les concepts d’AT et d’ActivityPub ne correspondent pas proprement terme à terme
  • Si did:web impose d’héberger un serveur .well-known et que les données sont presque statiques, pourquoi ne pas utiliser directement le DNS, lisible un peu comme une URL, probablement mis en cache et moins susceptible de tomber en panne par accident, à la manière d’un enregistrement TXT ?
    Les problèmes de dépendance au DNS et de difficulté à détecter facilement les mises à jour de did.json subsisteraient, mais si l’objectif est d’associer un domaine donné à l’identité d’une personne, il semblerait préférable de réduire au minimum les composants et de s’appuyer directement sur les capacités du DNS. Je me demande s’il existe une raison pour laquelle cette approche ne fonctionnerait pas ou serait difficile à mettre en pratique