KERIとOSSを使ったACDC発行の試行

DIF Japan Monthly Sync 2025/3にて発表した際の資料です。

Transcript

1. KERIと OSSを使ったACDC発行の試行 GMOグローバルサイン・ホールディングス 神沼 2025/3/28
2. KERI 2
3. KERI 分類 3 OIDF OID4VC ISO mDL/mdoc Hyperledger Aries DIF Decentralized Web Node ToIP KERI 参考: (拙著)2024年の分散型アイデンティティ領域の潮流の考察とKERIについて
4. KERI Autonomicモデル 4 出典: The Architecture of Identity Systems
5. KERI KEL (Key Event Log) 5
6. KERI 外部データのKELへのアンカリング 6 Key Event Transaction Event ダイジェスト Key Event 外部データ (e.g. ACDC発行) KEL
7. KERI Witness 7 • Witness = KEL(公開鍵)の置き場所 • Issuer, Holder, Verifierによらず、Controllerが各々、複数箇所に配備する • セキュリティ目的 • 不正アクセス対策 -> AID乗取り(=KEL上書き)には全てのWitnessを破る必要 • ブロックチェーンでは一番長いチェーンが勝つ。 • KERIではWitnessのアクセス制御における攻防になる。 • ControllerによるDuplicity(二枚舌)防止 -> Inception EventにWitness情報をバインド • どこに置くかは、エコシステムのガバナンス次第 • GLEIF vLEIのガバナンスでは、Webサーバ5台 or (分散台帳 or Mix?)
8. アーキテクチャ/処理方式 8
9. アーキテクチャ/処理方式 全体像 9
10. KERI OOBI (Out-Of-Band Introduction) Protocol 10 • AriesにおけるOOBでのDID Document Exchangeと同じようなもの • 相手のEndpointと公開鍵の取得 • 相手とOOB URL(Endpoint)を交換し、そこからKEL(公開鍵)を取得する • GLEIF Governance FWでは、ZoomやGoogle MeetなどVideo Callを指定。 • AID(識別子)へのバインドの検証も入ると思う。 • Challenge – Response • AID/KELのController(=秘密鍵の保持者)であることの認証 • Challengeも信頼できるOOBで渡すのが通例のよう。 • 仕様上指定はなくKERI上でP2P Messageでいいのではと思ったが、GitHubで質問したところ。 • ↑のKELのOOBルートが、なりすましのリスクがあり信頼できない場合に備えて？ （例えば、OOBI URLがどこかでオープンになっていたりする場合？）
11. KERI IPEX(Issuance and Presentation Exchange) Protocol 11 Issuer Holder Holder Verifier apply offer agree grant (issue or present) admit ※ apply, offer, agreeはoptional
12. KERI IPEX(Issuance and Presentation Exchange) Protocol 12 • OID4VCやAriesと比較して、 通信のための鍵と、VC(VP)署名の鍵を分けない。 • KERIでは、両方ともAIDで執り行う。 • 他の標準 • OID4VCでは、通信はTLS用の鍵。 • Ariesでは、通信はdid:peer
13. KERI ACDC(Authentic Chained Data Container) 13 • 標準の特徴 • マルチシグ機能 (エンタープライズ向き) • SD-JWT, MSOライクなSelective Disclosure機能 • 他のACDCとのDAG形式のチェーン機能 • ACDC内に別のACDCのダイジェストをプロパティとして持つ。
14. KERI CESR(Composable Event Stream Representation) 14 • バイナリデータを対象にした独自のSerialization方式 • (Base64,58,Hexではない、独自のバイナリエンコーディング方式を含む。) • 対象データ= KERIではCryptographic Primitives • 識別子(AID), 公開鍵, 署名値, ハッシュ(Digest) • 自己フレーミング • バイナリ、テキスト両方で、型・サイズ・Primitive値を自己完結的に表現する。 • JOSEのようにメタデータ不要 • Grouping • 複数プリミティブを構造化(連結、階層化)できる。 • ラッパー(JSON, CBOR)の全体解析不要でストリーム処理できる。(JSON解析 -> messageとsignatureを比較のオーバ ーヘッドなし) • CESRだけでもSerializeされている =データを構造化して転送・保存しやすい形式に変換されている。 • 加えて、JSONとCBORの1つのプロパティ値として埋め込むことができる。
15. ユースケース ~GLEIF vLEI~ 15
16. GLEIF vLEI 6種のvLEI Credential 16 出典: vLEI Demystified Part 1: Comprehensive Overview
17. GLEIF vLEI Trust Model: ACDCチェーンの検証 17
18. オープンソースとアプリ開発 18
19. オープンソースとアプリ開発 全体像と処理・実装方式 19
20. オープンソースとアプリ開発 所感 • Web5(DWN)と同様、基本的にアプリはフロントエンドのみ。 • Ariesと異なり、個人向けと企業向けアプリで形態が同じ。 • SDKが抽象度の高いAPIを提供するため、CESRなど細かい部分を把握していなくても、 OOBI/IPEXプロトコルを通して、アプリを開発することはできる。 • 現時点のオープンソースの成熟度としては、Ariesより劣る。 • Signify(SDK) APIの中で、戻り値がAny型であるのが結構ある。 (一度流して、ログから自分で型作ったり、Type Guard実装したりする手間) • 丁寧な開発ガイドはなく、テストコードを参考にする。 • Aries FWと異なり、以下をアプリ側で担う。 • プロトコル(OOBIとIPEX)の状態管理 • 他ピアとのメッセージ送受信に伴うイベントハンドリング (Aries FWではメッセージ受信のWebSocket/Polling機構、およびCallback登録機構を持つ) 20
21. デモ 21
22. デモ 環境 22
23. デモ 4つのフェーズ 1. アプリ初期化 1. AID/KELの生成 2. KERIA(Agent)との接続と権限委譲 3. KERIA(Agent)上にACDC Registryの作成 4. vLEI Credential Schemaの取り込み (vLEI ServerとのOOBI確立) 2. OOBI Session確立 3. ACDC発行と受領 (ACDC = QVI vLEI Credential) 4. ACDC失効と削除 23
29. ありがとうございました。 ご質問・ご意見ございましたら。 29