全6319文字

 ブロックチェーンやいわゆる「Web3.0(Web3)」、はたまたジャック・ドーシー氏が提唱する「Web5」まで、非中央集権をうたう様々な概念が乱立している。そのいずれにおいても重要な機能として語られることが多いのが、ユーザー自らIDや属性を管理できる分散ID (Decentralized Identity)であり、その主要要素とされる分散識別子(Decentralized Identifier、DID)である。

 政府や大手企業に頼らず誰もが自身のIDを持てるという自己主権(Self-Sovereigen)IDとともに語られることが多いDIDだが、ブロックチェーンの登場とともに突然出てきたわけではない。その背景には少なくとも20年にわたる歴史がある。本稿ではその歴史をたどることにより、DIDの何が新しいか、また、DIDに何が欠けているか、そして今後の展望を考察する。

DIDとは何か

 DIDは、Web技術の標準化団体であるWorld Wide Web Consortium(W3C)が2022年7月19日に勧告した標準規格である。対象であるDID Subject(人、モノどちらでもよい)に対して、DIDという恒久識別子を割り振り、その後の作業につなげる。ここで重要なのは、DIDが社員番号やマイナンバーのように組織によって振られるのではなく、各主体が自分で採番する点である。

 DIDの形式は以下のようになっている。

図1●DIDの形式
図1●DIDの形式
(出所:W3C)
[画像のクリックで拡大表示]

 Scheme(スキーム)というのはURI(Uniform Resource Identifier)書式で表現される識別子の種類を表すもので、一番身近なのはhttps://~の「https」であろう。スキームによってその識別子の取り扱い方が決まる。DIDの場合のスキームは「did」である。

 DIDメソッド(DID Method)は、特定のタイプのDIDとその関連DIDドキュメントを作成、解決、更新、および無効化する方法を定める。後述のDID Data Registry に対する読み書きの方式と考えると分かりやすい。

 DID Method-specific Identifier は、そのDIDメソッドの名前空間の中で一意になるような識別子である。

 DID自体は検証可能データレジストリ(Verifiable Data Registry)というレジストリに、DIDメソッドに従って登録される。検証可能データレジストリはざっくり3つの類型に分けることができる。

  1. 生成型:レジストリは論理的にしか存在せず、DID自体から生成する。例:「did:jwk」の場合、当該DIDを仕様で定められたテンプレートに埋め込むことで生成される。なお、DIDではないがOpenID ConnectのSIOP(Self-Issued OpenID Provider)がまさにこの類型になる。

  2. 単階層登録型:DID Methodによってどのレジストリに登録するかが一意に決まる。例:「did:ion」の場合、sidetreeに登録するということが一意に決まる。

  3. 多階層登録型:DID Methodだけではレジストリは決まらず、その後に続くパスの一部も併せて評価することによってレジストリが決まる。例:「did:web」においては、その後に続くセグメントが登録するホスト名になる。

 このレジストリとして想定されているものの一部にブロックチェーンがあるため、DIDはしばしばブロックチェーンの主要ユースケースとして挙げられる。しかし、上記からわかるようにこのレジストリはブロックチェーンである必要はなく、テンプレートから生成されるのでも、普通のデータベースでも、DNSのようなものでも、はたまた中央集権政府によって管理されたレジストリでも構わない。

 しかしブロックチェーンの場合は、他のレジストリのように管理者や組織による管理ではなく、スマートコントラクトという合意されたスクリプトによる登録管理である。これはいわばそのスマートコントラクトに合意している主体たちの共同管理ともいえるであろう。DIDの分権性に関する議論では、このあたりを強調することが多い。

 DIDと対になる概念にDID文書(DID Document)がある。これは、あるDIDとそれにまつわるさまざまな情報(メタデータ)を収録した文書で、たとえばSubject認証の方式や、あるいはそのSubjectに関する情報の取得元となるサービスの情報などを記す。DID文書はJSON-LDないしはJSON形式で保存されることが多いが、その他の方式も許されている。

 DID文書も検証可能データレジストリに登録される。なお、W3CのDID Core勧告案においては、DIDは個人情報を含まないとなっているが、DIDの対象が個人である場合、DID自体が個人情報であるため、日本でも欧州でもDID文書は当然個人情報であることには留意しなければならない。

 DID文書自体はかなりの大きさになることが想定される。そのため、ブロックチェーンに記録する場合には、DID文書自体をブロックチェーンに置くのではなく、DID文書へのリンクをDIDと対にしてブロックチェーンに書くほうが一般的である。また、そうでないと忘れられる権利の行使も困難になる。

 このDID文書を制御する主体はDID制御者 (DID Controller)と呼ばれる。DID制御者はDIDの指し示す主体自身であることもあれば、その主体が子供であるときは親、物であるときにはその所有者であることが想定される。

 これらの関係は図2のように表現できる。

図2●DIDアーキテクチャーと基礎的構成部品間の関係の概要
図2●DIDアーキテクチャーと基礎的構成部品間の関係の概要
(出所:W3C)
[画像のクリックで拡大表示]

 DIDは基本的に当該主体が自ら発行するものであり、どこかの発行機関が発行するものではない。発行機関による削除なども受けないことから「自己主権」であるといわれる。しかし、検証可能データレジストリ から削除されたり、自分以外のDID制御者によってDID文書が書き換えられたりした場合、事実上削除されたのと同じ効果を持ち得ることは留意すべきである。

 こうして登録されたDID文書の内容は、DIDに対するメタデータとなる。このメタデータを検索、取得するためのサービスがDIDリゾルバー(DID Resolver)である。各DID方式は、それぞれDIDリゾルバーを実装しなければならないが、一部のDIDリゾルバーは複数のDID方式に対応する。その時点で知られているほとんどすべてのDIDに対応するリゾルバーをユニバーサルリゾルバー(Universal Resolver)という。DIDリゾルバーはDID文書全体を返すこともできるし、DID URLに示される一部分だけを選択して返すこともできる。