DIF Japan Monthly Sync Hyperledger Ariesを使った開発 GMOグローバルサイン・ホールディングス 神沼 貴⼤(@t_kanuma) 2023/11/24

⽬次 ● 私の仕事のロール ● (IMHO)SSIの全体像 ● (IMHO)Ariesの全体像 ● Aries詳細 ● 2023年のユースケース事例 ● OID4VCとの関連性 ● 今後の展開の予測 2

仕事: サービス化へ繋げるためのR&D ● 標準仕様の理解 ● W3C ● DIF ● Hyperledger Aries ● OpenID4VC ● OSSの試⾏ ● プロトタイピング 3

SSIの全体像 4 Self Sovereign Identity / Decentralized Identity Other W3C, DIF Specs Trust Triangle / Issuer-Holder-Verifier Model W3C Decentralized Identifiers W3C VCDM (Rep: JWT-VC, LDP-VC) OpenID4VC Hyperledger Aries DIF Decentralized Web Node ACA-Py, AFJ Issuer,Holder,Verifier Apps/System for specific use-cases Web5 (did:ion) 思想 モデル 標準 OSS SDKs / Services 標準 Sphereon (on Veramo) 私 DID Methods AnonCreds, mDL Verification Methods Signature Suites / Algorithms web3 , 分散型SNS (Bluesky) Input Output MS Entra Indicio, Animo, Northern Block Gaia-X/EDC Identity Hub (did:web?) walt.id IoT

Hyperledger Ariesの全体像 5 Aries Interop Profile(AIP) 2.0 Aries Out-Of-Bound Protocol, DID Exchange Protocol Aries DIDComm(v1), DIF DIDComm(v2) (over HTTP, WebSocket...) did:sov, did:key, did:peer HL AnonCreds Aries Issue Credential Protocol v2 (DIF Credential Manifest v1...) Aries Present Proof Protocol v2 (DIF Presentation Exchange v1...) Issuer,Holder,Verifier Apps/System for specific use-cases Aries Framework Go Profile for Trust Triangle DID Methods/ VC Formats Messaging, Relay Open Source FWs Connection Establish Protocol Aries Cloud Agent – Python (ACA-Py) LDP-VC (Ed25519Signature2018, BblBlsSignature2020, JSONWebSignature2020) Data Exchange Protocol(Format) Aries Framework JavaScript (AFJ) Aries Mobile Agent - React Native Open Source Apps Cloud/Edge Wallet Concept Data Storage Apps/System API for Developers 利⽤ 私

処理⽅式と使い⽅ 6

AgentとTrust Triangle 7 ACA-Py or AFJ ACA-Py or AFJ Verifier ACA-Py or AFJ Registry App App Holder API Call DIDComm DIDComm App Issuer Notify events デフォルトで複数のIndy Ledger Network と接続可能

DIDComm Message送受信に対するイベントハンドリング ● DIDComm上: コネクション⽣成, VC発⾏&保管, VP提⽰&検証 ● イベントハンドリング: Agentで処理 or Appで処理 or Userが処理 8 ACA-Py or AFJ ACA-Py or AFJ Issuer Holder App App 例⽰: Aries Issue Credential Protocol on DIDComm offer offer-sent issue request- received request credential- issued ack done イベント通知 auto request API呼び出し API呼び出し イベント通知

ACA-PyとAFJの⽐較 9 ACA-Py AFJ Cloud or Edge Cloudのみ - Cloud(Node.js), - Edge(Mobile/React Native) Issuer, Verifier, Holder, Mediator 全部 全部 API REST API (Swagger UIあり） - TS Method - REST API (extension利⽤時, Swagger UIあり) イベント通知 Webhook - TS Function - Webhook(extension利⽤時) モジュール性 △ ◯(細かい) 開発ドキュメント ◯ △ （ある程度コード読まないと。 コード⾃体は整理されていて読みやすい。） 先進性, 汎⽤性 (e.g. Aries外の標準取り込み） △ ◯(早い) IMHO - REST/Webhookにより開発が柔軟にできる - 開発ドキュメント豊富で助かる - Issuer,Verifierに使う - Edge型のHolder Agentを実装するなら、これ⼀択 - REST/Webhook利⽤できるが本体と同期していない

開発環境の例⽰ 10 ACA-Pyプロセス (Wallet: SQLite) Issuer ACA-Py Verifier Node.js App on AFJ (Wallet: SQLite) React Native App on AFJ コンテナ (PC or クラウド) コンテナ (PC or クラウド) コンテナ (PC or クラウド) ACA-Py コンテナ (PC or クラウド) bc-gov/von-network (開発⽤Indy Ledger) (AnonCreds採⽤の場合） コンテナ (PC or クラウド) 開発者 App App Holder Mediator(ACA-Py) Registry 開発者 開発者 REST API Call DIDComm atop HTTP androids/iOS コンテナ (PC or クラウド) DIDComm atop WS

本番環境の例⽰ 11 ACA-Py(冗⻑化) Issuer ACA-Py(冗⻑化) Verifier React Native App on AFJ (Wallet: SQLite) AWS ECS on Fargate AWS ECS on Fargate Sovrin Network (AnonCreds採⽤の場合） AWS Serverless App Holder ACA-Py(冗⻑化) Registry REST API Call with API Key DIDComm atop HTTP(S) AWS ECS on Fargate AWS Serverless App DIDComm atop WSS Wallet AWS RDS(Postgres) Wallet AWS RDS(Postgres) Mediator Wallet AWS RDS(Postgres) AWS ALB AWS ALB AWS ALB AWS ALB AWS ALB AWS ALB

ACA-PyのAgent Config (プロセス起動時設定のパラメータ抜粋) 12 パラメータ 概要 endpoint DIDCommのendpoint admin REST APIのendpoint api key REST APIのAPI Key wallet key Walletを暗号化するマスターキー(KEK) の基になるパスフレーズ (後述) genesis url 繋ぎにいくIndy Ledger Network seed Indy上に登録するdid:sovのEd25519 Key Pairのseed auto {protoco内アクション} イベントをAppに通知せず、 Agentが⾃動でプロトコルを進める

ACA-Py REST API Endpoints 13 機能分類 ⾊合い トップディレクトリ 概要 Connection⽣成 Aries /didexchange, /out-of-band Invitation(did:peerドキュメント) 作成と受容 VC発⾏&保管 Aries /issue-credential-2.0 AnonCreds, LDP-VCの 提案、オファー、要求、発⾏、保管 VP提⽰&検証 Aries /present-proof-2.0 AnonCreds, LPD-VC証の 提案、要求、提⽰、検証 (Holder専⽤)発⾏済み Credential情報取得 Aries /credentials 発⾏済みAnonCreds, LDP-VCの情報取得 Mediation Aries /mediation DID CommのRouting依頼と許可 Wallet内のDID管理 Aries /wallet Wallet内でdid:sov(unposted), did:keyの 鍵ペア⽣成 Indy Ledgerとのやりとり Indy /ledger did:sov Documentの登録、取得 書き込み対象のIndy Ledgerの切り替え Indy TX書込み Endorsement Indy /transactions Author -> Endorser: TX署名依頼 Endorser -> Author: TX署名 Indy上のAnonCreds オブジェクト管理 Indy /schemas /credential-definition AnonCreds発⾏に必要なオブジェクト⽣成 AnonCreds失効 Indy /revocation Revocation Registry作成、AnonCreds失効

まとめ Ariesのlimitationがシステム要求に収まる、 またはそれを満たすFW拡張の労⼒が合理的であることを前提に、 ● インフラ ● Agent構成設定 ● アプリからのAPI Call組み⽴て これらを要件に対し設計することでシステムを開発できる。 14

Wallet Concepts 15

Hyperledger Ariesの全体像 16 Aries Interop Profile(AIP) 2.0 Aries Out-Of-Bound Protocol, DID Exchange Protocol Aries DIDComm(v1), DIF DIDComm(v2) (over HTTP, WebSocket...) did:sov, did:key, did:peer HL AnonCreds Aries Issue Credential Protocol v2 (DIF Credential Manifest v1...) Aries Present Proof Protocol v2 (DIF Presentation Exchange v1...) Issuer,Holder,Verifier Apps/System for specific use-cases Aries Framework Go Profile for Trust Triangle DID Methods/ VC Formats Messaging, Relay Open Source FWs Connection Establish Protocol Aries Cloud Agent – Python (ACA-Py) LDP-VC (Ed25519Signature2018, BblBlsSignature2020, JSONWebSignature2020) Data Exchange Protocol(Format) Aries Framework JavaScript (AFJ) Aries Mobile Agent - React Native Open Source Apps Cloud/Edge Wallet Concept Data Storage Apps/System API for Developers 利⽤ 私

Wallet全体像 17 DID key pair VC Exchange Records Link Secret CEK CEK CEK HL Askar ACA-Py/AFJ Module Agent Config Param: パスフレーズ SQLite or PostgreSQL ACA-Py or AFJ 開発者 外から設定 マスターキーのローテーションに対し、 データ本体のを再暗号化が必要ない。 argon2で マスターキー(KEK)導出 開発者がパスフレーズを管理する データ読み書き App

依存関係: Hyperledger Shared Components 18 ACA-Py AFJ Indy VDR (Indy LedgerのClient Lib) Askar Wallet （汎⽤的な暗号化されたWallet） CredX (Indy dependent) Anoncreds-RS (Registry Agnostic) AnonCreds Lib Rust実装 Python Wrapper JS Wrapper 依存

Cloud Agentでのキーフレーズ管理設計の例⽰ 19

Edge Agent(Andoird)でのキーフレーズ管理設計の例⽰ 20

バックアップ&リストア 21 Cloud Agentの場合は、開発者が通常のシステム運⽤の様に、 PostgreSQLを定期的にバックアップすれば良い。 以下、Edge Agent(モバイルアプリ）の場合の例⽰ AFJのWallet Export/Import機能のAPIをUIから呼び出す。

DID Methods, VC Formats 22

Hyperledger Ariesの全体像 23 Aries Interop Profile(AIP) 2.0 Aries Out-Of-Bound Protocol, DID Exchange Protocol Aries DIDComm(v1), DIF DIDComm(v2) (over HTTP, WebSocket...) did:sov, did:key, did:peer HL AnonCreds Aries Issue Credential Protocol v2 (DIF Credential Manifest v1...) Aries Present Proof Protocol v2 (DIF Presentation Exchange v1...) Issuer,Holder,Verifier Apps/System for specific use-cases Aries Framework Go Profile for Trust Triangle DID Methods/ VC Formats Messaging, Relay Open Source FWs Connection Establish Protocol Aries Cloud Agent – Python (ACA-Py) LDP-VC (Ed25519Signature2018, BblBlsSignature2020, JSONWebSignature2020) Data Exchange Protocol(Format) Aries Framework JavaScript (AFJ) Aries Mobile Agent - React Native Open Source Apps Cloud/Edge Wallet Concept Data Storage Apps/System API for Developers 利⽤ 私

VC FormatsとDID Methods 24 VC Formats VC発⾏: Issuer署名 VP提⽰: Holder署名 Revocation AnonCreds (CL-Signature) did:sov(≠Universal), did:indy (AFJのみ,did:indy:{nw}:{id}, did:cheqd(AFJのみ) Link Secret AnonCreds v1 Revocation Scheme LDP-VC (Ed25519Signature2018) did:sov, did:key (did:indy,cheqdは不明) did:key 無し(W3C Status List 2021...) LDP-VC (BbsBlsSignature2020/ Bls12381G2) did:key (did:indy,cheqdは不明) did:key 無し(W3C Status List 2021...) W3C Linked Data Cryptographic Suite Registry の中でAries RFCがサポートするSuite ACA-Py AFJ Ed25519Signature2018 ◯ ◯ BbsBlsSignature2020 ◯ ◯ JSONWebSignature2020 ✖ ✖ ACA-Py&AFJのDID Methodデフォルト実装(プラグイン可能)

AnonCredsの発⾏検証の準備 Indy Ledger(did:sov)上にAnonCreds独⾃の4つのオブジェクトの作成 25 AnonCreds オブジェクト 概要 いつ誰がどう作る︖ 誰がTXに署名する︖ NYM DID Documentの ID, Verification Method (Ed25519 Public Key) Steward/EndorserがIssuerからの 申請時に作る。 Steward(Node運⽤者) or Endorser Attribute DID Documentの Endpoint Agent起動時に、 構成パラメータからAgentが作る。 Issuer(正確にはEndorser) Schema AnonCredsのスキーマ （各Claim nameの列挙） Agent起動後、 IssuerがAPIから作る。 (ClientがClaimを指定する。） Issuer(正確にはEndorser) Credential Definition Schemaに1:多で紐づき、 各Claimに対する公開鍵情報を持つ (CL-SignatureのSDの仕組み) Agent起動後、 IssuerがAPIから作る。 （Key PairはAgentが作る） Issuer(正確にはEndorser)

Schema作成 POST http://{IP:Port}/schemas 26

Hyperledger Indy(did:sov)におけるロール 27 Trustee (Network創始者) Sovrin Governance Auditor的なロール Endorser (Object署名者) (might be Issuer) Author (Object作成者) (might be Issuer) Sovrin Networkの場合 Steward (Node運⽤者) 遵守 Endorser 登録依頼 (Sovrin: 公開鍵渡す via Webフォーム?メール?) Node参加依頼 オブジェクトに署名 on DIDComm Steward NYM書込み Endorser NYM書込み ⾃⾝のNYM以外のオブジェクト作成 ⾃⾝の全てのオブジェクト作成 オブジェクト署名依頼 on DIDComm Indy Ledger

AnonCreds v1 Revocation Scheme ● Holderプライバシー保護 ● 暗号学のAccumulatorのスキームを利⽤ ● 現⾏のAnonCreds仕様に組み込まれている ● スケーラビリティに課題あり ● GitHub: hyperledger/anoncreds-revocationにて新しいスキームを策定中 28

依存関係: Hyperledger Shared Components 29 ACA-Py AFJ Indy VDR (Indy LedgerのClient Lib) Askar Wallet CredX (Indy dependent) AnonCreds-RS (Registry Agnostic) AnonCreds Lib Rust実装 Python Wrapper JS Wrapper 依存 デフォルトではdid:sov(Indy)とdid:cheqdを Registryとして使える。 Registryのプラグイン可能

VC FormatsとDID Methods 30 VC Formats VC発⾏: Issuer署名 VP提⽰: Holder署名 Revocation AnonCreds (CL-Signature) did:sov(≠Universal), did:indy (AFJのみ,did:indy:{nw}:{id}, did:cheqd(AFJのみ) Link Secret AnonCreds v1 Revocation Scheme LDP-VC (Ed25519Signature2018) did:sov, did:key (did:indy,cheqdは不明) did:key 無し(W3C Status List 2021...) LDP-VC (BbsBlsSignature2020/ Bls12381G2) did:key (did:indy,cheqdは不明) did:key 無し(W3C Status List 2021...) W3C Linked Data Cryptographic Suite Registry の中でAries RFCがサポートするSuite ACA-Py AFJ Ed25519Signature2018 ◯ ◯ BbsBlsSignature2020 ◯ ◯ JSONWebSignature2020 ✖ ✖ ACA-Py&AFJのDID Methodデフォルト実装(プラグイン可能)

did:webでLDP-VCの試⾏ ● Plugin(Pythonパッケージ）を実装し、DID DocumentをAWSにホストする。 ● Ed25519, BBS+両⽅で完遂できた。 ● （ちなみにテックブログ記事がIdentity WomanのSovereign Identity Updatesに載りました） 31 Plugin

依存関係: JSON-LD周り 32 ACA-Py AFJ digitalcredentials/json-ld digitalcredentials/jsonld-signatures digitalbazaar/pyld 依存 Digital Bazaar: W3C SpecのAuthors欄でよく⾒る Digital Credentials Consortium: アカデミックのクレデンシャル普及を⽬指す、 世界から集まった⼤学で構成される団体 元々Digital BazaarのリポジトリをFolkしている。

依存関係: BBS+ Signature 33 ACA-Py AFJ mattrglobal/bbs-signatures mattrglobal/ffi-bbs-signatures Rust実装 Python Wrapper 依存 TypeScript実装

JSON-LD周りの⾊々試⾏(ACA-Pyの実装) ● JSON-LDの妥当性バリデーション ● Context+Typeに存在しないプロパティがある場合、どこかしらのタイミングで エラーが出る実装になっている。 ● Issuerがオファーする際 ● HolderがVP提⽰する際 ● VerifierがVP検証する際 ● Context + Typeの作成をサポートする機能ない。⾃作してホストする。 ● LDP(正規化⇨ハッシュ⇨署名プロセス)に対し、JSON + LD-Proofにすると、 IssuerでエラーがでてVCの発⾏はできない。 34

Message, Connection, Routing 35

Hyperledger Ariesの全体像 36 Aries Interop Profile(AIP) 2.0 Aries DID Exchange Protocol, Out-Of-Bound Protocol Aries DIDComm(v1), DIF DIDComm(v2) (over HTTP, WebSocket...) did:sov, did:key, did:peer HL AnonCreds Aries Issue Credential Protocol v2 (DIF Credential Manifest v1...) Aries Present Proof Protocol v2 (DIF Presentation Exchange v1...) Issuer,Holder,Verifier Apps/System for specific use-cases Aries Framework Go Profile for Trust Triangle DID Methods/ VC Formats Messaging, Routing Open Source FWs Connection Establish Protocol Aries Cloud Agent – Python (ACA-Py) LDP-VC (Ed25519Signature2018, BblBlsSignature2020, JSONWebSIgnature2020) Data Exchange Protocol(Format) Aries Framework JavaScript (AFJ) Aries Mobile Agent - React Native Open Source Apps Cloud/Edge Wallet Concept Data Storage Apps/System API for Developers 利⽤ 私

Aries DIDComm v1 ● JWE ● protected: 次ページ ● iv ● ciphertext: AEAD(payload, protected, iv, cek) ● tag ● Payloadの暗号化アルゴリズム: xchacha20poly1305 ● 使い捨てCEKをKEKで暗号化してprotected内で配送する。(enc algは↑と同じ?) ● ⾃分DID秘密鍵, 相⼿DID公開鍵 -> KEK⽣成 ● 鍵交換アルゴリズム: X25519(ECDH curve 25519) ● DID Methodの指定はない。任意。 ● ACA-Py/AFJは名寄せ防⽌⽬的でPairwise DID(did:peer) ● did:peer ● 平たくいうとService Endpointを持つdid:key ● method specific identifier -> DID Document 37

Aries DIDComm v1 ● protectedプロパティの⼤雑把な中⾝ 38

Aries DIDComm v1 ● Payload = JWM(JSON Web Message)形式 (IETF Draft, expired) 39 メッセージID DIDComm上で機能するプロトコル種別 didcomm.orgサイトで登録/検索できる 後述 LDP-VC⾃体 全体のメタデータ

Connection(Aries DID Exchange, OOB Protocol) ● Connection⽣成 ● DIDComm上でDID Exchangeをして双⽅向にメッセージを送れるようにすること ● 2つの⼿法 ● Implicit: 相⼿のDIDが既知 ● Explicit: 相⼿のDIDが未知 ● Out-Of-Band Protocolを組み合わせる。 ● ⾃分のDIDをメールやQRコードで相⼿に知らせる。 40

DID Exchange(Implicit) 41 Agent A Agent B Registry Bʼs public DID Resolve DID (Verification Relationship: “keyAgreement”, Service Type: ”DIDCommMessaging”) request response complete did:peerなど⽣成 JWE (payload: DIDDoc) JWE (payload: DIDDoc) did:peerなど⽣成 JWE (payload: なし) 以降、交換したDIDでJWEを作り通信する

DID Exchange(Explicit) 42 Agent A Agent B request response complete JWE (payload: DIDDoc) JWE (payload: DIDDoc) did:peerなど⽣成 JWE (payload: なし) 以降、交換したDIDでJWEを作り通信する did:peerなど⽣成 Out-Of-Band Invitation via QRコード, email インライン or Public DID DID Exchange完了までJWE作成に使う鍵

Mediation(Routing) ● Aries Mediator Coordination Protocol ● Routing専⾨のAgent 43 Agent A Agent B Mediator Agent Mediatorしか開けられないJWE To: Bʼs DID msg: Bしか開けられないJWE

Mediation(Routing) ● 使い所: HolderがEdge型Agentのとき ● Endpoint持てない、頻繁にオフライン ⇨ Mediator(Cloud型)にキューイングする。 ● 処理⽅式設計例 44 Issuer Agent Verifier Agent Holder Agent (Mobile App) Mediator Agent [通常] WebSocketでリアルタイムで送信する 送信できない場合はキューイングする [アプリ起動時、WebSocket接続切れ後ポーリングなど設計] HTTPリクエストのレスポンスとして滞留した JWEメッセージ群を返す(Client-Server, Not P2P) (Aries Pickup Protocol) [キュー] ACA-Py/AFJとも基本インメモリキュー 永続化対応としてカナダBC州政府がRedisベースの ACA-Py Plugin⽤意

Mediation(Routing): Mediation確⽴までのシーケンス 45 Holder Issuer Mediator DID Exchange Completion(*) service endpoint: ws DIDComm atop WebSocket DIDComm atop HTTP Mediation Request Mediation Grant (routing keys, endpoint情報をもらう) ⾃DID Doc⽣成 Issuer向け HolderのDIDComm⽤DID Issuer向け MediatorのDIDComm⽤DID Issuer向け

Mediation(Routing): Mediation確⽴までのシーケンス 46 Holder Issuer Mediator DID Exchange Request(↑のDID Doc) service endpoint scheme: ws 本⽂(e.g. did:peer)⽣成 ↓ Holder向けJWE⽣成 ↓(ラップ) Mediator向けJWE⽣成 DIDComm atop WebSocket DIDComm atop HTTP Key List Update(⾃did:keyをRouting Tableに登録, *のDIDに紐付ける) DID Exchange Response (Mediatorのdid:key, endpointを使う) Holder向けJWE取り出し ↓ Routing Table参照 ↓ WebSocketのコネクション決め このdid:keyで来たら、このMediatorを経由する Implicit or ExplicitでIssuer DID Doc resolution 以降、交換したDIDでJWEを作り通信する DID Exchange Complete

Data Exchange Protocol/Formats 47

Hyperledger Ariesの全体像 48 Aries Interop Profile(AIP) 2.0 Aries Out-Of-Bound Protocol, DID Exchange Protocol Aries DIDComm(v1), DIF DIDComm(v2) (over HTTP, WebSocket...) did:sov, did:key, did:peer HL AnonCreds Aries Issue Credential Protocol v2 (DIF Credential Manifest v1...) Aries Present Proof Protocol v2 (DIF Presentation Exchange v1...) Issuer,Holder,Verifier Apps/System for specific use-cases Aries Framework Go Profile for Trust Triangle DID Methods/ VC Formats Messaging, Relay Open Source FWs Connection Establish Protocol Aries Cloud Agent – Python (ACA-Py) LDP-VC (Ed25519Signature2018, BblBlsSignature2020, JSONWebSIgnature2020) Data Exchange Protocol(Format) Aries Framework JavaScript (AFJ) Aries Mobile Agent - React Native Open Source Apps Cloud/Edge Wallet Concept Data Storage Apps/System API for Developers 利⽤ 私

Aries Issue Credential Protocol 2.0 49 ACA-Py or AFJ ACA-Py or AFJ Issuer Protocol開始地点 ”どういったVCを発⾏するのか︖“をInputする勘所、 アプリ開発者視点だと、それ以降は振られたcredential exchange idをAPIのPath Paramに指定するだけ offer issue request ack propose Holder データフォーマットは︖

VC FormatとData Format 50 VC Format Data Format仕様 ACA-Py AFJ Indy依存のAnonCreds (Aries RFC) Hyperledger Indy Credential ◯ ◯ Registry Agnosticな AnonCreds (Aries RFC) Hyperledger AnonCreds Credential ✖ ◯ LDP-VC (Aries RFC) LDP-VC ◯ ◯ LDP-VC (DIF) Credential Manifest (仕様⾃体はVC Format agnostic) ✖ ✖ データフォーマット仕様によってAPIのInputの内容も変わってくる。 Issue Credential Protocol 2.0の中で、VC Formatに対するData Format仕様が定義されている。 各Data Format仕様が各ActionすなわちDIDCommのMessage Type(offer,request,issue...)でのFormatを定義する。

ACA-Py REST API Call ● Data Format仕様: Indy Credential ● アクション: Credential Offer 51 POST http://{IP:Port}/issue-credential-2.0/send-offer Request Body ⇨ did:sov:

ACA-Py REST API Call ● Data Format仕様: LDP-VC ● アクション: Credential Offer 52 POST http://{IP:Port}/issue-credential-2.0/send-offer Request Body ⇨

Present Proof Protocol 2.0 53 ACA-Py or AFJ ACA-Py or AFJ Holder present & verify request ack (verifiedは通知されない) propose Verifier データフォーマットは︖ Protocol開始地点 VP定義をInputする勘所。基本的に、それ以降は振られた presentation exchange idをAPIのPath Paramに指定するだけ VP要求定義に対し、複数のVC候補 がある場合は、提⽰するVCを Request Bodyに指定する。

VC FormatとData Format 54 VC Format Data Format仕様 ACA-Py AFJ Indy依存のAnonCreds (Aries RFC) Hyperledger Indy Proof ◯ ◯ Registry Agnosticな AnonCreds (Aries RFC) Hyperledger AnonCreds Proof ✖ ◯ LDP-VC (DIF) Presentation Exchange v1 (仕様⾃体はVC Format agnostic) ◯ ◯ データフォーマット仕様によってAPIのInputの内容も変わってくる。 Present Proof Protocol 2.0の中で、VC Formatに対するData Format仕様が定義されている。 各Data Format仕様が各ActionすなわちDIDCommのMessage Type(request,present...)でのFormatを定義する。

ACA-Py REST API Request Body ● Data Format: Indy Proof ● アクション: Presentation Request ● AnonCreds ● Selective Disclosure ● Predicates 55 POST http://{IP:Port}/present-proof-2.0/send-request Request Body ⇨ did:sov: did:sov:

ACA-Py REST API Request Body ● Data Format: DIF Presentation Exchange v1 ● アクション: Presentation Request 56 POST http://{IP:Port}/present-proof-2.0/send-request Request Body ⇨

57 JSON Schemaに則る 各Descriptorごとに要求するVCを定義 Proof of Possession(vc.credentialSubject.id = VP署名DID) Selective Disclosure機能で Derived Credential導出の要求 - URIは何なのか︖ - どこまで中⾝をValidateするか︖ は実装依存 v2ではschemaプロパティは無くなり、 constraintsで必須項⽬チェックのプロパティが設けられた。

2023年のユースケース 58

ユースケース3点 ● ソース: Hyperledger公式サイトのユースケース紹介 ● いずれも官⺠共同で進められている。 ● 1. カナダの資源採掘とレポートシステム ● In Production ● 2. インドの旅客機搭乗システム ● In Production ● デリーなど複数の空港で運⽤されている。 ● セキュリティ担当者の介⼊なしで⼊⼝、セキュリティ、搭乗エリアなどの 空港のさまざまなタッチポイントでプロセスを迅速化する。 ● 3. ブータンの国⺠デジタルIDシステム ● In Development 59

カナダの資源採掘とレポートシステム ● VC: 規制に則っていること、ESGのパフォーマンス具合など ● Issuer: 政府、監査法⼈ ● Holder: 資源採掘会社 ● Verifier: 協会、投資会社 ● Platform: Northern Block ● Holder: Cloud型︖ 60 Issuer Holder Verifier 出典: ENERGY & MINES DIGITAL TRUST: INTEROPERABLE TECHNOLOGY FOR SUSTAINABLE, RESILIENT SUPPLY CHAINS HEADS TO PRODUCTION

OID4VCとの関連性 61

AFJの最新バージョンの状況 （以下、全てAries RFCの外のこと） ● OID4VCIに⼀部対応済み ● 役割: Holder Wallet(=OAuth2 Client) ● Pre-Authorized Code Flowのみ実装 ● Sphereon社のOID4VCI Clientライブラリに依存 ● did:jwkに対応済み ● Experimental Featureとして、Aries Protocol上でLDP-VCの様に JWT-VCを扱える（様にコードから読み取れる） ● サポートするJWA署名アルゴリズム EdDSA(Ed25519), ES256, ES384, ES512 ● (publishされていないmainブランチの話)SD-JWTの実装が進められている模様 62

OID4VC vs Aries RFC (IMHO) ● OID4VCの思想 ● 今のWebインフラそのままでSSIを ● インフラ = HTTPS(DNS、認証局) ● SSIコミュニティ全体として、”組織ならdid:web“の⽅向に流れている中、 did:webに肯定的な⼈多い印象 ● did:ionはBitcoinベースだが、普通にDNS/認証局に依存している（と思う） ● 重要なのは、主体がGatekeeper/Authorities抜きにDID Documentをコントロールできること。 ● ”Decentralized” ● Issuer(OP)に対する依存度を下げる。↓ ● Identifier/Attributesを事業者から本⼈に集約する（個⼈に分散する） 63

OID4VC vs Aries RFC (IMHO) ● Hyperledger Indy/Ariesの思想 ● 今の集権的なWebインフラに依存せず、Secureな形で属性情報をVerifyしよう。 ● 加えてTCP/IP内外でも使えるように。 ● did:webに否定的な⼈もいる。 ● ⼿軽だしControllableだけど・・・ ● バージョニング、改竄防⽌/チェックの仕組みがない -> did:webs ● “Decentralized” = Issuer依存度下げ + 現在のインフラに依存しない ● 例えば、Indy Node間、Node-Agent(Client)間の通信は、DNS/認証局に⾮依存（と認識） ● 通信: 各Nodeは公開鍵を持つから署名と検証できる。 ● 通信: 流れる情報はPublicでOK。Agent-Node間は署名だけで暗号化されない通信、Node-Node間は 認証付き暗号による通信の模様。いずれにしてもTCP/IP上でIndy独⾃のプロトコルで通信する認識 (ソースのPDF) ● TXの⾮改竄チェックを含めて、Indy使う⼈は公開鍵群を信頼する。 （ただGenesis File(公開鍵/IPリスト)はGitHubから取得など..) ● 例えば、DIDComm over HTTPSは冗⻑ ● 結果、アーキテクチャが異なり⽐較するとConnection, Mediationという⾯倒が必要になる。 64

今後の展開の予測 65

直近のコミュニティ議事録から⾒る今後の発展の可能性 ● Aries RFC ● AIP3.0の策定 ● ACA-Py ● 特定のDID Methodに依存しないHyperledger AnonCredsへの対応(AnonCreds-RS) ● DIF DIDComm(v2)の実装 ● OID4VCへの対応︖ ● AFJ ● GenericなSSI FWとして、Open Wallet Foundationへの移管を検討中 ● DIF DIDComm(v2)の実装 ● Holder Wallet(=OP)としてSIOPv2, 4VPの実装 ● OID4VC以外の部分でEUDIW ARP(e.g. mDL, SD-JWT...)への準拠? 66

終わり ご清聴ありがとうございました。 67