Zu viel Gerede über DIDs

 (steveklabnik.com)
1 Punkte von GN⁺ 5 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Bluesky-Konten sind nicht an eine bestimmte App gebunden, sondern können in mehreren atproto-basierten Apps verwendet werden; DIDs (dezentrale Identifikatoren) liefern die von Apps entkoppelte Grundlage zur Identitätsprüfung
  • DIDs haben das Format did:<method>:<identifier>; mithilfe der im DID Document enthaltenen öffentlichen Schlüssel und PDS-Position wird die Zuordnung zwischen Beitragsersteller und Konto verifiziert
  • did:web ist ein einfacher Ansatz, bei dem /.well-known/did.json einer Domain abgefragt wird, ist aber anfällig durch Abhängigkeiten von DNS und Registraren, Ausfälle des Webservers sowie Verzögerungen bei der Übernahme von Dokumentänderungen
  • Das von Bluesky entwickelte did:plc trennt IDs von bestimmten Domains und überlässt plc.directory den Betriebsaufwand; statt DNS muss man jedoch plc.directory vertrauen, und in Bluesky lassen sich etwa keine Blockchain-basierten DID-Verfahren verwenden
  • Nutzer können durch das Registrieren zusätzlicher Schlüssel, Schlüsselrotation und den Betrieb eines eigenen PDS von Bluesky erzeugte Schlüssel entfernen und ihre Identität faktisch selbst kontrollieren; komplexes Schlüsselmanagement wird nicht allen aufgezwungen, sondern als Option für diejenigen angeboten, die es wollen

Bluesky-Konten und DID-basierte Identität

  • Ein „Bluesky-Konto“ ist kein Konto, das nur in Bluesky verwendet wird, sondern ein Konto, das in mehreren Anwendungen der ATmosphere genutzt werden kann
  • atproto, das zugrunde liegende Protokoll von Bluesky und anderen Apps, verwendet DIDs, um darzustellen, wer ein Nutzer ist, und um Logins oder die Urheberschaft von Beiträgen zu überprüfen
  • Die 2022 vom W3C standardisierten DIDs sind dezentrale Identifikatoren, die Anwendungen als Grundlage für Identitäten verwenden können
  • Die Dezentralität von DIDs besteht darin, dass nicht eine einzelne Institution festlegt, welche DID-Typen gültig sind, sondern Nutzer die DID-Methode wählen können, mit der ihre Identität verifiziert wird
  • Allerdings können Anwendungen nicht automatisch alle DID-Methoden verarbeiten
    • Für jede Methode muss Unterstützungscode separat implementiert werden
    • Wenn eine App die Methode foo nicht unterstützt, kann sie did:foo:1243 nicht auflösen, selbst wenn diese DID vorgelegt wird

DIDs und DID Documents

  • Die Beispiel-DID did:plc:3danwc67lo7obz2fmdg6jxcr besteht aus drei durch Doppelpunkte getrennten Teilen
    • Schema: did
    • Methode: plc
    • Methodenspezifischer Identifikator: 3danwc67lo7obz2fmdg6jxcr
  • Um eine DID zu verwenden, muss sie in ein DID Document aufgelöst werden
  • Ein DID Document enthält Daten wie kryptografische öffentliche Schlüssel, damit das DID-Subjekt oder ein Bevollmächtigter sich authentifizieren und seine Zuordnung zu dieser DID nachweisen kann
  • Das Beispieldokument enthält die für die Identitätsprüfung nötigen Informationen
    • id: die DID selbst
    • alsoKnownAs: at://steveklabnik.com
    • verificationMethod: Typ Multikey und publicKeyMultibase
    • service: PDS-Endpunkt vom Typ AtprotoPersonalDataServer
  • Wenn ein beliebiger Beitrag behauptet, von einem bestimmten Nutzer verfasst worden zu sein, lässt sich die Echtheit dieser Behauptung mithilfe der Verifizierungsinformationen im Dokument prüfen
  • Das Verfahren zur Auflösung einer DID in ein Dokument wird durch den jeweiligen methodenspezifischen Standard festgelegt
    • did:plc folgt dem PLC-Standard
    • did:web, eine weitere von Bluesky unterstützte Variante, wird nach der Web-Methode aufgelöst

Auflösung von did:web

  • Nur sehr wenige Menschen verwenden did:web, aber seine Struktur ist einfach, sodass der DID-Auflösungsprozess leicht zu verstehen ist
  • Liz Fong-Jones’ did:web:lizthegrey.com wird aufgelöst, indem der methodenspezifische Identifikator lizthegrey.com in die folgende URL-Vorlage eingesetzt wird
https://<id>/.well-known/did.json
  • Das DID Document, das unter dieser URL abgerufen wird, enthält folgende Informationen
    • id: did:web:lizthegrey.com
    • alsoKnownAs: at://web.lizthegrey.com, did:plc:i4tfenpfog244rxry5uz4vtk
    • verificationMethod: öffentlicher Multikey-Schlüssel für atproto
    • serviceEndpoint: https://pds.lizthegrey.com

Einschränkungen von did:web

  • did:web ist von DNS und Domain-Registraren abhängig
    • Wenn der Registrar eine Domain einzieht, geht auch die Kontrolle über die DID verloren
    • Auch wenn eine Domain nicht mehr genutzt wird oder nach Ablauf von jemand anderem gekauft wird, kann die Identität verloren gehen
    • Dasselbe gilt, wenn ein Registrar-Konto gehackt und die Domain entwendet wird
  • Der Webserver, der das DID Document bereitstellt, muss dauerhaft betrieben werden; fällt der Server aus, kann auch das Dokument nicht abgerufen werden
  • Es gibt auch keine Möglichkeit, Clients sofort über Änderungen am DID Document zu informieren
    • Anwendungen können weiterhin ein veraltetes Dokument verwenden
    • Durch die Verzögerung zwischen Dokumentaktualisierung und Übernahme durch Anwendungen können vorübergehende Probleme entstehen, bis das aktuelle Dokument erneut abgerufen wird

Wie did:plc die Aufrechterhaltung von Identität verändert

  • Bluesky entwickelte did:plc, um die Probleme von did:web zu verringern
  • did:plc ruft das DID Document ab, indem die vollständige DID in die folgende URL-Vorlage eingesetzt wird
https://plc.directory/<did>;
  • Dass eine URL abgefragt wird, ist wie bei did:web, doch Betrieb und Aufrechterhaltung der Identität unterscheiden sich
    • Da die DID nicht an eine bestimmte Domain gebunden ist, kann man steveklabnik.com auslaufen lassen und zu steve.klabnik.com wechseln und trotzdem dieselbe DID behalten
    • Den Betrieb des Webservers übernimmt plc.directory für den Nutzer, wodurch der Betriebsaufwand sinkt
  • Das Vertrauensobjekt verschwindet dadurch nicht
    • Bei did:web muss man DNS und Domain-Registraren vertrauen
    • Bei did:plc muss man darauf vertrauen, dass plc.directory keine IDs entzieht und nicht kompromittiert wird
  • Nutzer, die weder DNS noch plc.directory vertrauen, können eine andere DID-Methode wählen, die Namen etwa über eine Blockchain auflöst
  • Da Bluesky solche Methoden jedoch nicht unterstützt, können sie in Bluesky-Anwendungen nicht verwendet werden

Zugänglichkeitsprobleme und neue DID-Ansätze

  • did:web selbst einzurichten erfordert Aufgaben, die für nicht fachkundige Nutzer belastend sind
    • Eine Domain registrieren und laufend dafür bezahlen
    • Einen Webserver einrichten und JSON für das DID Document schreiben
    • Den Server dauerhaft betreiben
    • Private Schlüssel speichern und sicher verwalten
  • Dieser Prozess ist deutlich komplexer als die Registrierung bei einer typischen Web-App und passt daher nicht zu Blueskys Ziel, auch nicht fachkundigen Nutzern die Plattform zugänglich zu machen
  • Wenn plc.directory die entsprechenden Aufgaben verwaltet, müssen Nutzer diese Schritte nicht selbst durchführen
  • did:webvh ist ein Ansatz, der did:web erweitert, um einige Nachteile zu beheben, und Version 1.0 erreicht hat; die konkreten Spezifikationen werden hier jedoch nicht in den Vergleich einbezogen

Wie man in Bluesky die eigene Identität selbst besitzt

  • In der Standardeinstellung erzeugt Bluesky das Schlüsselpaar des Nutzers und kann auf den geheimen Schlüssel zugreifen, sodass man in gewissem Sinn sagen kann, dass Bluesky die Identität besitzt
  • did:plc kann zusätzliche Schlüsselpaare für eine ID registrieren und Signaturschlüssel rotieren
    • Von Bluesky erzeugte Schlüssel können entfernt werden
    • Sie können durch selbst erzeugte Schlüssel des Nutzers ersetzt werden
  • Nur den Schlüssel zu wechseln trennt einen nicht vollständig von der Bluesky-Infrastruktur
    • Damit ein PDS Beiträge signieren kann, muss er den Schlüssel des Nutzers verwenden
    • Bei einem von Bluesky verwalteten PDS wird der Schlüssel normalerweise in der Bluesky-Infrastruktur gespeichert
  • Um Identität von Bluesky zu trennen, muss man einen eigenen PDS betreiben und anschließend die Schlüssel rotieren
    • Der Schlüssel wird in Infrastruktur gespeichert, die dem Nutzer gehört
    • Danach kontrolliert Bluesky diesen Schlüssel nicht mehr
  • Auch wenn die meisten Nutzer sich nicht für einen eigenen PDS und eigenes Schlüsselmanagement entscheiden, ist es eine wichtige Designeigenschaft, dass motivierte Nutzer ihre Identität faktisch selbst besitzen können
  • Statt allen Nutzern direktes Schlüsselmanagement aufzuzwingen, ist es für die meisten Nutzer angemessen, es denjenigen als Option anzubieten, die es wollen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 5 시간 전
Lobste.rs-Meinungen
  • plc.directory wurde anfangs von Bluesky kontrolliert, befindet sich aber derzeit im Prozess der Ausgliederung zu einer schweizerischen Non-Profit-Organisation
  • Ehrlich gesagt ist DID eine bessere Lösung als das integrierte Login (SSO) großer Tech-Unternehmen. Allerdings muss es auch für normale Menschen nutzbar sein, etwa wie did:plc:, und selbst wenn es einer Non-Profit-Organisation gehört, sollte man sich fragen, ob man einer zentralen Instanz vollständig vertrauen will
    Ich entwickle gerade ein Projekt, das W3C DID und W3C Verifiable Credentials (VC) unterstützt, während ich Keybase neu implementiere. Ziel ist es, die Eigenschaft, ein Mensch zu sein, eindeutig und zugleich privat nachzuweisen und eine dezentralisierte Identität zu besitzen, die man selbst kontrolliert
    • Arbeitest du zufällig an FOKS, oder ist das ein anderes Projekt?
      https://foks.pub/
  • Nur anhand des Titels dachte ich, es würde zur DID-Spezifikation verlinken, aber der eigentliche Text ist auch kurz und informativ
    • Der erste Link im Artikel ist direkt der Link zur Spezifikation
  • Heute gelernt: DID war nicht Docker in Docker
    • Mir war neu, dass man Docker in Docker als DID lesen kann. Ich habe es immer als DinD oder als das noch verwirrendere dind abgekürzt gesehen, weiß aber nicht, ob das nur eine Gepflogenheit an meinem Arbeitsplatz oder allgemein üblich ist
    • Es steht auch nicht für Direct Inward Dialing
  • Kann jemand für Leser, die Bluesky nicht nutzen, definieren, was PDS ist?
    • PDS steht für Personal Data Server und bezeichnet den Ursprungsserver für Inhalte wie Beiträge
    • Bei Bluesky/AT werden nicht die Beiträge aller Nutzer in eine einzige große Datenbank gelegt, sondern jeder Nutzer hat einen eigenen Datenspeicher namens PDS. Man kann den von Bluesky bereitgestellten PDS nutzen, ihn selbst hosten oder einen Drittanbieterdienst verwenden, und man kann transparent zwischen PDS wechseln, ohne die gesamte Kontohistorie zu verlieren
      Es ist nicht dasselbe wie eine Instanz bei Mastodon, und die Konzepte von AT und ActivityPub entsprechen sich nicht sauber eins zu eins
  • Wenn did:web das Hosting eines .well-known-Servers erfordert und die Daten ohnehin fast statisch sind, warum verwendet man dann nicht direkt DNS, das sich ähnlich wie eine URL lesen lässt, wahrscheinlich gecacht wird und weniger leicht versehentlich ausfällt, etwa wie ein TXT-Record?
    Die Abhängigkeit von DNS und das Problem, Aktualisierungen von did.json nicht leicht erkennen zu können, bleiben zwar bestehen, aber wenn das Ziel darin besteht, eine bestimmte Domain mit der Identität einer Person zu verknüpfen, scheint es sinnvoller zu sein, die Komponenten zu minimieren und direkt an DNS-Funktionalität anzuknüpfen. Ich frage mich, ob es einen Grund gibt, warum dieser Ansatz nicht funktioniert oder in der Praxis schwierig ist