この記事の内容
分散型IDプラットフォーム「Trinsic」に関する概要の紹介や試用してみた感想などを記載します。
目次
- はじめに
- PaaS型のサービスを利用する動機
- Trinsicの特徴
- チュートリアルを試してみる
- おわりに
はじめに
分散型アイデンティティのプロトコルにはuPort、Hyperledger Indy/Aries、IONなど複数のオープンソースプロジェクトがありますが、それらをより実装しやすい形で提供するプラットフォームサービスも登場してきています。今回はその中でもHyperledger Indy/Ariesベースで数少ない商用レベルのPaaSプロダクトを提供する「Trinsic」という海外のサービスについて、特徴や試用してみての感想などをまとめてご紹介します。
PaaS型のサービスを利用する動機
オープンソースで提供されている分散型IDのリファレンス実装を利用すれば、オンプレミスで動作する環境を自分で構築する事は出来ます。ただしこのような素のライブラリを使った実装は、少ないドキュメントとサンプルを駆使して原因不明のエラーと格闘しながら進める事になる、というのはよくある話です。さらに実装したものを実運用で利用できるようスケーラブルでセキュアなものに仕上げていくには、結果的にかなりの追加投資が必要になってくることがあります。また、分散型IDのオープンソースはその多くが追加開発や標準化で現在も頻繁に更新がされている為、自社開発で常にその最新の実装を維持していく事は難しいという側面もあります。セキュリティ面においても、秘密鍵やウォレットの管理を自社でセキュアに維持していくのは簡単ではありません。
このような事情から、サードパーティのベンダが提供するPaaS型サービスを利用するというのは、分散型ID実装においては現実的な選択肢の１つではないでしょうか。特にPoCの目的が技術検証ではなくビジネス面の検証なのであれば、このようなサービスを利用して開発に要するコストを圧縮し、その分本来の目的に集中するのも賢明な判断かと思います。
Trinsicの特徴
Trinsicについて
Trinsicは2019年にアメリカで創業されたスタートアップで、Co-Founderは世界初の商用DIDネットワークであるSovrin Network立ち上げ時のメンバーです。Hyperledger Ariesのオープンソース開発における主要なコントリビューターであり、DIFやToIP Foundation,Sovrin Stewardなど複数の業界団体にも所属しHyperledgerコミュニティの中でも高い存在感のある企業です。導入事例などはあまり公開されていませんが、世界75か国で1000名以上の開発者に利用されているサービスと謳われています。SSIに関する国内のPoC公開事例を追っている限りでは、Trinsicの国内導入実績はおそらくまだ無いと思います。
主要プロダクト
主に以下のプロダクトが提供されています。
・Trisnsic Wallet
GoogleやAppleのアプリストアで入手できるローカル管理型のデジタルウォレットアプリです。UIデザインを自社向けに変更するホワイトラベル提供にも対応しています。
・Mobile Wallet SDK（β版）
既存のモバイルアプリケーションにSSIの機能を組み込みたいニーズ向けのSDKで、現在はβ版として提供されています。特徴的なのは、このSDKは後述する「Wallet API」を操作する為のもので、ローカルにCredentialなどのリソースを持たないCloud型のWalletを実装する事が出来ます。
・APIs
Trinsicのコア機能にアクセスする為のAPIです。以下の３つの機能群に大別されます。
Provider API： 企業向けCloud Agentのプロビジョニング処理等
Credentials API： Credentialコントロール関連（Agent間接続、Credential発行、Proof検証、テンプレート管理等）
Wallet API： Cloud Walletの作成および管理
・Trinsic Studio
管理者向けのダッシュボードUIです。上記APIのほとんどの機能をGUIベースで直感的に実行する事が出来ます。
引用：https://trinsic.id/interactive-connections/
こちらはプラットフォーム全体の構成図です。全体の流れとしては、まずProvider APIを介して企業のプロビジョニング処理が実行されると、クラウド上のマルチテナント型のサーバーにOrganization（Cloud Agent）が作成され、APIキー等が払い出されます。以降は企業ユーザーは自社のアプリケーションからAPI Keyで認証しCredential APIにアクセスする事で、IssuerやVerifierとしての処理を実行出来るようになります。一連の処理はTrinsic Studioのダッシュボード画面からも同様の事が出来るようになっています。またWallet APIを利用すれば、ローカルデバイスにCredentialや秘密鍵を置かないタイプのCloud Walletを持つことが出来ます。
Provider APIについて
APIの中で気になったのがProvider APIですが、これはSSIプロバイダとしてエコシステムにおいて管理的な立場になる組織向けの機能です。Provider企業はIssuer企業やVerifier企業のオンボーディングを管理し、各企業向けにAgentをプロビジョニングすると同時に認証の為のアクセスキーを提供する事になります。また不要になった企業Agentの削除も行います。一見するとコンソーシアム型ブロックチェーンと同様で、中央集権的な管理組織の介在に見て取れますが、現実的なアプローチだと思います。なぜなら、Verifier企業はCredentialの発行元であるIssuer企業が本当に身元確認の取れた実在する企業なのか信用する必要があります。参加している企業が数社のうちは良いですが、数十社、数百社となった場合に確認しきれませんので、管理組織が統括して規制当局のルール等と整合を取りながら参加企業を管理するガバナンスモデルがどうしても必要になってきます。このあたりはSSIのガバナンスフレームワークを規定するTrust Over IP Foundationでも述べられています。理想を言えば、法人格の登記を管理しているようなオラクルシステムと連携し、自律的にオンボーディングを審査するような仕組みが出来ればいいのですが、実現はまだ先の話になるでしょう。
Trinsicのアカウントを取得すると標準でこのProvider APIおよびTrinsic Studioで企業管理が出来るようになりますので、つまりTrinsicを契約するのは管理者的な立場であるSSIプロバイダに相当する組織という事になります。
引用：https://trinsic.id/trinsic-launches-ssi-provider-product/
Wallet APIについて
Wallet APIはエンドユーザー(Holder)のCloud Walletをホストし管理する為の機能です。Cloud Walletと対極のWalletの事をLocal WalletやEdge Walletと言いますが、これはWalletの機能自体がユーザーのデバイス上（スマートフォン等）にあるWalletの事です。サードパーティのプロバイダに頼ることなく個人が自分のWalletとそこに含まれるCredential、秘密鍵を制御し管理するという点で、より純粋なSSIソリューションであると言えます。
一方、Cloud Walletは負荷のかかるライブラリの処理をクラウド上のサーバーで処理することで、アプリの実装の軽量化や柔軟性を実現しています。エンドユーザーは任意のアプリケーションから認証のスキームを介してウォレットを制御する事が出来、例えばモバイルアプリとWebブラウザで同じウォレットを見る事が出来ます。個人に代わって組織がWalletを管理したい場合や、特定のデバイスを持たないような場合の用途に向いています。必要があればCloud WalletをエクスポートしLocal Walletへ移行する事も出来ます。
Cloud Walletが必ずしもいいというわけではありませんが、Local/Cloudという２つの選択肢を提供しているサービスは他にあまり無く、特徴的なのではないでしょうか。
Trinsic Studioについて
Trinsic StudioはProvider APIの部分で述べた通り、SSIプロバイダとして企業Agentのプロビジョニングが出来るほか、各企業Agentの管理画面から接続用のInvitation作成やCredentialの定義作成、発行、Proofの定義作成、Proof Requestの作成、Proofの検証などの一連の処理をGUIベースで行う事が出来ます。Trinsic Studioから実施できる事は全てProvider API、Credential APIを利用して実施出来ます。APIのみを提供しているPaaSプラットフォームは他にもありますが、しっかり作りこまれた企業向けのダッシュボードUIまで標準提供している点は非常に魅力的に感じます。参加企業が少なく、標準的なSSI機能だけで事足りる用途であればコードを一切書かずに完結する事も可能だと思います。よって小規模なPoCであればTrinsic Studioを利用してコストをかけずに実現出来るかもしれません。
チュートリアルを試してみる
今回はTrinsicのWebサイトで公開されているチュートリアルを試してみましたのでその内容を解説します。APIを用いたアプリケーション実装はまだ試していません。
0. シナリオ
Aliceは大学（Faber College）から学位証明のCredentialを受け取ります。そして企業（Acme Corp.）の採用申し込みの際にそれを提出するという、非常にシンプルなシナリオになります。
1. 組織のプロビジョニング
Trinsic Studioにログインします。SSIログイン機能があるので、初回にログイン用Credentialを発行しておけば2回目からはTrinsic WalletでQRコードをスキャンしてパスワードレスでログインが出来ます。
ログインCredentialの項目は氏名、メールアドレス、IDの３つです。
ログインに成功すると、Trinsic Studioのトップ画面に遷移します。Organizationsのセクションから、組織の追加を行います。
組織名を入力し、NetworkとRegionを選択します。Networkは複数サポートされており選択できますが、チュートリアル用なので課金されない「Sovrin Staging Network」を利用します。RegionはクラウドデータセンターのRegionを指しますが、デフォルトのUnited Statesのままにしておきます。ちなみに日本のRegionは存在せず、一番近いのはSingapoleです。
組織Agentのプロビジョニングが完了すると、API KeyやCredential発行用のPublic DID、エンドポイントURLが発行されます。これらは参加企業に提供しプログラムからアクセスする際に利用するものですが、今回のチュートリアルでは利用しません。
ここではFaber College、Acme Corp.の２つの組織を作成しておきます。
2. 学位証明Credentialの作成～発行
次にCredentialを作成していきます。先ほどプロビジョニングしたFaber Collegeを選択すると組織専用のメニュー画面に入りますので、「Credential Template」のメニューから発行するCredentialの定義をテンプレートとして作成していきます。
図のようにCredential名称やバージョン、属性項目を入力して作成します。非常に簡単です。
テンプレートを作成したら、続けてCredentialの発行を行います。
先ほど定義した属性に対応する値を入力し「Create Offer Link」
Credential OfferのリンクがQRコードとURLで生成されます。
これをAliceに伝えて、デジタルウォレットで読み込んでもらいます。伝え方はWebサイトに表示したりメールで送信するなど、SSIとは別のスキームで行います。
AliceがTrinsic WalletでQRコードをスキャンすると、直ちにCredential OfferがWalletに届きます。AcceptすることでCredentialがWalletに保存されます。
Trinsic Studio側には発行の履歴がステータスと共に記録され、詳細まで閲覧が出来ます。
ここまでがCredential発行の流れになります。
本来であれば最初にコネクション確立のプロセスがありますが、ここではそれをスキップするConnectionless Exchangeという機能を使いました。そのため、ユーザーは送信されてきたOfferをAcceptするという１ステップだけでCredentialを受け取る事が出来ました。Connectionless機能は、二者間でWebサイト内などでの認証が既に確立しており、DID Conncectionの確立がUX上煩雑である場合に利用すると便利です。どんな場合でもConnectionを確立しているとユーザーの接続先リストが膨大に増えてしまい負担がかかりますので、現実的な運用ではありません。そのため繰り返しやり取りしない相手で、一度しか発行しないCredentialを授受する場合などに適した方法です。
Credential発行だけでなく、Proofのやり取りの際もこの機能を利用する事が出来ます。
3. 企業採用への応募（Proof提供）
AliceがAcme Corp.と接続し、採用応募の為のProofを提供します。
ここではConnectionless機能は用いず、Invitationを作成してコネクションを確立する方法で行います。
Trinsic StudioのConnectionsのメニューから、Invitationを生成すると、QRコードとディープリンク用URLが生成されますので、Webサイトへ埋め込んだりメール送信するなどしてAliceに伝達します。
今回はQRコードをTrinsic walletから読み込みます。InvitationをAcceptすると接続先に追加されました。
続いて、Trinsic StudioからProof Requestの定義を作成していきます。TrinsicではProofの事を「Verification」と呼んでいます。Acme Corp.の組織画面で、Verification Templateのメニューからテンプレートを作成します。テンプレート名称や要求する属性項目を入力していきます。
ここで、Hyperledger Ariesの特徴であるゼロ知識証明を使ってみます。ゼロ知識証明についての詳細な説明は割愛しますが、ここでの文脈では属性項目の情報を相手に渡さずに、問われた命題に対しそれが真実であるという事実だけを伝える秘匿化技術で、プライバシーの保護に役立ちます。「GPA>3」という条件式を設定し、GPAの値は要求しないが3以上であることの証明を求めるようにします。
Schema IDとして、さきほどFaber Collegeで作成したCredentialテンプレートのIDを指定します。これによりCredentialの種類を「学位証明」に絞ることが出来ます。SSIではSchemaはBlockchainに記録され複数の組織で使い回されるものですので、さらにIssuer DIDを指定することで、「Faber Collegeが発行した学位証明」として特定する事が出来ます。
テンプレートを作成したら、続けて接続済のリストからAliceのWalletを選択し、「Send Request」でProof Requestを送信します。
AliceのWalletにProof Requestが届きます。所有する学位証明のCredentialから対応する属性項目がプレ表示されます。ゼロ知識証明の条件も満たしているため、Proofとして提供可能な状態になっています。「Present」でProofを送信します。
Trinsic Studio側でProofの状態を確認すると、ステータスが「Accept」になり属性値が共有されています。ゼロ知識証明を使用したGPAの項目は共有されていません。
この後、チュートリアルではAcme Corp.がAliceを採用し従業員証明を発行するプロセスへ進みますが、Credential発行の流れは最初に説明した内容の繰り返しになりますので割愛します。
最終的にAliceが学位証明と従業員証明の２つのCredentialを入手してチュートリアルは終了です。
このチュートリアルでは全てTrinsic Studioだけで処理を行いましたが、Provider APIとCredentials APIを利用すれば、さらに柔軟で複雑な処理をコードベースで実装する事が出来ます。
最後に、チュートリアルで紹介されなかったものも含め、APIやその他の特徴的な機能を列挙します。
・Connectionless Exchange
Connection確立をスキップしてダイレクトにCredential Offer／Proof Requestが可能
・Predicate Constraint
Proof Requestの項目に数値演算ベースのゼロ知識証明を利用した条件指定が可能
・Revocation
Issuer側でのCredential無効化と、Verifier側での有効性チェックが可能
・Proactive Credential Sharing
Proof Requestを待たずに、Holder側から能動的にProof提供のアクション実行が可能
・Multi-party Connection Invitations
1つのInvitationで複数のHolderと同時にコネクション確立が可能
・チャットメッセージング
Connection確立済みの相手とメッセンジャーライクなUIでやり取りするチャット機能
・Zapier連携
ワークフロー自動化ツールのZapierと連携し、他のSaaSと連携したSSI機能の実行が可能
おわりに
ダッシュボードまでついたSSIのPaaSに触れたのは初めてでしたが、とても完成度が高く便利なサービスであることが実感できました。Provider APIとWallet APIを提供している点は特徴的で用途によっては非常に便利ですし、またAriesのメインコントリビュータが提供しているサービスであることから、おそらくCredentials APIについても、今後Ariesの新しい機能がいち早く実装されメンテナンスされていく事が期待出来ます。費用的にも非常に安価で、現実的に導入を検討出来ます。現在社内のチームでは、素のHyperledger Ariesのライブラリを使った開発検証を実施していますが、実装がなかなかうまくいかず苦労している部分も多いのが現状です。開発時の機能や環境の要件にもよりますのでPaaSで全てカバー出来るとは思いませんが、使えるシーンではこのようなサービスを積極的に採用検討し、開発コストを減らす工夫をしていきたいと思いました。
参考情報
Trinsic Webサイト ：プロダクトの概要の他、ブログにはSSIを学ぶ為の有用な記事もあります
Trinsic 開発者ドキュメント ：コンセプト、サンプルアプリ、APIリファレンスなど