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

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

View Slide

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

View Slide

内容
• DID/VC理解の前提となる要素を説明：
• ブロックチェーン
• 秘密鍵／公開鍵とデジタル署名
• SSIの概要：
• デジタルアイデンティティの発展と課題
• SSIの思想と登場背景
• DID/VC
• DID／VCの仕組み
• DID／VC（Verifiable Credentials）のメリット
• ユースケースの例
3

View Slide

4
DID/VC理解の前提となる要素：
ブロックチェーン

View Slide

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

View Slide

ブロックチェーンの利用形態（ネットワーク）の分類
パブリック
公開制のネットワークを
不特定多数で運用
コンソーシアム
許可制のネットワークを
複数組織で運用
プライベート
許可制のネットワークを
単一組織で運用
パーミッションレス← →パーミッションド
6
6

View Slide

7
DID/VC理解の前提となる要素：
秘密鍵／公開鍵とデジタル署名

View Slide

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

View Slide

参考：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

View Slide

デジタル署名とその検証
10
署名対象の内容
署名アルゴリズムデジタル署名
デジタル署名
秘密鍵を署名鍵として用い、デジタル署名アルゴリズムを使い、ある内容に対してのデジタル署名を生成する
デジタル署名の検証
公開鍵を検証鍵として用い、署名された（はずの）内容とともに検証アルゴリズムにかけるとデジタル署名を検証できる
署名鍵＝秘密鍵
IN
OUT
署名対象の内容
検証鍵＝公開鍵
検証アルゴリズム
検証結果
（OK or NG）
OUT
IN
デジタル署名
IN
IN
IN

View Slide

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

View Slide

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

View Slide

13
デジタルアイデンティティの発展とSSI

View Slide

各サービスプロバイダで個別にIDを管理する方式
• ユーザーが多数のサービスのIDとパスワードを管理する
ことになる
• 覚えきれない
• パスワードの使い回しにつながりがち→セキュリティの
低下
• いちいちログインするのが面倒
• 情報が分断されている
• 同じ情報をサービスの登録のたびに何回も記入し
なければならない
デジタルアイデンティティの発展：Isolated Identity
14
サービスプロバイダ1
サービス1
ID1/PW
データ1
ID1/PW
ID1/PW
データ1
データ1
サービス2
ID1/PW
データ1
ID1/PW
ID2/PW
データ1
データ2
サービス3
ID1/PW
データ1
ID1/PW
ID3/PW
データ1
データ1
ID1で
ログイン
ID2で
ログイン
ID3で
ログイン
エンド
ユーザー

View Slide

アイデンティティプロバイダ（IdP）の提供するIDで複数サービスを利用する方式
• ユーザーは少数のIDとパスワードを管理するだけで良い
• ログインが楽
• ひとつのIdPのセキュリティ侵害が多数のサービスでの不
正利用につながる
• IdPがSPoF（単一障害点）で可用性が低い
• IdPと各サービスのコンテクストが密結合
• IdPの利用をやめると各サービスでのコンテクストを
失う
• IdPに情報が貯まっていく
デジタルアイデンティティの発展：Centralized Identity
15
アイデンティティプロバイダ1
サービス2
データ1
データ1
データ2
サービス3
データ1
データ1
データ3
ID1で
ログイン
暗黙的に
ID1で
ログイン
暗黙的に
ID1で
ログイン
エンド
ユーザー
ID1/PW
ID1/PW
ID1/PW
SSO

View Slide

サービス側でも個別にIDを管理しつつIdPのIDにリンク（フェデレーション、連合）
• ユーザーはサービス内のIDにIdPのIDをリンクできる
• 別のIdPのIDにスイッチが可能
• ひとつのIdPのセキュリティ侵害による不正ログイン被害
範囲が大きいのは変わらず
• IdPへの信頼が必要なのは変わらず
• IdPに蓄積されるプロファイルが増えている
• ユーザーは自身のプライバシーを
コントロールできているか確認できない
デジタルアイデンティティの発展：Federated Identity
16
サービス2
ID1/PW
データ1
ID1/PW
サービス2ID
データ1
データ2
サービス3
ID1/PW
データ1
ID1/PW
サービス3ID
データ1
データ1
ID1で
ログイン
IDxで
ログイン
IDxで
ログイン
エンド
ユーザー
ID1/PW
ID1/PW
ID1/PW
ID1/PW
ID1/PW
ID2/PW
ID2で
ログイン

View Slide

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
17

View Slide

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

View Slide

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

View Slide

前記のような従来型デジタルアイデンティティの課題
→SSI（Self-Sovereign Identity）というパラダイムの登場
• 2012年にDevon Loffretoが提唱、2016年にChristopher Allenが「SSIの10原則」を整理
SSIの根本の発想
• 個人は自身のアイデンティティに関しての確立した権利を生まれながらに持っている
• IdPにアイデンティティの管理の起点を明け渡していることがそもそもの間違い
• 「IdPやサービサーがちゃんとやってくれている／やり続けてくれることを信じるしかない」状況につながっている
• 個人の側にアイデンティティ管理の主権を取り戻す
※もともとのSSI理念のスコープはデジタルアイデンティティだけでなく国家によるアイデンティティ管理（戸籍など）にも及んでいるが、ここでは取り扱わない
Self Sovereign Identity（自己主権型アイデンティティ）の登場
20

View Slide

SSIの12原則
Sovereign Foundationでは
SSIの備えているべき12の原則を定義
https://sovrin.org/principles-of-ssi/

View Slide

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のエコシステムはアイデンティティ所有者と全てのステークホルダーが簡易に
アクセス、情報の確認ができ、インセンティブやルール、ポリシー、アルゴリズムなどエコシス
テム内で機能する内容を知る事ができる環境を提供します。
出典：https://sovrin.org/wp-content/uploads/Principles-of-SSI-V1.01-Japanese-v01.pdf

View Slide

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

View Slide

24
DID & VCの仕組み

View Slide

DID、VCの考案（2016年～）：
• DID：Decentralized Identifier（分散型識別子）
• VC：Verifiable Credential（検証可能な資格情報）
→それぞれの仕様の策定、規格化がいくつかの団体によって進められている状況
• 主だったところ：W3C、Sovrin、DIF、Open ID Foundation
• 規格間の相互運用性も意識（どれを使っても同じように便利に使える＝自由に選べる、が理想）
※Decentralized Identity（分散型アイデンティティ）を指してDIDと呼ぶこともある（が、ここでは採用しない）
…Decentralized IdentifierとVerifiable Credentialを利用したアイデンティティの仕組み（エコシステム）総体の呼び方
DID＆VCの登場
25

View Slide

DID（Decentralized Identifier）
• 規格として識別子の形式および発行、登録、公開、検証などの運用方法が規定されている
• DIDに関する規格、および実装（DID Methodと呼ばれる）は複数あるが、識別子の形式は共通の規格がある
• DIDの具体的な例：
• did:ion:EiCjHFpU1Fm6Qnq7XIj_Gt2QGCpnwQrrnUWoVrM4H9we1A
• did:sov:WRfXPg8dantKVubE3HX8pw
• DID Methodの例…それぞれ別々のレジストリにDIDが登録されている
• ION…パブリックのBitcoinブロックチェーンをレジストリとして利用
• Sovrin…コンソーシアムのHyperledger Indyをレジストリとして利用
• Ethr…パブリックのEthereumブロックチェーンをレジストリとして利用

View Slide

DIDの取得（生成と登録）
DIDのセットアップはアイデンティティの所有者が自身で行う（⇔ IdPに発行してもらう）
1. ウォレットを用意
2. キーペア（秘密鍵／公開鍵）を生成
3. DIDを生成
4. レジストリにDID Documentを登録
• DIDと公開鍵が含まれる
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

DIDの認証
1. Holder（DIDとVCの所有者）がVerifier（資格情報を要求し、検証する者）に対して、DIDの認証をリクエスト
2. Verifierがランダムに生成したチャレンジコードをHolderに送り、デジタル署名を要求
3. Holderはチャレンジコードに対して自身の持つ秘密鍵でデジタル署名して返却
4. VerifierはDIDに対応するDID Documentに含まれる公開鍵を使い、デジタル署名を検証することで認証
Wallet
秘密鍵
Holder わたしはdid:aaa:hogehogeです
本当にhogehogeなら
チャレンジコード:XXXXXX…に署名してみてよ
署名したらxxxxxx…になりました
hogehogeの公開鍵はこれだな
検証してみよう
→署名が合ってるから本物だな
or署名が合わないから偽物だな
Verifier

View Slide

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

View Slide

VC（Verifiable Credential）
• あるデジタルアイデンティティについての情報の「検証可能なデジタ
ル証明書」をVerifiable Credentialとして表現できる
• ヒトの例：身分証、免許、学歴、職歴、試験のスコア
• モノの例：品質鑑定結果、車検証、メンテナンス履歴
• 規格として証明書の形式および発行、保持、提示、検証などの
運用方法が規定されている
• 以下のような項目を持つ
• 誰が発行したのか（issuer）
• 誰／何についてのどのような情報か（subject）
• 誰／何：HolderのDID
• どのような：資格情報の内容
• 発行者のデジタル署名
• 署名検証用の公開鍵の所在
{
"@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

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を自身のウォレットに保管
レジストリ
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

VCの提示と検証
（前提：HolderのDIDは認証済）
1. HolderはVerifierに対してVCを提示
2. VerifierはVCに示されるIssuerの公開鍵を使ってVC（のIssuerのデジタル署名）を検証したうえで、
VCに記載の資格情報の内容を受け入れ
• ここでVerifierからIssuerへの問い合わせが生じない（HolderはIssuerに対してVerifierの提供するサービスを利用し
ていることを知られない）で資格情報の検証が行えている点は重要なポイント…プライバシー、アクセシビリティ
VC
Holder Verifier
レジストリ
DID 公開鍵
DID 公開鍵
Wallet
秘密鍵
VC VCの提示
Issuer署名の
検証

View Slide

DID/VCまとめの図
33
Holder
Wallet
秘密鍵
VC
Issuer
Wallet
秘密鍵
ブロックチェーンなどで
実装されたレジストリ
DID 公開鍵
DID 公開鍵
Verifier
VCの提示
DIDで認証
DIDで認証
VCの発行
DID Documentを登録
DID Documentを登録
DIDの署名検証の
ために参照
VCの署名検証の
ために参照
DIDの署名検証の
ために参照
サービス等の提供
ヒト／モノ
DIDs
VCs
1
n
1
n

View Slide

VP（Verifiable Presentation）
• Holder側での以下の（いずれかまたは両方の）操作によりVCからVP（Verifiable Presentation）を作成し、
Verifierに対してVCを直接するのではなくVPを提示することもできる
• ひとつのVCに含まれる複数の資格情報の項目から提示する項目を取捨選択して抽出（→選択的開示）
• 複数のVCから資格情報をまとめて抽出
• VPに対応するためには、VCが特定の形式（SD-JWT、BBS+など）でデジタル署名されている必要がある
※VCの標準によってはVerifiable Presentationの仕組みがないものもあるかも
元のVC（運転免許証）
選択的開示の例：
年齢確認のため免許証VCから生年月日のみをVPとして開示
氏名：鈴木太郎
住所：千代田区1-2-3
生年月日：1999/10/1
種類：中型
etc.
Holder
提示するVP
生年月日：1999/10/1
署名（SD-JWT）署名（SD-JWT）
VPを作成
Verifier
VPの提示

View Slide

理解しておきたいポイント：Issuerの信頼性の判断
• VerifierはVCの内容自体はIssuerのデジタル署名により検証可能だが、そのIssuerが信頼に足るかどうかはVCを見
ていても判断がつかない
• 不正の例：それっぽい名前でIssuerのDID Documentを適当に登録して都合の良いVCを濫造
Issuer：did:aaa:jpgovernment
subject:
“hogehogeは弁護士です”
sign:
xxxxxxxx
Verifier
署名検証はOKだけど、そもそも
このIssuerは信頼できるのか…？
Holder
VCの提示
ホワイトリストとのIssuerの照合や、
Webサイトなどを参照して
信頼性を判断することになりそう

View Slide

36
DID & VCのメリット、課題など

View Slide

W3CによるVCのユースケース領域の例
図：w3c, Verifiable Credentials Use Cases
https://www.w3.org/TR/vc-use-cases/
ヒトの
DID/VC
モノの
DID/VC

View Slide

ヒトのDID/VCのメリット①
プライバシー
• デジタルアイデンティティの持ち主であるDID所有者（Holder）は、自身に関する情報の取得、および開示が自身で
コントロール可能になる
• 紙の証書を自分で保管しておいて自分の意志で見せる、と同じようなモデル
• VCは偽造などの不正を排除しやすい、VPで開示する情報を絞れるという紙では難しいメリットも
• DIDはひとりで何個保持しても良く、プロファイルを使い分けられる
• 複数DIDを使い分けることで、IssuerやVerifierによる名寄せもある程度避けられる
• 利用してきたDIDと自身を切り離すこともできる
• 「法的な身分に紐づかないが他者から信頼可能」なデジタルアイデンティティを育てていける可能性もある
アクセシビリティ、ポータビリティ
• DIDはIdPおよび権威（国、政府、公的機関など）に依存しない
• IdPの廃業やアカウント利用停止、権威の消滅や意向（差別、排除）により利用不能にならず、いつでも、望む
限り使えるデジタルアイデンティティを手に入れられる
• VCの検証可能性がIssuerの存続可能性に依存しない（Issuer組織が消滅してもVCは検証可能）

View Slide

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

View Slide

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

View Slide

41
ユースケースの例

View Slide

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

View Slide

モノのDID：MOBI VID（Vehicle ID）
MOBIの提案する車両DID/VCであるところのVIDでは、
以下のようなユースケースが主として想定されている
参照：https://dlt.mobi/wp-content/uploads/2021/02/MOBI-VID0002-
Use-Case-2021.pdf
• 車両登録
• メンテナンスのトレーサビリティ
• パーツ交換のトレーサビリティ
• マシンからマシンへの支払い
• 事故のトレーサビリティ
• 保険
• 所有者と資格情報
• 車検
• 走行距離不正の防止
• 廃車のトレーサビリティ
図：MOBI VID White Paperより引用
https://dlt.mobi/wp-content/uploads/2022/06/MOBI-
VID0001WP2021-Version-2.0-1.pdf

View Slide

その他の参考情報
• ソフトバンク：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/

View Slide

Thank you
45

View Slide


View Slide

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

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

gakumura

More Decks by gakumura

Other Decks in Technology

Featured

Transcript

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

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

gakumura

More Decks by gakumura

Other Decks in Technology

Featured

Transcript

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

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