Hyperledger Indy・Ariesによる分散型IDアプリケーション開発ガイド
1. 概要編
目次
- はじめに
分散型アイデンティティとは
Decentralized Identifier(DID)とは
Verifiable Credentials(VC)とは
分散型IDの基本的な仕組みと流れ - Hyperledger Indy・Ariesフレームワークの概要
Hyperledger Indyの概要
Indyを使用するシステムの構成イメージ
Hyperledger Ariesの概要
Ariesを使用するシステムの構成イメージ
Ariesのフレームワークについて
Aries CloudAgent Python(ACA-Py)について - アプリ開発の流れと概要
アプリ開発の流れ
初期登録
接続確立
Credential発行
Presentation検証 - 参考情報
1. はじめに
TIS Blockchain推進室では、Blockchainユースケースの１つとして分散型アイデンティティに関する技術検証やリサーチを行っています。
本記事では分散型アイデンティティフレームワーク(Hyperledger Indy/Aries)の概要とアプリケーション開発の全体像についてご紹介します。また次回以降で、分散型アイデンティティの紹介シリーズ第2弾、第3弾として、Hyperledger Ariesを利用した環境構築手順、アプリの実装手順をご紹介する予定です。
◆ 本記事のゴール
- Hyperledger Indy/Ariesフレームワークの概要を理解する
- アプリケーション開発の全体像と主要なアーキテクチャを理解する
◆ Decentralized Identifier(DID)とは
W3Cが標準化を進めている、URIベースの識別子(デジタルID)の仕様です。
一般的なIDは、企業などの発行体からIDの保有者(個人)へ発行されるのに対し、DIDはIDの保有者が自身で作成でき、デジタル署名の技術を使用して、IDの保有者はそのDIDが自分のものであることを証明します。DIDはグローバルに固有の識別子であり、人に限らず、車や家などのモノ、企業といった組織やデータなど、あらゆる対象に割り当てることができます。
◆ Verifiable Credentials(VC)とは
W3Cが標準化を進めている、個人の資格情報をデジタルの世界でやり取りするための、JSON形式で定義されたデータ仕様です。
VCには、メタデータに発行元組織のDIDや電子署名に使用する公開鍵情報が含まれ、これらをDLTと照合することでCredentialの検証が可能になります。これにより、VCは「資格情報にウソや改ざんがないことを検証できる、デジタルな個人情報」になります。現在は個人が物理的に管理している住民票、免許証、卒業証書などといったCredentialを、オンライン上の様々なサービスで利用できます。
◆ 分散型IDの基本的な仕組みと流れ
分散型IDの基本的な仕組みを以下に図示します。
＜分散型アイデンティティの概念図＞
図1における関係者(登場人物)は以下の3名で、それぞれ以下の役割があります。
Credeintialの発行から検証までの主な流れは以下の通りです。
- IssuerがHolderに対し、資格情報(Credential)を発行する
- Issuerは「〇〇さんに△△のCredentialを発行した」という情報をVerifiable Data Registryに登録する
- HolderはIssuerから発行されたCredentialを、自分のスマートフォン等に所有するWalletアプリケーションに保存する
- Verifierが提供する何らかのサービスをHolderが受けたい時、Verifierはサービス提供に必要な情報(卒業証明など)をHolderに要求する
- Holderは自分の持っているCredentialをVerifierに提出する
- VerifierはVerifiable Data Registryに登録されているCredentialの発行情報と、Holderから提出されたCredentialの情報を突き合わせ、提出されたCredentialにウソや改ざんがないことを検証する
DID、VCの詳細については、弊社がQiitaに投稿しているブログ記事でも触れています。参考としてご覧ください。
2. Hyperledger Indy・Ariesフレームワークの概要
◆ この章について
この章では、「Hyperleger Indy/Ariesとは何か」を説明します。それぞれのフレームワークの概要と、フレームワークに含まれるものの種類を説明し、最終的に開発するシステムの構成イメージを記載します。
◆ Hyperledger Indyの概要
Hyperledger IndyはHyperledgerが提供するオープンソースプロジェクトの１つで、分散型IDに特化したアプリケーション・フレームワークです。ブロックチェーンをベースとしたデジタルIDを提供するためのツール、ライブラリ、再利用可能なコンポーネントを提供します。実装レベルでは、前述の「DID、VCを実装するためのフレームワーク」という認識で大丈夫です。
https://www.hyperledger.org/use/
◆ Indyを使用するシステムの構成イメージ
- Indyのノードと、そのクライアントとしてのアプリから構成されます。各ノードはそれぞれDBを持ってDLTのネットワークを形成し、「Verifiable Data Registry」として働きます。
- ノードにアクセスするためのライブラリとして「Indy-SDK」が様々な言語で用意されており、クライアント側のアプリは(Indy-SDKがカバーしているものであれば)自由な言語で実装できます。クライアントアプリ(のIndyとやり取りする部分)を「Agent」と呼び、Indy-SDKを利用して従来のアプリにその機能を実装します。
- クライアント側にはAgentに内包される「Key Management Service(KMS)※」があり、保有しているCredentialや秘密鍵など、個別に情報を持ちます。
※ KMSは「ウォレット」とも呼びます
◆ Hyperledger Ariesの概要
Hyperledger AriesはHyperledgerが提供するオープンソースプロジェクトの１つで、Hyperledger Indyの機能を拡張する仕様、ライブラリです。Indyの持つ分散台帳をベースとして、Agent間でのP2P通信を介したCredentialの発行・保存・検証といった機能、およびプロトコルを提供します。
Ariesを使用すると、Indyの持つCredential発行・保存・検証といった分散型IDのコアとなる機能に加え、Agent間通信を実装できるようになります。
◆ Ariesを使用するシステムの構成イメージ
Indyをベースとしているため、構成としてはIndyと変わりありません。 従来のIndy-SDKではAgent間通信を独自に実装する必要がありましたが、AriesではAPIが用意されているので容易に実装可能です。
※ 参考 アプリケーションと各フレームワークの関係図
◆ Ariesのフレームワークについて
Indy-SDK同様、Ariesの定める仕様に沿ったフレームワークが多くの言語で実装されており、フロント側は自由な言語で開発できます。また、Indy-SDK同様にアプリに組み込む形の他、Agent自体で独立したアプリケーションとなるものもあり(フロントとの連携はREST-APIで行う)、作りたいシステムに合わせてFWを柔軟に選択できます（※ まだ開発途中のFWもあります）。
本記事では「Aries CloudAgent Python(ACA-Py)」での環境構築、開発手順を記載しています。
Aries CloudAgent PythonはサーバーAgent(独立したアプリケーション)として提供されています。Aries MobileAgent Xamarinは、Xamarinを使用したモバイルアプリ開発用のFWで、モバイルアプリにAgent機能を組み込みます。その他、FWに応じてサーバーAgentとして提供されるもの、Webアプリを作るもの、デスクトップアプリを作るものなどがあります。
◆ Aries CloudAgent Python(ACA-Py)について
Pythonで実装された、AriesFrameworkの1種です。ACA-Pyは独立したアプリになっているため、Indy-SDKのように、自作のアプリに組み込む必要はありません。ACA-Pyの機能はREST-APIとして提供されており、自作のアプリからはHttpリクエストを投げて通信します。
ACA-PyにはAgent同士の通信機能が備わっているため、フロントアプリは自身が持つACA-Pyとのみ通信し、ACA-Pyが他のACA-Py、およびIndyの持つVerifiable Data Registryと通信します。
3. アプリ開発の流れと概要
◆ この章について
この章では、Indy/Ariesを使用したアプリ開発の基本的な流れについて説明します。 アプリが取る状態の種類を説明し、どのような流れで処理が進んでいくかを状態ごとに解説します。 この章での説明はIndy/Ariesで概ね共通する内容となり、具体的なコードの扱いは説明しません。
◆ アプリ開発の流れ
Hyperledger Indy/Ariesを使用したアプリの処理は、大きく以下のフローで遷移します。
(1). 初期登録
Credential Schema、Credential Definition等のデータをVerifiable Data Registryに登録する。
(2). 基本状態
下記(3)～(5)のいずれも進行していない状態。
(3). 接続確立
他Agentとの接続を確立しようとしている状態。 DIDの発行～DID交換の完了まで。
(4). Credential発行
Credential発行の流れを実施中の状態。 Credential Offerの発行(受領)～Credentialの保存まで。
(5). Presentation発行
Presentationの流れを実施中の状態。 Presentation Requestの発行(受領)～Presentationの検証まで。
※ (3)、(4)、(5)の実行順序に制約はありませんが、基本的には(3)→(4)→(5)と順番通り実行していきます。接続確立ができていないとCredential発行ができず、Credentialを持っていないとPresentationを送信できないためです。
以下、それぞれのステップについてもう少し具体的に説明していきます。
◆ 初期登録
初期登録関連の主要なキーワードは、以下の通りです。
< Credentialについて >
CredentialはIssuerがHolderに対して何らかのアイデンティ情報を発行しその内容を認定する為のもので、言い換えると「資格情報(身分証、認定証、会員証など)をデジタルで表現したもの」です。IssuerがHolderに資格としてCredentialを発行する、という関係はこれまでの紙ベースの資格情報と変わりありませんが、IssuerはHolderにCredentialを発行すると同時に、Verifiable Data Registry に「〇〇さん(Holder)にこのCredentialを発行した」という情報を登録します。CredentialにはIssuerのDIDやデジタル署名も含まれるため、Verifiable Data Registryを参照することで、「このCredentialはたしかにIssuerが発行したものだ」と検証できます。
イメージ：
Credentialを発行するには、事前にCredential Schema、Credential Definition（後述）を作成し、Verifiable Data Registryに登録しておく必要があります。
< Verifiable Data Registryについて >
Credintial発行の事実と共に、発行者であるIssuerのDIDと署名に利用した公開鍵情報（DID Document）を記録するデータストアです。公開されており誰でも参照可能ですが、登録される情報はハッシュ化されており、プライバシーは守られます。Verifierが検証の際に利用出来るよう耐改ざん性が求められる事から、Hyperledger IndyのようなBlockchainが利用される事が一般的です（Blockchainに限定されている訳ではありません）
< Credential Schemaについて >
はじめに、IssuerはCredential Schemaを作成します。これはCredentialに記載される属性を表すもので、「スキーマID」、「スキーマ名」、「属性のリスト」などで構成されます。作成したスキーマはVerifiable Data Registryに格納され、IDを知っていれば誰でも参照できます。
例：
< Credential Definitionについて >
次に、IssuerはCredential Definition を作成します。これはCredentialの定義情報(枠組み)で、内部にSchemaの情報や、Revocation Registryの情報を持ちます。こちらもVerifiable Data Registryに格納され、IDを知っていれば誰でも参照できます。 また、他Issuerの作成したSchemaIDを指定して、そのSchemaに沿ったCredential Definitionを作成することもできます(Schemaの使い回しが可能)
例： (※ 非常に大きなJSONになるので、一部のみ抜粋します)
具体的には、Credential Definitionは以下の情報を持ちます。
- Schemaの情報(Credentialの項目群)
- そのSchemaを使用して実際にクレデンシャルを発行するのは誰なのか(IssuerのDID)
- このCredentialでは、ゼロ知識証明の方法としてどの署名方法を使用するのか(デフォルトでは”CL”(Camenisch Lysyanskaya) ※ 現状”CL”しかサポートされていないようです)
- このCredentialは発行後に失効させる機能を使用するか
※ Credential SchemaとCredential Definitionの違い
Credential Schema/Credential Definitionの関係を現実世界のモノ(ここでは学生証)に例えると、以下のようになります。
- Credential Schema: 「学生証とは一般的にどういう項目が含まれているべきだ」と定義し、標準化したテンプレート
- Credential Definition: そのSchemaを使いつつ、「A大学の学生証」として、発行元のIssuerまで定義しているもの(加えて、署名の方法や失効の有無などのルールも定義)
SchemaはVCが濫立しないよう標準化と相互運用を目的としている為、あるIssuerが台帳に登録したものを別のIssuerが使い回せます（※ ただし、Schema IDの連携は必要です）。とはいえ、Schemaだけだと「どこの大学の学生証か」が識別できないため、IssuerのDIDまで定義しているのがCredential Definition、ということになります。
Credential発行の前提として必要な作業はCredential Schemaの登録、Credential Definitionの登録の2つです。これらの登録が完了すると、Credential Definitionの定義情報をもとに、実際のCredentialを発行できるようになります。Credential Schema、Credential Definitionは1度のみ登録すればよく、Credentialは値を変えながら何度でも発行可能です。プログラミングの概念で例えるとすると、「クラス定義」がCredential Definition、「インスタンス」がCredential、という関係になります。
◆ 接続確立
接続確立関連の主要なキーワードは以下の通りです。
Hyperledger Indyでの接続確立に登場するキーワード
分散型IDの世界では、原則としてAgent同士がP2P通信を行うため、それぞれが互いに識別し合い接続を確立する(相手のIPアドレスを知る)必要があります。 DIDはそのために使用でき、P2P通信は相手のDIDとIPを紐づけることで実現されます。自分のDIDは自分でいくつでも作成可能なため、通信する相手ごとに異なるDIDを使用することで、プライバシー(誰と繋がっているかなど)が漏れる恐れもありません。
イメージ：
< Pairwiseについて >
Pairwiseは、自分のDIDと相手のDIDのペアのことを指し、その相手との通信に使用します。各entityは接続確立した相手のDIDを、自分のDIDと合わせてPairwiseとして登録しておくことで、接続情報を管理できます。
イメージ：
< Indyでの接続確立の流れ >
※ 赤枠はAgent1側の処理、青枠はAgent2側の処理になります
< ACA-Pyでの接続確立 >
ACA-Pyの世界では、接続情報は「Connection」という単位で管理されます。Connectionは5つの状態を持ち、それぞれ接続確立のためのステップごとに進んでいきます。接続を確立したい2者は「inviter」と「invitee」に分かれ、Ariesのプロトコルに沿って下記の状態を進めていきます。
< ACA-Pyでの接続確立の流れ >
※ 赤枠はinviter側の処理、青枠はinvitee側の処理になります
◆ Credential発行
< Credential Offerについて >
Credential Offerとは、発行予定のCredentialの、内容の事前確認をするものです。Credentialの種類や、そのCredentialの各項目の値などをHolderに対して連携し、この内容で間違いないことの合意を取ります。Holderは、このCredential Offerの内容を確認し、後続のCredential RequestをIssuerに送信します。
Credential Offer例(ACA-Py)
※ Credential Offerを発行するには、そのIssuerが自身でCredential Definitionを作成しておく必要があります。Credential Definitionの作成時には他Issuerの作成したSchemaを利用できますが、Credential Offerの発行時には、他Issuerの作成したCredential Definitionは利用できません。
< Credential Requestについて >
Credential Requestとは、Credential Offerを受けた後にHolderがCredentialの発行を要求することです。そのOfferの内容でCredentialを発行してください、とIssuerに依頼するイメージになります。Holderはこの際にLinkSecretを発行し、Credential Requestに含めてIssuerへと渡します。このLinkSecretは発行者であるHolderしか持っていない情報である為、Issuerは「”このLinkSecretの所有者”にCredentialを発行した」ということをブロックチェーンに記録します。また、LinkSercretはPresentationの際にも使用され、自分が指定したCredentialの所有者であることの証明として、HolderからVerifierへと送ります。VerifierはHolderから受け取ったLinkSecretとIssuerがブロックチェーンに記録しておいた情報を照合する事で、Credentialの所有者を検証することができます。
※ LinkSecretは元々「MasterSecret」と呼ばれていましたが、現在は「LinkSecret」となり、「MasterSecret」という呼び方は非推奨とされています。
ただAPI側には反映されていないため、コード上「MasterSecret」という単語が出てくることがありますが、LinkSecretのことと解釈してください。
< Credential発行の一連の流れ >
実際にCredentialを発行する際の流れは、以下のようになります。
※ 赤枠はIssuer側、青枠はHolder側の処理になります。
※ 吹き出しは現実でのやり取りの際に行われるであろう会話のイメージです。
◆ Presentation検証
Presentation関連のキーワードは、以下の3つです。
PresentationはHolderが自分の資格情報をVerifierに開示する際に登場するもので、文脈としては「HolderがVerifierの提供するサービスを受けようとする際に、Verifierが事前確認として開示を要求する、Holderの資格」です。イメージとしては、たばこ購入前のタスポ提示、コンビニ等での荷物受取前の身分証提示、病院受付での保険証提示などになります。現実世界ではこれらの証明書を直接提示していますが、提示する証明書に必要以上の情報が含まれる事が多くプライバシーの課題を抱えています。例えばバーでアルコールを購入する為に成人であることの証明に運転免許証を提示した場合、必要なのは生年月日のみであり、運転できる車の種類や住所は本来必要の無い情報です。
分散型IDの世界では、Holderが所有する複数のCredentialから必要な項目だけを抜き出してPresentationを作成し、他の情報と組み合わせて送信する事ができます。つまりVerifierがサービスを提供するにあたって必要としない情報は、開示しません。また、「Verifierにはハッシュのみ渡す」ということも可能であり、Verifierへは一切の生データを渡さずに、資格の証明を行うこともできます。
Credentialとは異なり、Presentationに関する一連の流れでは、Verifiable Data Registryに登録するものはありません。
イメージ:
たとえば、身分証として自動車の運転免許証を使用する場合、以下のような組み合わせが可能です。
※ 身分証明として要求されているものが「氏名」と「住所」の場合
- 「氏名」は開示する
- 「住所」は開示する
- 「眼鏡が必要か」は開示しない
- 「対応する自動車の種類」は開示しない
Presentationのやり取りは、以下の流れとなります。
- HolderがVerifierのサービスを受けようとする(前提)
- VerifierはHolderに対し、Presentation Request(= 資格の開示要求)を発行する
- Holderは所有しているCredentialの中から、Presentation Requestを満たすCredential項目を選び、Presentationを作成、Verifierに送信する
- VerifierはHolderから受信したPresentationと、Verifiable Data Registryに登録されているCredentialの発行情報(Issuerが登録したもの)を照合し、Holderから受信したものに改ざん・なりすましがないことを確認する
- Presentation内容に問題がなければ、VerifierはHolderに対してサービスを提供する
4. 参考情報
最後に、Indy/Ariesの開発において参考となる情報をいくつかご紹介します。
W3C標準
・Decentralized Identifiers (DIDs) v1.0
・Verifiable Credentials Data Model 1.0
Hyperledger Indy/Aries概要
・Hyperledger Indy / Aries / Ursaについてまとめた
Github
・indy-node
・indy-sdk
・Aries-CloudAgent-Python(ACA-Py)
Aries-RFCs(仕様群)
・Ariesの仕様一覧
ラーニングサイトの紹介
・Introduction to Hyperledger Sovereign Identity Blockchain Solutions: Indy, Aries & Ursa (LFS172x)
・Becoming a Hyperledger Aries Developer (LFS173x)
今回は、分散型IDおよびそのフレームワークであるHyperledger Indy/Ariesの概要についてご紹介しました。
次回の記事では、Hyperledger Ariesの実装の1つであるAries-CloudAgent-Python(ACA-Py)について、環境構築手順を紹介します。
お問い合わせ: bc_prom@ml.tis.co.jp
記：TIS Blockchain Promotion Office (Hiromichi Abe)
Thanks to Takahiro Uchidate and Hideki Nakachi.
