テクニカル・ドキュメント[PART 1]　では、非中央集権的な分散型アイデンティティ「DID」（Decentralized Identity）　は、Webページと同じような仕組みで、所有者を表すブロックチェーンアドレスを指定するユニークな識別子とのことを詳しく説明しました。しかし、DIDは、「DIDドキュメント」というデジタル文書（DDOとも呼ばれ）へのアクセスを許可するアドレスです。 XSL LabsのSDI（Secure Digital Identity）は分散型識別子（DID）を活用するプロジェクトです。つまり、SDI技術というのは、パブリックブロックチェーン上で、DIDドキュメントを取得する非中央集権的な分散型識別子です。従って、この仕組みは「SDI　ドキュメント」と呼ばれます。

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年）

2017年、非中央集権的な分散型IDの初期の公的な実験と共に、「ユニバーサル・リゾルバ」（Universal Resolver）を構成するために、DIDレゾリューション・メソッドは分散型アイデンティティの国際標準化団体（「Decentralized Identity Foundation」または「DIF」→ https://identity.foundation) のリスティングに属し始めました。(https://github.com/decentralized-identity/universal-resolver/)。このUniversal Resolverというのは、ユーザーから提示されたDIDと「対話」することを希望するすべてのサービスプロバイダーが、ユーザーのDIDに関連付けられたDIDドキュメントを見つけることを可能にする対応表です（コレスポンデンス・テーブルとも呼ばれる）。 DIDに関するW3Cワーキンググループの最初のドキュメントではこの対応表と表記されます：https://w3c.github.io/did-core/ 2019年に完成した、このDIDに関するドキュメントを公開されてから大きな前進を遂げました。なぜかというと、World Wide Web Consortium（W3C）は、インターネット技術の標準化の主体です。（HTML、DOM、PNG、XML標準等も作成しました。） 我々が開発した「DIDメソッド」は公式DIDレゾリューションテーブルに上場するため、XSL Labs は分散型アイデンティティの国際標準化団体(DIF) のメンバーになる予定です。そうなると、XSL LabsのSDI（DID）をSDIドキュメント（DIDドキュメント）にレゾリューションする方法について、公開されるデータ情報へアクセスできるようになります。

「DDO」というDIDドキュメント

つまり、DIDは常にDIDドキュメントに関連付けられており、このドキュメントの中には個人情報が含まれていません。なお、このドキュメントには基本的にどんな情報が含まれているかを見てみましょう。

• DIDドキュメント内の情報を見つけるサブ識別子
• 公開鍵
• 公開鍵のサービスと使用に関する情報
• 作成日と変更日を含むDIDドキュメントの発行者に関するデータ情報
• 署名

注意：公開鍵（および「公開暗号」アドレス）は数学的に秘密鍵にリンクされており、所有者のウォレットに残しておくことが不可欠です。 秘密鍵はデータ（ドキュメント、トランザクション、証明など）に署名するために使用され、公開鍵は署名の有効性を検証する役割を果たします。 下記、DIDとDIDドキュメントがユーザーにリンクされている例です。 （もちろん、DIDは、個人だけでなく、アイテム、組織、機関にもリンクされることもあり） [DID Document]のフォーマットを見てみましょう（JSON / JSON-LD標準形式） 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ドキュメント」に記載されているアイデンティと同じですので、ここは最も単純なケースです。 実は、他のケースも沢山ありますので、見てみましょう。(網羅したリストではありません)

• ユーザーは、同じIDをコントロールするために、いくつかのウォレットを使用するケース
• ユーザーは、単一のウォレットを使用して複数のIDをコントロールするケース
• 成人したユーザーは、未成年者のユーザーの分散型アイデンティティを管理するケース
• 個人ユーザーは選んだ代理人に自分のIDの全部または一部を委任するケース、等。

“authentication”: [{     “id”: “did:syl:aea42randn1awa3xzhjkbvc33#authkey”,     “type”: “EcdsaSecp256k1KeyFID2021”,     “controller”: “did:syl:aea42randn1awa3xzhjkbvc33”,     “publicKeyBase58”:     “mM3wnZ3wXmC2AVvLNakc6zjZpfm3uJCwDMv6gVAnHqPV”   }] 上記は、公開鍵認証を直接に挿入して、このDIDの所有者を（デフォルトで）認証する方法です。 #authkeyで終わる新たな“id”は、直接にこのセクションにリンクされます。そうすると、DIDは “did:syl:aea42randn1awa3xzhjkbvc33”になります。ただし、鍵認証を指定したい場合、直接に“did:syl:aea42randn1awa3xzhjkbvc33#authkey”を入力することもできます。この方法は、ページを構成する「HTML」のアンカーリンク（ホームページに埋め込まれるリンクを細かく指定するタグ）をクリックすると別の場所へジャンプすることと同じようなコンセプトです。 「タイプ」は承認時使われる公開鍵電子署名のアルゴリズムを提供します。楕円曲線暗号（英：Elliptic Curve Cryptographyまたは「ECC」）を使用したDSAバリアントの例を使いましょう。 「コントローラー」者は、このセクションを担当するDIDといいます。ID所有者と同一であるため、ここも最もシンプルなケースです。 “publicKeyBase58”の後には、エンコードされた公開鍵のベース58の値があります。 次は、DIDドキュメントの内容を詳しく見てみましょう。外部Webサービスが、DIDを提示する新しいユーザーを、具体的にどのように認証できるかを説明たします。 “service”: [     “id”:”did:syl:aea42randn1awa3xzhjkbvc33#webvc”,     “type”: “VerifiableCredentialService”,     “serviceEndpoint”: “https://example.com/vcheck”   }] 検証可能なクレデンシャル（英：ヴェリファイアブル クレデンシャルズ、略：「VC」）について今度記事を作成いたしますが、クレデンシャルというのは、ユーザーウォレット内で利用できる検証可能なデータですが、 「検証可能なクレデンシャル」（VC）になるためには、信頼できる第三者によって検証される必要があります。   既にエコシステムに属していないユーザーには、VCを簡単に共有するための良く使われている方法です。具体的に、ユーザーは、示されたアドレスへアクセスして、このDIDにリンクされたVCの有効性を確認（テスト）できます→“https://example.com/vcheck”。コピーペストして終わりです。DIDドキュメントにあるVCを確認するだけでもOK！ “created”: “2021-01-01T14:22:21Z”,     “proof”: {       “type”: “LinkedDataSignature2020”,       “created”: “2021-01-01T14:21:14Z”,       “creator”: “did:syl:admin42randn1awa3xzhjkbvc33”,       “signatureValue”: “NRB43Y42Q21…1tndsf45sw==”     } DIドキュメントの最後に、ドキュメントを作成した人を認証するための電子署名があります。最初の日付は、スマートコントラクトでのドキュメントの作成日（有効日）とのことです。そして、日付の後には、証拠として使用される署名の詳細があります。（電子署名の日付は少し早くなってしまう場合が多くあります） しかし、作成者とIDの所有者は同じ人というケースが少ないです。 ブロックチェーンでのDIDドキュメントを作成するためにデータ作成は有料になり、ユーザー自身でこのトランザクションを実行するケースが少ないです。 例えば：まず、ユーザーはイーサリアムブロックチェーン上、スマートコントラクトでのDIDドキュメントを作成しないといけないです。しかし、非中央集権型のアイデンティティを作成するためにウォレットをダウンロードするユーザーは、必要なガス料金を支払うためのETHを持っていません。 この場合、ブロックチェーンのスマートコントラクトにこのDIDドキュメントを「オンライン」にするヘルプが必要です。このため、支援できる「仲介者」に依頼します。 つまり、この仲介者の役割は、ユーザー（所有者）の代理として、DIDドキュメントについての作成費を払うだけです。 DIDドキュメントの作成者と所有者は同じ人ではなくても構いません。下記のケースでも問題ありません：

• ＤＩＤ作成者は信頼できる仲介人であることと仲介人の身元を確認する役割を持っている。（例え、このDIDは、管理者（admin）のDIDドキュメントにリダイレクトできる）
• しかし、ユーザーが知らずに、作成者がＤIDドキュメントのデータを変更できることを必ずしも意味するものではありません。ユーザーのみが自分のDIDを制御でき、第三者とコントロールを共有するか、一人のみで管理するか選べることもできます。

用例：WebサービスがDID所有者を認証することを希望しているケース

さて、ウェブサービス「abcd.com」は、専用のページを経由してＳＤＩ（ＤＩＤ）を持っている所有者を確認することを希望しているケースを見てみましょう。（アプリを経由して承認されるケースを後でレビューしましょう） まずは、パソコン用のトラディショナルWebブラウザに焦点をあてましょう。 サーバーのログインページには、Webサービスのアドレスとユニークでランダムな文字列（英語で、「チャレンジ」とも言う）を含むQRコードが表示されます。 2-2　イラスト：　Webサーバー上、DIDの所有者を認証する仕組み。 ユーザーはDIDのウォレットでQRコードをスキャンします。 サーバーへの認証を行うため、ウォレットは、DIDにリンクされた鍵を使用されたいかどうかを、ユーザーの同意を得てから、認証秘密鍵を使用してQRコードに含まれている「チャレンジ」に署名します。次は、ウォレットは署名されたチャレンジとDID（識別子）をサーバーに送り返します。 WebサービスはDID（「ユーザー名」として）を受け取り、上記のイラストの手順に従って自動的に実行し、「DIDドキュメント」を取得します。認証に関するセクションを読み取り、デフォルトの認証ためにDIDにリンクされた公開鍵を見つけるサービスです。サーバーは、DIDの所有者が「公開鍵」に一致する「秘密鍵」を持っていることを確認する必要があります。このために、受け取った署名の有効性を確認したら完了です！署名が有効な場合、サーバーから承認され、アクセス可能になります。 注意：「DIDドキュメント」では、Webサービスに複数の認証鍵を割り当てることができます。 そして、メッセージの暗号化、契約書への署名など、さまざまな用途に複数の認証鍵を割り当てることが可能です。 ＶCの仕組みについて説明する前に、お客様の本人認証についてのDID仕組みを理解することが重要です。次の記事のテーマは、検証可能なクレデンシャルです！