【Hyperledger Aries】モバイルアプリ型Holder Agentの開発における選択肢

2022-07-08
2024-11-20
Decentralized Identity
Hyperledger, Verifiable Credentials, W3C DIDs
1099回
0件

こんにちは。GMOグローバルサイン・ホールディングスCTO室で分散型IDの研究開発をしている神沼@t_kanumaです。

この記事では、Hyperledger Indy/Ariesの領域に限定して、私が考える現時点(2022/7)でのHolder Agentの開発の選択肢をご紹介します。

1 前提
2 Holder Agent開発の選択肢
- 2.1 1. 商用のMobile SDKまたはWhite Label(OEM) Appを利用する
- 2.2 2. Hyperledger Aries
3 おわりに

前提

Hyperledger Indy/Ariesとは何か、またAriesのアーキテクチャなどについては以下の拙著をご参照ください。

Holder Agent開発の選択肢

現時点において、現実的には2つの選択肢になるのではと考えています。

SSI/VCモデルの実現を助けてくれる汎用的なプラットフォームサービス。それを展開する米国の会社がいくつかある。その会社が商用提供するHolder Agent開発のためのMobile SDKまたはWhite Label(OEM) Appを利用する。
GitHubのHyperledger Aries公式のリポジトリ群の中に、Holder Agentをモバイルアプリとして開発できるフレームワークが3つあり、それらを利用して開発する。またその内の2つのフレームワークではそれを基盤にした、開発者から見ると参照実装的な位置付けとして捉えることができるモバイルアプリのリポジトリが2つあり、それらのコードを参考にできる。

それではそれぞれについて詳しく見ていきます。

1. 商用のMobile SDKまたはWhite Label(OEM) Appを利用する

Evernym社

Evernym社はアメリカのスタートアップで、Hyperledger Indy/Aries/Ursa、そしてSovrin Networkの発展に貢献してきたSSI分野のリーディングカンパニーです。（詳細はこちらをご参照ください。）現在はAvastというサイバーセキュリティ会社の傘下に入っています。

Evernymは、以下のプロダクトを提供しています。

Holder向け
- Connect.me
  - Holder Agentとなるモバイルアプリ。
  - エッジ型でありWalletはモバイルデバイス内に生成される。
  - App Store/Google Playからインストールできる。
  - VC発行とProof検証のデモを体験できるページが用意されている。
- Mobile SDK
  - Holder Agentを開発するためのSDK。Walletはエッジ側（モバイルデバイス内）に生成される。
  - Android/iOSの両プラットフォームに対応している。
  - 各Holderに対応するCloud AgentをEvernymプラットフォーム内に作る必要がある。（SDKだけを利用するとしてもプラットフォームも合わせて使う必要があるということ。）
  - Evernym社に問い合わせたところ、Holderの開発にMobile SDKを利用するとしても、IssuerとVerifierの環境をACA-Pyなどを使い独自に構築することは可能とのこと。（ただし、Aries Interop Profileのバージョンが一致しなくてはならないと推測する。）
- White Label App
  - Connect.meベースのReact Native製アプリで、画面デザインや文言、DIDCommメッセージの受信方式などをカスタマイズできる。
  - カスタマイズできる項目はここを参照。
  - Mobile SDKと比較したメリット: 開発工数を少なくできる。
  - Mobile SDKと比較したデメリット: 自由度が低い。（VC発行やProof検証など他エージェントとやりとりするフローについて変更できないのではないかと、ドキュメントを読んだ上で推測する。）
Issuer、Verifier向け
- Verity
  - IssuerおよびVertifierを開発するためのREST API/SDK。
  - ControllerおよびWebhook部分はVertifyユーザー自身の環境に構築する。
  - Walletを含むAgentはEvernymの環境に構築される。
  - 各種ドキュメント
    - APIのSwagger UI
    - API/SDKのGitLabリポジトリ
      - 開発ガイド
      - サンプルコード
- Verity Flow
  - ノーコードでUIを操作しながらIssuerとVerifier（の管理画面）を構築する。
  - 開発中の模様で未だサービス提供されていない。

Trinsic社

Trinsic社もアメリカのスタートアップです。Evernymと同様にHyperLedger Ariesの発展に貢献してきた会社です。

以下のプロダクトを提供しています。

Holder向け
- Trinsic Wallet
  - Holder Agentとなるモバイルアプリ。
  - エッジ型でありWalletはモバイルデバイス内に作られる。
  - App Store/Google Playからインストールできる。
- Mobile Starter Kit
  - EvernymにおけるMobile SDKと同等のもので、エッジ側（モバイルデバイス内）にWalletを作る。
  - Xamarinでの開発が前提となる。
- White Label App
  - 上記のTrinsic Walletをベースとしたもの
- クラウド型のMobile Wallet SDK
  - 上記のMobile Starter Kitとは別にSDKを提供している。
  - 違いとしてWalletはエッジ側ではなく、クラウド側に持つCustodian Walletである。そのため、自己主権型の度合いは低くなると考える。
  - さまざまな言語、フレームワークでの開発ができる。
Issuer、Verifier向け
- Trinsic Core
  - IssuerおよびVerifierのAgentを構築するためのREST API/SDKを提供する。
- Trinsic Studio
  - ノーコードでUIを操作しながらIssuerとVerifier（の管理画面）を構築する。
  - EvernymのVerity Flowとは異なり、既にサービス提供されている。

備考:比較

こうして並べてみると、両社のプロダクトのラインナップは非常に似ていることがわかります。主な差異としては以下が挙げられると思います。

エッジ型のHolder Agent開発用のMobile SDKについて
- EvenymはNative(Android/iOS)で開発する。
- TrinsicはXamarinで開発する。
ノーコードでIssuerとVerifierを開発できるサービスについて
- Evernymは開発中で未だサービス提供していない。
- Trinsicは既にサービス提供している。

2. Hyperledger Aries

Aries Mobile Agent Xamarin / Aries Framework for .NET

Aries Mobile Agent Xamarin(AMA-X)は前述のTrinsic社のエンジニアもContributerになり開発されているリポジトリ自体がモバイルアプリのAgentです。現時点でのリリースはバージョン0.1.0のpre-releaseのみです。GitHubのCode Frequencyなどを確認すると、後述のAries Mobile Agent React Nativeほど活発ではありません。

DIDCommで他Agentとやりとりする基盤/コア部分に、Hyperledger Aries公式の別リポジトリであるAries Framework for .NETを使っています。
公式DocによればAries Framework for .NETはクラウド、IoT、そしてモバイルアプリ形式のAgentの開発におけるSSIフレームワークとして利用できるモノです。
ちなみにこのフレームワークは、当ブログでの筆者の記事でも度々登場するAries Cloud Agent – Python(ACA-Py)と同等の位置付けのものですが、ACA-Pyが対応するのはクラウド上のエージェントのみです。

Aries Mobile Agent React Native / Aries Framework JavaScript

概要

Aries Mobile Agent React Native(以降、AMA-RN ※正式な略称ではありません)もAMA-X同様、リポジトリ自体がモバイルアプリのAgentです。まだリリースは何もされていない状態ですが、AMA-Xと比較すると活発に開発が進められているように見えます。現在はバージョン0.1.0のMVPリリースに向かっている模様です。

DIDComm周りの基盤/コア部分にはACA-Pyや前述のAries Framework for .NETと同等の位置付けのフレームワークであるAries Framework JavaScript(AFJ)を使っています。AMA-RNは、そのコア部分を使いUIを構築しています。

公式DocのよればAFJはNode.js、React Native、およびElectron環境で動作するため、クラウドやモバイル、デスクトップ上のAgentを開発するために使えます。Node.jsとReact Native環境の開発ガイド/チュートリアルも用意されており取り組みやすいと思います。

AMA-Xとの差異として、AMA-RNではHyperledger AriesのConfluence Wiki内で、開発者などコミュニティ関係者のミーティングの議事録がオープンにされています。そこでは今後の方針やロードマップなどを確認できます。

テックスタックとアーキテクチャ

ソースコードを読んだ結果として、テックスタックを図示化します。

次にアーキテクチャの図化です。

以下、簡単な解説です。

テックスタックとしては、下層からIndy SDK、AFJ、AMA-RN独自部分（つまりはController）と積み重なっている。
Walletもモバイルデバイス内部に作成される。（詳細はAMA-RNの設計ドキュメントを参照。）
流れとして、アプリ起動時に独自部分でAgentオブジェクトを生成、初期化する。それ以降は、AFJのAPIをラップしたAgentオブジェクトが提供するサービスを呼び出していく。
AMA-RN独自部分のコードを参考にしながら、ここを置き換えることで自作のHolder Agentを開発できると考える。
MediatorからHolder方向への通信において、そのプロトコルはDIDComm over WebSocketである。（詳細はAMA-RNの設計ドキュメントを参照。）

ソースコードリポジトリ構造(2022/3時点)

ソースコードを読みGitHubリポジトリの構造を図示化してみます。

以下、簡単な解説です。

index.jsがエントリポイントになる。
App.tsxについて
- AFJを利用して、Walletを包含するAgentオブジェクトの生成、初期化をしている。
- Agentオブジェクトの初期化において、.envから以下の環境変数を読み込む。
  - MediatorのEndpoint
  - LedgerのEndpoint
- Agentオブジェクトの初期化において、configs配下に配置されているgenesis-transactionファイルをgenesis-utils経由で読み込む。
App/componentsディレクトリはボタンなどの細かいUI要素を持つ。
App/navigatorディレクトリでUIスタックを用意する。その中にApp/screenディレクトリのビューを入れ込んでいる。
App/screenディレクトリの各ビューの中で
- Agentオブジェクトが持つDIDComm周りのコアサービスを呼び出している。（このサービスはACA-PyにおけるAdmin APIに相当すると考える。）
- useEffect(..)にて他エージェントとのやり取りで発生するイベントをリッスンしている。（ACA-PyにおけるWebhookに相当すると考える。）

Aries Framework Go

Aries Framework GoもACA-PyやAFJと同じ立ち位置のフレームワークです。公式Docによれば、REST APIを提供する他、GoやJavaScript環境、そしてモバイルアプリ開発にも利用できるようです。

AFJとの差異を述べると、AFJはReact Nativeを前提としていたのに対し、Aries Framework GoではNative(Android/iOS)環境を前提にしているように見えます。

おわりに

Ariesのフレームワークにおいては、クラウド型のAgentのための実装が先に進んでいた印象ですが、エッジ型のHolder Agentを開発する土壌も整えられつつあると感じています。

次回の私の記事では、AFJを基盤にした独自のReact Native製Holder Agentを作り、Mediator、Issuer、Verifierと接続してVCモデルを一通り回してみる記事を投稿したいと思います。

どなたかのお役に立てたならば幸いです。