SSI、DID、VCとは？ 概念と仕組みの基本 / SSI DID VC 101

2023/7/12 Blockchain GIG#15 で喋った内容
SSI/DID/VCが求められ、開発されてきた経緯を紹介しつつ、それぞれどういったものなのか、どのような仕組みで成り立っているのか、どのようなことに使えるとされているのかなどの基本的な知識を整理して紹介。
できるだけ間口が広くなるよう、背景にある技術的な要素として理解しておくべきブロックチェーンや公開鍵、デジタル署名についても併せて簡単に説明。

Transcript

1. SSI/DID/VCとは？ 概念と仕組みの基本 Blockchain GIG #15 中村 岳 日本オラクル株式会社 クラウド事業統括／クラウド・エンジニアリング統括／CoE本部／ソリューションアーキテクト部 2023/7/12
2. Copyright © 2023, Oracle and/or its affiliates 2 中村 岳 Twitter @gakumura はてなブログ @gakumura …主にHyperledger Fabric関連 • 現職：ソリューションエンジニア@日本オラクル • 担当：Oracle Blockchain Platform、 Blockchain Table • 前職：金融決済系SIerでパッケージ開発 • SWIFT、CLS、日銀ネット関連の銀行間決済システム
3. 内容 • DID/VC理解の前提となる要素を説明： • ブロックチェーン • 秘密鍵／公開鍵とデジタル署名 • SSIの概要： • デジタルアイデンティティの発展と課題 • SSIの思想と登場背景 • DID/VC • DID／VCの仕組み • DID／VC（Verifiable Credentials）のメリット • ユースケースの例 Copyright © 2023, Oracle and/or its affiliates 3
4. Copyright © 2023, Oracle and/or its affiliates 4 DID/VC理解の前提となる要素： ブロックチェーン
5. DID/VCの文脈でブロックチェーンについて理解しておきたいこと • データとロジックを保持するノードを複数の組織や個人が分散して管理、運用していること…Decentralized、分権 • 全員が運用をやめない限り、データはアクセス可能なまま…アクセシビリティ • マジョリティ～全員が一致（結託）しない限り、ユーザーが排除、差別されない • 書き込まれたデータは不変の記録として残る • マジョリティ～全員が一致（結託）しない限り、記録を勝手に改変されたりしない…耐改ざん性 5 Copyright © 2023, Oracle and/or its affiliates
6. ブロックチェーンの利用形態（ネットワーク）の分類 Copyright © 2023, Oracle and/or its affiliates パブリック 公開制のネットワークを 不特定多数で運用 コンソーシアム 許可制のネットワークを 複数組織で運用 プライベート 許可制のネットワークを 単一組織で運用 パーミッションレス← →パーミッションド 6 6
7. Copyright © 2023, Oracle and/or its affiliates 7 DID/VC理解の前提となる要素： 秘密鍵／公開鍵とデジタル署名
8. 秘密鍵／公開鍵 （※一部正確性よりもわかりやすさを優先） • 秘密鍵／公開鍵はペアで生成される • 秘密鍵は誰にも渡さず自身で管理する • 公開鍵は直接渡すか公開するかして相手が利用できるようにしておく 8 Copyright © 2023, Oracle and/or its affiliates Alice 秘密鍵／公開鍵ペア 生成 Alice Bob 私の公開鍵です 了解、保存しときます Alice Alice Bobがアクセスできる 公開鍵置き場に登録 Bob Aliceの公開鍵は あそこにあるな 直接渡すパターン 公開するパターン
9. 参考：RSA秘密鍵（左）と公開鍵（右）のサンプル -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcnNh AAAAAwEAAQAAAYEA7ff6VyJ4T4Yb7jBnAx2n8r4OSaVRn+kXJk3xCi30t76cbXLJOkd+xuHdQe6 qMi89Fj8LXiq+0O/BJRLqviL6CNxVJGEiuHJZeZSW4bt2jj9zRt6/0H1NO1MgM723v92oDV1O+FVx GOPRFds50tKbm1QK+0mstccflpT2YNNhxQ0Ta+wEYA66B4apeCPjFTLW7QI8EyJ5DJi0MhrUmU wJX0m/VPdVpsobhZH4Jgl5njJ/QAHhapjybgC5NM/EoXX3fg2uMfdzFqDMX88WihWX4W7xcNaT ttIbyAx0GJU/ragec2j99cUxxokTgV98NPpLZJCGVbIt6ttAJb6sNvhGslE4RRK30m42/5m2R2GvF8C aKAF15XSJvi0e8uW7iq6HMTt5S3IutvnVmC07lK9m/i6J81q5vS2MWtb1bDSmCjILZ7MyBxTtJkuV Iwf+ueZRIxqswZ4jx1uHjKH14yyQ33AwmhYtEBim6RxoTLZG02ot2jLlc2bsWtkpgcRl5uv/AAAFkP7 4GhH++BoRAAAAB3NzaC1yc2EAAAGBAO33+lcieE+GG+4wZwMdp/K+DkmlUZ/pFyZN8Qot9Le+ nG1yyTpHfsbh3UHuqjIvPRY/C14qvtDvwSUS6r4i+gjcVSRhIrhyWXmUluG7do4/c0bev9B9TTtTIDO 9t7/dqA1dTvhVcRjj0RXbOdLSm5tUCvtJrLXHH5aU9mDTYcUNE2vsBGAOugeGqXgj4xUy1u0CPB MieQyYtDIa1JlMCV9Jv1T3VabKG4WR+CYJeZ4yf0AB4WqY8m4AuTTPxKF1934NrjH3cxagzF/PFo oVl+Fu8XDWk7bSG8gMdBiVP62oHnNo/fXFMcaJE4FffDT6S2SQhlWyLerbQCW+rDb4RrJROEUSt 9JuNv+ZtkdhrxfAmigBdeV0ib4tHvLlu4quhzE7eUtyLrb51ZgtO5SvZv4uifNaub0tjFrW9Ww0pgoyC 2ezMgcU7SZLlSMH/rnmUSMarMGeI8dbh4yh9eMskN9wMJoWLRAYpukcaEy2RtNqLdoy5XNm7F rZKYHEZebr/wAAAAMBAAEAAAGBAKHMydoVBdiMRtFc962WrGrP7scEMMuZoLPaqtlRBeMpJxM DyO5nTjvLtrTtoasdk1tc4k3UoolNevXKNvGwtnDv3rQtl33xwgR4k15IKAPwAGFfcuw/RhPgITUM+b Lq8yijGN6guZVC0RcbR+WgbUzfh9fz8ApoqYGpJxwOnZttmJb4ksD9Ql97oB6fx/bR6nCb5FzeQ4/ dBChNNeBFYtn3OrB6uzH8mVnoNeEm8BowG3VZ0fq4o51HwKW33uopWh4k35gwxwc0FF4Qljcc 0I0M68/UGmBZazEOFemj457FiS+05rR01ueZ2sNDe6mx9Nz/QxrIvMJFnUtEUMQLBJs0bG7rppC BQgUKjQvUAU+VYwB0+geKEeUsnIh7Wz3rBcKjHKEjk91b8fe4cqEYZKq1n9pF+pNiL7UoJa8KXn4 sn+dFYyhg5Gz1L/L6BSEif/CuzrWwpLriDY4ncQzCBBgzrfeFU6nXHBG6B4c1q0nF0x0WbC2Rr0gg BoCvQg8rgQAAAMAuEm4Nh8t/InPPO8F1OkCHC/2sfK8l+8L79RxcJyX3Pg3aMy54UcVJj9Y2LFl3 8ZsL9bXji19sFhdKgt9lSqp9wGd/bos9v151rUGRAR0Ze9NfOieyNk6PXLaXT2fm1EQrQGtzRVvaeY y+wDAUrIFpTtZ2GXYPlG/OlMh/orHlt4vQO4jxx2jr4e6bm68XuXorThFRbgcQoIsPuGcQl8uOrLtFR O5O2LPNVn1tyo3SbxFJaG6H4klVT4AFVIgoyxsAAADBAPiJwF9jz+xwis4g4GMMBH+tBBLbolnaxn 7UQmx0LZYzpNgswMAcX7sBPZmQ3WXaSXXuq6VH9Wrw7+6izoVdQxebUT7m/pmV814qAVis/ 2b4UrtYabnI5HF5b7k24L2jNZTf4k7mZRts8JPRkk53uExW+iX1IGMghMEkU8zHciCwZkg6r6/55Ld B7n3cOpATwqhv7CrfJ53smvVkNGdEleA71VwpGq7ouz7JjkC/M+ou2RV76kwMo8qjd0zef7O5uw AAAMEA9Rz9jtQrnyPfSw6FKQrRjkMGeu+T8iHThno+xc+Nby/bMkXDFbJQpAXwBxIBLkbl/oLIzH mHNnTuxiDxxsWGGK6wT9hR1T/YOw5Ztcz4SZvGPesroKmRuYuBU9XOzEXZ8Wz3kjE3cqWIhf+u Rm4RCEfUGahl0nxrkXjAMO/tujH15ixuOO6nSRxrrUtutGVBnWubJrKzHD/ncShAOA0FDKwYE0F7 okwbOsnWFkbBSdWXq5DH1sAO31uTUS020uCNAAAAFWdha3VAR05BS0FNVVItSkpYSExOMwE CAwQF-----END OPENSSH PRIVATE KEY----- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDt9/pXInhPhhvuMGcDHafyvg 5JpVGf6RcmTfEKLfS3vpxtcsk6R37G4d1B7qoyLz0WPwteKr7Q78ElEuq+I voI3FUkYSK4cll5lJbhu3aOP3NG3r/QfU07UyAzvbe/3agNXU74VXEY49E V2znS0pubVAr7Say1xx+WlPZg02HFDRNr7ARgDroHhql4I+MVMtbtAjwTI nkMmLQyGtSZTAlfSb9U91WmyhuFkfgmCXmeMn9AAeFqmPJuALk0z8S hdfd+Da4x93MWoMxfzxaKFZfhbvFw1pO20hvIDHQYlT+tqB5zaP31xTHG iROBX3w0+ktkkIZVsi3q20Alvqw2+EayUThFErfSbjb/mbZHYa8XwJooAXX ldIm+LR7y5buKrocxO3lLci62+dWYLTuUr2b+LonzWrm9LYxa1vVsNKYKM gtnszIHFO0mS5UjB/655lEjGqzBniPHW4eMofXjLJDfcDCaFi0QGKbpHGh MtkbTai3aMuVzZuxa2SmBxGXm6/8= gaku@GNAKAMUR-JJXHLN3 9 Copyright © 2023, Oracle and/or its affiliates
10. デジタル署名とその検証 Copyright © 2023, Oracle and/or its affiliates 10 署名対象の内容 署名アルゴリズム デジタル署名 デジタル署名 秘密鍵を署名鍵として用い、デジタル署名アルゴリズムを使い、ある内容に対してのデジタル署名を生成する デジタル署名の検証 公開鍵を検証鍵として用い、署名された（はずの）内容とともに検証アルゴリズムにかけるとデジタル署名を検証できる 署名鍵＝秘密鍵 IN OUT 署名対象の内容 検証鍵＝公開鍵 検証アルゴリズム 検証結果 （OK or NG） OUT IN デジタル署名 IN IN IN
11. デジタル署名とその検証の仕組みの利用 11 Copyright © 2023, Oracle and/or its affiliates Alice Bob • 送信者から受信者に対してメッセージを送る際に、メッセージ内容（のハッシュ値）に対しての送信者のデジタル署名を セットで送信する • 受信者は送信者の公開鍵を用いたデジタル署名の検証によって、確かに送信者からのものであること、メッセージ内容 が経路上で改ざんされていないことを確認できる メッセージ内容 ↑に対する Aliceの署名 • 直接の受信者以外も、（送信者の公開鍵にアクセス可能であれば）デジタル署名を検証することで 後からでもメッセージの真正性を確認できる Bob Aliceがこんなこと 言ってるんですよ Charlie Aliceの署名が正しいから 本当だな… デジタル署名できる秘密鍵を 持っているのはAliceだけなので 確かにAliceからのメッセージだな Aliceの 公開鍵 Aliceの 公開鍵
12. 参考：ハッシュ値 • ハッシュ値：元になるデータから一定の計算手順（→ハッシュアルゴリズム）により求められた固定長の値 • データが同一で、用いるハッシュアルゴリズムが同一であれば、同一のハッシュ値が出力される • 弱衝突耐性、強衝突耐性を持ち、元データの同一性の確認のために用いられる • 弱衝突耐性：あるハッシュ値を出力する元のデータを狙って作ることが（実践的には不可能なほど）困難 • 強衝突耐性：別々の元データから出力したハッシュ値が同一になることが（実践的には無視できるほど）稀 • ハッシュ値自体は意味のない文字列であり、かつ、ハッシュ値から元のデータへの復元はできない 12 Copyright © 2023, Oracle and/or its affiliates 75867688ec572fbb9121f1ef8bd63044 5446e83fb59625d8018f292045ab009d 67e0623844433a34fbb8ee2caf3a1559 元データ ハッシュ アルゴリズム ハッシュ値
13. Copyright © 2023, Oracle and/or its affiliates 13 デジタルアイデンティティの発展とSSI
14. 各サービスプロバイダで個別にIDを管理する方式 • ユーザーが多数のサービスのIDとパスワードを管理する ことになる • 覚えきれない • パスワードの使い回しにつながりがち→セキュリティの 低下 • いちいちログインするのが面倒 • 情報が分断されている • 同じ情報をサービスの登録のたびに何回も記入し なければならない デジタルアイデンティティの発展：Isolated Identity Copyright © 2023, Oracle and/or its affiliates 14 サービスプロバイダ1 サービス1 ID1/PW データ1 ID1/PW ID1/PW データ1 データ1 サービスプロバイダ2 サービス2 ID1/PW データ1 ID1/PW ID2/PW データ1 データ2 サービスプロバイダ3 サービス3 ID1/PW データ1 ID1/PW ID3/PW データ1 データ1 ID1で ログイン ID2で ログイン ID3で ログイン エンド ユーザー
15. アイデンティティプロバイダ（IdP）の提供するIDで複数サービスを利用する方式 • ユーザーは少数のIDとパスワードを管理するだけで良い • ログインが楽 • ひとつのIdPのセキュリティ侵害が多数のサービスでの不 正利用につながる • IdPがSPoF（単一障害点）で可用性が低い • IdPと各サービスのコンテクストが密結合 • IdPの利用をやめると各サービスでのコンテクストを 失う • IdPに情報が貯まっていく デジタルアイデンティティの発展：Centralized Identity Copyright © 2023, Oracle and/or its affiliates 15 アイデンティティプロバイダ1 サービスプロバイダ2 サービス2 データ1 データ1 データ2 サービスプロバイダ3 サービス3 データ1 データ1 データ3 ID1で ログイン 暗黙的に ID1で ログイン 暗黙的に ID1で ログイン エンド ユーザー ID1/PW ID1/PW ID1/PW SSO
16. サービス側でも個別にIDを管理しつつIdPのIDにリンク（フェデレーション、連合） • ユーザーはサービス内のIDにIdPのIDをリンクできる • 別のIdPのIDにスイッチが可能 • ひとつのIdPのセキュリティ侵害による不正ログイン被害 範囲が大きいのは変わらず • IdPへの信頼が必要なのは変わらず • IdPに蓄積されるプロファイルが増えている • ユーザーは自身のプライバシーを コントロールできているか確認できない デジタルアイデンティティの発展：Federated Identity Copyright © 2023, Oracle and/or its affiliates 16 サービスプロバイダ2 サービス2 ID1/PW データ1 ID1/PW サービス2ID データ1 データ2 サービスプロバイダ3 サービス3 ID1/PW データ1 ID1/PW サービス3ID データ1 データ1 ID1で ログイン IDxで ログイン IDxで ログイン エンド ユーザー アイデンティティプロバイダ1 ID1/PW ID1/PW ID1/PW アイデンティティプロバイダ2 ID1/PW ID1/PW ID2/PW ID2で ログイン
17. Federated Identityからユーザー側のコントローラビリティを向上 • アイデンティティのコントロールをエンドユーザー側に引き戻すべき、という潮流 • 同意の適切な取得、アクセス許可範囲の制御 • OpenID、OpenID Connect、Oauth、FIDOなどなど • 今日のFederated IdentityにはUser-Centricな改善が取り込まれている • 理想的にはIdPをエンドユーザーが自前で運用する • OIDC SIOP（Self-Issued OpenID Provider） • あんまり流行ってない？：ユーザー側のコスト vs メリット • エンドユーザー、サービサー両方にとっての技術的な難しさなどから結局IdP頼みの実装、運用になりがち • IdPに頼っている限りIdPへの信頼が必要 • IdPへのアクセシビリティ問題は継続 User-Centric Identity Copyright © 2023, Oracle and/or its affiliates 17
18. プライバシー問題： • IdPにプロファイルが蓄積しすぎ、サービサー側でも結託すれば名寄せできる • サービサーでの目的外利用や、IdPが不正にユーザーのプロファイル情報を売買していたり… アクセシビリティ問題： • デジタルアイデンティティやプロファイル情報を預かるIdPや個々のサービサーの重要性が大きくなりすぎ • IdP、サービサーの廃業や規約変更でID、プロファイルの利用を停止されてしまう可能性 • IdPに障害が発生すると様々なサービスが利用不能になる セキュリティ問題： • 認証情報、プロファイル情報の管理コストの増大←リスクの増大←攻撃の増加 • 厳格なKYCの必要なサービスのプロファイル確認は結局サービサー個別にやることになる • 本人確認書類など機微／重大な情報をサービサー個別で管理 • 扱う情報の重要性＝セキュリティやプライバシー上のリスクと管理能力が釣り合わない • 情報漏えいや不正利用などの事故、事件の頻発 従来型デジタルアイデンティティのなにが問題なのか？ Copyright © 2023, Oracle and/or its affiliates 18
19. • プライバシー保護の規制の拡大の結果、サービサー間の「適切な」情報共有もやりづらい • 規制に適合しつつサービサー間でデータを共有するのはますます難しくなっている • 適切にユーザーからの同意を得るコストが増大 • 不適切な共有が発覚したときのリスクも増大 • サービス間の情報共有の不足がユーザーから見ての利便性を大きく損なっている場面も • わかりやすい例：名前と住所と電話番号を何度も何度も記入／入力して提出… • わかりやすい例2：引っ越しのときの不動産屋、役所、警察、保険会社、電話会社、etc... • デジタル・アイデンティティに関する仕組みの未成熟により、データ共有で実現できるはずのよりスムーズで高度なサー ビスの可能性が阻害されている • 一方で、規制はユーザー側に自身のデータの共有／流通を管理する力がないことの裏返しでもある 規制の拡大と利便性のバランスの課題 Copyright © 2023, Oracle and/or its affiliates 19
20. 前記のような従来型デジタルアイデンティティの課題 →SSI（Self-Sovereign Identity）というパラダイムの登場 • 2012年にDevon Loffretoが提唱、2016年にChristopher Allenが「SSIの10原則」を整理 SSIの根本の発想 • 個人は自身のアイデンティティに関しての確立した権利を生まれながらに持っている • IdPにアイデンティティの管理の起点を明け渡していることがそもそもの間違い • 「IdPやサービサーがちゃんとやってくれている／やり続けてくれることを信じるしかない」状況につながっている • 個人の側にアイデンティティ管理の主権を取り戻す ※もともとのSSI理念のスコープはデジタルアイデンティティだけでなく国家によるアイデンティティ管理（戸籍など）にも及んでいるが、ここでは取り扱わない Self Sovereign Identity（自己主権型アイデンティティ）の登場 Copyright © 2023, Oracle and/or its affiliates 20
21. SSIの12原則 Sovereign Foundationでは SSIの備えているべき12の原則を定義 21 Copyright © 2023, Oracle and/or its affiliates https://sovrin.org/principles-of-ssi/
22. SSIの12原則 日本語版 1. 代理証明 自己主権IDのエコシステムは実在する存在に対し人間的、法的、自然的、物理的、 もしくはデジタルによって実現するデジタル上での識別子の数で証明できる環境を提供 します。 2. 相互互換性 自己主権IDのエコシステムは実在する存在に対してデジタルIDデータを証明、交換、 安全、保護、そしてデータ互換性の確認を前提としてオープンで公共な手数料が無い 環境を提供します。 3. 分散性 自己主権IDのエコシステムは中央集権型のシステムに依存する事なく、管理、もしくは 実在する存在の確認をデジタルIDに記録されたデータを下に行う事ができる環境を提 供します。 4. 管理とエージェンシー 自己主権IDのエコシステムは自然、人間、もしくは法的なアイデンティティと関連がある （アイデンティティ所有者） 実在する存在がデジタルIDデータと選択によって個人や組 織、デバイスやソフトウェアなどのエージェントの採用、データ保護管理を実施できる環 境を提供します。 5. 参加 自己主権IDのエコシステムはアイデンティティ所有者の参加を必要としない環境を提供 します。 6. 公正と包括 自己主権IDのエコシステムはガバナンス設計に置いてアイデンティティ所有者によって差 別、排除を行わない環境を提供します。 7. 利便性、アクセス性、一貫性 自己主権IDのエコシステムは利便性とエージェントのアクセス性を最大化し、他アイデン ティティ所有者の自己主権IDとの一貫した利用者体験を実現できる環境を提供しま す。 8. 可搬性 自己主権IDのエコシステムはアイデンティティ所有者によるアイデンティティの携帯、もし くはエージェント、システムにより選択されたアイデンディティデータのコピーの移行を制限 する事はありません。 9. 安全性 自己主権IDのエコシステムはアイデンティティ所有者が自身のデジタルIDデータを暗号 鍵や取引のエンドツーエンド暗号化を通じて安全に管理できる環境を提供します。 10. 確認と認証 自己主権IDのエコシステムはアイデンティティ所有者がデジタルIDデータを下に、認証に 必要な確認証明を発行できる環境を提供します。 11. プライバシーと公開の最小化 自己主権IDのエコシステムはアイデンティティ所有者がデジタルIDのプライバシーと取引 に必要なデジタルIDデータの最小化を実現できる環境を提供します。 12. 透明性 自己主権IDのエコシステムはアイデンティティ所有者と全てのステークホルダーが簡易に アクセス、情報の確認ができ、インセンティブやルール、ポリシー、アルゴリズムなどエコシス テム内で機能する内容を知る事ができる環境を提供します。 22 Copyright © 2023, Oracle and/or its affiliates 出典：https://sovrin.org/wp-content/uploads/Principles-of-SSI-V1.01-Japanese-v01.pdf
23. SSIの思想≒べき論 • IdPやサービサーに依存しない、権力が集中しない • ある仕組みにロックインされたりせず、別の仕組みにアイデンティティを持ち出せる • 仕組みは中央集権的（Centralized）なものではなく、分散／分権（Decentralized）されたものである • 自分の情報は自身でコントロールする • 自分以外の都合でプロファイルが消失しない • 都度、必要最小限の情報を提示できる • 自身に関する情報がどう利用されているかを確認できる • 安全で便利に使える • 常に利用できる • 利用者自身が安全に管理できる • どの仕組みを選ぼうとさまざまなサービスが便利に使えるように、仕組み同士は相互に互換性がある 23 Copyright © 2023, Oracle and/or its affiliates
24. Copyright © 2023, Oracle and/or its affiliates 24 DID & VCの仕組み
25. DID、VCの考案（2016年～）： • DID：Decentralized Identifier（分散型識別子） • VC：Verifiable Credential（検証可能な資格情報） →それぞれの仕様の策定、規格化がいくつかの団体によって進められている状況 • 主だったところ：W3C、Sovrin、DIF、Open ID Foundation • 規格間の相互運用性も意識（どれを使っても同じように便利に使える＝自由に選べる、が理想） ※Decentralized Identity（分散型アイデンティティ）を指してDIDと呼ぶこともある（が、ここでは採用しない） …Decentralized IdentifierとVerifiable Credentialを利用したアイデンティティの仕組み（エコシステム）総体の呼び方 DID＆VCの登場 Copyright © 2023, Oracle and/or its affiliates 25
26. DID（Decentralized Identifier） • 規格として識別子の形式および発行、登録、公開、検証などの運用方法が規定されている • DIDに関する規格、および実装（DID Methodと呼ばれる）は複数あるが、識別子の形式は共通の規格がある • DIDの具体的な例： • did:ion:EiCjHFpU1Fm6Qnq7XIj_Gt2QGCpnwQrrnUWoVrM4H9we1A • did:sov:WRfXPg8dantKVubE3HX8pw • DID Methodの例…それぞれ別々のレジストリにDIDが登録されている • ION…パブリックのBitcoinブロックチェーンをレジストリとして利用 • Sovrin…コンソーシアムのHyperledger Indyをレジストリとして利用 • Ethr…パブリックのEthereumブロックチェーンをレジストリとして利用 26 Copyright © 2023, Oracle and/or its affiliates
27. DIDの取得（生成と登録） DIDのセットアップはアイデンティティの所有者が自身で行う（⇔ IdPに発行してもらう） 1. ウォレットを用意 2. キーペア（秘密鍵／公開鍵）を生成 3. DIDを生成 4. レジストリにDID Documentを登録 • DIDと公開鍵が含まれる 27 Copyright © 2023, Oracle and/or its affiliates Wallet レジストリ DID Document 秘密鍵 DID 公開鍵 { "id": "did:example:123456789abcdefghi", "authentication": [{ "id": "did:example:123456789abcdefghi#keys-1", "type": "Ed25519VerificationKey2018", "controller": "did:example:123456789abcdefghi", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" }] } 登録 Holder アイデンティティの 所有者 DID Documentの例 ！！個人のプロファイル情報は含まれない！！
28. DIDの認証 1. Holder（DIDとVCの所有者）がVerifier（資格情報を要求し、検証する者）に対して、DIDの認証をリクエスト 2. Verifierがランダムに生成したチャレンジコードをHolderに送り、デジタル署名を要求 3. Holderはチャレンジコードに対して自身の持つ秘密鍵でデジタル署名して返却 4. VerifierはDIDに対応するDID Documentに含まれる公開鍵を使い、デジタル署名を検証することで認証 28 Copyright © 2023, Oracle and/or its affiliates Wallet 秘密鍵 Holder わたしはdid:aaa:hogehogeです 本当にhogehogeなら チャレンジコード:XXXXXX…に署名してみてよ 署名したらxxxxxx…になりました hogehogeの公開鍵はこれだな 検証してみよう →署名が合ってるから本物だな or署名が合わないから偽物だな Verifier
29. 理解しておきたいポイント：レジストリの基盤と運用 • レジストリは誰かが運用しなければ存続しないが、そのコストを誰がどのように負担するかは実践上の課題 • パブリックブロックチェーンであれば、DID Documentを登録するときにトランザクション手数料（GAS代）を支払う • コンソーシアム型ブロックチェーンでは運用者が負担する？DID利用者から利用料を徴収する？ • レジストリにブロックチェーン（分散台帳）を用いることは仕様上必須ではない …DIDの”Decentralized”はレジストリにブロックチェーンを用いることを必ずしも要求してはいない • レジストリには常にアクセスでき、DID/VCが用いられる期間は存続し、都合よく削除改変されないことが期待され るため、ブロックチェーンの特性が有利に働く 29 Copyright © 2023, Oracle and/or its affiliates パブリック ブロックチェーン上の レジストリ コンソーシアム型 ブロックチェーン上の レジストリ 単一組織の データベース上の レジストリ
30. VC（Verifiable Credential） • あるデジタルアイデンティティについての情報の「検証可能なデジタ ル証明書」をVerifiable Credentialとして表現できる • ヒトの例：身分証、免許、学歴、職歴、試験のスコア • モノの例：品質鑑定結果、車検証、メンテナンス履歴 • 規格として証明書の形式および発行、保持、提示、検証などの 運用方法が規定されている • 以下のような項目を持つ • 誰が発行したのか（issuer） • 誰／何についてのどのような情報か（subject） • 誰／何：HolderのDID • どのような：資格情報の内容 • 発行者のデジタル署名 • 署名検証用の公開鍵の所在 30 Copyright © 2023, Oracle and/or its affiliates { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "http://example.edu/credentials/3732", "type": [ "VerifiableCredential", "UniversityDegreeCredential" ], "issuer": { "id": "did:example:76e12ec712ebc6f1c221ebfeb1f", "name": "Example University" }, "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "Ed25519Signature2020", "created": "2022-02-25T14:58:43Z", "verificationMethod": "did:example:76e12ec712ebc6f1c221ebfeb1f#key-1", "proofPurpose": "assertionMethod", "proofValue": "z2Xdmp6YDYz5RPKeRFDcPYorAmnERyr7aRNzv176oLMxwcW7GgKxAQT 45jUKwsMA1XvrmFT5Y8WCx7ZnkNTTHJnu9" } } Verifiable Credentialの例
31. VCの発行と保管 前提 • Issuer（VCの発行者）は自身のDIDを取得（DID Documentをレジストリに登録）しておく • 後のVCの検証にIssuer公開鍵が必要になるため • なお、公開鍵をDIDではないかたち（Webサイト等） で公開しておくやり方も取り得る • HolderのDIDは認証済 VCの発行プロセス 1. HolderがIssuerに対して自身のDIDに対してのVC発行を リクエストし、IssuerとHolderとの間で必要な確認プロセス （資格情報の内容によって様々）を実施 • 例：大学に出向いて本人確認の上で学位証明の VCをリクエスト 2. IssuerがHolderに対して自身の秘密鍵でデジタル署名し たVCを送付 3. HolderはVCを自身のウォレットに保管 31 Copyright © 2023, Oracle and/or its affiliates レジストリ HolderのDID Document DID 公開鍵 IssuerのDID Document DID 公開鍵 Holder Issuer Wallet 秘密鍵 Wallet 秘密鍵 VC ①VCリクエストと 必要な確認 ②Issuerが秘密鍵で 署名してVC送付 VC ③Holderが VCを保管 HolderとIssuerのDID Method（＝レジストリ）は 別でも良い！！
32. VCの提示と検証 （前提：HolderのDIDは認証済） 1. HolderはVerifierに対してVCを提示 2. VerifierはVCに示されるIssuerの公開鍵を使ってVC（のIssuerのデジタル署名）を検証したうえで、 VCに記載の資格情報の内容を受け入れ • ここでVerifierからIssuerへの問い合わせが生じない（HolderはIssuerに対してVerifierの提供するサービスを利用し ていることを知られない）で資格情報の検証が行えている点は重要なポイント…プライバシー、アクセシビリティ 32 Copyright © 2023, Oracle and/or its affiliates VC Holder Verifier レジストリ HolderのDID Document DID 公開鍵 IssuerのDID Document DID 公開鍵 Wallet 秘密鍵 VC VCの提示 Issuer署名の 検証
33. DID/VCまとめの図 Copyright © 2023, Oracle and/or its affiliates 33 Holder Wallet 秘密鍵 VC Issuer Wallet 秘密鍵 ブロックチェーンなどで 実装されたレジストリ HolderのDID Document DID 公開鍵 IssuerのDID Document DID 公開鍵 Verifier VCの提示 DIDで認証 DIDで認証 VCの発行 DID Documentを登録 DID Documentを登録 DIDの署名検証の ために参照 VCの署名検証の ために参照 DIDの署名検証の ために参照 サービス等の提供 ヒト／モノ DIDs VCs 1 n 1 n
34. VP（Verifiable Presentation） • Holder側での以下の（いずれかまたは両方の）操作によりVCからVP（Verifiable Presentation）を作成し、 Verifierに対してVCを直接するのではなくVPを提示することもできる • ひとつのVCに含まれる複数の資格情報の項目から提示する項目を取捨選択して抽出（→選択的開示） • 複数のVCから資格情報をまとめて抽出 • VPに対応するためには、VCが特定の形式（SD-JWT、BBS+など）でデジタル署名されている必要がある ※VCの標準によってはVerifiable Presentationの仕組みがないものもあるかも 34 Copyright © 2023, Oracle and/or its affiliates 元のVC（運転免許証） 選択的開示の例： 年齢確認のため免許証VCから生年月日のみをVPとして開示 氏名：鈴木 太郎 住所：千代田区1-2-3 生年月日：1999/10/1 種類：中型 etc. Holder 提示するVP 生年月日：1999/10/1 署名（SD-JWT） 署名（SD-JWT） VPを作成 Verifier VPの提示
35. 理解しておきたいポイント：Issuerの信頼性の判断 • VerifierはVCの内容自体はIssuerのデジタル署名により検証可能だが、そのIssuerが信頼に足るかどうかはVCを見 ていても判断がつかない • 不正の例：それっぽい名前でIssuerのDID Documentを適当に登録して都合の良いVCを濫造 35 Copyright © 2023, Oracle and/or its affiliates Issuer：did:aaa:jpgovernment subject: “hogehogeは弁護士です” sign: xxxxxxxx Verifier 署名検証はOKだけど、そもそも このIssuerは信頼できるのか…？ Holder VCの提示 ホワイトリストとのIssuerの照合や、 Webサイトなどを参照して 信頼性を判断することになりそう
36. Copyright © 2023, Oracle and/or its affiliates 36 DID & VCのメリット、課題など
37. W3CによるVCのユースケース領域の例 37 Copyright © 2023, Oracle and/or its affiliates 図：w3c, Verifiable Credentials Use Cases https://www.w3.org/TR/vc-use-cases/ ヒトの DID/VC モノの DID/VC
38. ヒトのDID/VCのメリット① プライバシー • デジタルアイデンティティの持ち主であるDID所有者（Holder）は、自身に関する情報の取得、および開示が自身で コントロール可能になる • 紙の証書を自分で保管しておいて自分の意志で見せる、と同じようなモデル • VCは偽造などの不正を排除しやすい、VPで開示する情報を絞れるという紙では難しいメリットも • DIDはひとりで何個保持しても良く、プロファイルを使い分けられる • 複数DIDを使い分けることで、IssuerやVerifierによる名寄せもある程度避けられる • 利用してきたDIDと自身を切り離すこともできる • 「法的な身分に紐づかないが他者から信頼可能」なデジタルアイデンティティを育てていける可能性もある アクセシビリティ、ポータビリティ • DIDはIdPおよび権威（国、政府、公的機関など）に依存しない • IdPの廃業やアカウント利用停止、権威の消滅や意向（差別、排除）により利用不能にならず、いつでも、望む 限り使えるデジタルアイデンティティを手に入れられる • VCの検証可能性がIssuerの存続可能性に依存しない（Issuer組織が消滅してもVCは検証可能） 38 Copyright © 2023, Oracle and/or its affiliates
39. ヒトのDID/VCのメリット② （いずれもDID/VCや周辺エコシステムが整備され、広く利用されるようになっていることを前提に） 情報を取得、確認するプロセスのスムーズ化、コストの低下 • サービスごとに紙の用紙の記入、Webフォームの記入→VCを提示 • 検証可能性により不正防止のコストは低下 • 重要な証明情報のデジタル化 個人情報を扱うコスト、リスクの低減 • 余分な個人情報を扱わなくて済む部分が出てくる • Issuerは発行したVCの情報を自身で持っていなくて良い→個人情報の保管が必須でなくなる • サービス提供者（Verifier）は余計な個人情報を受け取らずに必要な確認ができる （例：「20歳以上である」ことだけをVCで提示してもらう） • 個人情報の提示についての本人の同意の確認がしやすい 39 Copyright © 2023, Oracle and/or its affiliates
40. モノのDID/VC？ モノを中心とした情報の管理 • 「モノ自体に紐づいた偽れない証明書」としてのユースケースが 想定されている • 製造過程での各パーツへの、各プロセスでの情報付与 • オーナーが代わっても残る、製品のライフサイクルに渡る履 歴情報の記録 • メーカー側に共有されない作りにもできる …オーナーのプライバシーや選択の自由にも対応できる • ヒトと異なり、モノと秘密鍵、DIDの不可分の結びつきは比較 的容易に実装できる 自律的なスマート◦◦のアイデンティティ • 自動、自律的に動くモノの契約／支払のためのアイデンティ ティや資格情報として 40 Copyright © 2023, Oracle and/or its affiliates 製造 販売 ・ リース 使用 点検 ・ 修理 廃棄 リユース リサイクル 二次流通
41. Copyright © 2023, Oracle and/or its affiliates 41 ユースケースの例
42. ヒトのDID/VC：就職や進学時の学歴、職歴、資格などの証明 • 予めVCを発行しておけばすぐ提示できる • 従来の確認プロセスのように数日～数週 間待たされない • コストも提示の都度発生しない • Issuerにプライバシーリークしない • 転職意思、転職しようとしている先が現職 にバレない • 偽装を防止しやすい • 紙の資格証はしばしば偽装が発生 • 発行機関が消滅しても有効 （IssuerのDIDの有効性が確認できる限りに おいて） 42 Copyright © 2023, Oracle and/or its affiliates Holder Verifier Issuer 就職先 進学先 高等教育機関、 以前の就職先、 資格発行機関 学歴VC 発行 資格VC 職歴VC 提示
43. モノのDID：MOBI VID（Vehicle ID） MOBIの提案する車両DID/VCであるところのVIDでは、 以下のようなユースケースが主として想定されている 参照：https://dlt.mobi/wp-content/uploads/2021/02/MOBI-VID0002- Use-Case-2021.pdf • 車両登録 • メンテナンスのトレーサビリティ • パーツ交換のトレーサビリティ • マシンからマシンへの支払い • 事故のトレーサビリティ • 保険 • 所有者と資格情報 • 車検 • 走行距離不正の防止 • 廃車のトレーサビリティ 43 Copyright © 2023, Oracle and/or its affiliates 図：MOBI VID White Paperより引用 https://dlt.mobi/wp-content/uploads/2022/06/MOBI- VID0001WP2021-Version-2.0-1.pdf
44. その他の参考情報 • ソフトバンク：DID/VCを用いた自己主権型アイデンティティの実現 https://speakerdeck.com/sbtechnight/vcwoyong-itazi-ji-zhu-quan-xing-aidenteiteinoshi-xian • 野村総合研究所＆NRIセキュアテクノロジーズ：ブロックチェーン技術等を用いたデジタルアイデンティティ の活用に関 する研究 https://www.fsa.go.jp/policy/bgin/ResearchPaper_NRI_ja.pdf • W3C：Decentralized Identifiers (DIDs) https://www.w3.org/TR/did-core/ • W3C：Verifiable Credentials Data Model https://www.w3.org/TR/vc-data-model/ 44 Copyright © 2023, Oracle and/or its affiliates
45. Thank you Copyright © 2023, Oracle and/or its affiliates 45
46. Copyright © 2023, Oracle and/or its affiliates