W3C で標準化された DID とは？ ー 基本的な概念を簡単に解説！

2022年8月に Web 技術の標準化団体である World Wide Web Consortium（W3C）において分散型識別子（Decentralized Identifiers; DIDs）が標準化されました。巷では分散型アイデンティティ管理や自己主権型アイデンティティへの応用などが期待されており、今非常にホットな技術要素の一つです。

一方、標準文書では抽象的なデータモデルのみ定義しており、具体的な実現方法は各実装（DID Method と呼ばれます）に依存していることから、抽象的な議論になりがちなのもあり、初見で理解しようとすると大変です。そこで、今回はこの DID について、基本的な概念を解説するとともに、現在提案されている具体的な実装をいくつか紹介したいと思います。

DID の基本的な概念

DID は識別子の一種！

DID は、識別子の一種です。今、非常に注目されていることもあり、場によっては DID が何か特別なアプリケーションであるかのように語られる向きがあるのですが、名前が表している通り、DID は単に識別子であり、それ以上でもそれ以下でもありません。したがって、通常のアプリケーション開発における識別子と同様にユースケースに応じて使い分ける必要がありますし、周辺技術といかに組み合わせるかが大事になります。

アプリケーション開発に明るくない方向けに簡単に説明すると、識別子とは、「ある実体（エンティティ）の集合の中の、特定の要素（元）を一意に特定する属性の集合」を意味します。具体的に、皆さんが普段触れるであろう識別子には、以下のようなものがあります。

• X（旧 Twitter）や Instagram などのユーザ・アカウントを識別する「ハンドル名」
• Web 空間上の資源（Web サイトや画像など）を識別する「Uniform Resource Identifier（URI）」
• コンピュータ・ネットワーク上に接続する端末を識別する「IP アドレス」や「MAC アドレス」
• リレーショナル・データベースのテーブル内においてレコードを識別する「プライマリ・キー」
• 日本国内に居住し行政サービスを受けている自然人を識別する「マイナンバー（個人番号）」
• 会社や学校内で個々の社員・学生を識別する「社員番号」や「学籍番号」
• 世界中で一意な識別子を提供することを目指している「Universally Unique Identifier（UUID）」

ご覧の通り、識別子はサイバー空間上はおろか、フィジカル空間上でもよく使われる非常に大切なものであることがわかります。万が一この識別子が指す対象（主体、Subject とも言われます）が複数存在してしまった場合に起こることを想像してみてください。例えば、Web サイトにアクセスするたびに違う内容が表示されたり、会社の業績や学校の講義での評価が正確になされなかったり、非常に困ったことになります。

それでは様々な識別子が存在する中で、なぜ DID が注目を浴びているのでしょうか。その理由の 1 つとしては、自己主権的な形で識別子を扱うことができることが挙げられるでしょう。

この特性について考えるにあたっては、今年（2023年）7月ごろに起きた、SNS の「ハンドル名」をサービス運営が勝手に変更した事例について知っておくと良いでしょう。

• 2007年からTwitterで「@X」を使っていた男性がユーザー名を運営に乗っ取られる、金銭的補償は1円もなし – GIGAZINE
• X（旧Twitter）のスクリーンネーム剥奪、日本ユーザーにも影響　“玉突き事故”で二次被害も – ITmedia NEWS

先ほどの例にも載せた通り、SNS のハンドル名は、SNS のユーザ同士が個人のインターネット空間上のアイデンティティを識別する立派な識別子です。これが自分の意図しないままに勝手に変えられてしまうと、連絡が取れなくなったり、本人であるかの確認が困難になったりし、実際の生活でも大なり小なり様々な支障をきたします。今回の場合は利用規約に明記されていることもあり、議論の余地は十分にありますが、本人が予期していない中で属性を勝手に除去・付加されている点で、プライバシ侵害であるとみなせなくもないとも考えられます。

自己主権的な DID Method を用いれば、これらの問題は解決しやすくなります。この場合における「自己主権的」であるとは、DIDが指す対象自身がその識別子を管理することができることを意味します。 次のセクションでは、具体的な仕組みを通じて、どのように実現しているのかを説明します。

DID の構成要素

仕様書に登場する DID を構成する要素は 6 つです。DID、DID Subject、DID URL、DID Document、DID Controller、そして Verifiable Data Registry です。それぞれの要素の関係を表した図を示します。これは標準文書中の Figure 2 を引用したものです。これらの 6 つの要素やその他様々な制約などを含めて定義し、まとまった1 つの実装として動くものを DID Method と言います。

DID Subject

DID Subject は DID が指し示す対象の実体ことを言います。これは人、グループ、組織、モノ、概念など、何でもなり得えます。

DID

DID は DID スキーマを用いて表現されます。以下に標準文書で用いられている Figure 1 を示します。

DID スキーマは、DID であることを示す接頭辞である “did:” から始まり、DID Method 固有の識別子が続きます。2つ目の :（コロン）から先の DID Method-Specific Identifier は DID Method によって異なりますが、RFC3986 で定義される URI のフォーマットに従う必要があります。例えば、後述する did:ethr では Ethereum アドレスが、did:key では公開鍵暗号方式の検証鍵を base58-btc エンコードを行い、Multicodec の符号をつけたものが用いられています。

DID URL

DID Method 上で定義されていれば、後述する DID Document の特定の記述を指し示す用途などに、DID URL と呼ばれる形式も利用可能です。これは、通常の DID 表現に対しパスやフラグメントの情報も加えることで表現します。

DID Document

DID を DID Method 毎に定義される方法で名前解決（リゾルブ）すると、DID Document が得られます。

DID Document には DID Subject に関する情報が記述されています。ここでは DID Controller の指定や、DID Subject を認証するための検証鍵の情報、DID の制御権の委譲先、DID に関連するサービスエンドポイントなどが含まれます。

DID を利用するアプリケーションは、この DID document に含まれる情報を解釈することで、ユーザと DID の紐付きの確認や、記述されているサービスエンドポイント経由で追加の情報を得たりすることがきます。

DID Controller

DID Controller とは DID Document を変更することのできる実体です。DID Method に依って、この DID controller は DID subject と同一の場合もありますし、そうでない場合もあります。DID Controller 自身も DID Document 内で DID の形で指定されます。DID Controller は DID Subject と必ずしも同一ではないというのは、例えば、親が子の DID Document を管理するケースなどが挙げられます。他にも、連携型アイデンティティプロバイダ（IdP）を利用している場合は、IdP がこの DID Controller となるかもしれません。もちろん、全ては DID Method に依って決まるので、DID の標準としてこうである、あるいはこうすべきである、といったことは決まっていません。

Verifiable Data Registry

最後に、Verifiable Data Registry です。長いので、以下 VDR と略します。VDR は DID と DID Document を記録・管理し、DID と DID Document を名前解決することを可能にします。これらはシステムやネットワークとして用意されていて、標準文書では分散型ファイルシステムやブロックチェーン、データベースや P2P ネットワークなどが挙げられています。1つ注意すべき点として、標準としてどのような技術を使用すべきであるといったことは決まっていません。名前解決する時に、DID Document を正しく得ることさえできれば、使用する技術は何でも良く、その手続きも DID Method に依って定義されます。

よくある誤解ですが、DID は必ずしもブロックチェーンや、そのほか自律分散や非中央集権と呼ばれるような技術に依存しているわけではありません。もちろん策定までの文脈から、アーキテクチャや概念などはそれらの技術の影響を受けたかもしれませんが、ブロックチェーンに依存しない DID Method も多く存在します。

何度も書きますが、W3C の標準文書はあくまでこれら 6 つの要素の抽象的な概念を規定するもので、具体的な手続きや制約は全て DID Method に依ってそれぞれになります。したがって、ユースケースに合わせてどの DID Method を用いるかしっかり検討することが重要です。判断を助けるための道具として、W3C は各 DID Method の特性についてまとめたルーブリックも公開しています。

既存の DID Method の事例

次に、具体的な事例として、実際に存在する DID Method をご紹介していきたいと思います。

DID Method は現在、W3C の DID Specification Registries と呼ばれる文書で管理されており、一覧は同文書の §14 で確認できます。また、仕様書のリンクや仕様については 2023年9月現在の情報であり、場合によっては以後変更されている可能性がありますのでお気をつけください。

did:key

仕様書：The did:key Method v0.7

did:key はその名の通り、デジタル署名に使う検証鍵を元にした DID Method です。W3C のコミュニティグループで議論されています。DID Document を管理する特定の具体的な空間はなく、仕様で決められた特定の手順を実行することで得ることができます。Method Specific Identifier も検証鍵のビット列をを base58-btc エンコードして識別用の符号をつけるのみの、非常なシンプルな実装です。シンプルであるが故に、DID document を自由に記述できないという制約もあります。他の DID Method の認証をするための方法を指定するためのフィールドである verificationMethodで、公開鍵を指定するために使用されることもあります。

did:web

仕様書：did:web Method Specification

did:web は DNS の FQDN とドメインで示されるサーバ上のパスを Method Specific Identifier として用いた DID Method です。FQDN で示されるアクセス可能な Web サーバの特定のパスで DID Document を公開することで運用できます。具体的には、did:web:example.comの DID Document は http(s)://example.com/.well-known/did.jsonへ GET リクエストを送信することで解決することができます。したがって、did:web の VDR は FQDN を管轄するドメインレジストリと Web サーバであるとみなすことができ、ブロックチェーンに依存しない DID Method の 1 つと言えます。

did:ethr

仕様書：ETHR DID Method Specification

did:ethr は Ethereum 上のスマートコントラクトを VDR とした DID Method です。元は uPort プロジェクトの一部でしたが、プロジェクトチームの発展的解消の後、現在は Veramo コアチームが管理しています。Method Specific Identifier は Ethereum アドレスが用いられています。コントラクト内部に直接 DID Document が格納されているわけではなく、プロパティに対応したコントラクトのフィールドをリゾルバが読み取り、仕様で決められた手順に従って処理することで DID Document を得ることができます。

did:ion

仕様書：ION Design Document

did:ion は Microsoft 社が開発し、現在は Decentralized Identity Foundation が管理している Bitcoin 上のレイヤ 2 オーバレイネットワークを VDR とする DID Method です。Sidetree と呼ばれるプロトコルに準拠しています。

did:plc

仕様書：DID PLC Method (did:plc)

上の 4 つに比べると認知度も低く、完全ではないと思いますが、筆者が個人的に興味深く感じている DID Method の一つが did:plc です。この DID Method は Bluesky 社によって開発され、did:web とともに、最近話題の SNS「Bluesky」で用いられている AT Protocol でサポートされています。鍵のローテーションが可能な点や、VDR を変更コストが高く、その伝播も遅いブロックチェーンではなく、CRDT（Conflict-free Replicated Data Type）の考え方を応用したような独自の仕組みを使っている点が興味深く感じている理由です。一方で、現状 VDR は PLC registry と呼ばれる単一のサービスに依存しており、可用性やトラストの観点など、課題はまだまだ残ります。トレードオフのバランスを今後どう取られていくかが注目です。

まとめ

今回の記事では、DID の簡単な概念やアーキテクチャについて解説し、既存の DID Method についての事例について紹介しました。今回は解説しませんでしたが、DID は名寄せのリスク対策など、プライバシやセキュリティに関してかなり考慮された設計となっています。興味を持った方は標準文書にある Security Consideration や Privacy Consideration の項目も読んでみることをおすすめします。

また、事例を見ていく中でわかる通り、DID の標準はあくまで抽象的なデータモデルやアーキテクチャを定義しているだけであり、一概にこうであるといえるものではありません。 DID Method に依ってプライバシリスクや集権性などの特性も様々です。決してあらゆる課題を解決する銀の弾丸のようなものは存在しないので、DID 自体の特性や Method 毎に異なる特性をきちんと理解し、ユースケースや活用する周辺技術に応じて、そもそも DID を用いるか否か、用いるならばどの Method を使うのかを慎重に検討する必要があります。

今回の記事がそういった判断の一助になれば幸いです。