フィンテック養成コミュニティでお話した資料です。 SSI/DID/VCの整理をしようと試みています（難しい） https://fintech-engineer.connpass.com/event/252076/

1. 分散型IDと検証可能なアイデンティティ
技術概要
2022/07/29
富⼠榮 尚寛 - @phr_eidentity
OpenIDファウンデーションジャパン代表理事

2. 今日の目標
個人的な課題感
• 「分散型」IDという言葉から脱GAFA〜web3が想起されてしまう
• 関連して、自己主権型ID（SSI）、NFTなどを含めIDやデータに所
有権があるかの如く語られてしまう
目標
• この辺りをそれぞれの技術要素に触れることで、ちゃんと分けて
考えられるようになれると良いな、、、、と思っています
• と言いつつ簡単に説明するのが至難の業。ご質問をいただければ
ディスカッションの中でお答えします

3. 「分散型ID」により実現する世界？
こんなイメージが広がっている？
• 特定事業者によって自分のIDを牛耳られない
• GAFA等のプラットフォーム提供者によってIDを与えられるではなく、利用者自身でIDを作
成〜「保有」できる
• プライバシー保護に最適
• 身分証明書として使える
• 事業者や行政による後ろ盾がなくても自分のインターネット上での身分が証明できる
• Metaverse内の身分証明として利用できて、NFTと合わせると仮想世界でも暮らせる
• ブロックチェーンを使っている
• 分散！分散！分散！web3！

4. 分散型ID – 関連キーワードの整理
ž 自己主権型アイデンティティ（Self Sovereign Identity）
ž 分散型識別子（Decentralized Identifiers）
ž 検証可能な属性情報（Verifiable Credentials）
本日のゴール
SSI/DID/VCを分離して考えられるようにする

5. 自己主権型アイデンティティ（SSI）
https://blog.goodaudience.com/how-blockchain-could-become-the-onramp-towards-self-sovereign-identity-dd234a0ea2a3

6. 自己主権型アイデンティティ（SSI）
ž インテンション・エコノミー（Doc Searls / 2012）
ž 顧客の意思に基づく経済（VRM）の実現
ž 企業が顧客の関心（アテンション）を中心に行う経済活動（CRM）と対局
ž 顧客が企業に自分自身の意思を持ってアイデンティティ情報を提供することで、
ž 企業がBig Dataをもとに推測したリコメンド・広告表示による気持ち悪さからの脱却
ž 企業が大量データを収集・分析を行うためのコストの削減
ž Sovrin foundationの定義
ž 自己主権型アイデンティティ（SSI）とは「個人は、管理主体が介在することなく、自身のア
イデンティティを所有しコントロールできるべきである」、と考えるデジタル・ムーブメン
トを表す言葉である。SSIを使うと、人々は現実世界で彼らが行っているのと同じ自由度と信
頼性をもってデジタル世界でも活動することが出来る。（https://sovrin.org/faq/what-is-self-
sovereign-identity/）
いつの間にか「アイデンティティの所有」の話になってきている？？

7. 自分の意思を持ってアイデンティティ情報を提供
ž 利用者目線で必要なこと→ポータブルであること
ž 事業者になるべく依存せずにIDを自身で発行・管理できる
ž 事業者の都合によらず（例：IdPが落ちていたり、IdPによってBANされることなく）、自身
の属性情報を利用できる
ž 一方でサービス事業者目線では→高度な信頼
ž 提供された属性情報を信頼できること（事業者の介在なく提供された情報への信頼）
ž 「No trust, more truth」に通じる？「Trust, but verify（信じよ、されど確認せよ）」
※信頼とは？
事実の確認をしない状態で、相手先が期待したとおりに振る舞うと信じる度合い
（内閣官房/Trusted Web推進協議会の定義より）

8. 分散型識別子（DID/Decentralized Identifiers）
ž 特定の事業者に依存しない識別子（Identifier）
ž Identity（属性の集合）ではなく、Identifier（識別子）→did:method:xxx
ž W3C勧告：https://www.w3.org/TR/did-core/
ž DIDと紐づく鍵ペアを生成、秘密鍵へのアクセス≒「所有」
ž 識別子に紐づくDID Documentが分散台帳上等で公開される
ž DIDに紐づく秘密鍵で署名したデータをDID Document上の公開鍵で検証する
ことでDIDの「持ち主」が発行したデータであることを検証できる（VCはこ
の仕組みを利用）
ž 事業者の都合（倒産やアカBANなど）で公開鍵の取り消しや改竄ができない
ため、自己主権っぽく見える（そのためにはPermissionlessなチェーンが望ま
しいが実態は・・・）※did:webなど単純にwebサイト上で公開されるものもある

9. DID Documentのサンプル
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/jws-2020/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
]
"id": "did:example:123456789abcdefghi",
"verificationMethod": [{
"id": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
"type": "JsonWebKey2020",
"controller": "did:example:123",
"publicKeyJwk": {
"crv": "Ed25519",
"x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ",
"kty": "OKP",
"kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A"
・・・

10. 何が分散
ž 系の分散：特定の系への依存度を下げる（ソーシャルログオンと同レベル）
ž 系の中でのノード分散：系を運営する事業者への依存度を下げる（本質）
基盤レイヤ
データレイヤ
APIレイヤ
sovrin bitcoin ethereum
ION（sidetree）
N N … N N N … N N N … N
・・・
did:sov:xxx did:btcr:xxx did:ion:xxx did:eth:xxx ・・・
Discovery Service（Universal resolver等）
driver driver driver driver ・・・

11. ざっくり言うと
ž 各エンティティがメソッド単位で鍵ペアに紐づくDIDを取得する
ž メソッド（ionとかbtcrとかethrとか）ごとのノードの運営が特定事業者に限定されないので、
少なくとも識別子の単位で勝手に消されたり、公開されるDID Documentが改ざんされる恐れ
は少ない＝分散、事業者非依存、SSIというキーワードへ繋がっている
ž よくある質問
ž メソッドを跨いでDIDを引っ越すことはできる？
ž できません。SSIと言いつつメソッドの系への依存はします。
ž DID Documentを分散台帳へ記録するためのコストは誰が負担するの？
ž 系によってまちまちです。Sovrin foundationだとFoundationへの参加した組織だけが書き込めて、トランザクショ
ンごとに費用が発生していたはず。
ž 鍵のローテーションはどうする？
ž DID Documentの更新（公開鍵の追加）を行います。過去の秘密鍵で署名されたVCは過去の公開鍵で検証ができる
ので、少なくとも当該のDIDを管理しているエンティティにより署名された過去があることはわかります。

12. DIDのご利益は何なのか？
ž ガバナンス（Identifier/DID Document管理）
ž マルチステークホルダーのガバナンスの中で管理できる（系による）
ž 現状の事業者のモチベーションとは反することが多いのでシナリオを選ぶ（囲い込み、統制
とは正反対）
ž 疎結合アーキテクチャーの一歩（公開鍵の置き場所、DPKIとして）
ž プライバシーへの配慮（IdPへのCall home問題を解決。IdPによるトラッキングを回避）
ž IdPへの依存度が下がるため、
ž IdPの可用性が下げられたる
ž 事前の信頼関係の構築が不要
ž DID自体は公開鍵の情報を含むデータ（DID Document）を指し示すロケータ

13. 検証可能な属性情報（VC/Verifiable Credentials）
ž 検証可能なデータモデル（JWTやJSON-LD）
ž 発行者（Issuer）のDIDに紐づく秘密鍵によりデジタル署名される
ž 発行者のDID Documentに含まれる公開鍵を使って検証可能
ž エンティティ間でのトランスポートはW3C定義外。ここはOpenID for VCxやDIDCommの範囲
分散台帳（DID Documentを配置）
⾏政/キャリア/企業
など
個⼈のID Wallet
アプリケーション
VP: Verifiable Presentation
VCを複数束ねたもの

14. メリット
ž Issuerの事業継続性を気にする必要がない（OIDCとの対比で言うと、IdPがなく
てもRPがid_tokenの検証ができる）⇒過去のVCを検証可能、疎結合でOK
ž 複数Issuerから発行されたVCをまとめて提示可能
分散台帳（公開鍵基盤）
個⼈のID Wallet
アプリケーション

15. ざっくり言うと
ž 関連エンティティ
ž VC発行者（Issuer）、利用者（Holder）、VC消費アプリ（Verifier）
ž 単なるJSON/JSON-LDであるVCやVPへ、DIDに紐づく秘密鍵で署名をする
ž OIDCと対比し、RP（Verifier）目線で言うとこんな感じ。
ž よくある質問
ž VCの発行元（VC内のIssuerとして指定されているDIDの持ち主）は誰か？をどうやって判
別・信頼するのか？
ž DNSにバインド。DID Document内のLinked Domainに記載のあるドメイン配下に/.well-known/did-
configuration.jsonを配置。受け取ったら検証 → よく考えると結局疎結合になりきれない・・・
取得元 Verify用の公開鍵 含めることのできる属性 何を信じるか
Id_token IdP Jwks_uriから取得 IdPが発行したもの
（Aggregatedだと元CPの署名検証は不
可）
IdP
VP Holder DID Documentから取得 複数のVCをVPに含めることで複数の発
行元から検証可能な状態で取得可能
DID Documentが格納され
る分散台帳の系

16. 実は最も重要なこと）DIDとVCを切り離す
ž VCはあくまでデジタル署名されたデータセット
ž id_tokenとほぼ変わらない
ž iss/subにDIDを用いる必要はない
ž 実際、ワクチン接種証明はVerifiable Credentials
ž スキーマ：FHIR
ž Issuer：https://vc.vrs.digital.go.jp/issuer
ž 署名：デジタル庁の自己証明書書
ž 参考）
ž https://idmlab.eidentity.jp/2021/12/verifiable-credentials.html
ž DIDと組み合わせることで得られるのは疎結合
ž 署名検証を行う際にIssuerの公開鍵を取得する方法の違い
ž jwks_uriエンドポイントへのアクセスによる取得 → DID Documentから取得
ž DID Documentが分散台帳上にあることでIdP（Issuer）とRP（Verifier）の直接通信は不要となる

17. 分散型IDは自己主権型IDを実現するのか？
ž 「IDの所有」と呼ぶにはあまりにも限定的
ž 確かに事業者の都合で署名済みのVC＝デジタルIDが使えなくなるリスクは低減できる
ž WalletにVCを入れればポータビリティっぽく見える
ž 真の価値は「IDプロバイダへの依存度を下げる」ことではないか？
ž ユーザ目線では、「IdPが落ちていてもサービスが継続して利用できる」
ž 事業者目線では、「IdPの可用性要件を下げられる」「継続的なID管理が不要となる」
ž こう考えるとユースケースが見えてくる
ž 情報管理はしたくないが、ID発行事業者として身元保証はしたい
ž ID発行事業者に知られることなくサービスを利用したい
ž IdPとサービスが連携できないスケールのサービス
ž 例）大学における卒業生の管理、資格証明（資格試験、所属等）、スマートシティ、etc

18. 「分散型ID」により実現する世界？
こんなイメージが広がっている？
• 特定事業者によって自分のIDを牛耳られない
• GAFA等のプラットフォーム提供者によってIDを与えられるではなく、利用者自身でIDを作
成〜「保有」できる
• プライバシー保護に最適
• 身分証明書として使える
• 事業者や行政による後ろ盾がなくても自分のインターネット上での身分が証明できる
• Metaverse内の身分証明として利用できて、NFTと合わせると仮想世界でも暮らせる
• ブロックチェーンを使っている
• 分散！分散！分散！web3！
あくまで識別子
メソッドの系には縛られる
秘密鍵へのアクセスの拡大解釈
公開鍵をIdPから都度取得する必要はないが、Issuer
DIDの確認するためにIdP（well-known）へアクセス
オラクル問題を解決するものではない
そもそもDIDではなくVCの話（分散関
係なし）
DIDメソッドによっては
ブロックチェーンを使わ
ない

19. まとめじみたもの
• SSI ------------à DID、VC。だいぶ距離がある
• そもそも思想の話と技術の話なので短絡させない
• ×）DIDがあればSSIが実現する！
• ◯）SSIの思想とDIDで実現できることの「ごく一部」に共通点がある
• DIDとVCも関係なし
• VC単体で使うケースは既に広がってきている（ワクチン接種証明、モバイル運転免許証）
• DIDで実現できることは？
• これまでデータの署名検証をIdPに依存しない形（疎結合な環境）で実施するための仕組み
は色々と考えられてきた
• SIOP：subに公開鍵のThumbprintを入れる
• 学術認証フェデレーション：コンソーシアムでの公開鍵を含むmetadataの管理・公開
• DIDはIdPに依存しない（しなくても良い）形で公開鍵を含むmetadata（DID Document）
へのロケータであり、SIOPや学術でやってきたこととならび疎結合実現の候補の一つ

20. おしらせ
DID Developer Community
https://discord.gg/UFE9m22TeT
DIDに関する雑談、情報交換、Playgroundなど
Digital Identity Across Asia : An IIW ½ Day Workshop
https://www.eventbrite.com/e/digital-identity-across-asia-an-iiw-12-
day-workshop-tickets-374391784907
8/9（火）10:00 – 15:00
アンカンファレンスですがDIDの話もたくさんある（はず）