DIDについて、あまりにも多くの話

 (steveklabnik.com)
1 ポイント 投稿者 GN⁺ 5 시간 전 | 1件のコメント | WhatsAppで共有
  • Blueskyアカウントは特定のアプリに縛られず、atprotoベースの複数のアプリで利用でき、DID（分散型識別子） がアプリと切り離された本人確認の基盤を提供する
  • DIDは did:<method>:<identifier> 形式で、DID Documentに含まれる 公開鍵とPDSの場所 を使って、投稿の作成者とアカウントの関連性を検証する
  • did:web はドメインの /.well-known/did.json を参照する単純な方式だが、DNS・レジストラ依存 とWebサーバー停止、文書変更の反映遅延に弱い
  • Blueskyが作った did:plc はIDを特定ドメインから切り離し、plc.directory が運用負担を担うが、DNSの代わりに plc.directory を信頼 する必要があり、BlueskyではブロックチェーンベースのDID方式などは使えない
  • ユーザーは追加鍵の登録や鍵ローテーション、自前PDSの運用によってBlueskyが作成した鍵を削除し、身元を実質的に自分で制御 できる。複雑な鍵管理を全員に強制せず、望む人に選択肢を提供する

BlueskyアカウントとDIDベースの身元

  • 「Blueskyアカウント」はBlueskyだけで使うアカウントではなく、ATmosphereの複数のアプリケーションで使えるアカウントである
  • Blueskyや他のアプリの基盤プロトコルであるatprotoは、ユーザーが誰であるかを示し、ログインや投稿者の確認を行うために DID を使う
  • W3Cが2022年に標準化したDID は、アプリケーションで身元の基盤として利用できる分散型識別子である
  • DIDの分散性は、単一の機関が有効なDIDの種類を決めるのではなく、ユーザーが自分の身元を検証するための DIDメソッド を選べる点にある
  • ただしアプリケーションがすべてのDIDメソッドを自動的に処理できるわけではない
    • メソッドごとに対応コードを個別に実装する必要がある
    • アプリが foo メソッドをサポートしていなければ、did:foo:1243 を提示されても解釈できない

DIDとDID Document

  • 例のDID did:plc:3danwc67lo7obz2fmdg6jxcr は、コロンで区切られた3つの部分から成る
    • スキーム: did
    • メソッド: plc
    • メソッド固有識別子: 3danwc67lo7obz2fmdg6jxcr
  • DIDを使うには、これを DID Document に解決する必要がある
  • DID Documentには、DID主体または委任者が自分を認証し、そのDIDとの関連性を証明できるようにする 暗号学的公開鍵などのデータ が含まれる
  • 例の文書には身元検証に必要な情報が含まれる
    • id: DIDそのもの
    • alsoKnownAs: at://steveklabnik.com
    • verificationMethod: Multikey 型と publicKeyMultibase
    • service: AtprotoPersonalDataServer 型の PDSエンドポイント
  • 任意の投稿が特定ユーザーの作成だと主張しているとき、文書の検証情報を使ってその主張が真かどうかを確かめられる
  • DIDを文書へ解決する手順は、メソッドごとの標準で定義される
    • did:plc はPLC標準に従う
    • Blueskyがサポートするもう1つの方式 did:web はWeb方式で解決する

did:web の解決方法

  • did:web を使っている人は非常に少ないが、構造が単純でDID解決の流れを理解しやすい
  • Liz Fong-Jonesの did:web:lizthegrey.com は、メソッド固有識別子 lizthegrey.com を次のURLテンプレートにはめ込んで解決する
https://<id>/.well-known/did.json
  • そのURLから取得したDID Documentには、次の情報が含まれる
    • id: did:web:lizthegrey.com
    • alsoKnownAs: at://web.lizthegrey.com, did:plc:i4tfenpfog244rxry5uz4vtk
    • verificationMethod: atproto向けの Multikey公開鍵
    • serviceEndpoint: https://pds.lizthegrey.com

did:web が抱える制約

  • did:web は DNSとドメインレジストラ に依存する
    • レジストラがドメインを回収すれば、DIDの制御権も失う
    • ドメインを使わなくなったり、有効期限切れ後に他人が取得したりしても、身元を失う可能性がある
    • レジストラのアカウントがハッキングされてドメインを奪われた場合も同様である
  • DID Documentを配信するWebサーバーを継続的に動かす必要があり、サーバーが止まれば文書も取得できない
  • DID Documentの変更をクライアントへ即時に知らせる方法もない
    • アプリケーションが古い文書を使い続ける可能性がある
    • 文書更新とアプリケーションへの反映の間に遅延があるため、最新文書を再取得するまで一時的な問題が起こりうる

did:plc が変える身元維持の方法

  • Blueskyは did:web の問題を減らすため、did:plc を開発した
  • did:plc はDID全体を次のURLテンプレートに入れてDID Documentを取得する
https://plc.directory/<did>;
  • URLを参照する点は did:web と同じだが、運用と身元維持の仕組みは異なる
    • DIDが特定ドメインに結び付かないため、steveklabnik.com を失効させて steve.klabnik.com に移っても 同じDID を維持できる
    • Webサーバー運用はユーザーの代わりに plc.directory が担うため、運用負担が軽くなる
  • 信頼対象そのものがなくなるわけではない
    • did:web ではDNSとドメインレジストラを信頼しなければならない
    • did:plc では plc.directory がIDを奪わず、侵害されないことを信頼しなければならない
  • DNSも plc.directory も信頼できないと考えるユーザーは、ブロックチェーンなどで名前を解決する別のDIDメソッドを選べる
  • しかしBlueskyはそうしたメソッドをサポートしていないため、Blueskyアプリケーションでは利用できない

アクセシビリティの問題と新しいDID方式

  • did:web を自分で設定するには、非専門ユーザーには負担の大きい作業が必要になる
    • ドメインを取得し、継続的に費用を払う必要がある
    • Webサーバーを設定し、DID Document用のJSONを書く必要がある
    • サーバーを継続稼働させる必要がある
    • 秘密鍵を保存し、安全に管理する必要がある
  • このプロセスは一般的なWebアプリへの登録よりはるかに複雑で、非専門ユーザーにもプラットフォームを使ってもらいたいというBlueskyの目標に合わない
  • plc.directory が関連作業を管理すれば、ユーザーはこれらの手順を自分で行わずに済む
  • did:webvh は did:web を拡張して一部の欠点を補おうとする方式で、1.0に到達 したが、具体的な仕様比較まではここでは扱わない

Blueskyで身元を直接所有する方法

  • デフォルト設定ではBlueskyがユーザーの鍵ペアを生成し、秘密鍵にアクセス できるため、ある意味ではBlueskyが身元を所有しているとも言える
  • did:plc ではIDに追加の鍵ペアを登録し、署名鍵をローテーションできる
    • Blueskyが生成した鍵を削除できる
    • ユーザーが自分で作った鍵に置き換えられる
  • 鍵を変えるだけでは、Blueskyインフラから完全に切り離されるわけではない
    • PDSが投稿に署名するには、ユーザーの鍵を使う必要がある
    • Bluesky管理のPDSを使うと、通常は鍵がBlueskyインフラに保存される
  • Blueskyと身元を切り離すには、自前のPDSを運用した上で鍵をローテーション する必要がある
    • 鍵はユーザーが所有するインフラに保存される
    • その後、Blueskyはその鍵を制御できなくなる
  • 大半のユーザーが自前PDSや鍵管理を選ばないとしても、動機のあるユーザーが身元を実質的に所有できることは重要な設計特性である
  • すべてのユーザーに直接の鍵管理を強制するのではなく、望むユーザーが選べるようにする方式は、大多数のユーザーにとって妥当である

関連記事

1件のコメント

 
GN⁺ 5 시간 전
Lobste.rsのコメント
  • plc.directoryは当初Blueskyが管理していたが、現在はスイスの非営利団体として独立する手続きを進めている
  • 正直なところ、DIDは大手テック企業のシングルサインオン（SSO）より優れた解決策だ。ただし、did:plc:のように一般の人でも使える必要があり、たとえ非営利団体の所有であっても中央機関を完全に信頼してよいかは検討が必要だ
    Keybaseを再実装しつつ、W3C DIDとW3C検証可能資格情報（VC）をサポートするプロジェクトを開発している。人間であることを一意に、かつプライベートに証明し、自分で管理できる分散型アイデンティティを持てるようにするのが目標だ
    • もしかしてFOKSを開発中なのか、それとも別のプロジェクトなのか？
      https://foks.pub/
  • タイトルだけ見てDID仕様へのリンクかと思ったが、実際の記事も短くて有益だ
    • 記事の最初のリンクがその仕様へのリンクだ
  • 今日知ったこと: DIDはDocker in Dockerのことではなかった
    • Docker in DockerをDIDと読むこともあると初めて知った。いつもDinDまたはもっと紛らわしいdindという略し方しか聞いたことがなく、職場内の慣習なのか一般的な表記なのかは分からない
    • Direct Inward Dialingの意味でもない
  • Blueskyを使っていない読者のために、PDSが何か定義してもらえるだろうか？
    • PDSはPersonal Data Serverのことで、投稿のようなコンテンツのオリジンサーバーを指す
    • Bluesky/ATは、すべてのユーザーの投稿を単一の巨大データベースに入れるのではなく、各ユーザーがPDSという個別のデータストアを持つ構造になっている。Bluesky提供のPDSを使うことも、自分でホストすることも、サードパーティのサービスを使うこともでき、アカウント履歴全体を保ったままPDS間を透過的に移行することもできる
      Mastodonのインスタンスと同じものではなく、ATとActivityPubの概念は一対一できれいに対応しているわけではない
  • did:webでは.well-knownサーバーをホストする必要があり、データもほぼ静的なら、なぜTXTレコードのようにURLに近い形で読めてキャッシュされる可能性が高く、偶発的に停止する可能性も低いDNSを直接使わないのだろうか？
    DNS依存やdid.jsonの更新を簡単には検知できないという問題は残るが、特定のドメインを個人のアイデンティティに結び付けるのが目的なら、構成要素を最小限にしてDNSの機能に直接結び付けたほうがよさそうに見える。この方式が機能しない、あるいは現実的に難しい理由があるのか気になる