SSIの全体像と HL Ariesによるシステム構築 Blockchain GIG #15 神沼 貴⼤(@t_kanuma) 2023/7/12

会社概要 2 GMOグローバルサイン・ホールディングス株式会社 本社所在地 事業内容 代表者名 設⽴ 資本⾦ 上場市場 連結従業員数 加盟団体（抜粋） 東京都渋⾕区桜丘町26-1 セルリアンタワー クラウドホスティング及びセキュリティサービスを中核とした 各種インターネットソリューションの開発･運⽤ 代表取締役社⻑執⾏役員 ⻘⼭ 満 平成5年12⽉ 9億1,690万円 東京証券取引所プライム市場（証券コード︓3788） 社員972名 ⽇本ネットワークセキュリティ協会 トラストサービス推進フォーラム デジタルトラスト協議会 ⼀般社団法⼈⽇本クラウド産業協会（ASPIC） 電⼦認証事業および創業以来提供しているホスティング事業から、AI・IoTを活⽤したサ ービスにいたるまで、ITのチカラでお客さまのビジネスを⽀えています。 ● 電⼦認証・印鑑事業 ● クラウド・インフラ事業 ● DX事業 ※2022年12⽉31⽇現在 •「GMOおみせアプリ」導⼊店舗数 2万店以上 (2022年3⽉末時点) •「SSLサーバ証明書」発⾏実績 1,600万枚以上 (国内シェアNo.1※) •「電⼦印鑑GMOサイン」 導⼊企業数 190万社以上 (2022年3⽉末時点) ※ 2023年3⽉末時点 「SSL Survey by Hosting Country」より • 提供実績26年 • クラウドインフラサービス契約件数 約8万件 (2022年12⽉末時点)

ざっくりした流れ 3

前提: SSI/DID/VCの範囲 ● ⼈によって⼤分認識が異なるのではないか︖ ● 私の取り組み ● 既存のIdentity分野の延⻑線上にある⾊合いが強い。 ● SSI空間全体の⼀⾯、部分 ● （何事にも多様性は⼤事だと思う。否定的、攻撃的な意図はありません。） ● 私の取り組み︓Web3/Crypto領域のモノとは思っていません。No Tokens. ● Web3/Cryptoについては無知です。 4

前提: SSI/DID/VCの範囲 ● W3C ● Decentralized Identity Foundation (DIF) ● Hyperledger Indy/Aries ● OpenID Foundation ● Web5 5

SSI/DID/VCを理解するための良い⼿段は︖ オープンスタンダード（とそれに付随するドキュメント）をフルスキャンすること ● W3C ● VCs Data Model ● VCs Data Integrity ● VCs Impl Guidelines ● DID Core ● DID Specification Registries ● DID Resolution ● Revocation List 2020 ● Status List 2021 6 ● did:web ● did:sov ● did:key ● Securing VC using JWT ● JWT VC Presentation Profile ● Universal Wallet 2020 ● VCs JSON Schema 2022 ● Encrypted Data Vaults

SSI/DID/VCを理解する⼀番の⼿段は︖ ● DIF ● DID Registrar ● well-known DID configuration ● Sidetree ● did:peer ● DIDComm ● Decentralized Web Node ● Wallet Rendering ● Credential Manifest ● Presentation Exchange ● WACI-DIDComm Interop Profile ● The BBS Signature Scheme 7

SSI/DID/VCを理解する⼀番の⼿段は︖ ● Hyperledger Indy/Aries ● Indy SDK/Node/Plenum ● AnonCreds ● did:indy ● Aries Interop Profile 8

SSI/DID/VCを理解する⼀番の⼿段は︖ ● OpenID Foundation ● OpenID for Verifiable Credential Issuance ● OpenID for Verifiable Presentations ● Self-Issued OpenID Provider ● IETF ● SD-JWT 9

SSI/DID/VCを理解する⼀番の⼿段は︖ 前半: 細かいことは気にせず、ざっくりと(私が考える) 全体感をご説明 10

1. ToIP Tech StackのLayerごとに仕様/実態の特徴⽐較 11 SSI 仮説:アプローチ⼿法として、ToIP Tech Stackを 使ってみると、全体感を理解しやすくなるかもしれない。 (OAuth/OIDCが厳密に当てはまらないのは承知の上で） VC • 思想 • イデオロギー Entity/ Agent DID Layer 1: DID Methods Layer 2: Agents and Communication Layer 3: VC, Trust Triangle Layer 4: Apps, Ecosystem Open Standards did:web did:indy did:ion ToIP Tech Stack コア要素 仮説:宗教の中の宗派のように、それぞれ⼤事にしているポイントが異なる。 それを前提に、ポイントを⽐較することで理解が進むかもしれない。

2. 仕様セットごとの特徴⽐較 12 SSI VC Entity/ Agent DID Layer 1: DID Methods Layer 2: Agents and Communication Layer 3: VC, Trust Triangle Layer 4: Apps, Ecosystem Open Standards did:web did:indy did:ion ToIP Tech Stack コア要素

2. 仕様群ごとの特徴⽐較 / 3. エンジニアとして開発の選択肢 13 仕様群 per 管理団体 OSS サービス （プラットフォーマー） サービス （プラットフォーマー） 実装 ラップ 実装

後半 Hyperledger Indy/Ariesを使ったシステム構築の流れ 14

ToIP Technology Stack 15

Trust over IP Foundation ● IP = Internet Protocol ● デジタル空間でトラストを形成するために、 DID/VCを⽤いた相互運⽤性のあるアーキテクチャ/モデルを策定 ● コンセプトは国が推進するTrusted Webに近いかも︖ 16

ToIP Technology Stack 17 [出展] The Trust Over IP Model

Layer 1 ~DID Methods~ 18

DID DIDとは結局何なの︖: 公開鍵とエンドポイントで構成されるJSONを指すポインター/ロケーター 19 DID DID Document 公開鍵 エンドポイント resolve

DIDの⽤途分解 20 公開鍵 / エンドポイント 署名 VC (by Issuer) 通信 VP (by Holder) Public DID (e.g. web, indy, ion...) Public DID (e.g. key, web, ion...) Private Holder Binding (e.g. Link Secret) VCのPossession証明 HolderのCorrelation(名寄せ)リスクあり IDをexposeしない Correlation対策 Public DID (e.g. web, indy, ion...) Pairwise DID (e.g. peer) Correlation対策 HolderのCorrelation(名寄せ)リスクあり Layer 3(VC種別) Layer 2 Layer 1

DID Method ● メソッドによって何が異なるか︖ 1. DID Documentの保管⼿法（どこにどう保管するか） 2. Method Specific Identifierの作り⽅(e.g. did:key:foobarbaz) 3. DID Operation/Resolutionの⼿法 ● Operation = Create, Update, Deactivate ● Resolution = Read 21 Layer 1: DID Methods did:web did:indy did:ion

did:web ● WebサーバにDID Documentを保管 ● GET https://{domain}/.well-known/did.json ● ドメインを持つエンティティが管理 ● 現実的にはIssuerがサーバ⽴てる︖ ● DID Doc取得者は以下を信⽤する。 ● 既存のインターネットの中央集権的なインフラ ● DNS ● 電⼦認証局 ● 中央集権的に管理されるWebサーバ / 管理主体 22

did:web 23

did:web 24 Holder Issuer Verifier Issuer Webサーバ DID Document ①VC発⾏ ③VP提⽰ SSIポイント: 「提⽰の際にIssuerに問い合わせない / フィジカルな紙のモデルと同等にする」 はクリア。 - Issuerの負荷軽減 - IssuerにVC利⽤をトレースされない。 - + パスワードレス GET https://{domain}/.well-known/did.json ④公開鍵取得 ⑤VP検証失敗 ②公開鍵改ざん 例: (Issuer)あのHolderムカつくから公開 鍵、改ざんしてやんべ︕ -> 社会的信⽤を失うだけであり得ないの では。 例: サーバを攻撃されていつの間にか 改ざんされている︕ -> ただの当たり前で普遍的なリスクでは。 中央集権的な仕組みを危惧するなら、 ブロックチェーンが選択肢になる。 中央集権的 中央集権的 中央集権的

did:indy ● Hyperledger Indy(OSS)を使ったDLT/分散台帳。コンソーシアム型。 ● Redundant Byzantine Fault Toleranceベースのコンセンサスプロトコル ● ブロックはチェーンしていない。 ● Validator Nodeとしてネットワーク参加は許可制 ● TX書き込みクライアント(=Issuer)は許可制 ● TX読み取りクライアント(=Holder/Verifier)は誰でもなれる。 ● 稼働ネットワーク例 ● Sovrin: ⾮営利団体運営の最⼤規模のネットワーク ● IDUnion: ヨーロッパのエンタープライズ企業で構成 ● Indicio: ⺠間企業運営のネットワーク 25 [1]

did:indy 26 Agent Indy Node Indy Node Indy Node Agent [1] HTTPでいけるのでは︖(DNS、認証局に依存しない） [TX書き込み] • 改ざん検知: DIDで署名して送信する。 • 暗号化: 内容はPublicな情報 [TX読み込み] • 改ざん検知: • TX群をRocksDB(KVS) + Merkle Patricia Treeで管理 • 全ノードがRoot HashにBLS Multi署名 • ClientはMerkle proof-of-inclusionとノード署名を検証 • 暗号化: 内容はPublicな情報

did:indy 27 Sovrin IDUnion Agent did:indy:sovrin:abcde123 did:indy:idunion:xyz456 Indy Node Indy Node Indy Node DID Doc

did:ion (Sidetree実装 / Identity Overlay Network 28 クライアント IONノード Bitcoin IPFS IONノード IONノード DID ResolutionのRequest クライアント DID OperationのREST API Request Batch Write 定期Readとローカルキャッシュ DID Operation(DID Documentに対するCUDのTX)が発⽣した順序を保証するために、 中央集権無しでその機能を持つBitcoinを使う。 Storing DIDs on ION (a Layer 2 DID network that runs on top of Bitcoin) is a preferred design decision for the implementation of Web 5. ION is a decentralized replacement for DNS for identity identifiers, so there are no authorities, coordinators, tokens, or other centralized bottleneck. [出展]: What is Web5?(TBD)

did:ion 29 [出展] DIF Sidetree Protocol [出展] The Sidetree Protocol: Scalable DPKI for Decentralized Identity

各DID Methodのイデオロギー⽐較(私的妄想 – こう考えると区別、理解しやすいかも ) 30 did:web ⾮中央集権?/⾮集中?/分権?/分散?の度合い 低 ⾼ did:indy did:ion • パスワードレスとIssuer(IdP)の集中度合いの 分権は実現できているわけだし、 SSIとして、それで⼗分でしょ︖ • 今のインターネットの中央集権インフラ (DNS、認証局)でいいじゃない。 • ⾃分で改竄なんてしたら社会的信⽤失うだけ。 攻撃にはしっかりサーバー管理すれば良い。 問題視する必要ある︖ • 分散台帳、ブロックチェーンなんて⼤それた 仕組み使う必要ある︖ ⾮改ざん性⾼いし、 私が⼀番、分権のバランスが良い。 • 改ざんリスク︕ -> did:web • 中途半端やねん︕ -> did:indy -> did:ion 本当に持続可能なの︖ • 変動性⾼い。 • 分散と⾔いながら、BTCの保有具合はパレートの法則やん。 • 発⾏上限に達してモノよりBTCの価値が上がってデフレ状態になっても誰もリフレ、 通貨発⾏できないやん。 • アメリカだとアルトコインが証券扱いされて国にボコボコにされてるやん。

各DID Methodのイデオロギー⽐較(私的妄想 – こう考えると区別、理解しやすいかも ) ● 正解は無いのでは。 ● 結局、我々ホモサピエンスの営みなので、 どのくらいの⼈が、どのフィクションを信じるか。=> 勢⼒、常識 ● あなたはどれが好みですか︖ 31

Layer 2 ~Agents and Communication~ 32

DIDの⽤途分解 33 公開鍵 / エンドポイント 署名 VC (by Issuer) 通信 VP (by Holder) Public DID (e.g. web, indy, ion...) Public DID (e.g. key, web, ion...) Private Holder Binding (e.g. Link Secret) VCのPossession証明 HolderのCorrelation(名寄せ)リスクあり IDをexposeしない Correlation対策 Public DID (e.g. web, indy, ion...) Pairwise DID (e.g. peer) Correlation対策 HolderのCorrelation(名寄せ)リスクあり Layer 3(VC種別) Layer 2 Layer 1

⽐較 34 特徴 OAuth/OIDC DIDComm DWN アーキテクチャ クラサバ P2P P2P トランスポート HTTPS Agnostic HTTP? 通信にDIDを 使わない 使う 使う 通信のDIDは - Pairwise Public? OpenID4VCI/VPのベースになっているという 意味合いでわかりやすさ優先で載せています

DIDComm 35 Agent Agent 公開鍵 公開鍵 共有鍵⽣成 共有鍵⽣成 鍵交換 鍵交換 HTTP(S), Bluetooth, MQTT... Endpoint Endpoint Connection⽣成 DIDCommメッセージ送受信

DIDComm: Connectionの張り⽅ 2種類 36 Agent X Agent Y did:peer 公開鍵/Endpoint XのEndpointにYのdid:peer(公開鍵+ Endpoint)を送る Out-Of-Band(QRコード、メール）で送る Agent X Agent Y (Registry) Yʼs Public DID Endpoint取得 YのEndpointにXのdid:peerを送る

Correlationとは︖ 37 Holder像

Correlationとは︖ 38 Holder Verifier A Verifier B 通信のためのDID、複数のIssuer/Verifierに対し使い回す。 did:ion:abc123 Aさん、Holder(did:key:abc123)から、 こういう - 時 - 内容のVC - ⽬的 で来ている。そちらはどう︖ 結託 Holder Verifier A Verifier B did:peer:abc123 did:peer:xyz123

Decentralized Web Node 39 [出展] DIF: Decentralized Web Node

Layer2イデオロギー⽐較(私的妄想 – こう考えると理解しやすいかも ) 40 OIDC ⾮中央集権?/⾮集中?/分権?/分散?の度合い 低 ⾼ DIDComm • 今のインフラでいいっしょ。 • これだけスケールして、⼈々の⽣活インフラ になったインターネットに新しいレイヤーを 加えるのは⼤変だよ︖ -> DIDComm • クラサバは歪な⼒関係。P2Pが良い︕ • DNS/認証局、必要なし︕HTTPでワークする︕ • Transport Agnostic︕(WS、Bluetooth、MQTT...)

Layer 3 ~VC and Trust Triangle~ 41

2つのトピック 42 Layer 3: VCの種別 JWT-VC JSON-LD Credential(LDP-VC) (Ed25519 Sig/ BBS+ Sig) Indy AnonCreds Layer 3: VC発⾏/VP検証のプロトコル OpenID4VCI/VP Aries Issue Credential Protocol/ Present Proof Protocol DWN︖

VC種別 43 特徴 JWT VC JSON-LD Ed25519 Sig JSON-LD BBS+ Sig AnonCreds W3C Data Model 準拠 Yes Yes Yes No アドバンテージ JWTが⼀般に普及済み シンプルさ Contextsの再利⽤性︖ シンプルさ ⇦⇨ いいとこ取り (プライバシー + シンプル) VCとして現在、最も普及[3] プライバシー機能 ディスアドバンテージ ︖ ︖ ︖ パフォーマンス⾯ Holderプライバシー 保護機能 5つ 無し 無し ⼀部（全部︖） 全部 [2] Proponents of correlating credentials often make an argument that sounds like this: Going to great lengths to avoid correlation is wasted effort, because weʼll be correlated anyway. Just accept that and quit trying to fight a losing battle. Our energy is better used elsewhere. 出展: Evernym: The Dangerous Half-Truth of “We’ll Be Correlated Anyway” ←どの道最終的にはCorrelationされるのだから技術で それを防ごうとするのは無駄な努⼒と考える⼀派もいる︖

暗号技術を使ったプライバシー保護機能5つ 44 タイプ 機能 概要 Correlation（名寄せ）対策 Private Holder Binding VCにオーナーであることを⽰すDIDを記載せずに、 それをVerifierに証明する。 Privacy Preserved Revocation VCに失効状態を特定するIDを持たせずに、 Verifierに失効状態を証明する。 Signature Blinding • IssuerのVC署名の使い回しが、Holderの特定に繋がる︖ • わからない（知っている⼈いたら教えてください） 開⽰する情報の最⼩化 Predicate ZKPでClaim値を明かさずに、基準値以上以下だけを Verifierに証明する。 Selective Disclosure All or Nothingではなく、Verifierから要求のあった （もしくはHolderが提案した）Claim群のみを提⽰する。 [4]

DIDの⽤途分解 45 公開鍵 / エンドポイント 署名 VC (by Issuer) 通信 VP (by Holder) Public DID (e.g. web, indy, ion...) Public DID (e.g. key, web, ion...) Private Holder Binding (e.g. Link Secret) VCのPossession証明 HolderのCorrelation(名寄せ)リスクあり IDをexposeしない Correlation対策 Public DID (e.g. web, indy, ion...) Pairwise DID (e.g. peer) Correlation対策 HolderのCorrelation(名寄せ)リスクあり Layer 3(VC種別) Layer 2 Layer 1

Correlationとは︖ 46 Holder Verifier A VC Credential Metadata [4] Verifier B Claims Proof (Issuer署名) Holder DID VP Presentaiton Metadata VC Proof (Holder署名) VP提⽰ Aさん、Holder(did:ion:abc123)から、 こういう - 時 - 内容のVC - ⽬的 で来ている。そちらはどう︖ 埋め込む 署名 結託

Correlationとは︖ 47 Holder像

Correlationとは︖ 48 Holder Verifier A [5] Verifier B VP提⽰ W3C VCs Data Model • 気にするなら、HolderはDIDの使い回しはしないでね。 • シングルユースにとどめてね。Verifierごとに変えてね。 did:ion:abc123 did:ion:xyz456

AnonCreds = Anonymous Credentials ⾝元を明かさずに、Possessionを証明する。 Private Holder Binding (e.g. Link Secret) 49 Holder Issuer Verifier [4] Indy Ledger Link Secret Link Secretを元に⽣成された値X (発⾏単位で異なる） XをClaimの⼀部としてVC発⾏ Link Secretを明かさずに、 それがXに寄与することを証明

Privacy Preserved Revocation ● Indy Revocation ● 拙著:【Hyperledger Indy/Aries】ACA-PyでVerifiable Credentialを失効させる ● Evernym: ● OSS実装?仕組み⾃体?はスケーラビリティに⽋ける。 ● 我々のサービスでは失効機能を実装していない。 ● コミュニティで、効率的な⽅式について対応中 ● Non-Preserved ● DIF Revocation List 2020 ● DIF Status List 2021 50

備考: Privacyに関して標準における記述場所 ● W3C VCs Data Model ● 7. Privacy Considerations ● W3C VCs Implementation Guidelines ● 12. Zero-Knowledge Proofs ● 13. Progressive Trust ● W3C VC Data Integrity ● 6. Privacy Considerations 51

それぞれ進化の途中 52 JWT-VC JSON-LD Credential (BBS+ Signature) Indy AnonCreds SD-JWT (Selective Disclosure機能） Indy配下からHyperledger直下へ Indyなしでも使えるよう仕様化 Data ModelをW3C準拠へ 各種プライバシー保護機能の仕組み策定 Predicate Selective Disclosure その他︖ [2]

VC発⾏/VP提⽰のプロトコル 53 [出展] OpenID for Verifiable Credential Issuance ● Aries系は、後半で説明。 ● OpenID4VCI

OpenID4VCI (Pre-Authorized Code Flow) 54 JSON-LD Credential(LDP-VC) (Ed25519 Sig/ BBS+ Sig) Aries Issue Credential Protocol/ Present Proof Protocol [出展] OpenID for Verifiable Credential Issuance SSIの外側で、事前にHolderの認証が済んで いる状態から始まるフロー QRコードにOAuth2の認可コードが埋め込ん であり、これをHolderにメールなどで送る or ⾒せる。（この認可コードにClaim情報が紐 づいている︖） （OAuth2と同様に）Holderは認可コードを Token Endpointに送ることでアクセストー クンを得る。 Holderは⾃⾝のDIDで署名したnonceとアク セストークンを含むリクエストを IssuerのIssue Endpoint(OAuth2でのリソー スサーバー）に送る。 Issuerはそのレスポンスとして、HolderにVC を発⾏する。 VC発⾏オファー VC発⾏要求 VC発⾏ ここの ⼤まかな流れは Ariesと同じ

バーティカルカットで特徴⽐較 55

2. 仕様セットごとの特徴⽐較 56 SSI VC • 思想 • イデオロギー Entity/ Agent DID Layer 1: DID Methods Layer 2: Agents and Communication Layer 3: VC, Trust Triangle Layer 4: Apps, Ecosystem Open Standards ToIP Tech Stack コア要素

2. 仕様セットごとの特徴⽐較 57 仕様スタック / 管理団体 OSS サービス （プラットフォーマー） サービス （プラットフォーマー） 実装 ラップ 実装

団体の種別 58 コミュニティ、団体 種別 Hyperledger Indy/Aries 標準化、OSS OpenID Foundation 標準化 Web5 OSS Microroft Entra, Evernym, Indicio... サービス

スタック 59 (W3C) did:sov (DIF) DIDComm (Aries) Issue Credential Protocol/ Present Proof Protocol (DIF) Credential Manifest (DIF) Presentation Exchange Layer 4: Apps, Ecosystem Hyperledger Indy/Aries ToIP Tech Stack AnonCreds JSON-LD Credential Web5 (DIF) did:ion (W3C) did:web (DIF) DWN OIDF JWT-VC JSON-LD Credential (DIF) Credential Manifest (DIF) Presentation Exchange OAuth/OIDC OpenID4VCI/VP JWT-VC JSON-LD Credential AnonCreds (DIF) Credential Manifest (DIF) Presentation Exchange [6]

プラットフォーム環境 サービス / プラットフォームとは︖ 60 Holder Agent (Mobile App) Issuer Agent Verifier Agent expose REST API Issuer環境 (顧客) Verifier環境 (顧客) expose REST API • SSIシステム構築を楽にします。 • SSI的にありなのか︖わからない。 Issue/Store VC Present/Verify VP

スタック 61 (OIDF) Self-Issued OpenID Provider (OIDF)OpenID4VP (DIF) Presentation Exchange Layer 4: Apps, Ecosystem Microsoft Entra ToIP Tech Stack JWT-VC Evenym, Indicio, Northern Block : 海外スタートアップ Hyperledger Indy/Aries (DIF) did:ion (W3C) did:web [6]

団体間の関係性 62 OIDF W3C Web5 DIF 取り⼊れる Hyperlerdger Indy/Aries 競合

OSS、サービス出てきて3~4年くらい︖ / 普及していない ● なぜ︖（個⼈的⾒解） ● ビジネス化が難しいという話を周りからも聞く。 ● 普及 ● 多くの⼈がそのフィクションを信じること。 ● ⾃由主義の世界では多くの⼈に良いと思ってもらう必要がある。 ● ⽂明化、ビジネス ＝ 便利、楽になる。（e.g. ChatGPT) ● SSIは、そういう⽅向の明確な成分が少ないのでは。 ● 意味のあるもの︖ = 市場規模が⼩さくなりがち︖ ● 経済合理性が低い社会課題に近しい︖ ● ⼤きな組織単位で権⼒によるトップダウンが必要︖ ● トリガーになりそうなプロジェクト 63

European Digital Identity Wallet 64 ● eIDAS 2.0 (electronic IDentification, Authentication and trust Service) ● 希望するEU市⺠に対しWalletの提供を義務化 ● SSIでいうとHolder Agent(Wallet) ● EU市⺠は使う使わないは⾃由 ● 数々のSSI企業が参加しパイロットプロジェクトが進⾏中 ● ARF（Architecture and Reference Framework）発表 ● ⼀般に知られている標準とプラクティスに則り、 相互運⽤性のあるEUDI Walletを開発するための仕様群 ● OpenID4VCI採択 ● 5億⼈! [7]

エンジニアとして開発の選択肢 65

あり得そうな選択肢 1. オープンスタンダードを⾃前で実装 ● OpenID系だと、元々IdP、RPを持っていたらやりやすいのかも︖ ● Trusted Webのパイロットで、OpenID系の実装をされていた会社さん 複数いた気がする。 2. OSSの利⽤ ● Hypeledger Aries: Production Ready ● OpenID系: ありがたいことに、出てきているが実装中の段階 ● Sphereon社 ● Aries Framework JavaScript (⾯⽩いのはAriesのOSSで取り⼊れている所) ● Web5: まだTechnical Previewの段階 3. サービスの利⽤ 66

巨⼈の肩の上に⽴ち、Layer4実現を⽬指す、あるエンジニア 67 Layer 1: DID Methods Layer 2: Agents and Communication Layer 3: VC, Trust Triangle Layer 4: Apps, Ecosystem Open Standards ToIP Tech Stack SSIやれ、⾔われたけど、 仕様を全部実装する体⼒、スキルないしな・・・ HL Ariesさん、OSSいい感じやん︕ ありがたや、⼤感謝〜〜 仕様、OSSコード、開発Doc ⼀通り読んで、試してみよ︕ ⼈的資本 -> 社会資本のために 試した結果を公開しちゃお︕ アプリ、システム作ってPoCして、 ビジネス、サービスに繋げて会社の ミッション/ビジョン達成しちゃお︕ 社会資本 -> ⾦融資本

(前半部分) ソース ● [1] Hyperledger Indy Public Blockchain ● [2] ● Covid-19 Credentials Initiative: Verifiable Credentials Flavors Explained ● Covid-19 Credentials Initiative: Verifiable Credentials Flavors Explained (Infographic) ● Indicio: Five Things You Need to Know About JSON-LD Credentials in Hyperledger Aries Cloudagent Python ● Evernym: Categorizing Verifiable Credentials ● Evernym: Why the Verifiable Credentials Community Should Converge on BBS+ ● [3] Hyperledger: Announcing Hyperledger AnonCreds: Open Source, Open Specification Privacy Preserving Verifiable Credentials ● [4] ● Evernym: The Dangerous Half-Truth of “Weʼll Be Correlated Anyway” ● Evernym: How Does a Verifier Know the Credential is Yours? ● Aries RFC 0646: W3C Credential Exchange using BBS+ Signatures ● [5] W3C Verifiable Credentials Data Model: 7. Privacy Considerations ● [6] ● https://pkg.go.dev/github.com/TBD54566975/ssi-sdk#section-readme ● https://developer.tbd.website/docs/web5/learn/decentralized-identifiers/ ● Microsoft Entra Verified ID-supported standards ● [7] ● Biometric Update.com: EU Digital Identity Wallet Consortium selected for large-scale pilot ● European Commission: The European Digital Identity Wallet Architecture and Reference Framework 68

前半終わり 69

Hyperledger Ariesとシステム構築 70

71

ACA-Py / AFJ / von-network 72

ACA-Py (Issuer/Verifier) 73 Indy SDK Wallet(PostgreSQL or SQLite)

ACA-Py (Issuer/Verifier) 74

AFJ (Holder) 75

1. 開発⽤Indy Ledger⽤意 / Issuer Public DID⽣成 76

2. Issuer Agent(ACA-Py)の起動 77

2. Verifier Agent(ACA-Py)の起動 78

3. IssuerがVC発⾏、検証に必要になるTXを作成 79

3. IssuerがVC発⾏、検証に必要になるTXを作成 80

Mediator 81

4. ⼤まかな流れ 82 ● Issuer-Holder間でConnection⽣成 ● Holder-Verifier間でConnection⽣成 ● Issuer-Holder間でVC(AnonCreds)発⾏ ● Holder-Verifier間でProof提⽰検証 ● https://tech.gmogshd.com/medical-chekup-prototype/ ● 細かい部分は拙著群をご参照ください。 ● https://tech.gmogshd.com/?s=kanuma

後半終わり 83

最後に ● PoCを協業していただける企業様を探しています。 下記の窓⼝までご連絡ください。 ● [email protected] (マネージャ） ● 社会資本を引き続き増やしたいので、今回 or テックブログの内容に関する 質問、議論等、お気軽に連絡ください。 ● Twitter: @t_kanuma ● 何のコダワリもプライドもないIdentity素⼈のサラリーマンエンジニアです。 誤った理解をしている箇所があれば、学びたいと思うのでご教⽰ください。 84

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