Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

gakumura

July 12, 2023
Tweet

More Decks by gakumura

Other Decks in Technology

Transcript

  1. SSI/DID/VCとは?
    概念と仕組みの基本
    Blockchain GIG #15
    中村 岳
    日本オラクル株式会社
    クラウド事業統括/クラウド・エンジニアリング統括/CoE本部/ソリューションアーキテクト部
    2023/7/12

    View Slide

  2. Copyright © 2023, Oracle and/or its affiliates
    2
    中村 岳
    Twitter @gakumura
    はてなブログ @gakumura
    …主にHyperledger Fabric関連
    • 現職:ソリューションエンジニア@日本オラクル
    • 担当:Oracle Blockchain Platform、
    Blockchain Table
    • 前職:金融決済系SIerでパッケージ開発
    • SWIFT、CLS、日銀ネット関連の銀行間決済システム

    View Slide

  3. 内容
    • DID/VC理解の前提となる要素を説明:
    • ブロックチェーン
    • 秘密鍵/公開鍵とデジタル署名
    • SSIの概要:
    • デジタルアイデンティティの発展と課題
    • SSIの思想と登場背景
    • DID/VC
    • DID/VCの仕組み
    • DID/VC(Verifiable Credentials)のメリット
    • ユースケースの例
    Copyright © 2023, Oracle and/or its affiliates
    3

    View Slide

  4. Copyright © 2023, Oracle and/or its affiliates
    4
    DID/VC理解の前提となる要素:
    ブロックチェーン

    View Slide

  5. DID/VCの文脈でブロックチェーンについて理解しておきたいこと
    • データとロジックを保持するノードを複数の組織や個人が分散して管理、運用していること…Decentralized、分権
    • 全員が運用をやめない限り、データはアクセス可能なまま…アクセシビリティ
    • マジョリティ~全員が一致(結託)しない限り、ユーザーが排除、差別されない
    • 書き込まれたデータは不変の記録として残る
    • マジョリティ~全員が一致(結託)しない限り、記録を勝手に改変されたりしない…耐改ざん性
    5 Copyright © 2023, Oracle and/or its affiliates

    View Slide

  6. ブロックチェーンの利用形態(ネットワーク)の分類
    Copyright © 2023, Oracle and/or its affiliates
    パブリック
    公開制のネットワークを
    不特定多数で運用
    コンソーシアム
    許可制のネットワークを
    複数組織で運用
    プライベート
    許可制のネットワークを
    単一組織で運用
    パーミッションレス← →パーミッションド
    6
    6

    View Slide

  7. Copyright © 2023, Oracle and/or its affiliates
    7
    DID/VC理解の前提となる要素:
    秘密鍵/公開鍵とデジタル署名

    View Slide

  8. 秘密鍵/公開鍵 (※一部正確性よりもわかりやすさを優先)
    • 秘密鍵/公開鍵はペアで生成される
    • 秘密鍵は誰にも渡さず自身で管理する
    • 公開鍵は直接渡すか公開するかして相手が利用できるようにしておく
    8 Copyright © 2023, Oracle and/or its affiliates
    Alice
    秘密鍵/公開鍵ペア
    生成
    Alice Bob
    私の公開鍵です
    了解、保存しときます
    Alice
    Alice
    Bobがアクセスできる
    公開鍵置き場に登録
    Bob
    Aliceの公開鍵は
    あそこにあるな
    直接渡すパターン 公開するパターン

    View Slide

  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= [email protected]
    9 Copyright © 2023, Oracle and/or its affiliates

    View Slide

  10. デジタル署名とその検証
    Copyright © 2023, Oracle and/or its affiliates
    10
    署名対象の内容
    署名アルゴリズム デジタル署名
    デジタル署名
    秘密鍵を署名鍵として用い、デジタル署名アルゴリズムを使い、ある内容に対してのデジタル署名を生成する
    デジタル署名の検証
    公開鍵を検証鍵として用い、署名された(はずの)内容とともに検証アルゴリズムにかけるとデジタル署名を検証できる
    署名鍵=秘密鍵
    IN
    OUT
    署名対象の内容
    検証鍵=公開鍵
    検証アルゴリズム
    検証結果
    (OK or NG)
    OUT
    IN
    デジタル署名
    IN
    IN
    IN

    View Slide

  11. デジタル署名とその検証の仕組みの利用
    11 Copyright © 2023, Oracle and/or its affiliates
    Alice Bob
    • 送信者から受信者に対してメッセージを送る際に、メッセージ内容(のハッシュ値)に対しての送信者のデジタル署名を
    セットで送信する
    • 受信者は送信者の公開鍵を用いたデジタル署名の検証によって、確かに送信者からのものであること、メッセージ内容
    が経路上で改ざんされていないことを確認できる
    メッセージ内容
    ↑に対する
    Aliceの署名
    • 直接の受信者以外も、(送信者の公開鍵にアクセス可能であれば)デジタル署名を検証することで
    後からでもメッセージの真正性を確認できる
    Bob
    Aliceがこんなこと
    言ってるんですよ Charlie
    Aliceの署名が正しいから
    本当だな…
    デジタル署名できる秘密鍵を
    持っているのはAliceだけなので
    確かにAliceからのメッセージだな
    Aliceの
    公開鍵
    Aliceの
    公開鍵

    View Slide

  12. 参考:ハッシュ値
    • ハッシュ値:元になるデータから一定の計算手順(→ハッシュアルゴリズム)により求められた固定長の値
    • データが同一で、用いるハッシュアルゴリズムが同一であれば、同一のハッシュ値が出力される
    • 弱衝突耐性、強衝突耐性を持ち、元データの同一性の確認のために用いられる
    • 弱衝突耐性:あるハッシュ値を出力する元のデータを狙って作ることが(実践的には不可能なほど)困難
    • 強衝突耐性:別々の元データから出力したハッシュ値が同一になることが(実践的には無視できるほど)稀
    • ハッシュ値自体は意味のない文字列であり、かつ、ハッシュ値から元のデータへの復元はできない
    12 Copyright © 2023, Oracle and/or its affiliates
    75867688ec572fbb9121f1ef8bd63044
    5446e83fb59625d8018f292045ab009d
    67e0623844433a34fbb8ee2caf3a1559
    元データ
    ハッシュ
    アルゴリズム
    ハッシュ値

    View Slide

  13. Copyright © 2023, Oracle and/or its affiliates
    13
    デジタルアイデンティティの発展とSSI

    View Slide

  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で
    ログイン
    エンド
    ユーザー

    View Slide

  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

    View Slide

  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で
    ログイン

    View Slide

  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

    View Slide

  18. プライバシー問題:
    • IdPにプロファイルが蓄積しすぎ、サービサー側でも結託すれば名寄せできる
    • サービサーでの目的外利用や、IdPが不正にユーザーのプロファイル情報を売買していたり…
    アクセシビリティ問題:
    • デジタルアイデンティティやプロファイル情報を預かるIdPや個々のサービサーの重要性が大きくなりすぎ
    • IdP、サービサーの廃業や規約変更でID、プロファイルの利用を停止されてしまう可能性
    • IdPに障害が発生すると様々なサービスが利用不能になる
    セキュリティ問題:
    • 認証情報、プロファイル情報の管理コストの増大←リスクの増大←攻撃の増加
    • 厳格なKYCの必要なサービスのプロファイル確認は結局サービサー個別にやることになる
    • 本人確認書類など機微/重大な情報をサービサー個別で管理
    • 扱う情報の重要性=セキュリティやプライバシー上のリスクと管理能力が釣り合わない
    • 情報漏えいや不正利用などの事故、事件の頻発
    従来型デジタルアイデンティティのなにが問題なのか?
    Copyright © 2023, Oracle and/or its affiliates
    18

    View Slide

  19. • プライバシー保護の規制の拡大の結果、サービサー間の「適切な」情報共有もやりづらい
    • 規制に適合しつつサービサー間でデータを共有するのはますます難しくなっている
    • 適切にユーザーからの同意を得るコストが増大
    • 不適切な共有が発覚したときのリスクも増大
    • サービス間の情報共有の不足がユーザーから見ての利便性を大きく損なっている場面も
    • わかりやすい例:名前と住所と電話番号を何度も何度も記入/入力して提出…
    • わかりやすい例2:引っ越しのときの不動産屋、役所、警察、保険会社、電話会社、etc...
    • デジタル・アイデンティティに関する仕組みの未成熟により、データ共有で実現できるはずのよりスムーズで高度なサー
    ビスの可能性が阻害されている
    • 一方で、規制はユーザー側に自身のデータの共有/流通を管理する力がないことの裏返しでもある
    規制の拡大と利便性のバランスの課題
    Copyright © 2023, Oracle and/or its affiliates
    19

    View Slide

  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

    View Slide

  21. SSIの12原則
    Sovereign Foundationでは
    SSIの備えているべき12の原則を定義
    21 Copyright © 2023, Oracle and/or its affiliates
    https://sovrin.org/principles-of-ssi/

    View Slide

  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

    View Slide

  23. SSIの思想≒べき論
    • IdPやサービサーに依存しない、権力が集中しない
    • ある仕組みにロックインされたりせず、別の仕組みにアイデンティティを持ち出せる
    • 仕組みは中央集権的(Centralized)なものではなく、分散/分権(Decentralized)されたものである
    • 自分の情報は自身でコントロールする
    • 自分以外の都合でプロファイルが消失しない
    • 都度、必要最小限の情報を提示できる
    • 自身に関する情報がどう利用されているかを確認できる
    • 安全で便利に使える
    • 常に利用できる
    • 利用者自身が安全に管理できる
    • どの仕組みを選ぼうとさまざまなサービスが便利に使えるように、仕組み同士は相互に互換性がある
    23 Copyright © 2023, Oracle and/or its affiliates

    View Slide

  24. Copyright © 2023, Oracle and/or its affiliates
    24
    DID & VCの仕組み

    View Slide

  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

    View Slide

  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

    View Slide

  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の例
    !!個人のプロファイル情報は含まれない!!

    View Slide

  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

    View Slide

  29. 理解しておきたいポイント:レジストリの基盤と運用
    • レジストリは誰かが運用しなければ存続しないが、そのコストを誰がどのように負担するかは実践上の課題
    • パブリックブロックチェーンであれば、DID Documentを登録するときにトランザクション手数料(GAS代)を支払う
    • コンソーシアム型ブロックチェーンでは運用者が負担する?DID利用者から利用料を徴収する?
    • レジストリにブロックチェーン(分散台帳)を用いることは仕様上必須ではない
    …DIDの”Decentralized”はレジストリにブロックチェーンを用いることを必ずしも要求してはいない
    • レジストリには常にアクセスでき、DID/VCが用いられる期間は存続し、都合よく削除改変されないことが期待され
    るため、ブロックチェーンの特性が有利に働く
    29 Copyright © 2023, Oracle and/or its affiliates
    パブリック
    ブロックチェーン上の
    レジストリ
    コンソーシアム型
    ブロックチェーン上の
    レジストリ
    単一組織の
    データベース上の
    レジストリ

    View Slide

  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の例

    View Slide

  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(=レジストリ)は
    別でも良い!!

    View Slide

  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署名の
    検証

    View Slide

  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

    View Slide

  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の提示

    View Slide

  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サイトなどを参照して
    信頼性を判断することになりそう

    View Slide

  36. Copyright © 2023, Oracle and/or its affiliates
    36
    DID & VCのメリット、課題など

    View Slide

  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

    View Slide

  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

    View Slide

  39. ヒトのDID/VCのメリット②
    (いずれもDID/VCや周辺エコシステムが整備され、広く利用されるようになっていることを前提に)
    情報を取得、確認するプロセスのスムーズ化、コストの低下
    • サービスごとに紙の用紙の記入、Webフォームの記入→VCを提示
    • 検証可能性により不正防止のコストは低下
    • 重要な証明情報のデジタル化
    個人情報を扱うコスト、リスクの低減
    • 余分な個人情報を扱わなくて済む部分が出てくる
    • Issuerは発行したVCの情報を自身で持っていなくて良い→個人情報の保管が必須でなくなる
    • サービス提供者(Verifier)は余計な個人情報を受け取らずに必要な確認ができる
    (例:「20歳以上である」ことだけをVCで提示してもらう)
    • 個人情報の提示についての本人の同意の確認がしやすい
    39 Copyright © 2023, Oracle and/or its affiliates

    View Slide

  40. モノのDID/VC?
    モノを中心とした情報の管理
    • 「モノ自体に紐づいた偽れない証明書」としてのユースケースが
    想定されている
    • 製造過程での各パーツへの、各プロセスでの情報付与
    • オーナーが代わっても残る、製品のライフサイクルに渡る履
    歴情報の記録
    • メーカー側に共有されない作りにもできる
    …オーナーのプライバシーや選択の自由にも対応できる
    • ヒトと異なり、モノと秘密鍵、DIDの不可分の結びつきは比較
    的容易に実装できる
    自律的なスマート○○のアイデンティティ
    • 自動、自律的に動くモノの契約/支払のためのアイデンティ
    ティや資格情報として
    40 Copyright © 2023, Oracle and/or its affiliates
    製造
    販売

    リース
    使用
    点検

    修理
    廃棄
    リユース
    リサイクル
    二次流通

    View Slide

  41. Copyright © 2023, Oracle and/or its affiliates
    41
    ユースケースの例

    View Slide

  42. ヒトのDID/VC:就職や進学時の学歴、職歴、資格などの証明
    • 予めVCを発行しておけばすぐ提示できる
    • 従来の確認プロセスのように数日~数週
    間待たされない
    • コストも提示の都度発生しない
    • Issuerにプライバシーリークしない
    • 転職意思、転職しようとしている先が現職
    にバレない
    • 偽装を防止しやすい
    • 紙の資格証はしばしば偽装が発生
    • 発行機関が消滅しても有効
    (IssuerのDIDの有効性が確認できる限りに
    おいて)
    42 Copyright © 2023, Oracle and/or its affiliates
    Holder Verifier
    Issuer
    就職先
    進学先
    高等教育機関、
    以前の就職先、
    資格発行機関
    学歴VC
    発行
    資格VC
    職歴VC
    提示

    View Slide

  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

    View Slide

  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

    View Slide

  45. Thank you
    Copyright © 2023, Oracle and/or its affiliates
    45

    View Slide

  46. Copyright © 2023, Oracle and/or its affiliates

    View Slide