こんにちは。GMOグローバルサイン・ホールディングスCTO室で分散型アイデンティティの研究をしている開発者の神沼@t_kanumaです。
この記事は、以下の記事の続編です。
2024年の分散型アイデンティティ領域の潮流の考察とKERIについて
今回は、KERI Suite（KERI、OOBI、ACDC、IPEX、CESR）を実装するいくつかのオープンソースを用い、各々にAID（Autonomous Identifier）とKEL（Key Event Log）を持つ2つのエンティティを用意し、ACDCを発行するプロセスを共有します。
目次
1 1. KERIベースのシステム全体像2 2. KERI Suiteを構成する要素2.1 KELと外部イベントのアンカリング2.2 Witness2.2.1 他者による攻撃からの防御2.2.2 コントローラーによるDuplicity(二枚舌)の防止2.3 ACDC（Authentic Chained Data Container）2.4 OOBI（Out-Of-Band Introduction）2.5 IPEX（Issuance and Presentation Exchange）2.6 CESR（Composable Event Stream Representation）3 3. オープンソースを使った試行3.1 アプリ開発の全体像と処理方式3.2 実行環境と実装方式3.3 構成要素とライブラリ3.4 発行するVCのスキーマ3.5 リポジトリ3.6 参考にしたコード4 4. 試行とデモの流れ4.1 アプリ初期化4.2 OOBI Session確立4.3 ACDC発行と受領4.4 ACDC失効と削除5 5. 所感6 6. おわりに
1. KERIベースのシステム全体像
全体の構成としては、Hyperledger AriesやDIF DWNと同様に、各エンティティが自身のエンドポイントを持ち、P2Pでメッセージをやり取りします。各メッセージはAIDに紐づくKEL上の最新の公開鍵で署名され、HTTPを通じて通信されます。GitHub上で質問したところ、現時点ではAriesと異なり標準的な暗号化は実装されていないようです。（仕様と実装がまだ発展途上であるためと考えられます）
Witnessは、公開鍵を保存・参照するための場所として機能します。詳細は後述します。
2. KERI Suiteを構成する要素
前回の記事でご紹介したAIDやKELの仕組みを踏まえたうえで、本記事ではそれに加えてKERI Suiteの各構成要素について解説します。
KELと外部イベントのアンカリング
KELには鍵に関するイベントだけでなく、任意の外部イベントのダイジェストをイベントとしてアンカリングすることが可能です。本記事の試行においても、VCの発行および失効がイベントとしてKELにアンカリングされています。その目的は、AIDによって実行されたアクションを時系列で記録し、公開することで否認防止につなげたり、ある外部イベントに対してどの時点の公開鍵ペアで署名がなされたかを検証可能にすることなどが考えられます。
Witness
Witnessのインフラ構成は、各エコシステムのガバナンスによって定義されます。たとえばGLEIFの場合、いくつかの選択肢が用意されていますが、最もシンプルな構成としては、KELをホストするコントローラー自身が管理するWebサーバー群（最低5台）をWitnessとして利用する方法が挙げられます。
Witnessの役割として、セキュリティに関する2つの主要な目的があると考えられます。
他者による攻撃からの防御
例えば、攻撃者が秘密鍵Bを盗むことに成功した場合、イベントB’ → C’というような、本来とは異なる不正なチェーンを分岐させることが可能になります。これはブロックチェーンにおけるフォークに似た挙動です。ブロックチェーンでは「最も長いチェーンが正」とされる一方で、KERIでは複数のWitnessを介してチェーンの正当性が担保されます。
KERIでは、攻撃者がすべてのWitnessを乗っ取らない限り、チェーンの不正な分岐は成立しません。他者は、各Witness上のKELが一致しているかどうかを検証することで、信頼性を確認します。一致していない場合は検証に失敗し、不正が検出されます。現在はこのように理解しています。
コントローラーによるDuplicity(二枚舌)の防止
コントローラーが、通信相手ごとに同じAIDに対して異なるKELを提示することは、技術的には可能です。しかし、そのような操作を行うとKELの整合性および信頼性が損なわれてしまいます。これを防止するため、Inception EventにはWitness群の情報が明示的に紐付けられます。他者は、これらWitnessに記録されたKELがすべて一致しているかを検証することで、提示された情報の真正性を確認できると理解しています。
ACDC（Authentic Chained Data Container）
ACDCはKERI SuiteにおけるVerifiable Credentialに相当するものであり、以下のような特徴があります：
複数の署名者によるマルチ署名が可能
他のACDCとチェーン関係を構築可能（内部に別ACDCのダイジェストを含む）
IETFのSD-JWTやmDLにおけるMSOと同等の仕組みによるSelective Disclosureに対応
マルチ署名は、特に組織IDの発行や管理において重要な役割を果たすと考えています。また、ACDCのチェーン構造は、Issuerの信頼性検証に活用されると理解しています。
さらに、KERIではセキュアな通信とVC/VP署名に同一の鍵が使用される点も特徴的です。これは、OID4VCやAriesが通信と署名で異なる鍵を使用する点と対照的です。
通信において、OID4VCではTLS用の鍵を、Ariesにおいてはdid:peerを使い、それぞれVC/VP署名の鍵とは異なります。一方、KERIでは両方をAIDに紐づくKEL上の同じ鍵で行います。(OID4VCとAriesでは、VCすなわち署名付きデータを認証付き暗号でラップする形で送出しますが、KERIではこの階層構造がないと理解しています。)
OOBI（Out-Of-Band Introduction）
OOBIは、AriesにおけるOut-Of-BandでのDID Document交換に相当する仕組みです。通信相手のエンドポイントと公開鍵を取得するためのプロセスとなります。
流れとしては下記の理解でいます。
まず、信頼できる手段（例えばZoomやGoogle Meetなどのビデオ通話など）を使ってOOBI URLを相互に交換し、そのURLからKEL（公開鍵）を取得します。次にKELとURL内に含まれるAIDとのバインドを検証します。
次にAIDのコントローラーであることを証明するために、Challenge-Responseプロトコルを双方向で実施します。ここで、Challenge Wordの送信についても、OOBI URLと同様に、信頼できるOut-Of-Band（OOB）ルートを通じて渡すのが一般的とされています。仕様上はこれに関する明確な規定はなく、KERI上のP2Pメッセージで送信することも技術的には可能と考えていましたが、GitHub上で質問したところ、Challenge WordもOOB経由で渡すべきという見解が示されました。これは、KELの取得と同様に、OOBI URLがインターネット上で公開されている、あるいは悪意ある第三者によって置き換えられるといった、OOBルートの信頼性が確保されていない場合を想定し、なりすましのリスクを防ぐためであると理解しています。
IPEX（Issuance and Presentation Exchange）
IPEXは、ACDCを発行および提示するためのプロトコルであり、IssuerとHolder間のインタラクションを規定します。apply、offer、agreeのステップはすべて任意であり、ユースケースに応じて柔軟にプロセス設計を行うことができます。
CESR（Composable Event Stream Representation）
CESRはKERIが採用する独自のデータシリアライゼーション方式です。その中には、Base64やBase58、Hexといった一般的なエンコーディングとは異なる独自のバイナリエンコーディング方式も含まれています。KERIにおいて対象となるデータは、識別子（AID）、公開鍵、署名値、ハッシュ（Digest）などの暗号プリミティブです。
CESRでは、こうしたプリミティブを自己フレーミング形式で表現し、バイナリおよびテキストの両形式で、型やサイズ、値そのものを自己完結的に示すことが可能です。そのため、JOSEのように別途メタデータを付与する必要がありません。
また、複数のプリミティブを連結あるいは階層化して構造化できるGroupingの機能も備えており、JSONとは異なりラッパー全体を解析せずにストリーム処理を行える点も特徴です。たとえば、JSONをパースしてメッセージ本体と署名部分を照合するといった処理を行わなくても済みます。
さらに、CESR形式でシリアライズされたデータは、そのままでも構造化された形式として転送や保存に適しているわけですが、それに加えてJSONやCBORのプロパティ値としても埋め込むことができます。
ただし、SDKを利用してアプリケーションを開発する開発者は、CESRの詳細な仕様を深く理解していなくても問題はないと考えられます。というのも、これらの処理はSDK側が内部で担っているためです。
3. オープンソースを使った試行
アプリ開発の全体像と処理方式
KERIにはKATE（Key At The Edge）という方針があり、暗号処理（Cryptographic Operation）はフロントエンド側で行い、バックエンドのエージェントは鍵やデータの保管、メッセージのルーティングを担う構成になっていると理解しています。
Web5（DWN）やAries Mobile Appと同様にアプリはフロントエンドのみで構成されています。また同様にバックエンドのWeb APIを直接コールするのではなく、フロントエンド上のSDKを通じて機能にアクセスします。
Ariesと比較すると、Ariesでは、OOBでの鍵交換やVCの発行・提示プロトコルにおける状態管理、他ピアからのメッセージ受信、それに伴うコールバック処理の仕組みなどがSDKによって提供されていました。しかしKERIのライブラリでは、これらの処理は開発者自身が実装する必要があります。
また、アプリケーション、エージェント、Witnessがそれぞれ独自にAIDを持つ構成となっている点もKERIの特徴の一つです。
実行環境と実装方式
いくつかポイントを列挙します。
すべてローカルで完結する。
アプリはVueで構築し、ブラウザ上で動作する。
アプリ側でのOOBIおよびIPEXの状態管理については、今回の試行ではLocal Storageを用いて実装した。
他ピアからのメッセージ受信については、ユーザーによるUI上のリロードボタンのクリックをトリガーとして、エージェントに対してメッセージを問い合わせる方式を採用した。
構成要素とライブラリ
Signify-TS
フロントエンドアプリのSDK。
KERIA
バックエンド側でのアプリのエージェント。
DBを内包している。
WebOfTrustが提供する既成イメージからDockerコンテナとして起動する。
keripyというKERIの仕様を実装するローレベルなライブラリをラップしている。
Witness Demo
デモ用に構成済みのWitness群。
WebOfTrustが提供する既成イメージからDockerコンテナとして起動する。
各Witnessの中身は、前述のkeripyである。
vLEI Server
vLEI Credentialの全種別のスキーマを保持する。
OOBIプロトコルでアプリ側にスキーマを取り込む。
GLEIFが提供する既成イメージからDockerコンテナとして起動する。
発行するVCのスキーマ
vLEI Demystified Part 1: Comprehensive Overviewより引用
上図は、vLEIにおける各Entityと、それぞれの間で発行されるvLEI Credentialの種別（図中のNo.1〜6）を示しています。今回は、その中からQVI vLEI Credentialのスキーマ（プロパティとしてLEIのみを持つシンプルな形式）を使用しました。
リポジトリ
Issuerアプリ
Holderアプリ
バックエンドインフラ
参考にしたコード
アプリ側: Signifyのテストコード
バックエンドのインフラ側: Signifyにあるdocker-compose
4. 試行とデモの流れ
以下の手順でACDCの発行から受領、失効までを実施しました：
アプリ初期化（AID/KEL生成、KERIA接続、ACDC Registry作成、スキーマ取り込み）
OOBIセッションの確立
ACDC発行と受領（IPEXでの交換）
ACDC失効と削除
アプリ初期化
https://wp.addr.show/wp-content/uploads/2025/04/Part-1-Initialize.mp4
マスターシークレット（Signify内ではPasscodeと呼ばれます）は、AIDおよびKELの源泉となるものであり、コントローラーが厳密に管理すべき重要な情報です。具体的な管理手段としては、Password Managerソフトを用いる方法が考えられます。
OOBI Session確立
https://wp.addr.show/wp-content/uploads/2025/04/Part-2-OOBI.mp4
GLEIF vLEIでの実際の運用では、OOBI URLおよびチャレンジワードは、ZoomやGoogle Meetなどのビデオ通話を通じて、信頼できる手段で相手に手渡されると理解しています。
ACDC発行と受領
https://wp.addr.show/wp-content/uploads/2025/04/Part-3-Issue.mp4
ACDC失効と削除
https://wp.addr.show/wp-content/uploads/2025/04/Part-4-Revoke.mp4
SignifyとKERIAの実装における失効の仕組みですが、テストコードや試行した結果として、以下の流れであると理解しています。
Issuerが自身のRegistry上の該当のACDCを失効する。
Registry上のACDCの状態がアップデートされる。
失効イベントがKELにアンカリングされる。
IssuerがOut-Of-BandルートでHolder側に、失効したことを連絡する。
Holderが自身のRegistry上の該当のACDCを削除する。
5. 所感
SignifyのSDKは抽象度が高く使いやすいものの、Ariesと比較して型定義やガイドが未整備な部分が多く、現時点の成熟度ではやや劣ると感じました。
AriesではEntityの役割に応じてシステム構成が異なっていましたが、KERIではIssuer・Holder・Verifierのすべてが同様の構成で統一されている点も印象的です。
Ariesと異なり、プロトコルの状態管理やメッセージ受信のハンドリングをフロントエンドアプリ側で担う必要がある点には注意が必要です。
6. おわりに
本記事では、KERI Suiteを用いたACDC（QVI vLEI Credential）の発行、失効について、一連のプロセスを実践的に試行しました。
今後さらに理解を深めていくにあたって、以下の点が検討事項として挙げられるかもしれません。
動画内でのマスターシークレット(Signifyではパスコードと呼ぶ)を起点とした秘密鍵の管理方式の理解
マルチ署名によるACDC発行の試行
複数のACDCをチェーン形式で発行・検証する手法の確認
今回は出来合いのデモ用Witnessを使ったが、keripyを直接使ったWitnessの構築
vLEIの普及とともに、KERI Suiteがどのように社会実装されていくのかを引き続き注視していきたいと思います。
本記事がどなたかの参考になれば幸いです。内容に誤り等ございましたら、ご指摘いただけますと幸いです。