この記事の内容
この記事では、Evernym社が提供しているデジタルウォレットアプリ「Connect.me」を実際に使用しながら、自己主権型アイデンティティにおけるCredentialの取得やProof提供を体験する事が出来るデモの流れを解説していきます。
目次
はじめに
シナリオの全体像
#1. Faber Colledge
#2. Acme Corp.
#3. Thrift Bank
まとめ
はじめに
これまでの記事で、自己主権型アイデンティティの概要やその実装技術の1つであるHyperledger Indy / Aries / Ursaについて触れてきました。次に気になる部分としては、実装されたアプリケーションが実際にどのようなシーンでどのようなイメージで動くのかという点です。イメージを掴むために手っ取り早い方法としては、コンシューマー目線でデジタルウォレットのアプリを触ってみるのが1つだと思いました。デジタルウォレットアプリは世の中に色々と存在しますが、その中でもHyperledger Indyの開発元かつSovrin Networkの中心企業でもあるEvernym社が提供する「Connect.me」というウォレットアプリがあります。技術としてはこれまで調べてきているHyperledger Indy /Ariesが採用されていますし、企業の立ち位置的にSSIのコンセプトをプロダクトにしっかり反映しているはずという期待から、この「Connect.me」を触ってみることにしました。
同社が提供するデモシナリオを、アプリを使いながら解説していきます。ただ説明するだけでは面白くないので、裏で技術的にどんな処理が行われているのかをなるべく想像しながら追っていこうと思います。どんな処理が行われているかの説明は、前々回と前回の記事を一通り理解した前提で記載しており、細かい用語や基本的な概念の説明などは省いています。
シナリオの全体像
ざっくり言うと、ユーザー（Alice）がまず自分が卒業した大学から成績証明書をデジタルクレデンシャルとして取得します。次にAliceはそのクレデンシャルを提示してある企業の採用に応募し、採用された後に雇用証明のクレデンシャルを取得します。最後にAliceは成績証明書と雇用証明のクレデンシャルを銀行に提供して自動車ローンの申し込みを行う、という流れです。これらをデジタルウォレットアプリを使って行います。以下3つのパートに分けて追っていきます。
#1. Faber Colledge
・大学にアクセスし、成績証明書のCredentialを取得
#2. Acme Corp.
・Acme Corp.にアクセスし、従業員採用の申し込みを行う（#1で取得した成績証明書をProofとして提供）
・その後Acme Corp.に無事採用され、雇用証明のCredentialを取得
#3. Thrift Bank
・Thrift Bankにアクセスし、自動車ローンを申し込む（#1,#2で取得した成績証明書と雇用証明をProofとして提供）
#1. Faber Colledge
まず最初にPCブラウザでtry.connect.meにアクセスします。
前提として、WebサイトのリンクからConnect.meアプリをスマホにインストールしておきます。（Android/iOS両対応）
「Start Tutorial」でシナリオスタートです。
Faber ColledgeのWebサイトに遷移します。見た目それっぽいですが、実在しないダミーサイトです。
右上の「Sovrin」アイコンをクリックします。
QRコードのポップアップが表示されます。
※何をやっているか： Endpoint情報の公開
ここでの関係性はFaber ColledgeがIssuer、AliceがHolderになります。
QRコードにはIssuerであるFaber Colledgeが世間に公開しているPublic DIDと公開鍵が埋め込まれており、Public DIDはHolderとDIDベースのコネクションを確立する為のエンドポイント情報としての役割を担います。公開鍵の用途は後述します。
次に、Connect.meでPCの画面越しにこのQRコードをスキャンします。すると「Faber Colledgeが接続を要求しています」のようなメッセージが出るので「Connect」で接続します。ここで実行する際に生体認証を挟みます。
PCの画面にこのようなポップアップが表示され、Faber ColledgeとConnect.meが接続されたことがわかります。
※何をやっているか： DIDの交換とコネクション確立
Connect.meでQRコードを読み取った後、HolderとIssuerの間でDIDコネクション確立の処理が行われます。おそらく前回の記事で触れたHyperledger Ariesの**DID Exchange Protocol**で処理されていると思います。まずQRコードで取得したEndpoint(Public DID)に対して、HolderがConnection Requestを送信します。この時、Holderは自分のDIDとDID Docを生成して自分の公開鍵と一緒に同封し、QRコードに含まれていたIssuerの公開鍵を使って暗号化しています。次に、Issuerがメッセージを受信し、自分の秘密鍵で復号化して開きます。HolderのDID、DID Doc、公開鍵などを取得した後、今度は同様にIssuer自身のDID、DID Docを生成してメッセージに同封し、HolderにConnection Responseを返します。最後にHolderは受信したメッセージからIssuerのDID、DID Docを取得し、これで双方の通信が確立します。少しややこしい表現になってしまいましたが、要するに公開鍵暗号方式でお互いのDID/DID Docを交換しています。
ここでやり取りしているDIDはPrivate DIDであり、Blockchainには書き込まれません。二者間のみが知るDIDベース、かつ公開鍵で暗号化を行っているのでセキュアな通信になっています。また、相手のDIDと自分のDIDを記録したレコードをローカル（ウォレット内）に保存することで、以後も継続的にこのコネクションを使うことができます。
次に進みます。PCブラウザでは、Aliceに対して成績証明書の発行を促す画面になります。「Continue」をクリックします。
Connect.meに通知メッセージが届きます。開くと成績証明書の情報が確認できます。「Accept」をタップすることでこのCredentialが取得され、通知メッセージは消えます。
PCブラウザの画面を見ると、成績証明書のクレデンシャルをConnect.meで取得できた旨が表示されています。HTTPの裏側でDIDの通信が行われていますので、それをトリガーに勝手に画面が遷移するようです。周期的にポーリングみたいな処理をしているのでしょうか。
※何をやっているか： Credentialの発行
PCブラウザで「Continue」をクリックしたタイミングで、IssuerからHolderに対してCredential Offerが送信されています。ここで使われているプロトコルは**Issue Credential Protocol**が該当すると思います。Connect.me側で「Accept」した段階でCredentialが発行されます。もっと細かく言うと、IssuerにCredential Requestを送り、IssuerからCredentialが届き、さらにIssuerにack（受信完了通知）を返す、という動きをしています。
それともう１つ、IssuerはBlockchainに自分のPublic DID、公開鍵、Credentialのスキーマなどの情報を書き込みます。この情報は後でVerifierがHolderから受領するProofを検証する際に必要になるものです。
ここまでで、#1のシナリオは完了です。
#2. Acme Corp.
次のシナリオです。またPCブラウザの画面から「Continue」で進みます。
採用申込先であるAcme Corp.のWebサイトへ遷移します。先ほど同様に「Sovrin」アイコンをクリックます。
Endpoint情報を含むQRコードが表示されます。
Connect.meに接続リクエストが届き、「Connect」でコネクションが確立します。
ここまででやっている内容は#1のFaber Collegeの前半部分と全く同じです。AliceがConnect.meでEndpointを読み取った後、DID Exchange ProtocolでAlice ⇔ Acme Corp.間のDIDコネクションが確立されました。
次に、ここからが少し違う動きをします。「Continue」で継続します。
Acme Corp.からAliceに対して、５つの項目の情報提供を要求しています。
Connect.meを見るとAcme Corp.からメッセージが届いています。開くと、先ほど要求された項目に対応するAliceの情報がプリセットされています。Faber Colledgeのアイコンからわかる通り、この情報はAliceが#1のステップで取得した成績証明書を由来としています。
「Send」をタップすると、この情報がAcme Corp.に提供されます。
Acme Corp.のWebサイト画面が自動的に遷移し、Aliceの送信した項目がセットされました。こういったWebフォームでの手入力が不要になるという利便性向上もSSIのメリットの一つです。「Continue」をクリックします。
Acme Corp.への採用申込が完了しました。
※何をやっているか： Proofの提示
ここまでの内容を整理します。まずここでのAcme. CorpとAliceの関係性は、Acme Corp.がVerifierでAliceがHolderです。
HolderはFaber Colledgeの時と同じ方法でVerifierとDIDコネクションを確立しました。この時、Holderが生成しVerifierに提示したPrivate DIDはFaber Colledgeに提供したものとは異なるものです。Private DIDは当事者間のプライベートな通信を担保する為、異なる相手に使い回すことはしません。
次に、VerifierとHolderの間でProofのやり取りが実施されました。ここでは**Present Proof Protocol** というものが使われているはずです。まずVerifierからHolderに対してProof Requestが送信されます。「この項目を出してください」と要求するものです。Holderはそれを承諾すると、#1でFaber Colledgeから取得した成績証明書のCredentialを使い、Proofを作成します。そしてVerifierにそのProofを送信し、VerifierはProofを受信した後にHolderにack（受信完了通知）を返します。
VerifierがProofを受け取った後は、本来であればその内容が正しいかの検証を行うはずです。具体的には#1のステップでFaber ColledgeがBlockchainに書き込んだ情報を参照しProofと突き合わせることで、Issuerが本当にFaber Colledgeか・間違いなくAliceに発行されたProofか・変更されていないか・失効していないかなどをチェックします。ただし、このシナリオでは検証については含まれていないようです。実際のシーンではProofを受領した時点で即時チェックするかもしれませんし、定期的にバッチ処理するかもしれません。ユースケースによるかと思います。
次に進みます。少し話が飛んで、AliceはAcme Corp.に採用された事になっています。そして雇用証明を受け取るように促されます。
Acme Corp.のWebサイトからCredential Offerが送信されました。
Connect.meに通知が届いているので、Credential Offerの内容を確認し、「Accept」で受領します。
#1のステップで成績証明書のCredentialを受領した時とやっている事は同じですね。
これで、#2のシナリオは完了です。
#3. Thrift Bank
最後のシナリオです。ここでは、AliceがThrift Bankに自動車ローンの申し込みを行います。
PCブラウザの画面から「Continue」で進みます。
Thrift BankのWebサイトに遷移しました。これまで通り「Sovrin」アイコンから接続します。
ここも同様です。接続用のEndpoint情報を含むQRコードが表示されます。
Connect.meで読み取って接続します。
PC側の画面で接続完了メッセージが表示されます。
次に進むと、また同様に情報提供を要求するProof Requestです。今回は項目が多いですね。
Connect.me側でメッセージを開きます。
この時点で気づいたのですが、各項目をスライドすると右端のアイコンが変わります。これはおそらく「このClaim項目を提供しない」というアクションですね。住所の番地、生年月日、名字を提供しない事にしました。
SendでProofを送信します。
PCの画面が切り替わり、項目が自動反映されました。これだけの項目を手入力というのはかなりうんざりしますし、入力ミスも起こりがちなので自動反映は便利です。ただ、ここで気になる点が２つありました。
まず１つは、先ほどConnect.me側で項目提供しない事にした住所の番地、生年月日、名字が普通に反映されています。必須項目になっているからでしょうか？それにしても勝手に情報渡されるのはちょっと困ります。
２つ目は、デモシナリオの事前説明では成績証明書と雇用証明の２つのCredentialを使うと言っていたのに、成績証明書に関する項目は何も登場せず提供することもありませんでした。
いったん置いておき、「Continue」で進みます。
必要項目が全て登録され、ローンの申請が完了しました。
※何をやっているか（やりたかったか）： 複数のCredentialから構成されるProofの提示
このシナリオで実施した操作はVerifier・Holderの間でのDIDコネクション確立とその後のProof授受の2つです。やっている事自体は#2のシナリオと同じなので、2つについて詳細な説明は省きます。ただ推測ですが、本来は成績証明書と雇用証明の2つを組み合わせたProofを想定していたのかなと思いました。Proofとして出す情報は#2のシナリオのようにVerifiable Credentialsをそのまま提供する事も出来ますが、異なるVerifiable Credentialsを組み合わせたサブセットであるVerifiable Presentation（詳細は前回記事参照）を使う事も出来ます。その点が反映されていたらデモとしてもっと良かったのではと思いました。
これで全てのシナリオが完了し、デモは終了です。
まとめ
「Connect.me」を使って自己主権型アイデンティティにおけるCredentialの取得やProof提供を体験する事が出来るデモを一通り操作し、どのような処理が行われているかを考察してきました。よかった点、気になった点がいくつかありますので最後にまとめます。
よかった点
全体的にわかりやすいシナリオで、SSIの考え方で登場する基本的な要素（Credential発行・所有と参照・Proofの提示）を一通り体感する事が出来ました。ユーザー目線におけるSSIのメリットとして以下のような点が挙げられますが、どれも実際に利用してみて強いメリットだなと感じました。
・認証の為にID/Passwordを覚える必要がない
・相互のDID認証により相手と安全なコネクションが確立できる（フィッシングのリスクが低い）
・オンラインサービス上の入力の手間がかなり軽減される
・ウォレットに取得した自分のアイデンティティ情報をいつでも確認できる
気になった点
・UX / リテラシー上の課題
PCとスマホを行ったり来たりするのがやや複雑で、この点はITリテラシーが高くない層にとってはやや厳しいのではと思いました。Agentはウォレットアプリに限らずPCブラウザのExtenshionなども想定されているので、PCだけで完結するオペレーションも実現できるはずです。ただそういったプロダクトはまだ見たことがないのと、デバイス間の同期はどう実現するのかが気になります。ちなみにスマホだけで完結できないか、という点は試してみました。スマホのブラウザで各Webサイトにアクセスすればいいだけです。この場合「Sovrin」アイコンをタップした時のアクションはQRコードの表示ではなく、Connect.meが起動し接続リクエストの画面に移動しました。スマホで完結すればいつでもどこでもCredential発行やProof提供が出来るので、この点は便利です。ただこのデモでは不具合なのか、#3のThrift Bankとの接続が出来ず途中で止まってしまいました。
・どこまで自己管理できるか
Proofを提供する際にClaim項目ごとに提供する・しないを選べる点も（デモではうまく機能しませんでしたが）、まさに自己主権的だなと思う一方で実際どこまで使われるかが気になりました。案外みんな気にせず全項目提供してしまうのでは？という気もします。ここはプライバシーに関する意識とか国民性が影響してくるのかもしれません。
また、Credentialが大量に増えてきたときにどれを使うべきかの判断や管理が難しくなるのでは？とも思いました。個人情報の基本4項目（氏名、生年月日、性別、住所）を証明するだけならパスポートでも運転免許証でもマイナンバーカードでも従業員証明でも使えるわけで、どれをソースにするべきなのか、誰がそれを使うと判断するべきなのかなどを考える必要があります。ここを解決するにはUIの改良もそうですし、標準化の検討も必要になるのではないでしょうか。そのあたりを全部代行しますよという発想で日本では情報銀行ビジネスが登場していますが、もしかすると情報銀行の方が先に流行るのかもしれません。
・デモの挙動
ここは別にデモだから許容範囲ではあるのですが、Proof提供時にClaim項目を選べる機能が実際のProofに反映されなかったり、スマホ内ブラウザでアクセスするとThrift Bankとのコネクションが出来なかったり、複数のCredentialを組み合わせてProof作成する部分がシナリオになかった点がやや気になりました。
今後やってみたいこと
同じようなSSIウォレットのプロダクトはEthereumベースのuPortなど他にもありますので、今後触ってみたいと思います。また情報銀行アプリやeKYCアプリなど、類似カテゴリのプロダクトとのコンセプトや機能における違いも整理してみたいと思っています。
それともう1点、Evernym社では今回取り上げたConnect.meの他に、Crtedential発行やProofのVerifyなどIssuer・Verifier側の機能を提供するSaaS製品も出しており、無料のSandboxも提供しています。私の関わっている業務では現在これらのバックエンド処理も含めて開発検証にチャレンジしていますが、こういったSaaS・PaaSが今後増えてくると開発がかなり楽になるはずです。これらのプラットフォームで何がどこまで出来るのかといった検証をやってみたいと考えています。
[参考]
デモ体験用Webサイト
Connect.meアプリ（Google Play）
Connect.meアプリ（App Store）
Evernym社Webサイト
[過去の記事] [自己主権型アイデンティティ（Self-Sovereign Identity）の概要](https://qiita.com/pirodate/items/afc8c239345cfd9fb3a5) [Hyperledger Indy / Aries / Ursaについてまとめた](https://qiita.com/pirodate/items/7615fa71f59ae148c5f8)