分散型IDってなんだ
はじめに
過去のTech BlogでもブロックチェーンやWeb3にまつわる記事を出しています。今回はそんなブロックチェーンを主に活用した**分散型ID (Decentralized ID: DID)**についてご紹介します。分散型IDはWeb3で注目されている非集中化、つまり、現在ITの世界でメジャープレーヤーであるGoogleやAmazonといった大企業に依存しないかたちでのインターネット利用にとって重要な概念になると期待されています。
さて、本題に入る前にアイデンティティ(Identity)とID(Identifier)の違いについて述べたいと思います。 なお、本記事でいうところのアイデンティティはデジタルアイデンティティを指しています。こちらはウェブ上のウェブサイト、サービス、あるいはアプリケーションに対して自分が誰であるかを証明するために使用する情報のことです。例えばユーザー名や氏名、メールアドレスなどが該当します。一方、IDは日本語にすると識別子です。あくまでも個人(あるいはもの)を特定するための文字列であり、アイデンティティとは異なる概念です。身近なところではマイナンバーやパスポート番号などがそれにあたります。
インターネット上でのID管理は、現在FacebookやGoogleなど大規模IDプロバイダーに依存している状況です。ユーザーが大規模IDプロバイダーを利用しない場合、各サービス事業者で新しいアカウントを作成しなければならず、ID管理に関する負担がすべてのしかかり、ユーザー体験も分断的で使いにくいものになってしまいます (パスワード管理めんどくさいなって感じている方も多数いらっしゃることでしょう)。また、IDを管理されているということはアクセスする権利やプライバシーもサービス事業者側に握られています。分散型IDはこうした課題を回避して、ユーザーが自分のIDに関連する情報を自ら管理しながら、安全な方法でサービスにアクセスすることを可能にする技術として注目されています。
IDの種類
現在のIDは中央集権モデル(表の左側)が主流になっています。中央集権モデルは管理を所属する組織に依存するタイプになっており、パスポートや運転免許証でいえば国家に管理を依存していますし、ITの世界ではアカウントを作成するとそのデータはサービス事業者側が管理することになります。組織側が管理していますので、例えばFacebookにアカウントを作成すると接続許可の大元はFacebook側が所有しています。Webサイト、サービス、アプリケーションへの接続許可は制限されたかたちでユーザーに貸し出されているとも言い換えられます。たとえば、Twitterが拒否したため、トランプ元大統領がTwitterへアクセスできなくなったのは記憶に新しいことだと思います。
このようなアイデンティティの保証以外にも集中管理されたIDには、すべてのユーザー名とパスワードを管理する負担がユーザー側にかかってくるという問題点があります。各サイトが独自のセキュリティとプライバシーポリシーを実施し、それらはすべて異なっています。典型的な例としてはパスワードに関する規則（最小限の長さ、許可される特殊文字など）はかなりバラバラです。このようなパスワードバラバラ問題に代表される課題を解決しようとしたものが真ん中のフェデレーションモデルです。本質的には中央集権モデルと同じなのですが、ユーザーと組織の間にIDプロバイダーというIDとアクセス許可の管理を集中して管理してくれる媒体を置くことでユーザーは1つのアカウントを管理すれば、すべてのサイトにアクセスできるようになります。「Facebookアカウントでログイン」「Googleアカウントでログイン」といった機能をすでにご利用になっているかたも多いのではないでしょうか。
しかしながら、ユーザー側のID管理が便利になる一方、プライバシーの問題が残ります。例えばFacebookでログインの機能でログインするということはFacebook側からすれば、ユーザーがどのようなサービスを、いつ、どこから、どのようなデバイスから利用したのかといったことが分かります。さらにいえばFacebookに氏名、年齢、家族などが登録されていれば、「あなた」がどんなサービスを利用しているのかFacebookが行動履歴を掌握できることになるわけです。実際Facebookの広告ビジネスはこうしたデータを収集、活用しています。
SSI:Self Sovereign Identity
こうした大手テック企業が大量のデータを保持する監視経済あるいは監視資本主義への抵抗手段として自己主権型アイデンティティ(SSI: Self Sovereign Identity)が存在しています(IDではなくアイデンティティです)。管理者を介さず、自分のIDを自分で管理することを実現しようという考え方です。これまでは前述のとおり国家やサービス事業者などなんらかの形で組織に属することによってIDが発行され、発行元に管理されていました。一方、SSIは個人が自己主権を持つことができるようにすることを目的とした運動であり、インターネットと暗号通貨を活用し、個人が国家や企業に支配されることなく、自己決定できる未来の実現を目指しています。このムーブメントは、1997年にジェームズ・デイル・デイビスとウィリアム・レイによって提唱されました。彼らは、著書『The Sovereign Individual』の中で、インターネットの普及によって、情報の自由な流通が可能になり、それによって個人が国家や企業に支配されることなく、自己決定できる社会が実現することを予測していました。そして、その実現に向けて、暗号通貨の発展や個人間取引市場の発展などに言及しています。
SSIでは物理世界の身分証のように必要な情報を自分の意思で提示して、確認する側は発行元に都度確認することなく身分証を信頼できるモデルをインターネットの世界に持ち込もうとしています。例えば下の図を使って身分証としてパスポートを提示することを例にとってみましょう。ここではIssuerがパスポートの発行元(日本であれば外務省)、Holderが資格保持者、そしてVerifier身分を確認する側です。この際重要なのはVerifier(確認者)側は外務省に都度パスポートの持ち主が正しいかどうか確認しません。では、これをデジタル世界で実現しようとした場合、どのようにすべきでしょうか？
Trust Over IP (ToIP)
さきほどご紹介したSSIが全体的なコンセプトに対して、それを実際にどのように実施すべきかというフレームワークがTrust Over IP (ToIP) です。デジタル世界ではさきほどのパスポートのように物理的に信頼できるものをそのまま持ち込むことができません。その分、技術や法規制によって信頼できるモデルを構築する必要があります。ToIPはその名が示すようにIPネットワーク(インターネットで利用される通信規格)で信頼性を担保するための枠組みを定義しています。ToIPには下図のようにテクノロジースタック(技術的な側面)とガバナンススタック(法的な側面)が存在します。つまりSSIのコンセプトを実現する場合、技術的な面と法的な整備の両面が必要だということが理解できます。
そして、分散型IDがToIPの技術的な中核を担っています。もしご興味があれば、ToIPをホストしているLinux Foundationという標準化団体のページに詳細がありますのでご覧になってみてください。ToIPの概要、プロジェクトに関する情報、イベント、ニュース、リソースなどが掲載されています。(Linux Foundationは非営利団体で、オープンソースソフトウェアや開放的なテクノロジーの開発、促進、普及を行うことを目的としています。)
分散型ID (Decentralized ID / DID)
デジタルアイデンティティを自己管理しようとするムーブメントに端を発したID管理の考え方がSSIで、その実現に向けたフレームワークがTrust Over IPでした。そして、技術的に実装する際に使われる技術がこれから説明いたします**分散型ID(DID)と検証可能な属性情報(VC)**です。(ようやく分散型IDが出てきます)
冒頭で述べたように識別子はアイデンティティ(名前、年齢、所属など)とは異なり、特定の人物を示すための文字列です。分散型IDも同様にあるフォーマットに従った文字列になっています。
分散型IDで使用する識別子はその番号や文字列から特定の人物(あるいはもの)を特定できる必要があるため、フォーマットが決められています。分散型IDの場合、W3Cという団体が標準化していまして、3つのパートに区切られています。
スキーマ
メソッド
文字列(String)
分散型IDでは分散型IDであることを示すためにスキーマはdidになります。(実はウェブではdid以外にも様々なスキーマが存在していて、皆さんがよく目にするhttp:もスキーマの一種です)
2つめのメソッドは分散型IDで使用されるプロトコルが何かを定義しています。分散型IDではブロックチェーンが利用されることが多いと述べましたが、どのタイプのブロックチェーンあるいはその他のプロトコルを利用しているかをここで定義しています。例えば、ethrであればEthereumというブロックチェーンを利用していることを示し、btcrはビットコインブロックチェーンを利用することを定義しています。なお、ブロックチェーン以外ですと、did:webメソッドのようにWeb上のリソースを識別するための分散型IDも存在します。たとえば、did:web:example.com:xxx は、Web上のexample.comドメインであることを示しています。
3つめの文字列(Strig)は利用されるメソッドの中で一意になる文字列を指します。さきほどの例から、did:web:example.com:aliceだった場合、Web上のexample.comドメイン内にいるaliseさんが特定できるということになります。仮にexample.comドメイン内ににaliseさんが二人いる場合にはどっちのaliseさんなのか特定できるようにexample.com:alise_smith、example.com:alise_johnsonといったかたちで工夫する必要があります。
検証可能な属性情報 (VC)
分散型IDにおいて、VCとは、個人が所有するデジタルアイデンティティの一部であり、第三者が検証可能な形で特定の情報を提供できる仕組みを指します。
従来のIDシステムでは、サービス事業者がIDを発行し、そのIDを使用してサービスを提供しています。一方、分散型IDでは、ユーザー自身が自分のIDを管理し、それに紐づくデータをコントロールすることができます。しかし、他の人や組織とのやり取りを行う場合、自分のIDだけでは信頼性が保証されない場合があります。 この問題を解決するために、VCが開発されました。これは、第三者機関が発行する証明書のようなもので、その情報が本当であることを確認するための証拠を提供します。具体的にはVCは3つの要素から成り立っています。
Credential Metadata ここにはVC自体の情報を含みます。たとえば、発行者 (Issuer) の分散型ID、発行日、有効期限（Expiration Date）などが含まれます。
Claim クレームがVCの本質的な内容になっており、保有者 (User) の分散型ID、氏名、生年月日などが含まれます。クレームは1つのVCの中に複数格納することができ、保有者が必要に応じてどのクレームを提供するか選択できるようになっています。
Proof VCが信頼できるものであることを証明するための情報です。VCが信頼できる発行元から発行されたものであることを示すために使用されるデジタル署名とそれを検証するための公開鍵が含まれています。
さて、VCが”検証可能な”と謳っているのは属性情報を確認したい側(Verifier)が発行元(Issuer)に問い合わせなくても信頼を担保できる点にあります。これを可能にするのは2つの要素が必要で、ひとつは信頼できるネットワーク(このためにブロックチェーンが分散型IDでは主に利用されます)、もうひとつはProofの中に入っているデジタル署名(と公開鍵)です。
分散型IDを使って本人確認をする仕組み
分散型IDのシステム的な側面
分散型IDに関する用語がひととおり出揃ったので、次は分散型IDに関する各要素(コンポーネント)について説明いたします。まずはシステム的にどのような様子があるかをみてみましょう。ここではワクチン接種証明書アプリで分散型IDを使うシーンを想定してみます。まずワクチンを接種した人が自分のスマホにワクチン接種証明書のアプリをインストールします。この時アプリの利用者(User)が分散型IDのサブジェクト(Subject)になります。サブジェクトは分散型IDの持ち主です。アプリ内には分散型IDで一意に定義されるIDがあり、このIDと利用者が登録した氏名や年齢などがひもづくかたちになります。そして、このID情報はどこかに保存した方が便利です。例えばスマホ内のストレージに保存されたりします (これをIdentity Hubと呼んでいます)。こうすればワクチン接種証明を提示する際にスマホがあればいつでも提示することが可能になります。
もう一つ、重要な要素がリゾルバ(Resolver)です。分散型IDに関連する情報はDID Documentとして保存されていますが、この中身を取り出して検証しないと何が書かれているのかが分かりません。この中身を閲覧する要素がDIDリゾルバになります。また前述のとおり分散型IDには複数のメソッドがあると述べましたが、この複数のメソッドに対応したリゾルバを**ユニバーサルリゾルバ(Universal Resolver)**と呼んでいます。
DIDエコシステム
さて、それでは分散型IDとVCを用いてどのように本人確認をするのかを実際に見ていきたいと思います。まずHolder(資格所有者) と Issuer (組織側)の双方が分散型IDを持ちます。これらのID情報はレジストリ(Resistry)と呼ばれる分散型IDを司る信頼できるネットワークやデータベース上に保存されます。そのため、ブロックチェーンのような改ざんされにくい基盤が一般的には用いられます。
次にHolderはIssuer側に自分自身の分散型IDを検証してもらいます。例えば学位証明書であればきちんと卒業していることを証明してもらう、会社であれば所属していることや役職や年収を証明してもらうといった具合です。そして、こうしたHolderに関する情報がVCとして保存されます。最終的にHolderは必要に応じて提示したい情報をVCとしてVerifier側に送付しVerifierが確認することによって本人確認や年齢、年収、学歴といったことを確認できるようになります。
ここで重要になるのはHolder側は提示したい情報だけをVCとしてVerifier側に渡せるということと、さらに、提示した情報はVerifierが所有しないということです。こうすることでHolderのプライバシーを保護しつつ、信頼を担保したかたちで情報の確認(上記の例では年齢確認など)ができるということです。
実際に分散型IDを作ってみよう
それでは実際に分散型IDを作成してみましょう。分散型IDを試すのであれば dock.io がおすすめです。
dock.ioにアカウントを作成
dock.io にアクセスしたらTry Free からアカウントを作成します。
アカウント作成方法はいくつかありますのでお好きなものを選択ください。本ブログ記事で紹介したようにGoogleでログインも可能です(笑)
Issuerの分散型IDを作成
ログインできましたら、まずはIssuerの分散型IDを作成してみましょう。Issuer Profilesをクリックして、Create Issuer Profileを選択します。
ロゴやIssuerの名前を入力します。Create Issuer Profileをクリックします。
Issuerの分散型IDが作成されました。did:dock:xxxのようにスキーマ：メソッド：文字列の順で並んでいることも確認できます。
Holderの分散型IDを作成
今回は簡易的に先ほど作成したIssuerの中に所属する人物としての分散型IDを作成します。Credentials をクリックし、Issue credentialsをクリックします。
Basic Credentialをクリックします。
Create new designをクリックします。
すると次のようなデザインテンプレートが表示されますので、Enter design nameに適当な名称を入力して、Save & Issueをクリックします。
各種情報を入力します。
Subject ID：分散型ID、メールアドレス, 社員番号など組織内で一意になる文字列
Subject Name：Holderの氏名
Subject Email：Holderのメールアドレス
Credential Title：タイトル名
下の段にあるPersistent credentialにパスワードを入力してください。また、今回はPDFでの出力も試したいのでGeneraet PDFをオンにしてみてください。
準備が完了したらIssue Credentialsをクリックします。
完了すると以下の画面が表示されるのでDownload CredentialsをクリックしてVCをダウンロードしてみてください。ZIP形式になっていますので解凍するとJSONファイルとPDFファイルが入っているはずです。
JSONファイルを開くと作成したVCの中身を確認することができます。IssuerやProofの情報を確認することができます。こうしたVCの情報をやり取りすることでVerifier側はHolderの情報が正しくIssuer側に担保されていることを確認できるようになっています。
分散型IDについてのまとめ
分散型IDについてコンセプトから実際の作成までご説明いたしました。個人がデジタルアイデンティティを管理することでこれまではとは違ったID情報の持ち方を実現しようというSSIという考え方があり、これを実現するためのフレームワークとしてToIPが存在しています。そして、ToIPの中核的な技術要素として分散型ID(DID)があり、HolderやIssuerの分散型IDはVCとして保存・流通し、Verifierが確認できることで信頼が担保されるという仕組みになっています。
デジタルの世界で情報をどのように信頼できるようにするか、そして、その情報のプライバシーをどう守っていくのかという問題はAIが大量のデータを消費していく世の中にとってますます重要になることでしょう。
分散型IDがこうした課題を解決する方策の一つになるかもしれません。正直理解しやすい概念ではないかと思いますが、本ブログの記事が少しでも皆様の理解のお役に立てましたら幸いです。