テクニカル・ドキュメント [PART 2]
DIDとは「識別子」である
テクニカル・ドキュメント[PART 1] では、非中央集権的な分散型アイデンティティ「DID」(Decentralized Identity) は、Webページと同じような仕組みで、所有者を表すブロックチェーンアドレスを指定するユニークな識別子とのことを詳しく説明しました。しかし、DIDは、「DIDドキュメント」というデジタル文書(DDOとも呼ばれ)へのアクセスを許可するアドレスです。
テクニカル・ドキュメント[PART 1] では、非中央集権的な分散型アイデンティティ「DID」(Decentralized Identity) は、Webページと同じような仕組みで、所有者を表すブロックチェーンアドレスを指定するユニークな識別子とのことを詳しく説明しました。しかし、DIDは、「DIDドキュメント」というデジタル文書(DDOとも呼ばれ)へのアクセスを許可するアドレスです。
XSL LabsのSDI(Secure Digital Identity)は分散型識別子(DID)を活用するプロジェクトです。つまり、SDI技術というのは、パブリックブロックチェーン上で、DIDドキュメントを取得する非中央集権的な分散型識別子です。従って、この仕組みは「SDI ドキュメント」と呼ばれます。
2-1 イラスト: “did:syl:aea42randn1awa3xzhjkbvc33” DIDに一致するDIDドキュメント。
このドキュメントは、DID“did:syl:aea42randn1awa3xzhjkbvc33”のレゾリューションです。
このドキュメントを見つけるため、“:”の側にある部分を解釈しないといけないわけです。従って、 “did”は非中央集権型識別子プロトコルとのことです。同じように、「http」は、ウェブを閲覧するためのサーバー/クライアント通信プロトコルです。 一方、「syl」というのは、使用されるDIDメソッドに一致しており、メソッドを詳しく調べるため、DIDメソッド公式リスト(https://w3c.github.io/did-spec-registries/#did-methods)を確認する必要があります。
メソッドを見つけたら(例:イーサリアムブロックチェーン上、「0xb9c15…98e246504」スマートコントラクト)識別子の末尾を使用して、最終のDIDドキュメントも見つけることができます。この例では、“aea42randn1awa3xzhjkbvc33“識別子を持っているスマートコントラクトといいます(普段、DIDの作成時に割り当てられるランダムな識別子です)。別の記事では、DID作成の初期段階について説明します。
「親」スマートコントラクトまたは個別スマートコントラクトを経由して、DIDメソッドを使用するおかげで、DIDドキュメント・「DIDレゾリューション」を取得できます。
実は、DIDドキュメントの根本的な内容(上記のイラスト)は、はるかに綿密ですが、この例では、このタイプのドキュメントについて概要を把握するために各ステップを説明していきます。
“@context”: “https://www.w3.org/ns/did/v1”
上記はDIDドキュメントです。
“id”: “did:syl:aea42randn1awa3xzhjkbvc33”
この最初の“id”というのは、このDIDドキュメントに関連付けられているDIDアドレスです。
(または、このDIDドキュメントによってレゾリューションされるDIDとも言います)
“controller”: “did:syl:aea42randn1awa3xzhjkbvc33”
「コントローラー」は、誰がこのDIDを制御・管理し・変更できるかを決めます。コントローラーのアイデンティティは、「DIDドキュメント」に記載されているアイデンティと同じですので、ここは最も単純なケースです。
実は、他のケースも沢山ありますので、見てみましょう。(網羅したリストではありません)
2-2 イラスト: Webサーバー上、DIDの所有者を認証する仕組み。
ユーザーはDIDのウォレットでQRコードをスキャンします。 サーバーへの認証を行うため、ウォレットは、DIDにリンクされた鍵を使用されたいかどうかを、ユーザーの同意を得てから、認証秘密鍵を使用してQRコードに含まれている「チャレンジ」に署名します。次は、ウォレットは署名されたチャレンジとDID(識別子)をサーバーに送り返します。
WebサービスはDID(「ユーザー名」として)を受け取り、上記のイラストの手順に従って自動的に実行し、「DIDドキュメント」を取得します。認証に関するセクションを読み取り、デフォルトの認証ためにDIDにリンクされた公開鍵を見つけるサービスです。サーバーは、DIDの所有者が「公開鍵」に一致する「秘密鍵」を持っていることを確認する必要があります。このために、受け取った署名の有効性を確認したら完了です!署名が有効な場合、サーバーから承認され、アクセス可能になります。
注意:「DIDドキュメント」では、Webサービスに複数の認証鍵を割り当てることができます。 そして、メッセージの暗号化、契約書への署名など、さまざまな用途に複数の認証鍵を割り当てることが可能です。
VCの仕組みについて説明する前に、お客様の本人認証についてのDID仕組みを理解することが重要です。次の記事のテーマは、検証可能なクレデンシャルです!
DIDは「DIDドキュメント」に関連
DIDドキュメントは、本質的にユーザーの「公開プロフィール」です。大量のデータを保管するつもりありませんし、パブリックブロックチェーンを利用するため、ユーザーの名前、生年月日などの個人情報を基本的に保管・保存すべきではありません。 DIDドキュメントの可能な内容を定義する標準化制度の「努力」のおかげで、様々な「タイプ」(種類)のデータをDIDドキュメントに追加することはとても簡単ですので、後で説明します。革新的な業界と努力する標準化活動について
ディセントラライズド・アイデンティティについての研究は最近のもので、自己主権型アイデンティティ(Self Sovereign Identity 「SSI」)に関連しています。このSSIというのは、管理主体(企業)が介在できず、本人は自分自身の個人情報を保有できるだけでなく、ストーレージやコントロールをすることもでき、保有・保管・管理ができる仕組みで、データ情報を提出する際、または、検証可能にしたい場合(クレデンシャル)、信頼できる「仲介者」へ依頼する必要ない概念です。 2017-2018年頃に、分散型IDは初めてブロックチェーンを使用しました。同じ頃に、マイクロソフトよりのビットコイン実験、イーサリアムブロックチェーン上でuPortコントラクトの公開及びパブリックブロックチェーン「Sovrin」と「Ontology」の使用などもされました。 下記の先行研究の取り組みのおかげで、現在のソリューションを開発できました。(網羅したリストではありません)- Pretty Good Privacy (PGP) の生みの親、フィル・ジマーマン氏の「Web of Trust」 (閲覧サイトの信頼性を表示する拡張機能)(90年代)
- カール・エリソン氏の「認証局のないID」についての出版(90年代)
- マイクロソフトを退任したキム・キャメロン氏の「アイデンティティの原則」 (The Laws of Identity、2005年)
- – Audun Jøsan氏とSimon Pope氏の「中心アイデンティティ管理」(User centric identity management)についての研究(2005年)
- 「W3Cの検証可能な認証情報」(Verifiable Credentials)についての初期の研究(2006年)
- 創設者モクシー・マーリンスパイク氏の暗号化メッセンジャーアプリ「Signal」についての研究(2012年)
- SSL/TLS共同発明者・Blockstreamの建築家クリストファー・アレン氏の「個人的および文脈的プライバシーの概念」(Personal and contextual privacy) についての研究及び自己主権型アイデンティティ(SSI)についての提唱(2016年)
- 「信頼のWebの再起動」(Rebooting the Web of Trust)での最初のワークショップの際、ヴィタリック・ブテリン氏、クリストファー・アレン等より、分散型公開鍵インフラストラクチャ(DPKI/PKI)の必要性についてのホワイトペーパーの出版(2015年)
「DDO」というDIDドキュメント
つまり、DIDは常にDIDドキュメントに関連付けられており、このドキュメントの中には個人情報が含まれていません。なお、このドキュメントには基本的にどんな情報が含まれているかを見てみましょう。- DIDドキュメント内の情報を見つけるサブ識別子
- 公開鍵
- 公開鍵のサービスと使用に関する情報
- 作成日と変更日を含むDIDドキュメントの発行者に関するデータ情報
- 署名

- ユーザーは、同じIDをコントロールするために、いくつかのウォレットを使用するケース
- ユーザーは、単一のウォレットを使用して複数のIDをコントロールするケース
- 成人したユーザーは、未成年者のユーザーの分散型アイデンティティを管理するケース
- 個人ユーザーは選んだ代理人に自分のIDの全部または一部を委任するケース、等。
- DID作成者は信頼できる仲介人であることと仲介人の身元を確認する役割を持っている。(例え、このDIDは、管理者(admin)のDIDドキュメントにリダイレクトできる)
- しかし、ユーザーが知らずに、作成者がDIDドキュメントのデータを変更できることを必ずしも意味するものではありません。ユーザーのみが自分のDIDを制御でき、第三者とコントロールを共有するか、一人のみで管理するか選べることもできます。
用例:WebサービスがDID所有者を認証することを希望しているケース
さて、ウェブサービス「abcd.com」は、専用のページを経由してSDI(DID)を持っている所有者を確認することを希望しているケースを見てみましょう。(アプリを経由して承認されるケースを後でレビューしましょう) まずは、パソコン用のトラディショナルWebブラウザに焦点をあてましょう。 サーバーのログインページには、Webサービスのアドレスとユニークでランダムな文字列(英語で、「チャレンジ」とも言う)を含むQRコードが表示されます。