金融庁

御中

ブロックチェーン技術等を用いたデジタルアイデンティティの活用に関する研究報告書
株式会社野村総合研究所

NRIセキュアテクノロジーズ株式会社
2021年3月31日

調査の背景と目的
 調査の背景 近年、技術革新に伴い金融サービスのデジタル化が急速に進展しており、多様な金融サービスが様々なデバイスやプラットフォー
ムを通じて提供されるようになっている。こうした動きに対応すべく、金融庁においては、「金融デジタライゼーション戦略」を策定し、データ利活用や顧客のプライバシー保護といった課題に取り組んでいるところである。
 こうした中、金融サービスをデジタル化する上で不可欠な構成要素の一つがデジタルアイデンティティであると指摘されている。サービスの提供形態によらず、金融サービス提供者は利用者保護、マネーロンダリング・テロ資金供与防止等の観点からアイデンティ
ティの適切な取り扱いが求められるが、金融サービス提供者が顧客を適切かつ効率的に識別した上で、利用者の属性やニーズに応じたきめ細やかなサービスを提供するためには、適切なフレームワークに基づくデジタルアイデンティティ・システムを構築することが期待されている。
 足下、デジタルアイデンティティの技術開発や標準化に向けた様々な取組がみられており、そうした動向を適時適切に把握することは重要となる。さらに、近年、その発行と利用が中央的に管理されたデジタルアイデンティティに関するプライバシーの懸念、
個人情報保護規制への対応、ロックイン回避及び金融包摂実現の必要性等を踏まえ、ユーザ自らがアイデンティティを管理す
る自己主権型／分散型アイデンティティ（SSI/DID）の議論も活発になっている。SSI/DIDの構築にあたっては、ブロックチェーン
技術等を用いた分散型アーキテクチャが望ましいとの指摘もあるところ、こうした新たな動向にもフォワードルッキングに対応する必要がある。
 デジタルアイデンティティ領域については、ブロックチェーンを含め認証技術、アクセス制御技術、暗号化技術など多様な技術コン
ポーネントや、その運用体制及びガバナンスなど、幅広い論点について理解を深めるとともに、関与する様々なステークホルダーとの対話が必要となる。

 調査の目的 そこで、本調査研究においては、国際共同研究の一環として、金融サービスにおけるデジタルアイデンティティの活用に関する研究を行うこととする。金融規制当局として、今後の金融デジタル化を見据え、デジタルアイデンティティ・システムの現状把握及び、
望ましいデジタルアイデンティティ・システムの在り方やその運用についての方向性を検討するために実施するものである。
1

目次
第1章

アイデンティティに関わる技術や運用についての基礎
1-1. デジタルアイデンティティとアイデンティティマネジメントシステム(IMS)
1-2. 主要なIMSモデルと構成要素
1-3. 自己主権型アイデンティティモデル

第2章 デジタルアイデンティティに係る金融規制当局や関連団体及び学術的な既存の研究・検討状況および金融サービスにおける活用可能性
2-1. 金融機関のアイデンティティ管理の現状と課題
2-2. onboardingプロセスの非対面化の進展
2-3. デジタルIMSの活用可能性
2-4. 課題解決（先進的事例からのインプリケーション）
2-5. 課題解決の方向性の整理

第3章 自己主権型アイデンティティ(SSI) /分散型アイデンティティ(DID)
3-1. SSI/DIDの概要
3-2. SSI/DIDの実現に必要な構成要素
3-3. SSI/DIDの先行事例/PoC事例
3-4. SSI/DIDの長所と実現に向けた課題
3-5. SSI/DID活用時の金融規制上の論点

第4章

デジタルアイデンティティ活用に向けた今後の論点

4-1. 本章の構成
4-2. 各課題のステークホルダーとその関心事項
2

謝辞・免責事項

謝辞
 本報告書作成にあたっては、米国OpenID Foundation・崎村夏彦理事長、早稲田大学・佐古和恵教授、慶応義塾大学・鈴木茂哉特任教授、米ジョージタウン大学・松尾真一郎研究教授
から有益な助言やコメントを得た。
• また、金融庁のご担当者からも有益な示唆・助言をいただいた。
 もっとも、本報告書に関する内容の誤りは、すべて受託者である株式会社野村総合研究所並びにNRIセキュアテクノロジーズ株式会社に帰する。

免責事項
 本報告書の内容は金融庁の公式見解を示すものではない。
 本報告書で記載している過去または現在の事実以外の内容については、本稿執筆時点で入手可能な情報に基づいた見通しであり、実際の動向等は種々の不確定要因によって変動する可能
性がある。

3

用語集
 下記用語は主にISO/IEC 24760シリーズ*1)に則る。
用語
エンティティ（entity）
アイデンティティ
(identity)
アトリビュート(attribute)
アイデンティファイア
(identifier)クレデンシャル
(credential)
ベリフィケーション(verification)

定義
明確に存在が区別されるドメインの運用目的に関連するアイテム
エンティティに関連するアトリビュートの集合

エンティティの特性または性質
ドメイン内のアイデンティティを一意に特徴付けるアトリビュートまたはアトリビュート群






オーセンティケーションで使用するためのアイデンティティの表明
例えばユーザネーム、パスワード付ユーザネーム、PIN、スマートカード、トークン、指紋、パスポート等
特定のエンティティに関連付けられたアイデンティティ情報が正しいことを確立するプロセス
ベリフィケーションのプロセスでは、エンティティを認識するのにどのアトリビュートが必要かを決定した上で、決定された必要なアトリビュートが提示されているかや、正しいシンタックスを有しているか、定義された
有効期間内のものか、そしてそれがエンティティに関連しているものであるかを確認する
ベリフィケーションの正式な（文書化され・組織によって認められた）プロセス。

オーセンティケーション
(authentication)
バリデーション
(validation)
アイデンティティマネジメントシ ステム(identity
management
system: IMS)

文書やクレデンシャル、またはアトリビュートが有効であることを確認するために、利用可能な最新の情報に基づき、イシュアまたはオーソリティのソースに確認を行うこと関連するメタデータを含むアイデンティティ情報を維持するためのポリシー、手順、技術、その他のリソースで構成されるメカニズム*1) ISO/IEC 2460は以下の３部から構成される。
ISO/IEC 24760-1:2019 A framework for identity management — Part 1: Terminology and concepts
ISO/IEC 24760-2:2015 A framework for identity management — Part 2: Reference architecture and requirements
ISO/IEC 24760-3:2016 A framework for identity management — Part 3: Practice4

用語集
 下記用語は「マネー・ローンダリング及びテロ資金供与対策に関するガイドライン」および関連法規制に則る。
また一部海外事例にて使用した用語は海外規定を参照する。
用語

定義

疑わしい取引の届出*1)• 犯収法*2)の特定事業者に該当する金融機関等が、特定業務に係る取引について、当該取引において収受した財産が犯罪による収益である疑いがあるかどうか、又は顧客等が当該取引に関し組織的犯罪処罰法*3)第10 条の罪若しくは麻薬特例法*4)第６条の罪に当たる行為を行っている疑いがあるかどうかを判断し、これらの疑いがあると認められる場合においては、速やかに、政令で定めるところにより、政令で定める事項を届け出る義務（犯収法第８条第１項、同法施行令*5)第16 条）。
（参考：FATF勧告20*6)）• 金融機関が、資金が犯罪活動の収益ではないか、又はテロ資金供与と関係しているのではないかと疑うか又は疑うような合理的な根拠を有する場合には、法律または規制に基づいて、その疑いを金融情報機関(FIU)に速やかに届け出ること。

金融包摂*7)• 個人や企業が、信頼があり持続可能な方法により、取引、支払、貯蓄、与信、保険といった要望を満たしかつ有益な金融商品やサービスを手頃な価格で利用可能なこと。

*1) マネロン・テロ資金供与対策ガイドラインに関するよくあるご質問 (FAQ) https://www.fsa.go.jp/news/r2/2021_amlcft_faq/2021_amlcft_guidelines_FAQ.pdf*2) 犯罪による収益の移転防止に関する法律 https://elaws.e-gov.go.jp/document?lawid=419AC0000000022*3) 組織的な犯罪の処罰及び犯罪収益の規制等に関する法律 https://elaws.e-gov.go.jp/document?lawid=411AC0000000136*4) 国際的な協力の下に規制薬物に係る不正行為を助長する行為等の防止を図るための麻薬及び向精神薬取締法等の特例等に関する法律
https://elaws.e-gov.go.jp/document?lawid=403AC0000000094*5) 犯罪による収益の移転防止に関する法律施行令 https://elaws.e-gov.go.jp/document?lawid=420CO0000000020*6) The FATF Recommendations https://www.fatf-gafi.org/media/fatf/documents/recommendations/pdfs/FATF%20Recommendations%202012.pdf*7) The World Bank Financial Inclusion https://www.worldbank.org/en/topic/financialinclusion

5

用語集
用語

定義

口座開設 (取引時確認) *1) • 金融機関等が顧客と取引を行うに当たって、当該顧客がどのような人物・団体で、onboarding due
団体の実質的支配者は誰か、どのような取引目的を有しているか、
diligence
資金の流れはどうなっているかなど、顧客に係る基本的な情報を適切に調査し、講ずべき低減措置を判断・実施すること。
継続的顧客管理*2)
ongoing due diligence• 継続的に顧客情報更新や当該顧客が実施する取引内容等を検証し、顧客リスクを再評価するとともにリスク低減措置を判断・実施する一連の流れ。

実質的支配者*3)• 法人である場合において、その事業経営を実質的に支配することが可能となる関係にあるもの。

顧客フィルタリング*2)• 取引前やリストが更新された場合等に、取引関係者や既存顧客等について
反社会的勢力や制裁対象者等のリストとの照合を行うことなどを通じて、
反社会的勢力等による取引を未然に防止することで、リスクを低減させる手法。
いわゆるネームスクリーニングという業務も含む。

取引モニタリング*2)• 過去の取引パターン等と比較して異常取引の検知、調査、判断等を通じて疑わしい取引の届出を行いつつ、当該顧客のリスク評価に反映させることを通じてリスクを低減させる手法。

リスクベース・アプローチ*1)• 金融機関等が、自らのマネロン・テロ資金供与リスクを特定・評価し、これをリスク許容度の範囲内に実効的に低減するため、当該リスクに見合った対策を講ずること。

*1) マネー・ローンダリング及びテロ資金供与対策に関するガイドライン https://www.fsa.go.jp/common/law/amlcft/2021_amlcft_guidelines.pdf*2) *1)およびマネロン・テロ資金供与対策ガイドラインに関するよくあるご質問 (FAQ) を参考に定義*3) 犯罪による収益の移転防止に関する法律施行規則 https://elaws.e-gov.go.jp/document?lawid=420M60000f5a001

6

用語集
用語

定義

AAL*1)• Authentication Assurance Level：
認証プロセス自体、および認証コードと特定個人の識別子の紐付けの頑強性

AML/CFT*2)• Anti-Money Laundering and Combating the Financing of Terrorism：
マネー・ローンダリング及びテロ資金供与対策

eKYC*3)• electric Know Your Customer：
オンラインで完結する自然人の本人特定事項の確認方法

IAL*1)• Identity Assurance Level：
個人のアイデンティティを確信を持って決定するためのアイデンティティ証明プロセスの頑強性

FATF*2)• Financial Action Task Force：金融活動作業部会

KYC*4)• Know Your Customer：顧客確認のプログラム

LEI*5)• Legal Entity Identifier：取引主体識別子

LoA*6)• Level of Assurance：受領した個人のアイデンティティに対する信頼度

NPI*5)• Natural Persons Identifier：自然人識別子*1) NIST Special Publication 800-63-3 Digital Identity Guidelines（日）https://openid-foundation-japan.github.io/800-63-3-final/sp800-63-3.ja.html（英）https://pages.nist.gov/800-63-3/sp800-63-3.html*2) マネー・ローンダリング及びテロ資金供与対策に関するガイドライン（日）https://www.fsa.go.jp/common/law/amlcft/2021_amlcft_guidelines.pdf（英）https://www.fsa.go.jp/common/law/amlcft/en_amlcft_guidelines.pdf*3) 「犯罪による収益の移転防止に関する法律施行規則の一部を改正する命令」の公表について https://www.fsa.go.jp/news/30/sonota/20181130/20181130.html*4) 銀行の顧客確認に関するガイダンス https://www.fsa.go.jp/inter/bis/f-20011004-2.html*5) 日本銀行決済機構局ISOパネル（第1回）https://www.boj.or.jp/paym/iso/iso_panel/data/isop201127.pdf*6) eID Documentation https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eIDAS+Levels+of+assurance

7

第1章

アイデンティティに関わる技術や運用についての基礎

8

1. 本章の概要

9第1章 アイデンティティに関わる技術や運用についての基礎

本章の概要
1-1. デジタルアイデンティティとアイデンティティマネジメントシステム(IMS) アイデンティティとは「ある実体に関連する属性の集合の表現」であり、常に変化・成長するアイデンティティの状態を管理するための仕組みとして、アイデンティティマネジメントシステム（IMS）が必要となる。IMSとは、アイデンティティ情報を維持するためのポリシー、手順、技術、その他のリソースで構成されるメカニズムのことである。
 デジタルアイデンティティとは「ある実体に関連する属性の集合の電子的な表現」である。従来のIMS間のアイデンティティ情報のやり取りについては、紙媒体等を用いたアナログでの処理を行っているシステムも依然として多かったが、デジタルアイデンティティの活用により、このような相互のやりとりをデジタル化すること（例えば、マシンリーダーブルな形式でのアイデンティティエビデンスの連携等）を目指す動きも出てきている（＝IMSのデジタル化）。

1-2. 主要なIMSモデルと構成要素
 現在の主要なIMSモデルは、Centralizedモデルや、フェデレーションモデルであるが、これらモデルを支える技術要素として、プロビ
ジョニング管理、認証、認可、アイデンティティ連携に関するプロトコルの技術標準が策定されている。
 また、IMSを適切に運用していくにあたっては、標準プロトコル等の技術要素だけではなく、ガバナンスの要素も踏まえた設計・運用が重要となる。例えば、欧州ではeIDAS規則として法制化されていたり、米国や英国、カナダなどでもデジタルアイデンティ
ティを適切に設計・開発・運用・利用していくためのガバナンスフレームワーク（トラストフレームワーク）が策定されており、これら
法規制やフレームワークに準拠したデジタルアイデンティティの活用が求められている。

1-3. 自己主権型アイデンティティモデル 既存のIMSモデルには、（悪意を持った）IdPにアカウント停止されるリスクや、（悪意を持った）IdPにアイデンティティを改ざんされるリスクが指摘されており、これら懸念に対応するモデルとして、「自己主権型アイデンティティ(Self-Sovereign Identity: SSI)」、「分散型アイデンティティ(Decentralized Identity: DID)」が提唱されている。
 SSIモデルが提示する①認証と属性の分離、②選択的なクレーム提示、③Unlinkability、④過去取得したクレームの再提示・検証が可能、といった特徴により、既存モデルの懸念を解消する可能性を有している。
10

1-1. デジタルアイデンティティとアイデンティティマネジメントシステム(IMS)111-1.デジタルアイデンティティとアイデンティティマネジメントシステム(IMS)

アイデンティティとは 「アイデンティティ」とは、「ある実体（エンティティ）に関連する属性（アトリビュート）の集合」（ISO/IEC 24760）
である。なお、エンティティは人だけでなく、組織やモノも含まれる。
 例えば、エンティティが人の場合、「属性」には以下のような情報が含まれる。

人のアイデンティティに含まれる属性例

関連性/評判

識別子/
クレデンシャル

ユーザ属性

基本的属性
（性別、年齢、生年月日・・）
付加的属性（生体パタン、名前、趣味、所属・・）

他社との関係性、評判、信頼情報

サービス利用履歴

医療診断履歴、購買履歴、写真、
ロケーション、日記、つぶやき…

121-1.デジタルアイデンティティとアイデンティティマネジメントシステム(IMS)

アイデンティティの特徴
 サービス利用や関係性とともに属性も増えるため、アイデンティティは一定のものでなく、属性の増加・変更に伴い変化・成長していく点が特徴である。

アイデンティティの変化・成長例

メールアドレス

ユーザ属性

決済手段

利用・購買履歴

行動履歴、発言・評判

13

1-1.デジタルアイデンティティとアイデンティティマネジメントシステム(IMS)

デジタルアイデンティティとは 「デジタルアイデンティティ」は、各国・機関において様々な定義がなされているが、グローバルで定まっていないため、本調査では、ISO/IEC 24760のアイデンティティの定義(p.3)に沿って「ある実体に関連する属性の集合の電子的な表現」と定義する。
主要組織におけるデジタルアイデンティティの定義例
団体

デジタルアイデンティティの定義

米国政府

デジタルアイデンティティとは、オンライン・トランザクションに従事する対象者の固有の表現である。

英国政府

デジタルアイデンティティとはあなたが誰であるかのデジタル表現である。

豪州政府

デジタルアイデンティティとは、オンラインでやり取りする際に、エンティティを十分に識別できるようにするためのエンティティの電子的表現である。

(US, “NIST SP 800-63 revision 3”)(UK, “The UK digital identity and attributes trust framework”)(Australia, “The Trusted Digital Identity Framework”)

ITU

デジタルアイデンティティとは、デジタル・コンテキストの中で個人を識別できるほど詳細なエンティ
ティのデジタル表現である。(ITU, X.1252 “Baseline identity Management terms and definitions”)

World
Bank

デジタルアイデンティティとは、個人を一意に識別することができる電子的に捕捉され保存された属性および認証情報のセットである。 (ID4D, “Technical Standards for Digital Identification Systems”)

出所）各HPをもとにNRI作成。

14

1-1.デジタルアイデンティティとアイデンティティマネジメントシステム(IMS)

デジタルアイデンティティの特徴
 現実世界における個人の属性を容易にデジタル化できるようになったことで、個人は利用するデジタルサービスに応じて、様々なデジタルアイデンティティを使い分けて利用することが可能になった。
 現実世界のアイデンティティと比較し、デジタルアイデンティティは容易に作成・利用できる点が特徴の一つであると言える。

現実世界のアイデンティティ

デジタル世界のアイデンティティ
社員ID：12345
メールアドレス：
XX@YY.co.jp

実体としての
個人

電車に乗る

勤務先での

活動
SNS上の
情報発信

氏名：XX一郎
身長：〇〇
職業：会社員
住所：東京都～出所）NRI作成

ID：Xxichiro
Password:XXXX
位置情報：～

15

1-1.デジタルアイデンティティとアイデンティティマネジメントシステム(IMS)

アイデンティティ管理システム(IMS)とは
 ICTシステムなどにおいて管理されるアイデンティティはアイデンティティ情報として管理される。アイデンティティ情報を適切に管理するためには、アイデンティティ情報を維持するためのポリシー、手順、技術、その他のリソースで構成されるメカニズム（＝アイデンティティ管理システム：IMS）が必要となる。
 IMSは管理的活動（アイデンティティ情報の管理やポリシー管理）とリソースアクセス活動（認証や属性情報の取得）が主な役割。

IMSの主な仕組み
アイデンティティ管理システム(IMS)
アイデンティティ
情報の管理

ユーザ認証

要求された属
性の取得

ポリシー管理IMS管理者

ユーザ

サービスへのアクセス

サービス提供IMSを用いたICTシステム
出所）ISO/IEC24760-2を元にNRI作成

16

1-1.デジタルアイデンティティとアイデンティティマネジメントシステム(IMS)「アイデンティティの7原則」
 元マイクロソフトのアイデンティティ・アーキテクトで、アイデンティティに関する国際的な議論に多大な影響を与えたキムキャメロン氏は、アイデンティティの管理での「アイデンティティの7原則（Seven Laws of Identity)」を提唱している。
 IMSにおいてもこれら原則に基づく設計・開発・運用をしていくことが重要である。
#

原則

1 ユーザによる制御と同意内容•

アイデンティティ・システムは、ユーザの同意がなければユーザを識別する情報を開示すべきではない

2

限定された用途で最低限の公開•

最も安定し、長期にわたって使用できるソリューションとは、開示するアイデンティティ情報を最小限にし、情報へのアクセスを適切に制限するソリューションである

3

正当な関係者のみへの情報開示•

アイデンティティ・システムは、特定の状況において識別情報を必要とし、かつ入手できる正当な権利を持つ関係者のみに対して情報を開示するように設計されなければならない•

アイデンティティ・システムは、公に使用する「全方位的」な識別子とプライベートで使用する「特定の方向性」を持った識別子の両方をサポートしなければならない。このことにより公共性を維持しながら不必要に関連付けの公開を防止できる•アイデンティティ・システムは、複数のアイデンティティ・プロバイダによって実行される複数のア
イデンティティ技術の相互運用性を保持しなければならない•

アイデンティティ・システムは、利用者たるユーザを分散システムの1つのコンポーネントとして定義しなければならない。明確なマンマシン・インターフェイスを策定してユーザを分散システムに統合し、アイデンティティを保護しなければならない•

アイデンティティ・システムは、さまざまな状況下でのアイデンティティ・コンテキストの分離を可能にしつつも、一貫性のあるユーザとテクノロジのインターフェイスを提供しなければならない

方向づけられたアイデンティ
4
ティ
5

複数のアイデンティティ・プロバ
イダと技術の相互運用性

6 人間の統合

7

シンプルで一貫性のあるユー
ザ・エクスペリエンス

出所）Kim Cameron, “The Laws of Identity” https://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf
日本語訳は、崎村夏彦、「アイデンティティの7原則」 https://www.sakimura.org/2011/05/1104/ を参照

17

1-1.デジタルアイデンティティとアイデンティティマネジメントシステム(IMS)

アイデンティティ管理のデジタル化
 IMS間のアイデンティティ情報のやり取りについては、依然として紙媒体等を用いたアナログでの処理を行っているシス
テムが多い（一例として、アイデンティティプルーフィングに用いられるアイデンティティエビデンスの連携手段として免許証のコピーを郵送する等）。
 本調査では、アイデンティティマネジメントシステムのデジタル化とは、このような相互のやりとりをデジタル化すること（例えば、マシンリーダーブルな形式でのアイデンティティエビデンスの連携等）と捉える。

アナログのIMS（例）

デジタルのIMS（例）• 本人は、金融機関での新規口座開設にあたり、本人確認書類として、公的身分証のコピー（紙）を金融機関に提出• 金融機関はアナログ情報をもとに本人確認を実施• 本人は、金融機関での新規口座開設にあたり、本人確認書類として、（デジタルな）公的身分証を金融機関に連携。
• 金融機関はマシンリーダブルな形式で連携された公的身分証の検証を行うことができる。

電子署名

公的身分証
（デジタル/紙/カード）
公的身分証（デジタル）

公的身分証コピー（紙/画像データ）

免許証（紙/画像データ）

公的機関

確認書類

電子署名

公的身分証
（デジタル）

アナログ
IMS

金融機関

公的身分証
（デジタル）

公的身分証（デジタル）

公的機関

確認書類

デジタル
IMS

金融機関
18

1-1.デジタルアイデンティティとアイデンティティマネジメントシステム(IMS)

IMSを構成する主要アクター
 IMSを構成する主要アクターとして、サービス提供事業者であるリライングパーティへのクレーム（エンティティの属性集合のうちの一部）
連携時（＝フェデレーションモデル）を例とすると、以下のアクターが存在する。
IIA

CP

CP

⑨クレームB取得

CSP
⑦認証

IdP

⑩⑨で取得したクレームBの情報を元にクレームAを発行⑧認可（アクセストークン付与）⑤クレームB要求⑥IdPにクレームBを連携してよいかどうか確認（認可）RP

CSP③クレームA
発行要求

④認証

RP
⑫クレームAの検証

クレームA：RPのサービス利用に必要な属性集合
クレームB：プリンシパルの本人確認に必要な属性集合⑪クレームA連携①サービス利用の要求②クレームAを提示するよう要求⑬サービスを提供

ユーザ（プリンシパル）
アクター（ロール）#
1 プリンシパル (Principal)

定義
IMSによりアイデンティティ情報が保存、管理されているエンティティ
アイデンティティの一つ以上の属性値の妥当性および／または正しさについて証明可能な記述を行うことができるエンティティ
利用可能なアイデンティティ情報を提供し、アイデンティティ情報を作成・維持するエンティティ。
IIAがIdPの役割を担う場合もある
アイデンティティ情報プロバイダー(Identity information provider：IIP)とも呼ばれる。
クレデンシャル（認証時に利用するアイデンティティの表明。例えばユーザID、パスワード）の管理責任を負う、信頼済みエンティティ。

2

アイデンティティ情報オーソリティ(Identity Information Authority：IIA)

3

アイデンティティプロバイダ(Identity Provider：IdP)

4

クレデンシャルサービスプロバイダ(Credential Service Provider：CSP)

5

クレームプロバイダ(Claims Provider: CP) クレームを提供するエンティティ

6

リライングパーティ (Relying Party: RP) 特定のエンティティのアイデンティティ情報のベリフィケーションに依拠するエンティティ

出所）ISO/IEC24760-1、OpenID Connect Core 1.0を基にNRI作成

19

1-2. 主要なIMSモデルと構成要素

20

1-2. 主要なIMSモデルと構成要素

集中型モデルとサードパーティIdP/フェデレーションモデルIMSのモデル/スキームとして、これまで/現在の代表的なものとしては以下の2つのモデルが挙げられる。
 Centralized（集中型）モデル• RPがIdPとなり個別にアイデンティティ管理とサービス提供を行う。ユーザはサービス毎にアイデンティティ管理が必要
例：ユーザはA銀行、B銀行、C銀行のオンラインバンキングにアクセスする際、各行で作成したオンラインアカウントで個別にログインし、個別にオンラインバンキングにアクセスする。

 フェデレーションモデル
•RPとIdPは別エンティティであり、ユーザはRPのデジタルサービスにアクセスする際、IdPのアイデンティティ情報を用いる。
ユーザはRP毎にログインする必要なく、特定のIdPのアイデンティティ情報をもとに、複数のRPにアクセスできる。
例：ユーザは、A銀行、B銀行、C銀行のオンラインバンキングにアクセスする際、D銀行が提供するアカウントを使って、A～Cの各行のオンラインバンキングにアクセスする。

集中型モデルフェデレーションモデル

ユーザ

ユーザ
D銀行
IdP

A銀行
IdP

B銀行
IdP

C銀行
IdP

A銀行
RP

B銀行
RP

C銀行
RP
21

1-2. 主要なIMSモデルと構成要素

主要IMSモデルにおいて用いられる主な技術要素
 デジタルアイデンティティの活用において用いられているプロトコルと代表的な仕様は以下の通り。
プロトコル概要

仕様名
標準化団体名OpenID Connect
アイデンティティフェデレーションの一種で、アイデンティティアサーションの手法のプロトコル

アイデンティティ連携

OpenID Foundation

OAuth 2.0
リソースを処理するための認可を提供するデータのフォーマットと、
そのやり取りをするプロトコル

IETF

認可
FIDO

エンティティをオーセンティケーションする
プロトコル

認証

FIDO Alliance & W3C

SCIM 2.0
アイデンティティ情報を記載・やり取りするプロトコル

出所）NRI作成

プロビジョニング管理

IETF

22

1-2. 主要なIMSモデルと構成要素

プロビジョニング管理：SCIM 2.0とは
 SCIM 2.0 (System for Cross-domain Identity Management 2.0)

アイデンティティ連携
認可
認証
プロビジョニング管理

 Webサイトやアプリケーション等のクライアントからWebアプリケーションのサービスプロバイダに、
IMS内で管理されているアイデンティティ情報に対しプロビジョニング（管理指示）を行うためのプロトコルの仕様。
•

登場の背景

•

•

仕様の特徴
•

•

仕様の詳細

•

インターネットの普及・拡大に伴い、単一のドメインだけに閉じず、横断的にアイデンティティ情報の管理指示（プロビジョニング）を行う必要が生じた。
プロビジョニング処理の標準化を目指し、SPLM（Service Provisioning Markup Language）というプロトコルが策定されたが、SPLMは仕様が複雑かつ相互運用性が悪く普及しなかった一方、クラウドサービスの発展と利用機会の増加に伴い、使い勝手の良い新たな仕様が必要となった。
2015年に公開されたSCIM 2.0では、アイデンティティ情報を共通のスキーマのJSON形式で記述すること、
RESTfulなWeb APIでCRUDに特化した処理を行うこと、といった拡張性は持ちつつもシンプルな仕様とすることで、使い勝手の良いプロトコルとして利用の拡大が進んだ。
各種サービスがSCIMに準拠や対応することで、Webサイトやアプリケーションは単一の方法に対応することで、多様なアプリケーションからのプロビジョニングが可能となった。
SCIM 2.0は、Webサイトやアプリケーション等のクライアントが、HTTPのRESTプロトコルのリクエストメソッドを用いて、プロビジョニング（管理指示）を行うことが出来る。
指示の対象として、WebアプリケーションのIMS内においてJSON形式で管理されているアイデンティティ情報（属性（アトリビュート））の群（「リソース」）が規定されている。

出所）情報処理推進機構 『情報セキュリティ技術動向調査（2011年上期）』（https://www.ipa.go.jp/security/fy23/reports/tech1-tg/a_08.html）
System for Cross-domain Identity Management （http://www.simplecloud.info/） 、IETF RFC:7643 SCIM Core Schema（https://tools.ietf.org/html/rfc7643） をもとにNRI作成

23

アイデンティティ連携
認可
認証
プロビジョニング管理

1-2. 主要なIMSモデルと構成要素

プロビジョニング管理：SCIM 2.0とはSCIM 2.0によるプロビジョニング処理概要①リクエストWebサイトや
アプリケーション等のクライアント②リソース①RESTプロトコルでのリクエストメソッド
操作内容
作成
閲覧
置換
削除
更新

Web
API

HTTP Webアプリケーションのサービスプロバイダ②「リソース」の種類がユーザである場合の属性（アトリビュート）例

属性名

配下属性名

userName

name

概要
ユーザ名

Formatted

フルネーム 例：“Mr. Kenta Christopher Yamada, II”

familyName

性 例：”Yamada”

givenName

名 例：”Kenta”

middleName

ミドルネーム 例：”Christopher”

honorificPrefix

敬称 例：”Mr.”

honorificSuffix

接尾辞 例：”II”

displayName

表示名nickName

ニックネーム出所） IETF RFC:7643 SCIM Core Schema（https://tools.ietf.org/html/rfc7643）をもとにNRI作成

24

1-2. 主要なIMSモデルと構成要素

認証：FIDOとは

アイデンティティ連携
認可
認証
プロビジョニング管理

 FIDO (Fast IDentity Online) アイデンティティを操作しようとするエンティティが、以前登録された際と同一のエンティティであることを確認する、多要素認証を行うためのプロトコルの仕様。

登場の背景• 従来のIDとパスワードの組み合わせを用いたオーセンティケーション方式は、ネットワーク上での盗聴、ベリファイアへの不正アクセス、フィッシングサイト等による中間者攻撃でのクレデンシャル窃取、リスト型攻撃、といったリスクが存在していた。
• これに対応する為、クレデンシャルの窃取による不正ログインや、ユーザエクスペリエンスを低下させない
多要素認証の仕様が求められていた。

仕様の特徴• FIDOプロトコルは、標準的な公開鍵暗号方式を用いて堅牢な認証を実現可能としている。
• オンラインサービスへの登録時、ユーザのクライアントデバイスで新しい鍵ペアを生成し、秘密鍵はクライアント
デバイスに保持し、公開鍵のみオンラインサービスに登録される。クライアントデバイスが秘密鍵を用いチャレンジに署名することにより、秘密鍵を保持していることをオンラインサービスに証明し、認証を行う。
• クライアントデバイスに保持された秘密鍵は、ユーザがデバイス上でロック解除を行うことで使用可能となる。ロッ
ク解除には、指紋認証、顔認証、暗証番号入力、2段階認証デバイス挿入など、ユーザにとって使いやすく安全なアクションを採用可能である。

仕様の詳細• FIDOの仕様策定と普及活動を担うFIDO Allianceでは、当初はUAF（Universal Authenticator
Framework）、U2F（Universal Second Factor）と呼ばれる仕様策定を行った。
• その後、インターネットに関連する標準技術仕様を策定するW3Cにより、WebブラウザをFIDOクライアントとして機能させFIDO認証器にアクセスする為のAPI仕様を定義した、WebAuthn（Web Authentication
API）が策定された。加えて、FIDOクライアントと認証器間の通信仕様を規定したCTAP （Client toAuthenticator Protocol）が策定され、併せてFIDO2と呼んでいる。

出所） FIDO Alliance 『仕様概要』 （https://fidoalliance.org/仕様概要/?lang=ja）をもとにNRI作成

25

アイデンティティ連携
認可
認証
プロビジョニング管理

1-2. 主要なIMSモデルと構成要素

認証：FIDOとは

 秘密鍵はクライアントデバイス（認証器）に保持し、公開鍵のみオンラインサービスに登録される。クライアント
デバイスが秘密鍵を用いチャレンジに署名することにより、秘密鍵を保持していることをオンラインサービスに証明し、認証を行う。
FIDO2でのオーセンティケーション概観
ユーザ（プリンシパル）側

Web/ネイティブアプリユーザ（プリンシパル）が認証器の中でオーセンティケーションを実施

FIDOクライアント（OS/Webブラウザ）② プリンシパルが保持する認証器でのベリフィケーション
結果をIMS側に送付

サービス側
（IMS）
アプリケーションサーバ(FIDO RP)

③ 結果のベリフィケーションを実施① ユーザ（プリンシパル）による
オーセンティケーション

プリンシパルが保持する認証器
ユーザ（プリンシパル）

秘密鍵出所）FIDO Alliance “FIDO2: WebAuthn & CTAP”（https://fidoalliance.org/fido2/）
厚生労働省 『認証認可調査研究事業一式 報告書（令和２年９月）』（https://www.mhlw.go.jp/stf/newpage_14525.html）をもとにNRI作成

FIDOサーバ
公開鍵26

1-2. 主要なIMSモデルと構成要素

認可：OAuth 2.0とは
 OAuth 2.0

アイデンティティ連携
認可
認証
プロビジョニング管理

 データ（例：アイデンティティ情報）やサービスといったリソースを処理するための認可を提供するデータのフォーマットと、
そのやり取りをするためのプロトコルの仕様。

登場の背景• 認可の概念を定義したOAuthプロトコルが規定されるまでは、特定のリソースに対し処理させたいアプリケーショ
ン等に対し、IDとパスワードといったクレデンシャルを委ねる必要があった。
• このため、アプリケーションの情報漏えい時にリソースに全面的にアクセスできるクレデンシャル（パスワード）も流出されうるリスク、不必要なリソースへのアクセス権限までも付与する危険性、アプリケーションによるアクセスを制限（停止）する方法がクレデンシャルの変更に限定される、等の課題があった。
• このため、権限を限定とした個別のクレデンシャルを付与可能で、リソースのオーナーによって任意のタイミングでアクセスも制限できる仕様が求められていた。

仕様の特徴• OAuth 2.0は、アクセス権限を委譲する、認可という考えで規定されたOAuth 1.0から発展されている。
• 権限が限定された個別のクレデンシャル（トークン）を提供し、アプリケーションの情報漏えい時には全面的な権限を持つクレデンシャルまでは流出せず、不必要なリソースへのアクセスも制限でき、任意のタイミングでクレデンシャルを無効にすることが可能になった。

仕様の詳細• OAuth 2.0ではリソースの所有権を持つエンティティ（リソースオーナー）、リソースをリソースオーナーに代わって保持と保護するサーバ（リソースサーバ）、リソースオーナーの認可を得たうえでリソースにアクセスしようとする
アプリケーション等（クライアント）、認可のやり取りの機能を提供する認可サーバに役割を分担している。

出所） OAuth “Introduction” （https://oauth.net/about/introduction/）
IETF RFC:6749 The OAuth 2.0 Authorization Framework（https://tools.ietf.org/html/rfc6749 ）をもとにNRI作成

27

アイデンティティ連携
認可
認証
プロビジョニング管理

1-2. 主要なIMSモデルと構成要素

認可：OAuth 2.0とはOAuth 2.0の概観の流れ③クライアントは自らの情報と共に認可サーバに認可グラントを提示し、アクセストークンを要求①リソースにアクセスしたいクライアントがリソースオーナーに対して認可を要求②リソースオーナーはクライアントに、
クライアントが保護されたリソースに対してアクセスを行うことに対する認可を提示（認可グラント）
リソースオーナー④認可サーバはクライアントのオーセンティケーションを行い、認可グラントの正当性を確認し、正当なものであることが確認できればアクセストークンをクライアントに対して発行

認可
サーバ

クライアント⑤クライアントはリソースサーバに対してアクセス
トークンを提示してリソースへのアクセスを要求⑥リソースサーバはアクセストークンの正当性を確認し、確認できればリソースへのアクセスをクライアントに提供

出所）IETF RFC:6749 The OAuth 2.0 Authorization Framework（https://tools.ietf.org/html/rfc6749 ）をもとにNRI作成

リソース
サーバ

28

1-2. 主要なIMSモデルと構成要素

アイデンティティ連携：OpenID Connectとはアイデンティティ連携
認可
認証
プロビジョニング管理

 OpenID Connect
 IMSが他のIMSに対してアイデンティティ情報を渡す、アイデンティティフェデレーションを行うためのプロトコルの仕様。

•

登場の背景

•

•

OpenID ConnectはOpenID FoundationによってOAuth 2.0を土台として2014年に公開され、XMLではなくJSON形式での軽量なデータ記述を採用した点、RESTfulなプロトコルでやり取りが可能な点などから、広く利用されるようになった。

•

OpenID Connectは OAuth 2.0 認可プロセスに認証の概念を拡張することで、セキュアなID連携とAPI連携を利用可能としている。
リライングパーティー（OAuth 2.0でのクライアント）はOpenID Provider（OAuth 2.0での認可サーバ）からのユーザのオーセンティケーションの結果やアイデンティティ情報が含まれる「IDトークン」と呼ばれるJSON Web
Token（JWT）を受け取るか、もしくはリソースサーバから、ユーザの情報の集合体であるクレームとしてアイデンティティ情報を受け取る。

仕様の特徴

仕様の詳細

Webサービスにおけるシングルサインオンの需要等に対し、IMS同士のフェデレーションの実現手段として、
SAML（Security Assertion Markup Language）呼ばれるプロトコルが策定された。
同プロトコルは事前に公開鍵とメタデータの交換を行った上でフェデレーションを行う必要があり、またXML形式を重視したマークアップ言語の為、より軽量な言語を用いたフェデレーションのプロトコルの登場が期待されていた。

•

出所）総務省「情報流通連携のためのオープンなID連携プラットフォームにおけるプライバシー保護機能の高度化の研究開発（平成24）」（https://www.soumu.go.jp/main_content/000256289.pdf）、及びOpenID Connect Core 1.0 incorporating errata set 1（https://openid.net/specs/openid-connect-core-1_0.html）をもとにNRI作成

29

アイデンティティ連携
認可
認証
プロビジョニング管理

1-2. 主要なIMSモデルと構成要素

アイデンティティ連携：OpenID ConnectとはOpenID Connectの処理概観②OPがユーザのオーセンティケーションを実施①RPがOP（OAuth 2.0での認可サーバ）に対して
オーセンティケーション要求を実施

ユーザ③OPがRPにIDトークンとアクセストークンを発行

RP
リライング
パーティー

④RPはユーザのアイデンティティ情報を保持しているリソースサーバ（OPと同一の場合もある）にアクセストークンを提示し、アイデンティティ情報を要求

OP
OpenID
Provider⑤リソースサーバはアクセストークンの正当性を確認し、確認できればクレームをRPに提供

出所）OpenID Foundation “OpenID Connect Core 1.0 incorporating errata set 1”の1.3 Overview（https://openid.net/specs/openid-connect-core-1_0.html）をもとにNRI作成

30

1-2. 主要なIMSモデルと構成要素

デジタルアイデンティティのガバナンスフレームワーク（トラストフレームワーク）
 IMSを適切に運用していくにあたっては、標準プロトコル等の技術要素だけではなく、ガバナンスの要素も踏まえた設計・運用が重要となる。
 デジタルアイデンティティのガバナンスに関するルールとして、諸外国では「トラストフレームワーク」という名称で策定・公表されているものが多い。例えば、国際非営利団体のOpen Identity Exchange(OIX)は、トラストフレームワークを「ユーザや組織、サービスそしてデバイスが相互にトラストできるようにするためのルール体系に基づきガバナンスされたアイデンティティトランザクションのための環境」と定義し、以下の項目についてのルール/ガイドを作成・公表している。
OIXのトラストフレームワークで規定される構成要素
構成要素

項目

原則
トラストマークとUX

構成要素

項目

構成要素

リライングパーティサービスアイデンティティサービスへのユーザア
クセス

技術・セキュリ
ティ要件

役割と義務
一般ルール

記録保存と監査証跡
不正行為とサイバーコントロール

ユーザサービス

IDの作成＆管理
トラストの獲得と提示

レクエスト＆レスポンス(API)RPによるID保証

証跡の記録と提示

ライアビリティ

リクエスト及びレスポンススキーム
相互運用性

同意
ヘルプ＆サポート

出所）OIX,” OIX Guide to Trust Frameworks(version 0.1 Beta)”

プルーフィング

内部の相互運用性
外部の相互運用性

ヘルプ＆サポートトラストルール

セキュリティルール
エコシステム参加者のトラストレジス
トリ

サービスレベル

デジタルアイデンティティの選択

項目

ガバナンス

トラストフレームワークの構築と管理

アイデンティティ保証

トラストフレームワークの強制力

認証

トラストフレームワークの認証

適格性保証

トラストフレームワークの運用

31

1-2. 主要なIMSモデルと構成要素

諸外国におけるデジタルアイデンティティに関する主なガバナンスフレームワーク 多くの国では政府機関や民間事業者等が適切にIMSを運用するためのガバナンスフレームワーク（トラストフレームワーク）を策定・発行しており、各IMS運営主体はこれらを踏まえたガバナンスの態勢構築が求められている。
 日本においては、犯罪収益移転防止法や携帯電話不正利用防止法、電子署名法等で本人確認に関する要件は規定されているが、デジタルアイデンティティ全般のガバナンスフレームワークは存在していない。

諸外国におけるデジタルアイデンティティに関する主なガバナンスフレームワーク

国

発行組織

米国

NIST

ガバナンスフレームワーク
NIST SP800-63シリーズ(2017)•

アメリカ国立標準技術研究所(NIST)は、「電子的認証に関するガイドライン」として
SP800-63シリーズを策定しており、政府機関のみならず民間部門も含めて広く参照されるガイドラインとなっている。

•

eID（電子本人確認）とeトラストサービス（電子署名、電子シール、タイムスタンプ、
電子配布、ウェブサイト認証等）について定めたもので、EU加盟国に法律として適用される。(2014年7月23日批准)

EU

欧州委員会

豪州

デジタルトランス
フォーメーション庁

Trusted Digital Identity
Framework•

豪州のデジタルトランスフォーメーション庁は、2018年2月にTrusted Digital Identity
Framework(TDIF)を公表。デジタルアイデンティティサービスのプロバイダーの認証の基
準やルールを規定。

UK Digital Identity and
Attributes Trust
Framework•

英国

デジタル・文化・
メディア・スポーツ省

2021年2月にしたデジタルアイデンティティを活用する事業者（アイデンティティサービス
プロバイダー、アトリビュートサービスプロバイダー、オーケストレーションサービスプロバイダー、
リライングパーティ）向けのガイドライン（アルファ版）。将来的にプロバイダーの認証を行うことを目指し、必要となる要件などについて明記。

カナダ

DIACC
※非営利団体Pan-Canadian Trust
Framework (PCTF) 1.0••

カナダ財務省のタスクフォースでの提言を受け2012年に設立された非営利団体。
PCTFはカナダの政府機関や民間事業者がデジタルアイデンティティを利用する際のフレームワークとして策定。

•

OIXは2010年に発足した非営利団体。米国政府の要望により、OpenID
FoundationとInformation Card Foundationの資金等をもとに設立。
トラストフレームワークは、デジタルアイデンティティを活用する事業者向け、原則や内容、責任などについて具体的に既定。
32

-

OIX
※非営利団体出所）各種HPをもとにNRI作成

eIDAS規則概要

OIX Guide to Trust
Frameworks•

1-3. 自己主権型アイデンティティモデル33

1-3. 自己主権型アイデンティティモデル

フェデレーションモデルに対する懸念
 現在フェデレーションモデルが主流となっており、IdPへの依存度が高まっている。
 しかしながら、特定のIdPに依存することに対する懸念点も指摘されている。例えば、以下のようなリスクが顕在化した
場合、ユーザに与える影響は甚大である。
① IdPにアカウント停止されるリスク（悪意あるIdPが故意に停止したり、倒産等で停止される等）② （悪意を持った）IdPにアイデンティティを改ざんされるリスク

 これら懸念を解決しうるアイデンティティ管理の思想として、「自己主権型アイデンティティ(Self Sovereign Identity:
SSI)」と、その仕組みとして「分散型アイデンティティ(Decentralized Identity: DID)」が提唱されている。
例：IdPにアカウント停止されるリスク

例：IdPに改ざんされるリスク• IdPがユーザのアカウント停止することで、ID連携で活用しているその他サービスも利用できなくなってしまう。

• IdPが、意図的にユーザのアイデンティティを改ざんし、改ざんされたクレームがRPに連携されてしまうリスクがある。

改ざんされた
クレームを連携
IdP

アカウント ユーザ
停止

IdP
RP

出所）NRI作成

改ざん

ユーザ
RP
34

1-3. 自己主権型アイデンティティモデル

自己主権型アイデンティティ/分散型アイデンティティとは 自己主権型アイデンティティ(Self-Sovereign
Identity: SSI)

 分散型アイデンティティ(Decentralized Identity: DID)

 アイデンティティの管理主体が介在することなく、個人が自分自身のアイデンティティをコントロールできるようにすることを目指す思想(※1)。
 ユーザが自分の属性情報に関するコントロール権を確保の上、信頼できる組織から発行された本人の属性情報を取得し、ユーザの許可した範囲でRPに連携する。

 自分自身でデジタルアイデンティティを自己制御できることを目指す思想であるSSIに対し、分散型アイデンティティは、
ユーザのデジタルアイデンティティが特定のIdPに依存しな
いよう、その依存度を下げることを目的とする仕組み。
 実現にあたり、ブロックチェーン等の分散レポジトリの活用が提唱されることが多く、例えば、分散型アイデンティティのホ
ワイトペーパーを公表しているマイクロソフトは以下のように定義している(※2) 。
「分散型アイデンティティとは、ユーザ名などの識別子を、自己所有の独立したIDに置き換え、ブロックチェーンや分散型台帳技術を用いてデータ交換を可能にすることで、プライバシーの保護や取引の安全性を確保することができるトラストフレームワーク」

SSIの概念図

DIDの概念図
IdP
（CP）

ユーザ
（IdP）

RP

ユーザ
IdP

RP

DIDs
ウォレット

分散リポジトリ（例：ブロックチェーン）※1 : Sovrin Foundation, https://sovrin.org/faq/what-is-self-sovereign-identity/※2 : Microsoft, https://www.microsoft.com/en-us/security/business/identity-access-management/decentralized-identity-blockchain35

1-3. 自己主権型アイデンティティモデル

SSIの7原則
 「アイデンティティの7原則（Seven Laws of Identity)」を提唱したKim Cameron氏は、「アイデンティティの7原則」をベースにした「SSIの7原則」を提示している。
 アイデンティティの7原則から、主に原則５及び６がSSI版として更新されている。本更新内容の詳細は3章で詳述。
#

原則

内容

1

ユーザによる制御と同意•

アイデンティティ・システムは、ユーザの同意がなければユーザを識別する情報を開示すべきではない2

限定された用途で最低限の公開•

最も安定し、長期にわたって使用できるソリューションとは、開示するアイデンティティ
情報を最小限にし、情報へのアクセスを適切に制限するソリューションである

3

正当な関係者のみへの情報開示•

アイデンティティ・システムは、特定の状況において識別情報を必要とし、かつ入手できる正当な権利を持つ関係者のみに対して情報を開示するように設計されなければならない•

アイデンティティ・システムは、公に使用する「全方位的」な識別子とプライベートで}使用する「特定の方向性」を持った識別子の両方をサポートしなければならない。
このことにより公共性を維持しながら不必要に関連付けの公開を防止できる

4

方向づけられたアイデンティティ

5「アイデンティティハブ」の統合•

ユーザは、プロバイダ間で一貫した方法で自分自身を表現し、アイデンティティを使用することができ、同時にコンテキスト間でアイデンティティを分離することができる

6

長期のアイデンティティの安定性に向けたDIDの統合•

個人データを事業者に依存しない形で保管したうえで、アイデンティティ事業者を存続させ、サービスとの関係を維持する•

アイデンティティ・システムは、利用者たるユーザを分散システムの1つのコンポーネントとして定義しなければならない。明確なマンマシン・インターフェイスを策定してユーザを分散システムに統合し、アイデンティティを保護しなければならない

7

人間の統合

出所）崎村夏彦、「The Law of Identity in SSI Era by Kim Cameron」を基にNRI作成
https://nat.sakimura.org/2020/06/23/the-law-of-identity-in-ssi-era-by-kim-cameron/36

第２章 金融分野におけるデジタルアイデンティティの活用可能性

37

2. 本章の概要

38

第2章：金融分野におけるデジタルアイデンティティの活用可能性

2. 本章の概要

本章の流れ
第1章：アイデンティティに関わる技術や運用についての基礎
分析手法

2-1

ヒアリング・文献調査

アナログIMS（対面）の課題
AML/CFT／サービス向上に関する課題

アナログIMSのユースケース分析（アイデンティティエビデンスの検証困難性、煩雑な顧客手続き等）

非対面化

2-2

アナログIMS（非対面）の課題
課題の
一部解決

新たに
生じる課題

大半の課題は未解決
デジタル化

対面／非対面での口座開設

書面等のアナログなやり取りによる継続的顧客管理2-3

デジタルIMSの課題

デジタルIMSによる課
題解決

残余課題
2-4

2-5



新たに
生じる課題

課題解決に向けた検討

課題解決の方向性の整理（SSI/DIDによる一部課題解決への示唆含む）

デジタルIMSのユースケース分析
 単独型
 フェデレーション

先進的事例分析

先進的事例分析

第3章：自己主権型アイデンティティ(SSI) /分散型アイデンティティ(DID)の活用可能性と課題
39

2. 本章の概要

調査方法
 次節以降で述べる各種課題の抽出や課題解決の方向性の調査にあたっては主に以下の手法を用いた。
 国内・海外有識者へのヒアリング調査
 文献調査 デジタルアイデンティティを活用した先進的事例の分析
 調査の対象・観点
 金融分野におけるデジタルアイデンティティ活用に関連する多様なステークホルダーを対象にヒアリング、および各ステークホルダーが発行した文献の調査を実施した。
 金融機関の中でも銀行(預金取扱金融機関)の業務を主に想定した業務分析を実施した。
調査対象先と調査の観点
調査対象先

課題抽出/課題解決の方向性調査の観点

国内

金融機関
法曹関係者
ソリューションベンダー• AML/CFT業務を中心とした、アイデンテイティ管理の現状業務の課題• デジタルアイデンティティ活用についての現在の取り組み・課題・今後の展望• デジタルアイデンティティ活用時の法的・技術的課題

海外

金融機関
規制当局/関連団体
国際機関
業界団体
標準化団体
ソリューションベンダー• デジタルアイデンティティ活用に関する現在の取り組み・課題・今後の展望• 顧客利便性向上に資する具体的な活用事例とその課題• リスクベース・アプローチの高度化や金融包摂に向けてのインプリケーション• 規制整備/規制対応の状況・今後の展望• 技術標準化動向
40

2-1. 金融機関のアイデンティティ管理の現状と課題

41

2-1. 金融機関のアイデンティティ管理の現状と課題

本節での議論対象
2-1

アナログIMS（対面）の課題
AML/CFT／サービス向上に関する課題（アイデンティティエビデンスの検証困難性、煩雑な顧客手続き等）

非対面化

2-2

アナログIMS（非対面）の課題
課題の
一部解決

新たに
生じる課題

大半の課題は未解決
デジタル化

2-3

デジタルIMSの課題

デジタルIMSによる課
題解決

残余課題
2-4

2-5

新たに
生じる課題

課題解決に向けた検討

課題解決の方向性の整理（SSI/DIDによる一部課題解決への示唆含む）

42

2-1-1. 金融機関におけるアイデンティティ管理業務の現状

アイデンティティ管理業務の概略
 本章の調査対象分野
 本章において、アイデンティティ情報とは、 1章と同様に、ICTシステムなどにおいて管理されるアイデンティティ（ある実体に関連する属性の集合の表現）を指す。
具体的には、氏名・住所・生年月日等のユーザ属性、ユーザの識別子、取引履歴等を指す。
 本章において、アイデンティティ管理とは、１章で定義した「アイデンティティ管理システム(IMS)」 を通じた活動を指す。具体的には、アイデンティティ情報の管理や、各サービスから要求された属性の提供等を指す。
 本章では、アイデンティティ管理との関連が大きいと考えられる分野を主な調査対象として選定した。
 本人確認が法令で定められる等、アイデンティティ管理が最も厳格に求められるAML/CFT規制対応について、その一部である本人確認に関する業務を中心に議論する。
 加えて、利用者の最善の利益に沿った商品・サービスの提供を目標とする、多面的なアイデンティティ情報を活用した顧客サービスの向上にも言及する。
政策目標

主な対応事項

アイデンティティ管理との関連

金融システムの安定と金融仲介機能の発揮の両立

AML/CFT規制対応

取引時確認、顧客フィルタリング、
分析・評価、判断・対応

利用者保護と利用者利便の両立

利用者の最善の利益に沿った商品・サービスの提供のための努力

アイデンティティ情報を活用した顧客サービスの向上

出所：金融検査・監督の考え方と進め方 （検査・監督基本方針）https://www.fsa.go.jp/news/30/wp/supervisory_approaches_revised.pdf

を元にNRI作成

43

2-1-1. 金融機関におけるアイデンティティ管理業務の現状

アイデンティティ管理業務の概略
 本章で検討する業務の分類
 前頁の対象分野について、本章で検討する業務の種類を、業務の目的と業務の実施タイミングから、３種類に分類する。
 なお、ここでの「onboarding」「ongoing」は業務の実施タイミングの分類を意味し、以降の頁でも同様とする。
• onboarding：口座開設時の業務を意味し、本章においては下図の①を指す。
（本章の範囲では顧客サービスの向上を目的とした業務には口座開設時の業務がないため、用語集に記載のonboarding due diligence（口座開設（取引時確認） を意味する。）• ongoing ：口座開設完了後の業務を意味し、本章においては下図の②と③を指す。
なお、 用語集に記載のongoingduediligence（継続的顧客管理）は②を指す。
業務の実施タイミング

onboarding
業
務
の
目
的

ongoing

AML/CFT規制対応①口座開設（取引時確認）②継続的顧客管理

顧客サービスの向上（アイデンティティ登録前のため業務無し）③社内外のアイデンティティ情報を活用したサービス提供

業務分類毎のアイデンティティ管理業務概略
業務の分類

業務の概略

onboarding ①口座開設（取引時確認）

顧客の口座開設申込～金融機関による審査・開設判断

定期的顧客情報調査 口座保有顧客に対する定期的な属性変更確認②継続的顧客管理 取引受付時確認
ongoing

顧客からの取引申込～金融機関によるリスク確認と取引可否判断

取引モニタリング(事後) 金融機関による顧客の取引傾向分析と顧客リスクの再評価③社内外のアイデンティティ情報を活用したサービス提供金融機関による顧客アイデンティティ情報の収集・分析と顧客サービ
ス向上に資する取り組み（テーラーメードのサービス提案等）
44

AML

2-1-1. 金融機関におけるアイデンティティ管理業務の現状

アイデンティティ管理業務の詳細

サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供①口座開設（取引時確認）

口座開設（取引時確認）の業務プロセス
業務プロセス
申込受領

取引時確認

顧客フィルタリング

分析・評価

判断・対応

各業務のプロセス詳細
口座開設申込書等受領

本人確認・取引目的等の確認

顧客フィルタリング

顧客リスクの評価

口座開設通知 or 疑わしい
取引の届出

• 口座開設申込書類およびアイデンティティエビデンス(定義は次頁参照)を顧客から受領する。

• アイデンティティエビデンスの真正性(申込者本人の正しい情報であること)および有効性(アイデンティティエビデンスが有効であること)を確認し、取引目的および実質的支配者（法人の場合）等もあわせて確認する。
• 反社会的勢力や制裁対象等のリストとの照合、および、取引目的や属性との整合性検証や実質的支配者の確認を通じて、
反社会的勢力や制裁対象者等による口座保有を防止する。

• 取引形態や顧客属性、商品・サービスの特性等を踏まえてAML
リスク等の分析を行い、必要に応じて追加確認を実施する。

• 口座開設の承認と顧客への通知、もしくは口座開設の謝絶と必要に応じて疑わしい取引の届出を行う。
45

2-1-1. 金融機関におけるアイデンティティ管理業務の現状

補足：本章におけるアイデンティティエビデンスの定義と具体例
 本章において、アイデンティティエビデンスは「各法域で認められている本人確認書類/法人確認書類」とする。
アイデンティティ・エビデンスの一例
個人/法人

個人

概要

• 本人確認書類

 運転免許証 パスポート 国民IDカード(例：日本におけるマイナンバーカード)
 在留カード・特別永住者証明書(例：米国のグリーンカード) 等

法人• 法人確認書類

 登記事項証明書
 印鑑登録証明書
 上記のほか官公庁発行書類等で法人の名称及び本店又は主たる事務所の所在地の記載があるもの• 担当者・代表者・実質的支配者の本人確認書類
 個人と同様

46

AML

2-1-1. 金融機関におけるアイデンティティ管理業務の現状

onboarding

ongoing①口座開設②継続的管理サービス

アイデンティティ管理業務の詳細 ②継続的顧客管理③サービス提供②-1 定期的顧客情報調査

定期的顧客情報調査の業務プロセス
業務プロセス
申込受領

各業務のプロセス詳細
顧客情報収集・更新• 顧客リスクに応じた頻度にて定期的に顧客情報を収集（郵送、架電等）し、顧客情報を更新する。

取引時確認

顧客フィルタリング• 反社会的勢力や制裁対象等のリストとの照合、および、取引目的や属性との整合性検証や実質的支配者の確認を通じて、
反社会的勢力や制裁対象者等による口座保有を防止する。

分析・評価

顧客リスクの再評価• 取引形態や顧客属性、商品・サービスの特性等を踏まえて
AMLリスク等の分析を行い、必要に応じて追加確認を実施す
る。

判断・対応

取引リスクの低減 or
疑わしい取引の届出 or
関係の継続• 顧客リスクの再評価を踏まえ、取引金額等の閾値を厳格化す
る等の取引リスク低減措置を実施し、必要に応じ疑わしい取引の届出を行う。

顧客フィルタリング

47

AML

2-1-1. 金融機関におけるアイデンティティ管理業務の現状

onboarding

ongoing①口座開設②継続的管理サービス

アイデンティティ管理業務の詳細 ②継続的顧客管理③サービス提供②-2 取引受付時確認

取引受付時確認の業務プロセス
業務プロセス

各業務のプロセス詳細• 取引申請書類を顧客から受領する。

申込受領

取引時確認

取引申込受領当人認証・取引内容確認• 取引申請者の当人認証を行い、かつ、取引目的や金額等の取引内容を確認する。

顧客フィルタリング• 反社会的勢力や制裁対象等のリストとの照合、および、取引目的や属性との整合性検証や実質的支配者の確認を通じて、
反社会的勢力や制裁対象者等による取引を防止する。

分析・評価

取引リスクの評価• 取引形態や顧客属性、商品・サービスの特性等を踏まえて
AMLリスク等の分析を行い、必要に応じて追加確認を実施す
る。

判断・対応

取引受付 or
疑わしい取引の届出

顧客フィルタリング• 取引の受付、もしくは取引の謝絶と必要に応じて疑わしい取引の届出を行う。
48

AML

2-1-1. 金融機関におけるアイデンティティ管理業務の現状

onboarding

ongoing①口座開設②継続的管理サービス

アイデンティティ管理業務の詳細 ②継続的顧客管理③サービス提供②-3 取引モニタリング(事後)取引モニタリング(事後)の業務プロセス
業務プロセス

各業務のプロセス詳細

申込受領

取引時確認

顧客フィルタリング

分析・評価

取引モニタリング• 過去の取引パターン等と比較して異常取引の検知、調査、判断を行い、当該顧客のリスク評価に反映する。

判断・対応

取引継続 or
疑わしい取引の届出• 取引を継続する、もしくは必要に応じて疑わしい取引の届出する。（疑わしい取引の届出提出の上で、取引を継続し、顧客をモニタリングする事例も含む）
49

AML

2-1-1. 金融機関におけるアイデンティティ管理業務の現状

サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供

アイデンティティ管理業務の詳細 ③社内外のアイデンティティ情報を活用した顧客サービス向上 顧客に紐づく社内外の多様なアイデンティティ情報の収集・分析により、テーラーメードのサービス提案等、顧客サービス向上に資する取り組みを実施する。
社内外のアイデンティティ情報を活用した顧客サービス向上の業務プロセス
業務プロセス
申込受領
取引時確認
顧客フィルタリング• 自社内において、取引情報等顧客に紐づく情報を収集する。

自社内のアイデンティティ情報収集

分析・評価

判断・対応

他社からの
アイデンティティ情報収集• 他社から、金融/非金融の取引情報や非伝統的情報(顧客のサイトアクセス・
位置情報、SNS)等、顧客に紐づく情報を収集する。

アイデンティティ情報分析• 収集した情報から、顧客のファイナンス
ニーズ等を分析する。(例：顧客のECサ
イト購入履歴から教育ローンのニーズがいつ発生するか分析する等)

提供サービス選定/提案• 分析結果に基づき、顧客にとって最適なサービスを選定し顧客へ提案を行う。
50

AML

2-1-1. 金融機関におけるアイデンティティ管理業務の現状

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

依然としてアナログ中心のアイデンティティ管理業務
 アナログのアイデンティティエビデンス*の対面利用、書面の郵送による手続き等、アナログ中心の業務を実施している。
＊アナログのアイデンティティエビデンス：紙・カード・画像等、エビデンスの情報をデータとして読み取ることができないアイデンティティエビデンスを指す

口座開設（取引時確認）

継続的顧客管理（定期的顧客情報調査）

継続的顧客管理（取引受付時確認）

・顧客はアナログのアイデンティティエビ
デンスを金融機関に対面で提出している。
・金融機関は当該エビデンスを元に本人確認を実施している。

・金融機関は顧客情報等確認書類を顧客に郵送している。
・顧客は顧客情報等確認書類(回答) を金融機関に郵送している。
・金融機関は本人確認と属性変更登録を実施している。

・顧客は対面または郵送で金融機関に取引を申請している。
・金融機関は当該エビデンスを元に本人確認を実施している。

対面
提示

発行
アイデンティ
ティエビデンス(紙/カード)顧客

郵送

アイデンティティ
エビデンス(紙/カード)
アナログ
IMS

公的機関

金融機関

*公的機関へのアイデンティティエビデンスの真正性および有効性照会は、アナログのアイデンティ
ティエビデンスでは行われていない

顧客

顧客情報等
確認書類(回答)

郵送

対面/郵送

取引申請書類

顧客

顧客情報等
確認書類

アナログ
IMS
金融機関

アナログ
IMS
金融機関

51

AML

2-1-1. 金融機関におけるアイデンティティ管理業務の現状

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

依然としてアナログ中心のアイデンティティ管理業務
 自社の取引データ等を利用して、分析・評価を実施している。
継続的顧客管理（取引モニタリング(事後)）・金融機関はサンクションリスト等および金額等の閾値や顧客の取引傾向から異常取引を検知している。
・金融機関は検知した異常取引の内容を精査し、精査結果に応じて顧客リスクを再評価している。
・金融機関は検知した異常取引が疑わしい取引に該当する疑いがある場合は、疑わしい取引の届出を実施している。
金融機関
職員
金融機関

取引データ等・金融機関は顧客の属性や取引傾向を分析し、顧客に適したサービスを選定／設計している。
・金融機関は顧客にサービスを提案している。

金融機関
職員

顧客
疑わしい
取引の届出

分析・判断
アナログ
IMS

社内外のアイデンティティ情報を活用した顧客サービス向上

サービス提案

金融機関

金融当局

分析・提案作成
アナログ
IMS

部門別
顧客データ
部門別
顧客データ
52

AML

2-1-2. 対面・アナログIMSの主な課題 ①口座開設（取引時確認）

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供①口座開設（取引時確認） 課題の概要
 金融機関におけるアイデンティティ検証困難性や、顧客の事務負担が主な課題である。
 次頁以降で主要課題（下表ハイライト部分）について詳述する（その他の課題については補足資料参照）。
AML/CFTに関する課題(金融機関/当局)

申込受領

業
務
取引時確認
プ
ロ
セ 顧客フィルタリング
ス

サービス向上に関する課題(顧客/金融機関)

・申込情報やアイデンティティエビデンス情報をデータ ・新興国における遠隔地居住者の金融包摂
化する負担
・顧客の来店負担
・顧客の書類記入負担
・顧客の事務処理待ち時間
・金融機関毎に同様の口座開設申込を行う負担

・アナログのアイデンティティエビデンスの検証困難性
・オペレーショナルコスト(書類保管コスト)
・他社で検証済の顧客を一から検証する負担
・他社で検証済の顧客を一から検証する負担

分析・評価
判断・対応
53

AML

2-1-2. 対面・アナログIMSの主な課題 ①口座開設（取引時確認）

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供【AML/CFT】アナログのアイデンティティエビデンスの検証困難性
 金融機関は実務上、 ①アイデンティティエビデンスの真正性および有効性を照会・確認する仕組みがない、②ヒューマンエラーの可能性、という２つの課題を抱える。
 なお、①の仕組みは、日本においても現状構築されていない。 （次頁参照）

アイデンティティエビデンスの真正性・有効性を確認するフロー（口座開設時）
アイデンティティエビデンス発行元(公的機関)⑤真正性と有効性につ④許可

いて確認結果を回答③金融機関に対し照会結果を返してよいか確認

顧客(NRI作成)②アイデンティティ
エビデンス情報の照会①口座開設依頼・アイデンティティ
エビデンス提示

金融機関 金融機関職員⑥アイデンティティエビデンス
照会結果確認①アイデンティティエビデンスの真正性および有効性を照会・確認する仕組みがない。
• アイデンティティエビデンス発行元（公的機関）に対し、アイデンティティエビデンスの内容が正しくかつアイデンティティエビデンスが有効であることを確認する仕組みがない。
②ヒューマンエラーの可能性• アイデンティティエビデンスの偽造を目視等により検証しているため、担当者の主観的判断や経験不足による誤判定の可能性を排除でき
ない。
54

AML

2-1-2. 対面・アナログIMSの主な課題 ①口座開設（取引時確認）

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

参考：日本の主要なアイデンティティエビデンスにおける真正性および有効性の検証状況
 人の目に頼った真正性および有効性の検証が太宗である。
 なお、免許証とマイナンバーカードは、デジタルアイデンティティエビデンス（ICチップ情報等）の利用により真正性および有効性検証が機能的には可能なだが、実務での活用拡大に関してはコスト面や運用面での課題が指摘されている。
 免許証はICチップに格納された情報により真正性検証可能、マイナンバーカードは公的個人認証の仕組みを使い真正性および有効性の検証が可能である。

 実務での活用に関しては、国内金融機関や有識者へのヒアリングにおいて、ICリーダーの準備コストや参照用暗証番号を忘れている等、幅広い活用に向けた課題が意見として挙がっている。
本邦におけるアイデンティテイエビデンスの真正性および有効性検証可否
アイデンティティエビデンス
対面/
非対面
対面
免許証
マイナンバーカード
その他証明書非対面 証明書の紙コピー
証明書画像
証明書画像+本人容貌写真
免許証（ICチップ読み取り）
マイナンバーカード（ICチップ読み取り）

真正性および有効性の検証状況
真正性
有効性
〇*1)
×
〇
〇
×
×
×
×
×
×
〇*2)
×
*1)
〇
×
〇
〇*3)

*1)犯罪収益等移転防止法第６条第１項第１号へ〇：IC等に保存されたデータを元に照合可能*2)犯罪収益等移転防止法第６条第１項第１号ホ*3)マイナンバーカードによる本人確認のうち、ICチップに記録された公的個人認証用の署名用電子証明書を使用

×：人の目で判断

55

AML

2-1-2. 対面・アナログIMSの主な課題 ①口座開設（取引時確認）サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供【サービス向上】情報のアナログなやり取りに起因する顧客手続の諸課題
 来店や書類記入等、顧客にとって様々な手続負担がある。
対面・アナログIMSでの口座開設における顧客の主な課題
 各金融機関に対して同様の手続を都度行う負担が高い。

■書類記入負担が大きい。
申込書類 アイデンティティ
記入・提出 エビデンス提出

申込書類 アイデンティティ
記入・提出 エビデンス提出
金融機関A

金融機関A職員

顧客

口座開設

 事務処理待ち時間が長い。

金融機関B職員

金融機関B

口座開設

店舗への来店■来店負担により口座申込希望者が脱落する懸念がある。
■新興国では遠隔地居住者が口座開設できない懸念もみられる。

自宅
56

2-1-3. 対面・アナログIMSの主な課題

AML②継続的顧客管理

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供②継続的顧客管理 課題の概要
 AML/CFTにおける金融機関および顧客の事務負担等が挙げられる。
 次頁以降で主要課題（下表ハイライト部分）について詳述する（その他の課題については補足資料参照）。
AML/CFTに関する課題(金融機関/当局)

サービス向上に関する課題(顧客/金融機関)

・取引申請書類をデータ化する負担

取・郵便物の返送手続負担

・大量の顧客に対する検証事務負担

定・取引時のセキュリティリスク 取（非対面でアクセス時のパスワード盗取など）

定

申込受領

業
務
プ
ロ
セ
ス

取引時確認
顧客フィルタリング・アナログの顧客情報収集郵電費・データ化負担 定
分析・評価

凡
例

定 ・・・定期的顧客情報調査
取 ・・・取引受付時確認

判断・対応
57

2-1-3. 対面・アナログIMSの主な課題

AML②継続的顧客管理

サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供

定期的顧客情報調査におけるアナログIMSに起因した諸課題
 定期的顧客情報調査においては、顧客と金融機関の間の書面によるやり取りに起因した事務負担やコスト負担の課題が発生している。
定期的顧客情報調査における諸課題
 顧客情報確認書類が紙ベースであることによる郵電費負担が大きい。
顧客

郵送
顧客情報等
確認書類(回答)

 郵便物の投函等の返送手続負担が大きい。

郵送

顧客情報等
確認書類

金融機関
職員

金融機関

 紙で受け取った顧客情報確認
書類のデータ化負担が大きい。

58

2-1-4. 対面・アナログIMSの主な課題③アイデンティティ情報を活用したサービス提供

AML
サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供③アイデンティティ情報を活用したサービス提供 課題の概要
 データ利活用にあたってのデータ集約に課題がある。次頁で詳述する。
AML/CFTに関する課題(金融機関/当局)

サービス向上に関する課題(顧客/金融機関)

・複数サービス横断で顧客データを利活用するための、データ利用許諾の整備負担

・識別子の不一致によりデータ集約が困難
ー部門/組織毎の管理により顧客識別子不一致
ー他社データとの顧客識別子不一致
・社内外のデータフォーマットの不統一によりデータ集
約が困難
・データ利活用の目的と範囲に関する、顧客と金融機関の認識齟齬リスクの増大

申込受領
取引時確認

業
務 顧客フィルタリング
プ
ロ
セ
分析・評価
ス

判断・対応

59

2-1-4. 対面・アナログIMSの主な課題③アイデンティティ情報を活用したサービス提供

AML

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供【サービス向上】顧客識別子やデータフォーマットが社内で不統一でありデータ利活用が困難
 金融機関における情報分析業務に関して、複数の文献でデータの部分最適化に関する課題が指摘されている。
 銀行の管理会計は縦割りの部門軸であったため、事業部門・プロダクトごとに管理された膨大な数の業務によってマスターデータは部分最適化が進
み、横串での管理が困難な状況であるとの指摘が国内金融機関実務者から上がっている。*1)
 データ設計に関するルールがなく、システム毎にコード体系や粒度が異なり、データの体系を揃えるのに負担が大きくコストも大きいため、分析に有用なデータを提供することができないという問題も有識者から指摘されている。*2)

 社内データが部分最適化されると、顧客識別子やデータフォーマットが部門毎やシステム毎に異なる場合があり、サービス向上に向けた
顧客軸での横断的なデータ分析を十分に行えない、という課題が発生していると考えられる。
 関連する課題として、顧客との間のデータ利用許諾は契約の都度利用目的を明示する形で説明を行う等サービス毎になっている場
合があり 、その場合、顧客軸での横断的な分析にはデータ利用許諾の確認が必要なケースがあると考えられる。また、その際の不十分な顧客への説明により、顧客が顧客自身が望まないデータ利活用を懸念する可能性がある。

データ管理における顧客識別子の不整合
顧客

顧客へのサービス提案

金融機関職員

金融機関

部門A

顧客属性・取引内容等を元に分析・判断
同一顧客を指す
顧客ID

顧客マスタ

顧客1

aaa

部門B

個別管理のため不一致。
顧客軸でのデータ分析に
支障

顧客マスタ
顧客1

bbb

*1)FINANCE FORUM 金融機関に求められるデータ利活用の実践より抜粋 https://thefinance.jp/event/finance-forum-200528*2)金融機関におけるデータを活用した意思決定の高度化(2016) https://www2.deloitte.com/content/dam/Deloitte/jp/Documents/financial-services/bk/jp-fi-datautilization.pdf

60

2-2. onboardingプロセスの非対面化の進展

61

2-2. onboardingプロセスの非対面化の進展

本節での議論対象
2-1

アナログIMS（対面）の課題
AML/CFT／サービス向上に関する課題（アイデンティティエビデンスの検証困難性、煩雑な顧客手続き等）

非対面化

2-2

アナログIMS（非対面）の課題
課題の
一部解決

新たに
生じる課題

大半の課題は未解決
デジタル化

2-3

デジタルIMSの課題

デジタルIMSによる課
題解決

残余課題
2-4

2-5

新たに
生じる課題

課題解決に向けた検討

課題解決の方向性の整理（SSI/DIDによる一部課題解決への示唆含む）

62

AML

2-2-1. onboardingプロセスの非対面化の進展

サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供

onboardingプロセスの非対面化の進展
 eKYC等のリモート・オンボーディングに関する本人確認規定の整備や民間ベンダーによるソリューション提供の拡大に伴い、非対面化による課題解決の動きがみられる。
非対面化による業務プロセスの変化

業
務
プ
ロ
セ
ス

対面・アナログ

非対面・アナログ

申込受領

申込書類記載（対面・アナログ）

書面郵送/Web・画像（非対面・アナログ）

取引時確認

証明書現物
（アナログアイデンティティエビデンス）

証明書コピー郵送/画像（アナログアイデンティティエ
ビデンス）

顧客フィルタリング

現在のアナログIMSや関連システムを前提とした顧客スクリーニング

分析・評価

現在のアナログIMSや関連システムを前提とした情報収集・分析

判断・対応

対面で通知

非対面で郵送/電話等で
通知
63

AML

2-2-2. 非対面化による課題の一部解消

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

非対面化による対面・アナログIMSの課題の一部解消
 顧客・金融機関の一部事務負担は削減されるが、非対面化に伴う本人確認の難度上昇や、本人所在確認のための口座開設郵送通知コスト、Web申込用のインフラ整備・運用コスト（Web申込に対応する場合のみ）が新たに発生している。
：解消される課題

対面・アナログIMSの非対面化による課題の一部解消 青：非対面化に伴い新たに発生する課題
対面・アナログIMSによる
口座開設

非対面・ア
ナログIMS
による口座
開設
(郵送)
非対面・ア
ナログIMSによる口座開設(Web
申込)

店舗への 顧客
来店負担

申込書類記入負担

金融機関職員金融機関

アイデンティティエビデンス検証負担＋
顧客スクリーニング事務負担

店舗への 顧客
来店負担

申込書類記入負担＋郵送負担 金融機関職員 金融機関

口座開設通知郵送コスト

顧客

書類保管コスト

非対面化に伴う本人確認の難度上昇＋顧客スクリーニング事務負担

Web申込入力負担＋郵送負担

口座開設通知郵送コスト

書類保管コスト

Web申込用のインフラ整備・運用コスト
金融機関職員 金融機関

非対面化に伴う本人確認の難度上昇＋顧客スクリーニング事務負担

書類保管コスト64

AML

2-2-3. 非対面化後も残る課題

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

非対面化後も残る課題
 非対面化後も、顧客の事務負担と金融機関の書類保管コスト以外の課題は解消されないまま残存するほか、本人確認の難度上昇等の新たな課題も発生している。
 次頁以降で主要課題(下表ハイライト部分)について詳述する(その他の課題については補足資料参照)。
凡例

申込受領

業
務
プ
取引時確認
ロ
セ
ス 顧客フィルタリング

文字：非対面化により解消される対面・アナログIMSの課題
青字：非対面化により新たに生じる課題

AML/CFTに関する課題(金融機関/当局)

サービス向上に関する課題(顧客/金融機関)

・申込情報やアイデンティティエビデンス情報をデータ化する負担・Web申込用のインフラ整備・運用コスト

・新興国における遠隔地居住者の金融包摂
・顧客の来店負担
・顧客の書類記入負担→Web申込入力負担
・顧客の事務処理待ち時間
・金融機関毎に同様の口座開設申込を行う負担

・アナログ・アイデンティティエビデンスの検証困難性
・オペレーショナルコスト(書類保管コスト)
・他社で検証済の顧客を一から検証する負担・非対面化に伴う本人確認の難度上昇
・他社で検証済の顧客を一から検証する負担

分析・評価
判断・対応

・所在確認のための口座開設通知郵送コスト
65

2-2-4. 非対面化により新たに発生する課題

AML
サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供【AML/CFT】非対面化に伴う本人確認の難度上昇
 非対面取引は、対面取引と比較して、金融機関側が他人へのなりすましを看破する手段が限定されることから、本人確認の精度が低下するリスクを孕んでいる。
 取引の相手方と直に対面しないことで、性別、年代、容貌、言動等を直接確認することで容易に確認できる筈の情報を確認できないまま本人確認を行ってしまうことになる。これにより、本人特定事項の偽りや他人へのなりすましの有無を判断することが困難となる。
 また、顧客本人ではなく、アイデンティティエビデンスの偽変造等についても認識することが難しい傾向がある。アイデンティティエビ
デンスのコピーにより本人確認を行う場合には、その手触りや質感を感知できない。

 非対面でのonboarding業務において、アイデンティティエビデンスの真正性・有効性の検証が不十分にしかできない
アナログIMSを利用している限りにおいては、当該リスクを低減することが困難であり、非対面化により生じる／拡大するリスクが存在することに留意する必要がある。
 このため、一般的には、非対面取引は対面取引より高リスクなものとして金融機関が認識している傾向にある。
犯罪収益移転危険度調査書*1)でも、危険度の高い取引形態の一つとして非対面取引に言及している。

*1) 国家公安委員会,犯罪収益移転危険度調査書（令和2年度版） https://www.npa.go.jp/sosikihanzai/jafic/nenzihokoku/risk/risk021105.pdf

66

2-3. デジタルIMSの活用可能性

67

2-3. デジタルIMSの活用可能性

本節での議論対象
2-1

アナログIMS（対面）の課題
AML/CFT／サービス向上に関する課題（アイデンティティエビデンスの検証困難性、煩雑な顧客手続き等）

非対面化

2-2

アナログIMS（非対面）の課題
課題の
一部解決

新たに
生じる課題

大半の課題は未解決
デジタル化

2-3

デジタルIMSの課題

デジタルIMSによる課
題解決

残余課題
2-4

2-5

新たに
生じる課題

課題解決に向けた検討

課題解決の方向性の整理（SSI/DIDによる一部課題解決への示唆含む）

68

2-3-1. 金融機関のデジタルアイデンティティ活用の重要性

金融機関のデジタルアイデンティティ活用の重要性
 コロナ禍において社会全体のデジタルシフトが加速し、金融取引のデジタル化も急速に進展する中で、AML等のコ
ンプライアンスの観点から、デジタル空間における本人性の確認がより重要になっている。
 手続がデジタルで完結する利便性高いUXが金融においても徐々に普及し、デジタル化への顧客の期待が高まっている。
 前節で整理した、金融機関が直面しているアナログIMSの課題解決として、デジタルIMSの活用が期待されている。
コンプライアンス高度化の要請（AML等）

金融取引のデジタル化

デジタル化によるUX向上に対する顧客の期待

アナログIMSによる顧客管理の限界

顧客管理の高度化＝
デジタルIMSによるデジタルアイデンティティの活用
69

AML

2-3-1. 金融機関のデジタルアイデンティティ活用の重要性

サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供

IMSのデジタル化
 IMSのデジタル化：アイデンティティ情報の相互のやりとりをデジタル化することを指す。
（例えば、マシンリーダーブルな形式でのアイデンティティエビデンスの連携等）
デジタル化によるIMSの業務プロセスの変化

業
務
プ
ロ
セ
ス

対面・アナログ

非対面・アナログ

デジタル(非対面／対面)

申込受領

申込書類記載（対面・アナログ）

書面郵送/Web・画像（非対面・アナログ）

デジタルデータで送付（デジタル）

取引時確認

証明書現物
(アナログアイデンティティエビ
デンス)

証明書コピー郵送/画像(アナログアイデンティティエビ
デンス)

ICチップ読取・発行元照会
等(デジタルアイデンティティ
エビデンス)

顧客フィルタリング

分析・評価

判断・対応

サンクションリスト等とのスクリーニング

サンクションリスト等とのスクリーニング

自社DBのアイデンティティ情報を中心にデータ収集・分析

自社/他社から収集した
多様なデジタルアイデンティ
ティ情報を分析

・対面で通知・当局への届出

・非対面で郵送/電話等で通知・当局へ届出

・非対面でデジタルに通知
・当局へ届出

対面・アナログIMSの
課題：2-1

非対面化により課題の一部が解消：2-2

デジタルIMSによる更なる課題解決：2-370

AML

2-3-2. 分析対象ユースケース

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

分析対象ユースケース
 2-1-1の業務分類の単位でユースケースを設定して分析を行う。
 なお、onboardingプロセスについては、口座開設時のID連携が進むと想定し、（１-１）デジタルアイデンティティエビデンスを利用するパターンと、（１-２）アイデンティティエビデンスは利用せず
他社で作成済のデジタルアイデンティティを利用するパターンの２パターンに分けて分析を行う。
分析対象ユースケースの位置付け
業務の実施タイミング

AML/CFT規制
対応
業
務
の
目
的

顧客サービスの向上

onboarding

ongoing①口座開設（取引時確認）②継続的顧客管理

ユースケース（１-１）
デジタルアイデンティティエビ
デンスを利用した口座開設

ユースケース（１-２）
他社で作成したデジタルアイ
デンティを用いての口座開設

ユースケース（２）③社内外のアイデンティティ情報を活用したサービス提供（アイデンティティ登録前のため業務無し）

ユースケース（３）712-3-3. ユースケース分析 ユースケース（１-１） デジタルアイデンティティエビデンスを利用しての口座開設

AML

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

ユースケースの概要
 マシンリーダブルでデジタルに検証可能なアイデンティティエビデンスを用いて本人確認および口座開設処理を行う
非対面・アナログIMSによる口座開設(Web申込)

Web申込入力＋アナログアイデンティティエビデンス(本人確認書類のコピー・画像等)送付
金融機関職員 金融機関

顧客

口座開設通知郵送

アイデンティティエビデンス検証＋
顧客スクリーニング

公的機関

ユースケース（１－１）デジタルアイデンティティエビデンスを利用した口座開設＊青枠が変更部分

顧客

Web申込入力+デジタルアイデンティティエビデンス提示

口座開設通知(デジタル)

アイデンティティエビデン
スエビデンスの真正性および有効性の照会

結果回答

金融機関職員 金融機関

アイデンティティエビデンス検証＋
顧客スクリーニング72

2-3-3. ユースケース分析 ユースケース（１-１） デジタルアイデンティティエビデンスを利用しての口座開設

AML

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

デジタルIMSによる課題解決：アナログのアイデンティティエビデンスの検証困難性の解消
 マシンリーダブルでデジタルに検証可能なアイデンティティエビデンスの活用により、
アナログIMSにおけるアイデンティティエビデンスの検証困難性等諸課題が解消されうる。
デジタルIMSにおけるアイデンティティエビデンスの真正性および有効性を確認するフロー（口座開設時）

アイデンティティエビデンス発行元(公的機関)④許可③金融機関に対し照会結果を返してよいか確認

顧客①口座開設依頼・
アイデンティティエビデンス提示
アイデンティティ
エビデンス（デジタル）⑤真正性と有効性について確認結果を回答

アイデンティティ
エビデンス（デジタル）②アイデンティティ
エビデンス情報の照会
金融機関 金融機関職員

アイデンティティエビデンスの正しさを照会し確認する仕組みを確立

アイデンティティエビデンス照会作業のデジタル化により、ヒューマンエラーを削減⑥アイデンティティエビデンス
照会結果確認73

2-3-3. ユースケース分析 ユースケース（１-１） デジタルアイデンティティエビデンスを利用しての口座開設

AML
サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供

デジタルIMSによる課題解決：その他アナログIMSの諸課題の解決
アナログIMSにおける口座開設時の課題

デジタルIMSによる解決策

非対面化に伴う本人確認の難度上昇• デジタルIMSによる真正性および有効性の確認により、アイデン
非対面取引は、対面と比較すると、他人へのなりすましを看破
ティティエビデンス改ざんによるなりすましリスクが軽減されうる。
する手段が限定されるため、本人確認の精度が低下するリスク • 生体情報等とのバインドにより、提示されたアイデンティティエビ
がある。
デンスが口座開設を申し込んできた当人であることを確認する
精度が向上し、なりすましリスクが軽減されうる。
所在確認のための口座開設通知郵送コスト
非対面口座開設実施時には、口座開設申込者の届出住所確認のために、転送不要郵便を送付し所在確認を行うため、郵送コスト負担が大きい。

• デジタルアイデンティティエビデンスとして国民IDを利用する場合、国民IDの住所を正として国民IDのアップデートを速やかに取り込む仕組みの構築を行うことで郵便による確認を不要とする。
• 顧客の取引時の位置情報等を参考に届出住所を確認する仕組みを構築することで、郵便による確認を不要とする。

74

2-3-3. ユースケース分析 ユースケース（１-１） デジタルアイデンティティエビデンスを利用しての口座開設

AML
サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供

口座開設のデジタルIMS化により解消される課題と新たに発生する課題
 AML等規制対応の高度化や、口座開設申込における金融機関の省力化が図られる。
 一方、デジタルIMSを活用した本人確認手法の整備等、新たな課題が発生する。
 次頁以降で主要課題（下表ハイライト部分）について詳述する（その他の課題については補足資料参照）。
凡例

口座開設のデジタルIMS化により解消される課題と新たに発生する課題まとめ

申込受領

業
務
プ
ロ
セ
ス

取引時確認

顧客フィルタリング

黒字：デジタルIMS化により解決するアナログIMSの課題
黒字：デジタルIMS化でも解決困難なアイデンティティ管理上の課題
青字：デジタルIMS活用により新たに生じる課題

AML/CFTに関する課題(金融機関/当局)

サービス向上に関する課題(顧客/金融機関)

・アイデンティティエビデンス情報をデータ化する負担・Web申込用のインフラ整備・運用コスト

・Web申込入力負担・金融機関毎に同様の口座開設申込を行う負担
・デジタル対応できない人物の金融排除

・アナログ・アイデンティティエビデンスの検証困難性 ・連鎖的な口座開設等の新たなセキュリティ・リスク
・他社で検証済の顧客を一から検証する負担への対応
・非対面化に伴う本人確認の難度上昇
・デジタルIMSの適切な活用を促す規制フレームワー
ク整備・最適化された既存業務をデジタルIMS利用のために変更する投資判断が困難

・他社で検証済の顧客を一から確認する負担

分析・評価
判断・対応

・所在確認のための口座開設通知郵送コスト75

2-3-3. ユースケース分析 ユースケース（１-１） デジタルアイデンティティエビデンスを利用しての口座開設

AML
サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供

課題 デジタルIMSの適切な活用を促す規制フレームワークの整備（１／２）
 FATFは、規制目的に適したIAL （Identity
Assurance Level）が担保されるよう、デジタル
IMSの採否基準として以下を提唱している。

FATFが提唱するAML/CFT目的でのデジタルIMSの採否決定プロセス*1)①政府により顧客管理への利用を許可されたもの
または②堅牢性やIALが政府や政府認可機関により保証もし
くは監査され、かつAML/CFTの観点から十分なIALが提供されるもの

 加えてFATFは適切なIALが担保されたデジタルIMSの下では、リスクベース・アプローチが可能となり、AML/CFTの高度化や金融包摂への寄与する利点に言及している。
 一般に高リスクに分類される非対面取引においても、
適切なデジタルIMSに依拠する場合は、標準的もし
くは低リスクなレベルのリスクになる可能性がある*1) 。

*1) GUIDANCE ON DIGITAL IDENTITY(Mar 2020)
http://www.fatf-gafi.org/publications/financialinclusionandnpoissues/documents/digital-identity-guidance.html

ML/FTの観点で十分なIALが確保できないデジタルIMSは顧客管理のために利用すべきではない。

76

2-3-3. ユースケース分析 ユースケース（１-１） デジタルアイデンティティエビデンスを利用しての口座開設

AML

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

課題 デジタルIMSの適切な活用を促す規制フレームワークの整備（２／２）
 適切なIALの整備には、IALと本人確認規程との接合が重要であるが、現時点では、eIDが推奨されているEU（ドイツ）を除き、本人確認規定とIALとの接合は無い。
 EUではonboardingプロセスへのeID活用が検討され、金融分野における技術・ガバナンスともeIDAS規則への準拠を前提として議論が進んでいる。
 シンガポールは政府ID利用への統一化により、実質的にIALを均一化している。

本人確認規程
根拠

日本

アメリカ

英国

ドイツ

シンガポールニュージーランド

犯罪収益移転防止法で本人確認方法について規定愛国者法で連邦レベルでの本人確認方法を規定、州法もこれに準拠基本法となる
POCA概要を規定、
政府デジタルサービ
スガイダンス等で詳
細化

Money
Laundering Act(GwG)で総論を規定、詳細は別に個別の法で定める

マネロンおよびアンチ
テロリズム法で規定

Identification
Management
Standardsにて規定

対面での
本人確認
非対面での
本人確認の
特例

業態毎に水準を規定し、いずれの組み合わせでも水準を満たせば良い

原則写真付公的証明書

ビデオ通話と公的証
明書での確認も可

金融機関が定める
ことを要請

非対面での確認の規定無し

ビデオ通話での確認方法も詳細規定

非対面の場合の代替手段を列挙

必要水準が低い業態では非対面でも追加措置不要

GwG解釈ノートにて
eIDAS準拠を規定

無

無

あり

あり

一部あり
（IRD）

アイデンティティ保証フレームワーク（IAL）との接合

無無無（Good Practice
Guide45がeIDASと接合するもガイド
ライン留まり）（ご参考）
国民番号制度あり（マイナンバー※）

一部あり
（SSN）

なし（2010年にID
カード法廃止）※なお、マイナンバーの利用は、現在、社会保障、税金、災害対策の3つに厳しく限定されており本人確認には利用できない

77

AML

2-3-3. ユースケース分析 ユースケース（１-１） デジタルアイデンティティエビデンスを利用しての口座開設

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供（参考）米国・EUのアイデンティティ保証フレームワーク
 米国：NIST (米国立標準技術研究所) がSP-800-63A*1)においてIAL、AALを規定している。
 EU：eIDASにてLoA (Levels of Assurance) を規定している。
 米国・EUのようにアイデンティティ保証フレームワークが規定されている法域は限定的である。
eIDASの本人確認時のLoA
2.1 登録
•
•
•

申請
登録
身元確認
NIST SP800-63 IAL
とほぼ同様



2.2 eID管理
•
•
•
•

デザイン
発行
停止
更新と交換

2.4 管理と組織

2.3 認証••

RPの本人確認要件

NIST SP800-63
AALとほぼ同様••••

情報セキュリティマネジメン
ト(ISM)
記録管理
施設とスタッフ
管理策
コンプライアンスと監査

LoAの記載例：身元確認
LoA

登録時の対面申請
アイデンティティ証跡の確認

Low

Substantial

High

不要

不要

必要

有効な身分証明書は直接確認しない認められた証跡に基づき、本人であることを確認

有効な身分証明書の保有を確認*1) CONFORMANCE CRITERIA for NIST SP 800-63A ENROLLMENT AND IDENTITY PROOFING and NIST SP 800-63B AUTHENTICATION AND LIFECYCLE
MANAGEMENT https://www.nist.gov/system/files/documents/2020/07/02/800-63A%20Conformance%20Criteria_0620.pdf

78

AML

2-3-3. ユースケース分析 ユースケース（１-２） 他社で作成したデジタルアイデンティを用いての口座開設

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

ユースケースの概要
 既存の金融機関口座のデジタルアイデンティティを用いて別の金融機関の新規口座を開設する。
 顧客の口座開設負担軽減、金融機関のアイデンティティエビデンス検証負担削減、等の効果が期待される。
各金融機関に対して個別に口座開設を行う場合の事務フロー
公的機関⑦アイデンティティ
エビデンスの真正性・有効性照会

⑧結果回答

公的機関

金融機関B 金融機関職員⑥Web申込入力+
デジタルアイデンティティ
エビデンス提示⑨アイデンティティエビデンス検証＋
顧客スクリーニング⑩口座開設通知(デジタル)

顧客①Web申込入力+
デジタルアイデンティティ
エビデンス提示⑤口座開設通知(デジタル)

ユースケース（２） 他社で作成したデジタルアイデンティを用いての口座開設 ＊青枠が変更部分
顧客
金融機関B 金融機関職員①口座開設依頼②アイデンティティ
エビデンスの真正性・有効性照会
金融機関職員

③結果回答

金融機関A

④アイデンティティエビデンス検証＋
顧客スクリーニング

金融機関職員 金融機関Ａ②検証済ID連携依頼④顧客スクリーニング ⑤口座開設通知(デジタル)

検証済アイ
デンティティ

③検証済ID連携
注)顧客は金融機関Aに対して、各金融機関に個別に口座開設行う場合と同じ事務フローで口座開設済

79

2-3-3. ユースケース分析 ユースケース（１-２） 他社で作成したデジタルアイデンティを用いての口座開設

AML
サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供

ユースケース(１-１)(自社のみ)からユースケース(１ｰ２)(他社で作成したデジタルIDを利用)への移行により解消される課題と新たに発生する課題
 口座開設における金融機関・顧客双方の更なる省力化が図られる一方、当事者間の責任分界等の課題が発生する。
 次頁以降で主要課題(下表ハイライト部分)について詳述する(その他の課題については補足資料参照)。
黒字：ユースケース（１-２）への移行により解決するユースケース(1)の課題
ユースケース(１-１)(自社のみ)からユースケース（１-２）
凡例 黒字：ユースケース（１-２）への移行でも解決困難なユースケース(1)の課題(他社作成デジタルIDを利用)への移行により解消される課題と青字：ユースケース（１-２）により新たに生じる課題
新たに発生する課題まとめ
AML/CFTに関する課題(金融機関/当局)
サービス向上に関する課題(顧客/金融機関)

申込受領

業
務
プ
ロ
セ
ス

取引時確認

顧客フィルタリング

・Web申込用のインフラ整備・運用コスト
・ID連携当事者間のビジネスモデル・責任分界の未整備

・Web申込入力負担・金融機関毎に同様の口座開設申込を行う負担
・デジタル対応できない人物の金融排除
・煩雑なID連携仕様への対応負担
・ID連携の同意管理負担

・他社で検証済の顧客を一から検証する負担
・連鎖的な口座開設等の新たなセキュリティ・リスク
・デジタルIMSの適切な活用を促す規制フレームワー への対応
ク整備
・特定の金融機関(IdP)への依存リスクが高まる
・最適化された既存業務をデジタルIMS利用のために変更する投資判断が困難
・他社で検証済の顧客を一から検証する負担

分析・評価

判断・対応
80

2-3-3. ユースケース分析 ユースケース（１-２） 他社で作成したデジタルアイデンティを用いての口座開設

AML
サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供【AML/CFT】 ID連携当事者間のビジネスモデル・責任分界の整備にまつわる課題 ID連携にあたっては当事者間の役割・責任を明らかにする必要があり、検討が必要な主な論点は下表の2点である。
 いずれにおいても、責任の範囲は当事者間でやり取りされる対価を考慮して検討されると考えられる。
【論点２】金融機関A(IDの出し手)のデータに過誤があり、それが原因で金融機関B(IDの受け手)側で問題が発生した場合の処置• IDの出し手のデータに過誤があり、IDの受け手に損害を与えた場
合における損害賠償責任等を検討する必要がある。
• 損害賠償の額については、論点1で言及した責任の範囲や、過誤の理由(IDの出し手の管理不備、サイバーテロ、顧客の提供情報に誤りあり、等)により異なる。

【論点１】金融機関A(IDの出し手)から金融機関B(IDの受け手)に連携された顧客の本人確認やKYCの責任
以下２パターンが考えられ、当事者間でやり取りされる対価等を勘案し責任範囲を検討する必要がある。
#

パターン

想定される各参加者の業務

1

金融機関A(IDの出し手) ・金融機関Bは連携された情報を本人確認済情報として利用する。(責任小)に責任・金融機関Aの責任範囲は、顧客データを直近化して確認の上連携する等大きくなると考えられる。(責任大)かつ、金融機関Aへの過度な依存により金融機関BのKYC能力の弱体化、ひいては業界全体のKYC弱体化を懸念する意見もある。

2

金融機関B(IDの受け手) ・金融機関Bは受領情報を参考に、自ら本人確認を再度実施する。(責任大)に責任・金融機関AはID情報を参考情報として連携する。(責任小)81

2-3-3. ユースケース分析 ユースケース（１-２） 他社で作成したデジタルアイデンティを用いての口座開設

AML

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供【サービス向上】特定の金融機関(IdP)への依存リスクが高まる 顧客が他社で作成したアイデンティテイを用いての口座開設を複数金融機関に対して行う場合、 IDの出し手(下図
金融機関A)に対する依存度が高まる可能性があり、これに伴うリスクが懸念される。
 下図の金融機関Aでの検証に問題が発生した場合、ID連携先の金融機関のサービスに影響が発生する。

IdPである金融機関に不具合が発生した場合の影響
金融機関B
取引

顧客

金融機関C

金融機関Ａ

金融機関ＡのIMSに問題が
発生

取引

金融機関D
取引

サービス提供に影響が出る懸念

82

AML

2-3-3. ユースケース分析 ユースケース（２）継続的顧客管理

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

ユースケースの概要
 デジタルIMS化により金融機関と顧客のやり取りがデジタル化され、金融機関・顧客双方の事務負担が削減される。
 デジタルIMS化により他社データを活用した分析の実施が現状より容易になることが期待される。
現在のアナログの継続的顧客管理の事務フロー
顧客

金融機関職員 金融機関
疑わしい取
引届出

顧客情報確認書類郵送
顧客情報確認書類(回答)郵送/
取引依頼
取引/口座保有諾否連絡

分析・判断

顧客情報確認依頼(デジタル化)
顧客情報確認書類(回答) (デジタル化)/
取引依頼

書類保管

自社データ

デジタル化された継続的顧客管理の事務フロー ＊青枠が変更部分
顧客

金融当局

金融機関
金融機関職員

金融当局

疑わしい取
引届出

分析・判断
他社(金融/他業態)取引/口座保有諾否連絡

他社情報(金融取引)
自社データ

他社データ
他社情報(非伝統的情報)
83

AML

2-3-3. ユースケース分析 ユースケース（２）継続的顧客管理

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

デジタルIMS化によるリスクベース・アプローチの高度化
 FATFはデジタルアイデンティティに関するガイダンスにて、
デジタルアイデンティティによる新たな技術を活用したリスク低減措置の高度化の可能性へ言及している*1)。
 顧客に紐づく情報の拡大• ジオロケーション、IPアドレス、取引に利用したデジタルデバイスのID等• インターネットや携帯電話等の様々なチャネルを通じて得られる追加情報

 広範な情報を用いた顧客の行動分析• アクセスしている人物に対する本人認証の強化• 異常なもしくは疑わしい取引検知の強化
 金融包摂• 新興国における従来の公的書類（パスポート、運転免許証等）の代替手段• 新興国におけるデジタルアイデンティティの保証レベルに応じた金融サービスの提供
リスクベース・アプローチのプロセス概要
各プロセ
スの定義

金融機関などの規模・特性を踏まえ、包括的かつ具体的に特定金融機関等の事業環境・経営戦略等を踏まえて、全社的に実施

実際の顧客や取引のリスクに応じて、実効的に低減措置を実施
例)顧客管理、取引モニタリング・フィルタリング、疑わしい取引の届出、等リスクの特定リスクの評価

リスクの低減*1) FATF Guidance on Digital Identity (March 2020)

http://www.fatf-gafi.org/publications/financialinclusionandnpoissues/documents/digital-identity-guidance.html

84

AML

2-3-3. ユースケース分析 ユースケース（２）継続的顧客管理

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

継続的顧客管理のデジタルIMS化により解消される課題と新たに発生する課題
 リスクベース・アプローチの高度化やコスト削減が図られる一方、他社データ利活用に対する課題が新たに発生する。
凡例
黒字：デジタルIMS化により解決するアナログIMSの課題
黒字：デジタルIMS化でも解決困難なアイデンティティ管理上の課題
青字：デジタルIMS活用により新たに生じる課題

継続的顧客管理におけるアナログIMSのデジタルIMS化により解消される課題と新たに発生する課題まとめ

AML/CFTに関する課題(金融機関/当局)
申込受領
取引時確認

業
務
プ
ロ
セ
ス

・取引申請書類をデータ化する負担

取・大量の顧客に対する検証事務負担 定

サービス向上に関する課題(顧客/金融機関)

・郵便物の返送手続負担 定・継続的顧客管理における情報漏洩防止等のための過度なセキュリティ対応によるUXの悪化 定 取・取引時のセキュリティリスク（非対面でアクセス時のパスワード盗取など）
取

顧客フィルタリング・アナログの顧客情報収集郵電費・データ化負担 定

分析・評価

判断・対応

・情報の第三者提供に関して、データ提供側として、顧客同意対応の負担が大きい 定 取(ユースケース(３)で詳述)
・情報の第三者提供に関して、データ受取側として、データ提供側への説明と確認の対応負担が大きい
定 取(ユースケース(３)で詳述)
凡例

定 ・・・定期的顧客情報調査
取 ・・・取引受付時確認
85

AML

2-3-3. ユースケース分析 ユースケース（３）他社情報を活用したサービス提供

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

ユースケースの概要
 デジタルIMS化により他社保持データも含めたアイデンティティ情報の収集・活用が容易となり、顧客に対し、より最適なテーラーメードサービスの提供等が期待される。
顧客へサービス提案を現在のアナログの業務を元に実施
顧客

金融機関職員 金融機関

顧客へのサービス提案
分析・提案
自社データ

顧客へサービス提案をデジタルIMSを活用しデータ分析を行い実施 ＊青枠が変更部分
金融機関
顧客
金融機関職員
顧客へのサービス提案
分析・提案
他社(金融/他業態)
他社情報(金融取引)
自社データ

他社データ
他社情報(非伝統的情報)

86

AML

2-3-3. ユースケース分析 ユースケース（３）他社情報を活用したサービス提供

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

デジタルIMSによる課題解決：顧客のアイデンティティ情報の部門間/会社間の紐づけ 社内の各部門のDBが持つ顧客のアイデンティティ情報や他社が持つ顧客のアイデンティティ情報を、
デジタルIMS上の共通の顧客識別子に紐づけて管理することで、社内でのデータ利活用の促進が期待される。
 アイデンティティ情報の連携は、社内の部門間から企業間に広がることが期待されるが、効率的連携には連携仕様の整備が重要である。この点、デジタルIMSにおいては、1章で述べたOpenID Connect®等のアイデンティティ連携仕様の活用により、ア
イデンティティ情報の連携はより行いやすくなることが期待される。 (下記左図参照)

 また、2-1-4.で言及したように金融機関においては個別最適化されたデータ・システムが多数存在しているケースもあるため、現実的には、下記右図のように、業務や利用目的が近いシステムに対し部分的に統一を図っていくことで段階的に成果を出していく形が考えられる。

 ただし、データ利活用の促進に当たり、顧客のアイデンティティ情報の紐づけは解決策の一部であり、データを横串で利用できるよう顧客とのデータ利用許諾規定を見直す等、引き続き残る課題がある。
デジタルIMSを活用した顧客アイデンティティ情報の紐づけイメージ
金融機関
他社(金融/他業態)

アイデンティティ連携の発展イメージとアイデンティティ連携仕様の活用
2社間

データ連携

顧客
発展

部門A
顧客マスタ

多社間

顧客1 aaa
部門B
デジタルアイデンティティのIMSではアイデンティティ連
携仕様が整備されており活用可能である。

デジタル
IMS上の顧
客識別子

顧客マスタ
顧客1

fff

顧客1 bbb

同一顧客を指す顧客ID部門C
顧客1 ccc

部分的に連携を図り段階的に成果を出していくことが現実的と考えられる。

87

AML

2-3-3. ユースケース分析 ユースケース（３）他社情報を活用したサービス提供

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

他社情報を活用したサービス提供のデジタルIMS化により解消される課題と新たに発生する課題
 他社保持データも含めたアイデンティティ情報の収集・活用が容易となる結果、他社から情報を受け取り利用するためのルール整備に関する課題が発生する。
 次頁以降で主要課題(下表ハイライト部分)について詳述する(その他の課題については補足資料参照)。
他社情報を活用したサービス提供のデジタルIMS化により解消される課題と新たに発生する課題まとめ
AML/CFTに関する課題(金融機関/当局)

凡例

黒字：デジタルIMS化により解決するアナログIMSの課題
黒字：デジタルIMS化でも解決困難なアイデンティティ管理上の課題
青字：デジタルIMS活用により新たに生じる課題

サービス向上に関する課題(顧客/金融機関)

申込受領

業
務
プ
ロ
セ
ス

取引時確認
顧客フィルタリング

分析・評価

識別子の不一致によりデータ集約が困難
・複数サービス横断で顧客データを利活用するため
ー部門/組織毎の管理により顧客識別子不一致の、データ利用許諾の整備負担
・情報の第三者提供に関して、データ提供側として、 ー他社データとの顧客識別子不一致
・社内外のデータフォーマットの不統一によりデータ集
顧客同意対応の負担が大きい
約が困難
・情報の第三者提供に関して、データ受け取り側として、データ提供側への説明と確認の対応負担が ・データ利活用の目的と範囲に関する、顧客と金融機関の認識齟齬リスクの増大
大きい

判断・対応
88

2-3-3. ユースケース分析 ユースケース（３）他社情報を活用したサービス提供

AML

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供【サービス向上】他社情報の活用に関する諸課題
 データ利活用が企業を跨いで行われるようになると、複数サービス横断で顧客データを利活用するためのサービス利用
許諾整備負担に加え、データ提供側/データ利活用側双方に、情報の第三者提供に関する対応負担が発生する。
情報の第3者提供における顧客からの同意取得フローと課題【データ活用側の課題】
情報の第三者提供に関して、データ受け取り側として、データ提供側への説明と確認の対応負担が大きいーデータ提供者側に対するデータ取得経緯等の確認負担
ーデータ利活用の目的・内容等をデータ提供側に説明し、理解を得る負担

顧客

データ活用側
金融機関職員

データ活用側
金融機関①顧客情報の利活用内
容・連携についての同意

データ提供側
データ提供側(金融/他業態)
職員④顧客情報連携②情報の第3者提供にあたっての顧客への説明③情報の第3者提供にあたっての顧客(データ主体)の同意【データ提供側の課題】
情報の第三者提供に関して、データ提供側として、
顧客同意対応の負担が大きいーデータ利活用に関する顧客への説明実施負担ー同意記録の作成・保管等の顧客との同意管理負担89

2-3-4. その他技術的課題

その他技術的課題
 以降では、ユースケースには分類が難しいが既存研究等で指摘されている技術的課題を挙げる。
課題分類

サイバー
セキュリティ
・データ
セキュリティ

課題の概要

課題の詳細

デジタルID集中によるサイバーセキュリティ
脅威の増大

IDプロバイダーがデジタルIDを集中管理すると、犯罪者から大量のデジタルIDを一度に狙われるリスクが高まる。より高いセキュリティレベルが求められる。*1)

オンラインID窃盗

IDがデジタル化されると、オンラインでのID窃盗のリスクが高まる。デジタルIDの導入と並行してID管理に対するセキュリティレベルの向上も必要である。*2)*3)

Authoritative
Sourceの突然死

身元確認が第三者によって実施される場合、Authoritative Sourceの身元確認プロセスに障害が発生すると、影響範囲が広がり、エコシステム全体に影響を与えることになる。*4)

インサイダーの脅威

IDプロバイダーがデジタルIDを集中管理することで、内部の犯行者が現れるリスクが高まる。ID
プロバイダー内部のアクセス権限の管理レベル、セキュリティレベルの向上が求められる。*1)

記録の完全性ある企業で作成したデジタル ID を他者が利用し、何らか問題が発生した場合、責任の所在を明確にする必要があるため、デジタルIDの作成や更新の記録が完全でなければならない。
*4)*5)*参照文献は次頁にまとめて記載

90

2-3-4. その他技術的課題

その他技術的課題
課題分類

認証
・認可

課題の概要

課題の詳細

申請者がIDの真の所有者であることの確認

バイオメトリクスの活用、IDデータベースの検証・取消リストの活用など、より高度な技術で、申請者がIDの真の所有者であることを確認する必要がある。*4)

認証技術の有効性についての継続的な測定

継続的認証技術の測定方法が成熟していないため、IDに紐づけられる属性が変化する可能性がある。分析システムはIDが詐欺等により悪用されることを示唆するリスク・シグナ
ルを検知できる可能性がある。*2)*3)*1) Digital Identities in Financial Services Part 2: Responsible Digital Identities, The Key to Creating More Inclusive Economies(Oct 2019)https://www.iif.com/Portals/0/Files/content/Innovation/10142019_responsible_digital_ids.pdf*2) Guidance on Digital Identity (March 2020) http://www.fatf-gafi.org/publications/financialinclusionandnpoissues/documents/digital-identity-guidance.html*3) OIX The value of digital identity to the financial service sector (Dec 2016) https://openidentityexchange.org/networks/87/item.html?id=202*4) DG-FISMA ASSESSING PORTABLE KYC/CDD SOLUTIONS IN THE BANKING SECTOR
https://ec.europa.eu/info/sites/info/files/business_economy_euro/banking_and_finance/documents/assessing-portable-kyc-cdd-solutions-in-the-banking-sectordecember2019_en.pdf*5) DG-FISMA Report on existing remote on-boarding solutions in the banking sector
https://ec.europa.eu/info/sites/default/files/business_economy_euro/banking_and_finance/documents/report-on-existing-remote-on-boarding-solutions-in-thebanking-sector-december2019_en.pdf

91

AML

2-3-5. 金融機関からのデータ参照先に関する課題

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供【AML/CFT】法人の実質的支配者確認に関する課題をめぐる動向
 国内金融機関に対するヒアリングにおいても、法人実質的支配者の確認負担が高いという意見が出ている。
 現状、FATFは、 2019年10月公表の「best-practices-beneficial-ownership-legal-persons」*1)において、FATFの相互審査で示された各国の実情を鑑みると、実質的支配者確認において、複数の情報(下表参照)を組み合わせて判断する手法を推奨しており、確認負担自体はやむを得ない側面もある。
 むしろ、FATFにおいてもこうした対応が推奨されている根本的な課題としては、法人の実質的支配者確認における実質的支配者情報の確からしさを担保する仕組みが確立されていないこと、であると考えられる。
FATFが推奨する実質的支配者情報収集のアプローチ*2)

No.

アプローチ名称概要

実質的支配者の照会先

1

the Registry
Approach

登記簿に実質的支配者に関する最新の正しい情報を集約（できる仕組みづくり）

2

the Company
Approach

各会社が実質的支配者に関する最新の正しい情報を管理各会社（できる仕組みづくりと政府からの要求）

3

the Existing
Information
Approach

登記簿

会社登記情報やその他の種類の登記簿（土地、自動車、移動可能な財産の登記簿など）

既存の情報源を利用

外部の金融機関やDNFBP*3)
情報源
その他の当局（監督官庁や税務当局）、証券取引所が保有する情報、商業データベース、など*1)FATF, best-practices-beneficial-ownership-legal-persons, Oct 2019 https://www.fatf-gafi.org/media/fatf/documents/Best-Practices-Beneficial-Ownership-Legal-Persons.pdf*2)*1)を元にNRI作成*3) 指定非金融業者及び職業専門家（Designated non-financial businesses and professions）

92

2-3-5. 金融機関からのデータ参照先に関する課題

AML

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供【AML/CFT】法人の実質的支配者確認に関する課題をめぐる動向
 前頁の課題に対し、各国で制度の整備等が検討されている。例えば、日本では以下の検討が進んでいる。
 法務省民事局で、犯罪収益移転防止法施行規則第１１条第２項第１号の実質的支配者（以下BO）を対象として、
商業登記所がBOリストの保管と写しの交付をする制度が検討されている。
（令和2年7月法務省民事局 「商業登記所における法人の実質的支配者情報の把握促進に関する研究会取りまとめ概要」より）• 日本では、公証人の行う定款認証における株式会社等のBOの申告制度により、会社設立時に公証人によるBO情報
確認が行われている。
• 今後の課題は、①法人の設立後における継続的なBOの把握及び②公的機関が把握したBO情報への捜査機関等によるアクセス。
• 専門性を有する商業登記所の登記官が実質的支配者を確認するハブとなって統一的に判断を行うことにより、個々の金融機関が窓口でその都度確認を行っている現状に比べ、運用の統一性及び一定レベルの判断水準が担保されることにより信頼性が向上するとされている。

出所：法務省,商業登記所における法人の実質的支配者情報の把握促進に関する研究会取りまとめ概要,Jul 2020 http://www.moj.go.jp/content/001324012.pdf

93

2-3-5. 金融機関からのデータ参照先に関する課題

AML
サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供【AML/CFT】クロスボーダー取引の諸課題をめぐる動向
 FSBが2020年4月にG20に提示したクロスボーダー送金の改善に向けた取り組み*1)の第一次報告書*2)では、クロスボーダー送金は、高コスト、低速、限定的なアクセス、透明性不足といった課題に直面している点が指摘されている。
 同報告書では、法規制や監督フレームワークに関わる論点として、多様な法的・規制慣行を持つ複数の国・地域をまたいでクロスボー
ダー送金を行う際の摩擦が指摘されている。
コンプライアンスの質を損なうことなく、また、適切な監督を確保しつつ、AML/CFTやその他のコンプライアンス・プロセスの効率性を改善しコストを削減するために、どのような取り組みが考えられるか検討すべきとしている。

 関連する議論として、2021年6月に改正されたFATF解釈ノートにより暗号資産の移転時に課せられる通知義務（いわゆるトラベルルール）に関しても、各国のAML/CFT法令の導入が進むと共に、差異に対する対応はFATF自身も課題と認識している*3)⇒ 以上から、クロスボーダー取引におけるアイデンティティ管理上の課題は、 AML/CFT規制の国家毎の差異や、FATF基準およびその他の規制・監督上の要件を実施する際の国境を越えたデータ共有への法的な障壁(各国のデータ保護法制等)、等、
法規制面のものが主であると考えられる。（金融機関のアナログIMSがデジタルIMS化されることで解決されるものではないと考えられる。）
 加えて、FSBの第一次報告書*2)では、“企業のための法人識別子（LEI）及び個人のためのデジタル ID の使用の拡大”といったデジ
タルアイデンティティに関する取り組みがあげられており、これは、金融機関が個人・法人についてのアイデンティティ情報をより効率的に確認するための周辺情報の整備の取り組みであると考えられる。
 国内金融機関に対するヒアリングにおいても、クロスボーダー取引における国を跨いだ顧客の情報収集の負担の声はあり、期待される施策であると考えられる。

*1) 2020年2月のG20財務大臣・中央銀行総裁会議において、優先事項としてクロスボーダー送金の改善に取り組んでいくことを決定。金融安定理事会（FSB）に対し、市場インフラ委員会（CPMI）等と協力して2020年10月までにクロスボーダー送金の改善に向けた工程表（ロードマップ）作成を要請*2)FSB,Enhancing Cross-border Payments Stage 1 report to the G20,Apr 2020 https://www.fsb.org/wp-content/uploads/P090420-1.pdf*3)ACAMS Today「暗号資産・暗号資産交換業者に関する新たなFATF基準についての12か月レビュー」におけるトラベルルールの課題,Nov 2020
https://www.fsa.go.jp/frtc/kikou/2020/FSA_article_ACAMSToday2020_Sept-Nov.pdf

94

AML

2-3-5. 金融機関からのデータ参照先に関する課題

サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供【AML/CFT】クロスボーダー取引の諸課題をめぐる動向
 FSBにおける課題解消に向けた取り組み
 FSBは、 2020年7月に課題改善のための19の構成要素（Building Blocks, 以下「BB」）を特定した第二次報告書を公表。
2020年10月にはBBごとの検討ロードマップを第三次報告書として公表している。*1)
 デジタルアイデンティティに関わる課題については、下図のBB5、BB6、BB8、BB16を中心に議論がなされている。
フォーカスエリアおよび関連するビルディングブロック*1)

フォーカスエリアＥ：新しい決済インフラ等の潜在的な役割の模索
BB17：新たな多面的プラットフォームの実現可能性検討
BB18：グローバルステーブルコインの健全性促進
BB19：国際性を持たせたCBDC設計

フォーカスエリアD：データの質の向上およびSTP化の促進
BB14：メッセージフォーマットとしてISO 20022の統一版の採用
BB15：データ交換のためのAPIプロトコルの調整
BB16：プロキシ登録による一意識別子の確立*1) Enhancing Cross-border Payments Stage 3 roadmap (13 October 2020)（日本語はNRI抄訳） https://www.fsb.org/wp-content/uploads/P131020-1.pdf

フォーカスエリアA：クロスボーダー送金の改善に向けた官民共同コミットメントの構築
BB1：共通ビジョン・目標の策定
BB2：国際的ガイダンス・原則の履行
BB3：海外送金サービスレベルの共通基準設定

フォーカスエリアB：規制・監督・オーバーサイト枠
組みの調和
BB4：規制・監督・監視の枠組み調整
BB5：AML/CFT規制の一貫かつ包括的な適用
BB6：データフレームワークの見直し
BB7：安全な送金コリドーの促進
BB8：KYCおよびID情報の共有促進
フォーカスエリアC：クロスボーダー送金市場のニーズに応じた
既存の決済インフラ等の改善
BB9 ：PvP決済の促進
BB10：決済システムへの（直接）アクセス改善
BB11：（中銀間の）互恵的な流動性供給手続きの模索
BB12：（主要な決済システムの）稼働時間延長
BB13：決済システム間の相互接続推進

95

2-3-6. デジタルIMS化により解決されるアナログIMSの課題 ユースケース分析結果まとめ

AML

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

デジタルIMS化により解決されるアナログIMSの課題 ユースケース分析結果まとめ
 アイデンティティエビデンスの検証負担等、事務負担の課題が多数解消されている。
 一方、社内の複数サービスのデータや他社データを利活用するためのデータ利用許諾等、
データ利活用に関する課題は引き続き残る。
 なお、金融機関からのデータ参照先に関する課題については、アナログIMSの課題ではないため下表には記載していない。
凡例
文字：デジタルIMSにより解消される非対面・アナログIMSの課題

AML/CFTに関する課題(金融機関/当局)

業
務
プ
ロ
セ
ス

申込受領

・アイデンティティエビデンス情報をデータ化する負担・Web申込用のインフラ整備・運用コスト

取引時確認

・アナログ・アイデンティティエビデンスの検証困難性
・他社で検証済の顧客を一から検証する負担・非対面化に伴う本人確認の難度上昇
・大量の顧客に対する検証負担

顧客フィルタリング

サービス向上に関する課題(顧客/金融機関)
・ Web申込入力負担・金融機関毎に同様の口座開設申込を行う負担
・郵便物の返送手続負担
・取引時のセキュリティリスク（非対面でアクセス時のパス
ワード盗取など）

・他社で検証済の顧客を一から検証する負担

分析・評価

・アナログの顧客情報収集郵電費・データ化負担
・識別子の不一致によりデータ集約が困難
・自社データのみを利用した犯罪検知の限界
ー部門/組織毎の管理により顧客識別子不一致
・複数サービス横断で顧客データを利活用するための、データ利用許 ー他社データとの顧客識別子不一致
諾の整備負担・社内外のデータフォーマットの不統一によりデータ集約が困
難・データ利活用の目的と範囲に関する、顧客と金融機関の認識齟齬リスクの増大

判断・対応・所在確認のための口座開設通知郵送コスト
96

AML

2-3-7. デジタルIMS化により新たに発生する課題 ユースケース分析結果まとめ

サービス

onboarding

ongoing①口座開設②継続的管理③サービス提供

デジタルIMS化により新たに発生する課題 ユースケース分析結果まとめ
 デジタルIMS化により、以下の課題が新たに発生する。

申込受領

取引時確認
業
務
プ
ロ 顧客フィルタリング
セス

AML/CFTに関する課題(金融機関/当局)

サービス向上に関する課題(顧客/金融機関)

・ID連携当事者間のビジネスモデル・責任分界の未整備

・デジタル対応できない人物の金融排除
・煩雑なID連携仕様への対応負担
・ID連携の同意管理負担
・継続的顧客管理における情報漏洩防止等のための過度なセキュリティ対応によるUXの悪化

・デジタルIMSの適切な活用を促す規制フレームワー ・連鎖的な口座開設等の新たなセキュリティ・リスク
ク整備への対応
・最適化された既存業務をデジタルIMS利用のた・特定の金融機関(IdP)への依存リスクが高まる
めに変更する投資判断が困難

・情報の第三者提供に関して、データ提供側として、顧客同意対応の負担が大きい
・情報の第三者提供に関して、データ受取側として、データ提供側への説明と確認の対応負担が大きい

分析・評価

判断・対応
97

AML

2-3-8. 課題まとめ

onboarding

ongoing①口座開設②継続的管理サービス③サービス提供

デジタルIMS化でも解決しなかったアイデンティティ管理上の課題およびデジタルIMS化により新たに発生する課題一覧
 課題は、下表の９つの観点に整理される。
 なお、８）９）は、本調査においては課題の提示にとどめ、次節以降の記載は割愛する。
１）IAL

課題の観点

２）ID連携（責任分界を中心に）

３）プライバシー（同意管理・データミニマイゼーション）
４）金融包摂５）相互運用性
６）新しい業務へ移行するための投資判断
７）金融機関からのデータ参照先に関する課題
８）その他ビジネス上の課題（UX改善、ITインフラ整備）
９）その他技術的課題

課題
・デジタルIMSの適切な活用を促す規制フレームワーク整備
・ID連携当事者間のビジネスモデル・責任分界の未整備
・特定の金融機関(IdP)への依存度が高まる
・ID連携の同意管理負担
・複数サービス横断で顧客データを利活用するための、データ利用許諾の整備負担
・情報の第三者提供に関して、データ提供側として、顧客同意対応の負担が大きい
・情報の第三者提供に関して、データ受け取り側として、データ提供側への説明と確認の対応負担が大きい・データ利活用の目的と範囲に関する、顧客と金融機関の認識齟齬リスクの増大
・デジタル対応できない人物の金融排除
・煩雑なID連携仕様への対応負担
・最適化された既存業務をデジタルIMS利用のために変更する投資判断が困難
・法人の実質的支配者確認に関する課題
・クロスボーダー取引の諸課題
・ Web申込入力負担
・継続的顧客管理における情報漏洩防止等のための過度なセキュリティ対応によるUX悪化
・連鎖的な口座開設等の新たなセキュリティ・リスクへの対応
・社内外のデータフォーマットの不統一によりデータ集約が困難
・2-3-4に記載の一連の技術的課題

982-4. 課題解決（先進的事例からのインプリケーション）992-4. 課題解決（先進的事例からのインプリケーション）

本節での議論対象
2-1

アナログIMS（対面）の課題
AML/CFT／サービス向上に関する課題（アイデンティティエビデンスの検証困難性、煩雑な顧客手続き等）

非対面化

2-2

アナログIMS（非対面）の課題
課題の
一部解決

新たに
生じる課題

大半の課題は未解決
デジタル化

2-3

デジタルIMSの課題

デジタルIMSによる課
題解決

残余課題
2-4

2-5

新たに
生じる課題

課題解決に向けた検討

課題解決の方向性の整理（SSI/DIDによる一部課題解決への示唆含む）

100

2-4. 課題解決（先進的事例からのインプリケーション）

課題解決に向けた先進事例の活用
 前節で挙げた通り、デジタル化されたIMSの構築・運用には様々な課題があるが、諸外国においてはこれらの課題に取り組む先進的事例もみられる。
 本節では前節で挙げた、デジタルIMS化でも解決しなかったアナログIMSの課題、デジタルIMS化により新たに発生す
る課題について、下表の通り、取組事例から課題解決の示唆を得る。
 なお、７）は、金融機関からのデータ参照先に関する課題のうち、海外での先進事例が見られるクロスボーダー取引の諸課題への対応のみを取り上げる。

課題の観点
１）IAL

事例
①EU、②シンガポール、③インド、④英国

４）金融包摂⑤ID連携サービス、⑥標準化団体の取り組み
本課題については、SSI/DIDによる課題解決が期待されている分野であるため、3章で詳細を議論する③インド

５）相互運用性⑨オーストラリア

６）新しい業務へ移行するための投資判断⑤ID連携サービス
クロスボーダー取引(越境金融)について、以下2事例⑦民間発行ID、⑧欧州大手金融機関

２）ID連携 (責任分界を中心に)
３）プライバシー(同意管理・データミニマイゼーション)

７）クロスボーダー取引の諸課題⑥標準化団体の取り組み

101

1) IAL

2-4. 課題解決（先進的事例からのインプリケーション）①EUにおける金融規制とアイデンティティ保証フレームワーク（eIDAS）の接合に向けた取組
 EUでは公共サービス向けであるeIDASの民間サービスにおける適用可能範囲の拡大を検討中である。
 合わせてAML指令の改訂による顧客管理規定の統一化も検討中である。

課題対応
の方向性

背景・
成功要因

対応前
• eIDASのLoA(IAL)と金融における本人確認・顧客管理の対応がEUレベルでは取れず、加盟国の規制に委ねられた結果、規制がパッチワーク化しコンプライ
アンスコストが増大。
• プライバシー保護については、GDPRとの対応が検討されているが、論点の指摘に留まる。

対応後• 金融機関がEUにおける越境金融サービスの提供に向けてeIDASに準拠したデジタルIDを提供することによりEUにおける金融機関間のIALの統一化が促進される見込みである。
• 次期AML指令制定もしくはAMLルールブック改訂
時にeIDASを踏まえた統一顧客管理が規定され、加盟各国のAML/CFT規定へ反映される。
• プライバシー保護は、EU内におけるデータ共有可能な範囲が欧州委員会より発表される見込みである

 欧州委員会の主導により2016年の施行以来eIDASが公共サービスへ広く導入されて来た。
 AML指令の強制力により、加盟各国のAML/CFT規制改訂が30年に渡り継続的に実施されて来た。

成果 eIDASの民間サービス適用拡大および顧客管理規定の統一化により、加盟国間の越境金融サービスが促進される見込みである。
 顧客管理規定の統一化により、加盟各国のAML/CFTが強化される見込みである。

今後の課題 EU域外の越境金融サービス促進に向けて、EU域外との相互運用性を図れるか。
 統一顧客管理規定が国内法化された際、KYCプロセス全体として加盟国間で調和を図れるか。
102

1) IAL

2-4. 課題解決（先進的事例からのインプリケーション）①EUにおける金融規制とアイデンティティ保証フレームワーク（eIDAS）の接合に向けた取組
 AML/CFT高度化（例：リモートオンボーディング）やクロスボーダー取引改善などを目的に、eIDASに基づくeIDの金融セクターでの活用に向けた検討が進展している状況である。
時期
2010年

2014年
2015年

できごと
補足
EUの成長戦略「欧州2020」の一環として、ICT戦略「欧 DSMに発展的解消
州デジタルアジェンダ」を公表
2014-20年のEU予算として、Connecting
EuropeeIDの活用がCEFの取り組みの1つとして規定
eIDASの身元確認（本人確認？）時のLoA
Facility（CEF）が採択
eIDAS規則採択
施行：2016年7月
デジタル単一市場（DSM）戦略が公表
eIDASは構成要素の位置付け、EU加盟国間の越境取引のeID活用重視

2015年11月

PSD2（欧州決済サービス指令）採択

2017年

DG FISMAにおいてeID/KYCエキスパートグループ設置

2017年11月
2018年7月
同上

PSD2のSCAに関するRTSがEBAから公表
AMLD5（第5次アンチマネー・ローンダリング指令）施行
CEFの枠組において、DG ConnectからeBankingにおけるeID活用に関する報告書が公表
上記eID/KYCエキスパートグループの報告書が完成（公表は2020年3月）
eIDAS改正に向けたパブリックコンサルテーション
Digital Finance Strategy for Europe公表

2013年

2019年12月
2020年7-10月
2020年9月97条でSCA（安全な顧客認証）の要求、98条にてEBAがSCAのRTS（規制技術基準）の策定を規定。eIDは法的義務ではない（推奨にとどまる）。
eIDAS下での識別・認証ツールに基づく、越境でのeIDおよびKYCポータビリティの活用促進手法を検討
電子的支払いに対する認証方式の厳格化を規定
eIDの利用が推奨はされるもののLoAのレベルについては規定なし
銀行セクターにおけるeIDの活用可能性や規制上の論点（主要規制とeIDとの関係性等）について整理（別紙：詳細レポート参照）
金融におけるeIDASを含むデジタルIDの活用に関する2つの報告書*1)*2)（別紙：詳細レポート参照）
改正案は2021年夏頃に公表予定①2021年Q3までに他の金融機関等の実施した顧客管理への依拠を可能とするガイドラインを整備、②AML/CTF規制のEUワイドでの統一、③eIDAS規制の民間IDへの拡張、を規定。

*1) Report on existing remote on-boarding solutions in the banking sector
https://ec.europa.eu/info/sites/default/files/business_economy_euro/banking_and_finance/documents/report-on-existing-remote-on-boarding-solutions-in-thebanking-sector-december2019_en.pdf*2) ASSESSING PORTABLE KYC/CDD SOLUTIONS IN THE BANKING SECTOR
https://ec.europa.eu/info/sites/info/files/business_economy_euro/banking_and_finance/documents/assessing-portable-kyc-cdd-solutions-in-the-banking-sectordecember2019_en.pdf

1031) IAL

2-4. 課題解決（先進的事例からのインプリケーション）①EUにおける金融規制とアイデンティティ保証フレームワーク（eIDAS）の接合に向けた取組
 DG-FISMAは本人確認及び 顧客管理に必要な属性要素を提唱*1)している。

コアアイデンティティ属性（個人）• 個人を一意に識別する属性のセット• 氏名・生年月日・出生地・氏名・国籍・個人ID等

コアアイデンティティ属性（法人）• 法人を一意に識別する属性のセット• 法人名・登記先・法人ID等

ステータス（個人）またはグッドスタンディング（法人）属性• 顧客管理目的で必要とされる属性• （個人）職業・収入源等• （法人）実質的支配者・債務不履行歴等

コンタクト属性• 当人との連絡を手助けする属性• 住所等*1) ASSESSING PORTABLE KYC/CDD SOLUTIONS IN THE BANKING SECTOR
https://ec.europa.eu/info/sites/info/files/business_economy_euro/banking_and_finance/documents/assessing-portable-kyc-cdd-solutions-in-the-banking-sectordecember2019_en.pdf
1041) IAL

2-4. 課題解決（先進的事例からのインプリケーション）②シンガポールにおける国民IDを活用したonboardingプロセスの効率化
 シンガポールでは政府が国民IDを20年近くに亘り推進、普及させてきた。
 この基盤を活用し、大手金融機関はonboardingプロセスの効率化に大きく成功している。
対応前

対応後

課題対応
の方向性

• SingPassは政府オンラインサービス利用のための共有認証システム、MyInfoは行政サービス間の共通
個人情報登録システムとして中央集権型プラットフォームで提供開始されるも、民間に開放されず。
• 一方でMAS 626および解釈ノートにより非対面における本人確認書類や確認手法は細目化されていた。

• SingPassおよびMyInfoを民間サービスへ開放することにより、民間サービスは政府所有の本人確認情報を利用可能となり、法域内のIAL統一が促進された。
• 生体情報や多要素認証追加、情報更新を政府主導で実施することにより、プラットフォームを利用する金融サービスのIALを一律にボトムアップしている。

背景・
成功要因

 政府の強力な主導により20年近くに渡り国民IDが推進、普及されて来た。
 SingPassが2018年、MyInfoが2017年に民間サービスへ開放された。

成果 当該大手金融機関の新規オンボーディングがリモート化、オンボーディングコストも削減された。
 リモートオンボーディング時の顧客情報を政府データから連携し入力項目を削減することでドロップ率が改善された。

今後の課題 SingPassやMyInfoをAML/CFTへ利用出来ず、各金融機関が独自蓄積・検証したデータで対策を実施している。
 国民IDや長期滞在ビザを所有しない人が口座開設や金融サービスを利用するハードルはむしろ上がっている。

105

1) IAL

2-4. 課題解決（先進的事例からのインプリケーション）②シンガポールにおける国民IDを活用したonboardingプロセスの効率化
 国民IDを基にしたSingPassによる行政サービス利用に端を発し、SingaPassの認証強化、セキュリティ強化を実施している。
 さらにSingPassおよびMyInfoを基盤にした官民共通のデジタル認証基盤NDIを構築、推進している。
NDI Stackの概念

国民IDの普及の経緯
時期

できごと

1948年

国民IDの導入

2003年

SingPassの導入（国民IDとパスワードによる行政サービスの利用）

2014年

Smart Nation構想

2015年

SingPassへ2段階認証の導入

2016年

MyInfoの導入

2017年

MyInfoを民間サービスへ開放

2018年

SingPassを民間サービスへ開放
SingPass Mobileの導入（スマホによる指紋認証、顔認証が可能化）

2020年

Trusted官民協働Service
Trusted
Access

政府主導

Trusted Identity

Trusted Data

電子署名等
トラスト
フレームワーク

SingPass

MyInfoSingPassおよびMyInfoを基盤とした官民共通のデジタル認証基盤NDI（National Digital
Identity）を構築
106

1) IAL

2-4. 課題解決（先進的事例からのインプリケーション）

4) 金融包摂③インドにおけるIndia Stackを活用した民間サービスの拡大
 インドでは政府がデジタル決済化を主導し、Aadhaarを核とした認証決済基盤・India Stackを整備した。
 India Stackを活用した民間サービス展開とともに爆発的に登録・利用が進んだ。
 なお、導入以来プライバシーに関する批判があり、2018年9月の最高裁判決によりAadhaarによる本人確認の民間利用が制限されたが、その後Aadhaar法の改正により本人の同意のもとであれば民間企業もAadhaarを本人確認に利用可能となった。
対応前

対応後• 政府は全国民への識別番号を付番と給付金直接振込を目指し、NPCIやUIDAIなどの公的機関を設立し、Aadhaar、および、AadhaarをIDとした認証・決済・口座登録機能 （”India Stack”）を公的基盤として開発・提供した。
• モディ政権の「デジタルインド計画」により、Aadhaar
およびIndia Stackの登録・利用が爆発的に進んだ。

課題対応
の方向性

• 低所得者層や遠隔層への社会保障、給付金の不正受給や中抜きが問題となっており、政府は全国
民に識別番号を付番し給付金を国民の口座へ直接振込む形を目指していた。
• なお、識字率が70%程度であったことから、生体認証の利用が検討されていた。

背景・
成功要因

 政府がデジタル決済化を主導し、Aadhaarを核とした認証決済基盤・API基盤（India Stack）を整備した。
 政府がデジタル決済の利用を拡大するための政策や法的整備を実施した。
（2015年に発表されたデジタル化政策「Digital India」の下、国民皆銀行口座プロジェクト、Aadhaar法、等）

成果

 登録は義務ではないものの現在成人の99%以上がAadhaarに登録している。
 金融包摂が進み、公的証明を持っていない貧困層、農村部の遠隔層も金融サービスを利用できるようになった。
 給付金の中抜き、さらにはマネー・ローンダリング、地下経済（脱税）の取り締まりも強化できた。

今後の課題 プライバシー：銀行口座やPANカードとのひも付けは登録の「義務」につながり、各自が持つ12桁の番号を他者に知らせることはプライバシーの侵害であるとの指摘がある。
 セキュリティ：システムがサイバー攻撃された場合、全ての登録データが危険にさらされるとの指摘がある。

出所）Digital Financial Services (April 2020) https://documents1.worldbank.org/curated/en/750421502949470705/pdf/118736-BRI-EMCompass-Note-42-DFS-Challenges-and-Opportunities-PUBLIC.pdf
NNA アジア取材ノート「国民皆番号、商機と危うさ生む改革」（2017年9月号） https://www.nna.jp/nnakanpasar/backnumber/170901/feature_001

1071) IAL

2-4. 課題解決（先進的事例からのインプリケーション）

4) 金融包摂③インドにおけるIndia Stackを活用した民間サービスの拡大 デジタルインフラ未整備の農村部での金融取引事例*1)
 インドの国民の大多数は農村部で暮らしており、周囲に金融機関の支店/ATMがなく顧客もモバイル端末を持っていない。
 そこで、金融機関が派遣したエージェントが顧客の生体認証操作と顧客との現金の受け渡しを行うことで、金融機関の支店/ATM網を整備することなく、農村部の国民へ金融サービスを提供している。

＜例：出金の場合＞生体認証で本人確認して顧客へエージェントから現金を渡した後、顧客口座からエージェント口座へ振込処理を行う。

*1)政府インターネットテレビ スーパーシティ／スマートシティフォーラム2019「インドにおけるアドハー成功の秘訣と金融サービス」
https://nettv.gov-online.go.jp/prg/prg19513.html

1081) IAL

2-4. 課題解決（先進的事例からのインプリケーション）④英国における国民IDの代替策としてのGOV.UK Verify導入
 英国では国民IDの普及に複数回失敗し、代替策としてGOV.UK Verify（詳細後述）を導入した。
 しかし利用者数、サービス数、本人認証成功率、利益いずれも未達であり、IdPの撤退が始まっている。

課題対応
の方向性

背景・
成功要因

対応前

対応後

• IDカード法を制定し英国に3か月以上滞在する16歳以上の個人にID登録番号およびIDカードを発行した。
• EU域内パスポートとしての利用に加え、民間サービス
利用時の本人証明として利用可能とした。
• 政府による管理や監視社会に対する強い危機感等のためIDカード法を廃止した。

• 民間企業が発行するIDを公共サービスへアクセスする際の本人認証手段として活用できるようGOV.UK
Verify を整備した。
• 各個人が選択したIdPからGOV.UK Verifyを通じて
公共サービスを利用可能とした。
• 政府による国民IDの集中管理に代わり、個人へ
IdPの選択、利用、中止の権利を付与した。

 政府横断的にデジタルサービスを担うGDS (Government Digital Service)が導入を主導した。
 IdPとして参加する民間企業に対して政府から一人当たり20ポンド*1)の資金を支援した。（2021年10月まで）

成果

 GOV.UK Verifyを利用して22種類の公共サービスを利用可能とした（2020年1月現在）。
 7社の認定事業者（2014年10月現在）と600万人が利用中である（2020年1月現在）。

今後の課題

 当初想定に利用者数やサービス数が未達かつコスト増のため、IdPが相次いで撤退し2020年3月現在2社へ減少した。
 主要銀行がデジタルアイデンティティを独自発行もしくはTISA等の業界団体による規定等、代替策の検討が進展している。

*1) https://www.governmentcomputing.com/identity/news/commercial-concerns-push-two-idps-away-verify-heads-towards-private-sector-delivery1091) IAL

2-4. 課題解決（先進的事例からのインプリケーション）④英国における国民IDの代替策としてのGOV.UK Verify導入
 Gov.UK VerifyはeIDASフレームワークのLevel2に相当する認証技術である。
 各個人が選択したIdPからGOV.UK Verifyを通じて公共サービスへアクセスする際の本人認証手段である。

アイデンティティの真正性・有効性を確認するフロー①サービスへアクセス⑧サービス提供⑥真正性および
有効性確認

⑤許可

顧客
認定IdP

公共サービス• モバイル情報• パスポート• 運転免許証• 銀行口座• クレジットカード

等③利用目的確認②リダイレクト④リダイレクト
GOV.UK Verify

⑦結果

⑦結果

110

2) ID連携（責任分界を中心に）

2-4. 課題解決（先進的事例からのインプリケーション）

6) 新しい業務へ移行するための投資判断⑤ID連携サービスにおける責任分界 ID連携サービス1および2においては 本人確認済みもしくは高認証レベルの情報に限定してIdPが責任を負う。
 ID連携サービス3においては参考情報の位置付けのため、RPが責任を負う。
サービス
提供地域

ID連携サービス１

ID連携サービス２

ID連携サービス３

欧州

北欧

日本

eIDASの適格トラストサービスプロバ
イダ (QTSP) として本人確認済情報 (クレーム) を連携

官民双方のサービスに利用出来る
統一IDを全市民へ提供

事業者がeKYCを実現するために金融機関が保有する本人確認済
情報を連携

OpenID Connect®の規定もしく
連携可能なはOpenID Connect for Identity
属性項目
Assurance®規定の仕様に準拠

口座開設に必要な属性に加えてAML/CFT要件を満たす属性項目

非公開

IdP：法域内の金融機関
主な参加者
RP ：非公開

IdP：法域内の金融機関
RP ：小売、法域内の金融機関、
政府サービス

IdP：法域内の金融機関
RP ：非公開

内容

料金体系

本人確認済み情報：有料
本人確認未済情報：無料

認証レベル高情報：有料
認証レベル低情報：有料

本人確認済み情報：有料
本人確認未済情報：ー

責任分界

本人確認済情報：IdP責任
本人未確認情報：RP責任

認証レベル高：IdP責任
認証レベル低：RP責任

RPが全責任※参考情報の位置付けのため
111

2) ID連携（責任分界を中心に）

2-4. 課題解決（先進的事例からのインプリケーション）

6) 新しい業務へ移行するための投資判断⑤ID連携サービスにおける責任分界 ID連携サービス１～３のいずれもID連携サービスのプラットフォームを介してIDが連携される点は共通である。
 連携されるIDに対する責任分界はID連携サービスにより異なる。
 連携されるIDの対価もID連携サービスにより異なる。
他社で作成したデジタルアイデンティティを用いた口座開設フロー①口座開設申請

金融機関B

⑦口座開設

⑤許可

顧客

金融機関A

③確認
②リダイレクト⑥ID連携④リダイレクト

ID連携サービス
事業者

⑥ID連携

112

2) ID連携（責任分界を中心に）

2-4. 課題解決（先進的事例からのインプリケーション）

5) 相互運用性⑥標準化団体の取り組み 金融当局として特に注視すべき標準化動向
 金融機関のアイデンティティ管理業務に影響が大きいと思われる標準化活動を、各々の標準化活動が解決に資する課題とあわせて下表に示す。
団体
名

検討グループ

活動概要

ステータス

注視すべき観点

対象課題• ISO 17442-2：Legal
2-3-5 金融機関からのISO TC 68• LEIは金融取引における法人を特 データ参照先に関する課
entity identifier
Financial services
活動終了
定する識別子であり、AMLへの活 題
SC8 Reference data for(LEI)(取引主体識別子)
用等も議論されている
financial services WG4
の規格策定
ISO
• ISO/DIS 24366：• NPIは個人の識別子であり現在第ISO TC 68
金融機関からのNatural Person
第一版の作成に一版検討中であるが、LEIと同様 2-3-5
Financial services
データ参照先に関する課
SC8 Reference data for
Identifier (NPI)(自然 向けて議論中
AML等への活用の動きが議論され 題
financial services WG7人ID)の規格策定。
ている• ID連携プロトコル• 個人の検証済属性のメタデータ連 2) ID連携
“OpenID Connect”を拡張し、属性情報に加 Implementation
携、法人関係者の情報連携等、
eKYC& Identity
Assurance WG
え、確認方法等を表す Draft2公開済
AML高度化につながるユースケース（詳細後述）
メタデータを連携する規が検討されている
OIDF
格の仕様検討を実施• 英国Open BankingにおけるFAPI2.0• FAPI(Financial-grade
FAPI WG
Implementation
PSD2対応等、幅広く活用されて 5) 相互運用性
API) 1.0の策定
Draft1発行済
いる• 金融機関のAML業務
・Digital ID for AML• AML等、金融特有の取組を実施 5) 相互運用性
OIX ・Banks in the Identityの活用等、金融特有の 検討中
中Market
課題を議論
1132) ID連携（責任分界を中心に）

2-4. 課題解決（先進的事例からのインプリケーション）⑥標準化団体の取り組み OpenID Foundation eKYC & Identity Assurance WG
 事業者間で行われるID連携における連携技術仕様について、属性情報に加えて、IDの信頼性の根拠となるメタデータ(検証の根拠とした法令・検証方法等)の連携や、法人関連の詳細情報の連携を実現する連携技術仕様を開発し、AML規制対応や不正防止等の対策強化に寄与している。

課題対応
の方向性

背景・
成功要因

対応前
• 本WGにおいて事業者間の連携技術仕様を整備す
るも、連携されるIDに対する信頼の前提となる、法令や契約に基づく属性検証ルール、検証状態、検証方法等を連携できず。
• 法人についても、法人詳細情報や法人の代理として活動する自然人(代表者等)の情報を連携できず。

対応後• 本WGにおいて、ID連携プロトコル“OpenID
Connect®”を拡張し、属性情報に加え、それがどのように確認されたかを表すメタデータを連携することが可能となるようID連携仕様を策定した。
• 法人については、法人の代理として活動する自然人の情報の連携から、仕様検討を実施中である。
(以上詳細次頁)

 デジタル化の進展による、デジタル空間における規制強化の要請に基づき検討を行った。

成果

 IDに関するメタデータの付与、法人詳細情報の連携により、AML規制対応や不正防止等の対策強化を実現し
ている。

今後の
課題

 他国の法令に基づくIDを信頼できるものとして金融機関業務に利用できるよう法令・ガイドラインに定める等、技術仕様に対応した法制度の整備が必要である。
114

2) ID連携（責任分界を中心に）

2-4. 課題解決（先進的事例からのインプリケーション）⑥標準化団体の取り組み OpenID Foundation eKYC & Identity Assurance WG
 活動概要 eKYC & Identity Assurance WGにおいて、ID連携プロトコル“OpenID Connect”を拡張し、属性情報に加えてそれがどのように確認されたか(法令や契約に基づく属性検証ルール、検証方法等)を表すメタデータを連携するためのデータフォーマット規格
OIDC4IDAの仕様検討を実施
 法人については、法人の代理として活動する自然人の情報の取得、を実現する“Authority Claims”の連携技術仕様を検討中
法人におけるID連携項目イメージ(青枠部分が現在検討中の情報)

自然人におけるID連携仕様イメージ

法人の代理として活動する自然人の情報
出所：OpenID Foundation JapanにおけるKYCに関する取組概要(2021)
https://www.slideshare.net/oidfj/openid-foundationjapankyc-openid-bizday-14

出所：同左

115

7) クロスボーダー取引の諸課題

2-4. 課題解決（先進的事例からのインプリケーション）⑦民間発行IDによるクロスボーダー取引 現在は法域内における民間IDの浸透を最優先し、当該IDを利用した本格的なクロスボーダーには未進出である。
 新eIDAS制定によりEU全域において当該IDが利用可能となった後にクロスボーダーサービスへの本格進出予定である。
現在

新eIDAS制定後

課題対応
の方向性

• 当該ID発行時は金融機関の店頭に赴く必要がある。
• 当該IDはeIDおよびeSignature*1)の双方に準拠しているため、隣接他法域においても利用可能だが、クロ
スボーダーには実質的に未進出である。
• 政府IDもかつて存在したが、現在は当該IDが官民双方のサービスに利用可能である。

• 現eIDAS規則第24条が改訂され、店頭に赴かずに当該IDの発行が可能となる見込みである。
• EUトラステッドリスト*2)認定に伴い、EU全域における利用が可能になる予定である。
• 当該法域政府が独自eID（政府ID）を発行予定
だが、民間発行IDの補足的な位置付けで当該IDの優位性が継続する見込みである。

背景・
成功要因

 提供サービスのリスクに応じた認証レベルの選択が可能である。
 当初から隣接法域のIDとの相互運用性を担保した設計を実施した。

成果

 当該法域の大半の成人市民に普及している。（本格的なクロスボーダーは未導入）
 民間企業が発行したIDを用いて法域内外の官民サービスを利用可能である。

今後の課題 欧州委員会による当該IDへの権限が強まる一方、同法域規制当局の権限が弱体化している。

*1）電子署名に関する指令（2016年7月にeIDASへ置換） https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A31999L0093*2) EU加盟国が適格と認めたサービスプロバイダーの一覧 https://webgate.ec.europa.eu/tl-browser/#/1167) クロスボーダー取引の諸課題

2-4. 課題解決（先進的事例からのインプリケーション）⑦民間発行IDによるクロスボーダー取引
 金融機関において口座開設を行うことによりIDが発行される。
 当該IDを用いて公共サービスや事業者サービスを利用することが可能である。
金融機関が作成したデジタルアイデンティティを用いたID連携フロー①公共サービスへアクセス

公共機関②リダイレクト⑦サービス提供①民間サービスへアクセス⑦サービス提供

⑥ID連携

⑤許可

顧客

金融機関

③確認

事業者

④リダイレクト②リダイレクト

⑥ID連携

⑥ID連携

ID連携サービス
事業者
117

7) クロスボーダー取引の諸課題

2-4. 課題解決（先進的事例からのインプリケーション）⑧欧州大手金融機関によるクロスボーダー口座開設
 ファイヤーウォール規制および個人情報保護規定等の制約がない法域間に限定し、欧州大手金融機関は一部顧客限定で国外からのリモート口座開設サービスを提供している。
 対象を上位ステータス口座保有顧客に限定することで、非対面リスクを抑制している。
従来

当該サービス利用時

＜米国外＞
自宅

課題対応
の方向性

＜米国＞
米国外支店

記入

訪問

面談

申送
・郵送

審査・
口座開設

申請書
コピー

アイデンティ
ティエビデンス

申請書 アイデンティ
ティエビデンス

2週間～数週間

＜米国外＞

米国支店

申請書 アイデンティ
ティエビデンス

自宅①電子申請②リモート面談＜米国＞
インターネット

米国支店

入力

確認

アイデンティティ
エビデンス
撮影・登録

その場で
口座開設

数日（申請～リモート面談日）

背景・
成功要因

 ファイヤーウォール規制および個人情報保護規定等の制約がない法域間では、上位ステータス口座を保有する顧客の情報がグローバルで共有されていた。
 当該顧客情報を活用した他国での口座開設の仕組みが存在した。

成果

 上位ステータス口座を保有する米国外在住顧客が簡易なリモート手続きにより短期で口座開設が可能になった。
 米国における上位ステータス口座数が増加している。

今後の課題

 他法域でのサービス実現ニーズがあるものの、ファイヤーウォール規制および個人情報保護規定等の制約がある法
域間、デジタルアイデンティティを活用できていない法域での実現は困難である。

出所）当該金融機関ホームページ、プレスリリースの内容を元に、NRIにて作成

1185) 相互運用性

2-4. 課題解決（先進的事例からのインプリケーション）⑨オーストラリアにおける官民サービスの相互運用
 オーストラリア政府は金融業界でmyGovID等の政府IDが利用されないと見込み、 TrustID frameworkを策定した。
 中銀・金融業界に加えDTAが参加し、金融系IdPによるID連携・統一を目的としてしている。
対応前

対応後

課題対応
の方向性

• DTA（デジタルトランスフォーメーション庁）を主体にTDIFの策定や、TDIF上のIdPとしてmyGovID（DTA）やDigitaliD（郵便公社）を認証していた。
• しかしTDIFは処理に時間を要することや、様々な制約が設けられていることから金融サービスへの適用が進まなかった。

• APC（Australia Payment Council）が設計するTrustID frameworkにTDIFとの相互運用性を持たせることで相互にサービスアクセス可能になる見込みである。
• 民間企業が発行するIDをTDIFおよびTrustID
framework双方で稼働させることでIdPと民間や政府機関RP間の本人確認ハブとして機能させている。

背景・
成功要因

 TrustID frameworkの策定にDTAおよび豪中銀が参画しTDIFとの相互運用性を担保した。
 郵政公社を巻き込むことにより民間企業が発行するIDによる行政ID管理を可能とした。

成果

 民間企業における顧客ID管理や認証と、政府からの給付金受領などの国民ID管理との双方に利用が可能となった。
 住宅ローン申請時の属性データの証明等、高付加価値のユースケースにおけるコスト節約を図ることが可能となった。

今後の課題 TrustID FrameworkはTDIFから、民間企業が発行するIDはTDIFおよびTrustID Frameworkの双方から認証を受けていない。
 民間企業が発行するID以外に商用フレームワークの提供がなく、また本格的な商業運用はこれからである。
119

5) 相互運用性

2-4. 課題解決（先進的事例からのインプリケーション）⑨オーストラリアにおける官民サービスの相互運用
 PSB （Payment System Board）は、金融システムのリ
スク管理・決済システムの効率化・競争の促進を検討する
RBA内の委員会であり、決済業界との調整機関としてAPCを設立した。
 APCは政府IDの代替としてTrustID frameworkを策定し、さらにTDIFとの相互運用性を持たせることで、官民双方のサービスへのアクセスを可能とした。
 DTA・豪中銀も関与してTrustIDフレームワークを策定した
背景には、政府としてもTDIF上のIdPであるDTAの
myGovIDや郵便公社のDigitaliDが金融サービス内で広く採用されることを期待するのが難しくなったことがある、という意見も見られている。
（参考）TrustID frameworkに参加している組織（2019年時点）
銀行• Australia and New Zealand Banking Group Ltd• Bendigo & Adelaide Bank Ltd• Commonwealth Bank of Australia• National Australia Bank Ltd• Suncorp-Metway Ltd• Westpac Banking Corporation

決済• eftpos Payments Australia Ltd• MasterCard Asia/Pacific (Australia) Pty Ltd• Visa AP (Australia) Pty Ltd• PayPal Pty Ltd• Cuscal Ltd

その他サービス• Coles Group Ltd（小売）• Woolworths Ltd（小売）• Optus（通信）• Australian Postal Corporation（郵便公社）
行政機関等• Digital Transformation Agency• Reserve Bank of Australia

出所：DTA HP、APC annual report 2019、it newsより

120

2-5. 課題解決の方向性の整理

121

2-5. 課題解決の方向性の整理

本節での議論対象
2-1

アナログIMS（対面）の課題
AML/CFT／サービス向上に関する課題（アイデンティティエビデンスの検証困難性、煩雑な顧客手続き等）

非対面化

2-2

アナログIMS（非対面）の課題
課題の
一部解決

新たに
生じる課題

大半の課題は未解決
デジタル化

2-3

デジタルIMSの課題

デジタルIMSによる課
題解決

残余課題
2-4

2-5

新たに
生じる課題

課題解決に向けた検討

課題解決の方向性の整理（SSI/DIDによる一部課題解決への示唆含む）

122

2-5. 課題解決の方向性

本節の検討事項の概要
 デジタルIMSの構築・運用に向けた様々な課題の解決に向けては、前節で取り上げた通り、諸外国において課題に取り組む先進的事例がみられた。
 本節では、2-3-8で挙げた「デジタルIMS化でも解決しなかったアイデンティティ管理上の課題およびデジタルIMS化により新たに発生する課題」に対し、 2-4で挙げた事例等を元に課題解決の方向性を改めて整理する。
 なお、SSI/DIDの活用により解決が期待される課題については、3章で課題解決の方向性を引き続き検討する。
（２）ID連携の課題の一部および３）プライバシーの課題の一部が該当する）

 一方、課題解決の方向性に従い具体的に課題解決を推進するにあたっては、複数のステークホルダーが存在し、各々異なる関心事項を持っていることが想定される。課題解決推進上の課題については、4章にて、想定されるス
テークホルダーおよび関心事項を整理し、解決のアプローチを検討することとする。

123

2-5-1. 本節の検討対象課題一覧

本節の検討対象課題一覧
 2-3-8.で整理した、下表の課題を対象とする。
課題の観点

課題

１）IAL

・デジタルIMSの適切な活用を促す規制フレームワーク整備

２）ID連携（責任分界を中心に）・ID連携当事者間のビジネスモデル・責任分界の未整備
・特定の金融機関(IdP)への依存度が高まる

３）プライバシー（同意管理・データミニマイゼーション）

・ID連携の同意管理負担
・複数サービス横断で顧客データを利活用するための、データ利用許諾の整備負担
・データ提供側として、情報の第３者提供に関する顧客同意対応負担が大きい
・情報の第3者提供に関して、データ受け取り側としての対応負担が大きい
・データ利活用の目的と範囲に関する、顧客と金融機関の認識齟齬リスクの増大

４）金融包摂・デジタル対応できない人物の金融排除

５）相互運用性・煩雑なID連携仕様への対応負担

６）新しい業務へ移行するための投資判断・最適化された既存業務をデジタルIMS利用のために変更する投資判断が困難

７）クロスボーダー取引の諸課題

・AML/CFT規制の国家毎の差異や、FATF基準及びその他の規制・監督上の要件を実施する際の国境を越えたデータ共有への法的な障壁

124

2-5-2. 各課題の解決の方向性

１）“IAL”の課題詳細と取り組み事例・得られた示唆
カテゴリ

課題

課題詳細

取り組み事例と得られた示唆

１）IAL ・デジタルIMSの適切な活用を促 • AML/CFT等の規制目的に適したIALが担保されるデ • 適切なIALの設定およびIALと接合したAML/CFT規制
す規制フレームワーク整備
ジタルIMSの利用が必要であると、FATFのガイダンス 等の整備を行うことが対策として考えられる。
で指摘されている*1)• 整備のアプローチとして、信頼性の高いIDを広く活用する• 適切なIALの整備には、IALと本人確認規程が接合 ことを前提とし、それを可能とするAML規制を整備するとしている状態（＝金融機関が信頼性の高いデジタル いう方策が事例からは示唆される。(②・③事例)
IMSをリスクに応じて適切に使用できるように本人確 • 具体的なAML/CFT規制等の整備に当たっては、技術認規程が規定されている状態）が望ましい。しかし、 革新の取り込み等を鑑み、各金融機関に工夫の余地を
現在は、各法域にてアイデンティティエビデンスに対す持たせることが必要と考えられる。
る規定は存在するもののIALとの明確な紐づけは行わ • また、IAL整備の範囲についても、本人確認に特化せず、れていない等、改善の余地があると考えられる。
AML対応に必要な顧客属性の保証レベルまで踏み込
む等の対応も考えられる(①事例)。
*1)FATF Guidance on Digital Identity (March 2020) http://www.fatf-gafi.org/publications/financialinclusionandnpoissues/documents/digital-identity-guidance.html

125

2-5-2. 各課題の解決の方向性

２）“ID連携” の課題詳細と取り組み事例・得られた示唆
カテゴリ

課題

課題詳細

取り組み事例と得られた示唆

２）ID連携 ・ID連携当事者間のビジ • 金融機関間等でID連携を実施する際に、以下の点が未 • 関係者間協議により、以下のような責任分界の明確ネスモデル・責任分界の 整備であるとID連携ビジネスが立ち行かない点が指摘され 化が必要と考えられる(⑤事例) 。
未整備ている。
–IDの出し手がID連携に当たり保証する責任範囲の• IDの出し手がID連携に当たり保証する責任範囲の明明確化
確化。
–新規口座開設や継続的顧客管理を実施するため• データ過誤により、顧客もしくはID連携を受けた金融機には、実務として許容できるデータの鮮度が必要にな関において何らかの損害が発生した場合の責任分界るため、ID連携する際のデータの鮮度を担保するため• 新規口座開設や継続的顧客管理を実施するためには、 のルール・責任を明確化
実務として許容できるデータの鮮度が必要になるため、–データ過誤により顧客もしくはIDを利用した金融機関
ID連携する際のデータの鮮度を担保するためのルール・において何らかの損害が発生した場合の責任分界の責任を明確化する必要がある
明確化• 上記3点の責任分界に見合う対価の合意
・特定の金融機関(IDプロ • 顧客が、ある金融機関(以下、IDの出し手)が発行したアイ • 特定のIDプロバイダーへの依存度を下げるためには、3バイダー)への依存度がデンティティを用いての口座開設を複数金融機関に対して章で取り上げられた通り、SSI/DIDが課題解決策の一
高まる
行うと、IDの出し手に対する依存度が高まり、リスクが懸念 つと考えられるため、3章で議論を継続する。
される。例えば、IDの出し手の検証に問題が発覚した場合
等、ID連携先の金融機関全てのサービスに停止等の影響が出る懸念があると考えられる。
• 更に、IDプロバイダーである金融機関に問題が発生すると、当該金融機関の発行したIDに依存しているユーザが一括で被害を被る可能性が有り、影響の拡大が懸念されると考
えられる。

126

2-5-2. 各課題の解決の方向性

３）“プライバシー” の課題詳細と取り組み事例・得られた示唆
カテゴリ
３）
プライバ
シー

課題

課題詳細

取り組み事例と得られた示唆

・データ提供側として、情報の第三者 • 個人情報保護法制上、ID連携の際、連携元と連携先との • 法令対応であるので、各国の個人情報保護提供に関する顧客同意対応負担
間で情報の第三者提供に関する同意管理が必要である。
法制に則った対応を実施する必要があると考が大きい• 情報の第三者提供に関する同意管理について、ID連携の拡 えられる。
・情報の第三者提供に関して、デー大に伴い以下のような対応負担が増大すると考えられる。
• 中長期的には、SSI/DIDの仕組みを活用し、タ受け取り側としての対応負担が(データ提供側の負担)
顧客が自己主権により各社とデータ利活用に大きいついて同意する形とすることで、第3者提供とーデータ利活用に関する顧客への説明実施負担・複数サービス横断で顧客データを利いう形態自体を見直し、負担削減を図るといー同意記録の作成・保管等の顧客との同意管理負担活用するための、データ利用許諾のう考え方もあるため、3章で検討を継続する。
(データ受け取り側の負担)
整備負担
ーデータの出し手に対するデータ取得経緯等の確認負担
ーデータ利活用の目的・内容等をデータ提供側に説明し、理解を得る負担・データ利活用の目的と範囲に関す • 国内有識者ヒアリングにて、以下の点が課題として指摘され • 形式的な同意取得ではなく、利用者が提供る、顧客と金融機関の認識齟齬リ ている。
したデータが、金融機関等においてどのようにスクの増大– 金融機関等からのデータ利活用に対する説明が不明瞭で 使われるかを顧客が正しく認識できる管理機
あると、顧客は自らが意図しないデータ利活用がなされてし 能を金融機関が提供する必要があると考えらまう懸念がある。
れる。
– 一方、特に個人においては、金融機関からの説明を完全 • 加えて、上記管理機能自体が正しく機能してに理解し金融機関が説明通りにデータ利活用しているか確 いることを確認するため、第三者による金融機
認することは困難、という側面もある
関の監査も必要と考えられる。
– 結果として、とりあえず同意してしまい、顧客の意図しない • また、情報銀行という形態も解決策の一つとデータ利活用を認めてしまうケースもある。
なりうる。情報の管理を情報銀行に委ねる形
で、情報銀行側で責務を負いデータ提供を実施する。消費者団体が情報銀行の認定制
度を設ける事例もみられる。*1)*1)日本IT団体連盟による「情報銀行」の認定制度

https://www.tpdms.jp/system/index.html

127

2-5-2. 各課題の解決の方向性

４）“金融包摂” の課題詳細と取り組み事例・得られた示唆
カテゴリ

課題

４）
・デジタル対応できない人物の
金融排除
金融包摂

課題詳細

取り組み事例と得られた示唆• デジタルインフラ整備状況の観点からの金融排除懸念に • 各国の金融機関の業務整備状況や各国の政治
ついて、FATFのガイダンスでは以下の指摘がされている。
体制等に応じた方針での対応になると考えられる*1)– 金融で活用できるデジタルアイデンティティインフ– 携帯電話・スマートフォン等が十分普及していない、イラ(アイデンティティ管理インフラや決済インフラ)を
ンターネットアクセスが可能な地域が限定的、等の理国を挙げて整備し、全国民をデジタルに取り込
由からデジタルインフラの活用が難しい地域においては、む方針(②シンガポール・③インドの事例)
デジタル化の推進が金融排除を生む懸念がある– 既存の業務も活用しアナログ・デジタル両方の• デジタルに対するリテラシーの観点の金融排除懸念につい形での受入を行う方針(日本等先進国)て、海外有識者へのヒアリングでは以下が指摘されている。 • マイノリティに対して、オペレーションの代理を行う職– デジタル化されていない人々の年齢層を見てみると高務(既存の行政書士に近い役割)を設け、運用対齢者の方が多く、彼らがデジタルサービスの利用、携帯 処を行う方策も考えられる
電話の銀行アプリの利用に躊躇する理由は、間違った • デジタル化によりAML規制対応の強化を図ってい操作に対する恐怖、例えば誤ってボタンを押してしまい る側面もあるため、AML規制強化と金融包摂のバ
間違った場所に送金してしまうなどの恐怖等の精神的 ランスを取った対応が必要と考えられる障壁である*1)FATF Guidance on Digital Identity (March 2020) http://www.fatf-gafi.org/publications/financialinclusionandnpoissues/documents/digital-identity-guidance.html

128

2-5-2. 各課題の解決の方向性

５）“相互運用性” の課題詳細と取り組み事例・得られた示唆
カテゴリ

課題

５）
・煩雑なID連携仕様へ
相互運用
の対応負担
性

課題詳細

取り組み事例と得られた示唆• 国内有識者ヒアリングにて、ID連携負担に関する • 技術仕様や関連する法制度の整備を官民の連携により対応し、
以下の課題が指摘されている。
社会全体への幅広い普及を目指す事例もみられる(⑩オーストラリア– 各金融機関が独自の仕様でデジタルIMSをの事例)実装してしまうと、金融機関間でID連携を行 • 左記は、主に一つの法域の範囲を想定した課題であるが、国をまたう際に、各金融機関の接続の度に別の技術いだ技術仕様の相互運用性ついても同様であり、グローバルでID連仕様に基づく接続対応が必要となる。
携仕様の標準化が進められている(⑥標準化団体の取り組み)– これは接続負担の増大につながり、結果、ID
国内有識者ヒアリングにおいても、以下が指摘されている。
連携の拡大につながらずID連携がビジネスとし – 各国毎に別々の仕様になるだけでも実装負荷は膨大となる。
て立ち行かない、顧客がデジタルアイデンティ– このため、国際標準一本化はより望ましい姿と、ベンダー等からはティを広く活用できず、社会全体にデジタルア
とらえられている。
イデンティティが普及するスピードが上がらない、 – ベンダーは、各国仕様に応じた実装は非常に煩雑と考えており、といった結果を招く。
積極的にISO活動等のグローバルな標準化活動に参画している。
• また、標準の策定にとどまらず、Certification Programの策定等、標準への準拠性を検証し正しく普及させる仕組みも出てきている。
（例）FDX(Financial Data eXcahnge)*1)– 準拠性を機械的に検証可能な仕組みも提供し、標準準拠の認定を実施– グローバルに共用できる部分と各国制度等による部分を各々検証（FDXのCertificateのテスト手順）
1次試験：OIDF Certificate(FAPI ConformanceTest)
2次試験：各国個別要件に応じたテスト*1)FDX Press-Release “Financial Data Exchange, OpenID Foundation Take Step Towards Global Standard for Financial Data Sharing” (March 2019)https://openid.net/2019/04/02/financial-data-exchange-openid-foundation-take-step-towards-global-standard-for-financial-data-sharing/129

2-5-2. 各課題の解決の方向性

６）“新しい業務へ移行するための投資判断” の課題詳細と取り組み事例・得られた示唆
カテゴリ

課題

課題詳細

取り組み事例と得られた示唆

６）
・最適化された既存業務をデジタル • 国内有識者ヒアリングにて、以下の課題が指摘されている。• 自らの持っているアイデンティティ情報の収益化
新しい業
IMS利用のために変更する投資判– デジタルIMS利用のための初期投資は、アナログIMS
によるコスト回収は対策の一つとして考えられる
務へ移行
断が困難
からの移行期間中は純粋に追加コストとなり、最適(⑤事例(ID連携))。
するための化された現行業務を変更してまで対応するインセン• ID連携事業単体で投資を回収するという収益
投資判断
ティブを見つけることが難しい。
回収モデルではなく、既存のオペレーションコスト– セキュリティ対応等は、技術進歩に合わせて継続的に 低減や盗難・不正行為の減少による対応コスト
投資することが必要であるが、どこまで最新技術を追低減などのコスト低減効果*1)も加味した、包いかけるための投資を行うべきか、判断できない。
括的な施策としてとらえる考え方もある。
– 新たな取り組み単体での収益化計画策定は困難。 • また、アイデンティティエビデンスとして国民IDを活既存プロセスからの移行に伴う既存コスト圧縮等を加 用する場合、国・当局は国民IDの整備コストに味した計画を作らねばならない。
ついてインフラコストに加えて普及コストの観点からも検討する必要があること*2)、金融機関は国
民IDのルール整備状況や普及状況に応じて手戻りのない投資が重要であること*1)、がそれぞれ文献で指摘されている。
*1)Private Sector Economic Impacts from Identification Systems https://elibrary.worldbank.org/doi/pdf/10.1596/31828*2)Public Sector Savings and Revenue from Identification Systems:Opportunities and Constraints
https://documents1.worldbank.org/curated/en/745871522848339938/pdf/Public-Sector-Savings-and-Revenue-from-Identification-Systems-Opportunities-andConstraints.pdf

1302-5-2. 各課題の解決の方向性

７）“クロスボーダー取引の諸課題” の課題詳細と取り組み事例・得られた示唆
カテゴリ

課題

課題詳細

取り組み事例と得られた示唆

７）クロス ・AML/CFT規制の国家毎の差異や、 • 金融機関は一定額を超えた海外送金には送金元・送金 • FSBにおいては、左記課題の解消を目指し
ボーダー取
FATF基準及びその他の規制・監督 先に関する情報の収集を求められている。
た対応ロードマップを作成し、対応方針の議
引の諸課上の要件を実施する際の国境を越 • FSBでは、海外送金時の送金元・送金先確認について、以 論を継続(2-3-5【AML/CFT】クロスボーダー
題
えたデータ共有への法的な障壁下のような法的障壁があるとしている。
取引の諸課題をめぐる動向 参照)– 各国におけるAML/CFT規制の差異により、本人確認の • 各金融機関・法域においては、EUという広厳格さのレベルが異なり、情報の信頼性に懸念がある。 域で利用できるeIDを用いてクロスボーダー取– 送金元・送金先に関する個人情報を国境を越えて共有 引の効率化を図ろうとする動き(⑦事例)や、する必要がある際に、各国のデータ保護法制が障壁とな 顧客を富裕層と限定することで、業務負担る場合がある。
を許容し外国からの口座開設を受け入れる
動き(⑧事例)等の個別の動きが見られる。

131

2-6. 本章の結論

本章の結論
 金融分野においてもデジタルアイデンティティの重要性は認識されており、また、信頼性の高いデジタルIMSの構築に
より、AML規制対応強化の実現とともに、アイデンティティエビデンスの検証負担等アナログを理由とした業務負担が多数解消されることが期待されることを確認した。
 このため、１章で述べたデジタルアイデンティティ概論と同様、フェデレーションモデルのアイデンティティマネジメントシステ
ムになりつつあり、デジタルアイデンティティの活用が進展していくと考えられる。銀行がIDPとなる事例もあり、かつIDPとしての役割への期待が大きいことも、この流れを後押しすると考えられる。
 この実現のためには、規制整備、責任分界、技術仕様の整備、プライバシー、金融包摂への配慮、新しい業務へ移行するための投資、といった課題の解決が求められる。本章では、先行事例等を参考にしつつ課題解決の方向性の整理を行ったが、実際の課題解決に当たっては規制当局・金融機関・顧客といったステークホルダー間の協議による推進が求められる。協議推進上の課題の解決については4章で引き続き議論を行う。
 また、デジタルIMSの課題として指摘された特定の金融機関(IDプロバイダー)への依存に対する対応やプライバシーの課題については、SSI/DIDの活用によってさらなる改善が図られる期待がある。この点は、3章で引き続き議論を行う。

132

第3章

自己主権型アイデンティティ(SSI)/分散型アイデンティティ(DID)133

3. 自己主権型アイデンティティ(SSI) /分散型アイデンティティ(DID)

本章の概要
3-1. SSI/DIDの概要
 自己主権型アイデンティティ(SSI)と呼ばれる思想と、その実現手段として検討されている分散型アイデンティティ（DID）に関する議論動向について整理した。
 SSIモデルによるIMSは、現時点で確立した標準が存在しない。したがって、代表的なユースケースを踏まえつつ、本調査におけるDIDを用いたSSI/DIDの想定実装イメージを定義した。その結果、
1. 認証と属性の分離、2. 分散した属性の活用・選択的な提示、3. 提示先の秘匿（Unlinkabilityの確保）、
4. デジタルアイデンティティの長期の保管・利用が可能、という4つの特性の導出を行った。

3-2. SSI/DIDの実現に必要な構成要素
 SSI/DIDに関する複数の標準化団体が提唱する実現方式を俯瞰し、3-1.で導出した特性の実現において技術面・統制面の両観点から必要な構成要素の抽出・整理を行った。

3-3. SSI/DIDの先行事例/PoC事例
 SSI/DIDに関して、特に先進事例として注目されているカナダのVerified.Me及びスペインのAlastria_ID/Dalionを中心に取組内容について整理した。

3-4. SSI/DIDの長所と実現に向けた課題
 SSI/DIDの長所と実現に向けた課題について整理した。SSI/DIDは3-1で挙げた4つの特性を活用することで、①自己主権の獲得②プライバシーへの配慮③利便性の向上／業界全体のコスト抑制、といったメリットが期待出来る。
 他方、課題としては、①技術②法的/制度③運用④ビジネスの観点で継続検討が必要な課題が存在する。

3-5. SSI/DID活用時の金融規制上の論点
 SSI/DIDを金融取引に活用する際に必要となる金融規制上の論点について検討を行った。SSI/DID独自の論点として、①ウォレットに対する金融規制の考え方、②新たな本人確認情報に対する法的手当て、の観点から整理した。
134

3-1. SSI/DIDの概要

135

第3章 自己主権型アイデンティティ(SSI)/分散型アイデンティティ(DID)「3-1. SSI/DIDの概要」の要旨
 SSIとDIDの概要
 SSIとは、「アイデンティティの管理主体が介在することなく、個人が自分自身のアイデンティティをコントロールできるようにすることを目指す思想」である。
 DIDとは、「ユーザのデジタルアイデンティティが特定のIdPに依存しないよう、その依存度を下げることを目的とする仕組み」のことである。

 SSI/DIDの特性
 SSI/DIDに関する定義を踏まえ、以下4点の特性を導出した。
実現すべき項目
認証と属性の分離••

項目概要
特定IdPへの依存度を下げるため、Recognition（当人認証）とSelfness（属性）を分離
クレームプロバイダー（CP）からDIDと紐づける形で属性を発行し、その後DIDを用いてリライングパーティ（RP）に対し認証を行うことで、クレームの連携を行う

分散した属性の活用・選択的な提示••

複数CPからのクレーム取得・連携
ウォレットからRPに対し選択的に提示する

提示先の秘匿（Unlinkability）•

ウォレットを介したクレームの連携を行うことで、CPに対し、クレームの送付先となるRPを秘匿しつつクレームの連携を行う•発行されたクレームの検証に用いる資材を分散リポジトリに長期保管することで、仮にCPが存在しなくなった場合でも、過去に発行されたクレーム検証が可能（分散リポジトリにブロックチェーンなど
Immutableな性質を持つ技術を採用することで、検証に必要な資材の完全性・透明性を確保する方式を提案する標準化団体も存在）

長期のデジタルアイデン
ティティの保管・利用

136

3-1-1. SSI/DIDの全体像

自己主権型アイデンティティ（SSI）とは
 SSIとはアイデンティティの管理主体が介在することなく、個人が自分自身のアイデンティティをコントロールできるようにすることを目指す思想(※)。
※ : Sovrin Foundation, https://sovrin.org/faq/what-is-self-sovereign-identity/

 ユーザが自分の属性情報に関するコントロール権を確保の上、信頼できる組織から発行された本人の属性情報を取得し、ユーザの許可した範囲でRP等に連携できるようにする。

SSIの概念図[ 凡例 ]

ユーザ
IdP

クレーム

クレームの流れ

クレーム

RP

137

3-1-1. SSI/DIDの全体像

分散型アイデンティティ（DID）とは
 自分自身でデジタルアイデンティティを自己制御できることを目的とするSSIに対し、分散型アイデンティティ(Decentralized Identity: DID)は、ユーザのデジタルアイデンティティが特定のIdPに依存しないよう、その依存度を下げることを目的とする。
 実現にあたり、ブロックチェーン等の分散レポジトリの活用が提唱されることが多く、例えば、分散型アイデンティティのホワイトペーパーを公表しているマイクロソフトは以下のように定義している(※) 。
「分散型アイデンティティとは、ユーザ名などの識別子を、自己所有の独立したIDに置き換え、ブロックチェーンや分散型台帳技術を用いてデータ交換を可能にすることで、プライバシーの保護や取引の安全性を確保することができるトラストフレームワーク」(Microsoft) ※ : Microsoft, https://www.microsoft.com/en-us/security/business/identity-access-management/decentralized-identity-blockchain

 DIDの実装にあたり、例えばWorld Wide Web Consortium(W3C)においては、以下二つの技術が検討されている。
• Decentralized Identifiers (DIDs)• Verifiable Credentials (VCs)[ 凡例 ]
DIDの概念図Claims Provider
クレーム
（VCs）

ユーザ
（IdP）

Relying Party

クレームの流れ

クレーム
（VCs）
DIDs
ウォレット

分散リポジトリ（例：ブロックチェーン）138

3-1-1. SSI/DIDの全体像

本調査と標準化団体でのSSI/DIDに関する用語
 SSI/DIDについては3-2-2.項で挙げる標準化団体等がそれぞれ仕様の策定を進めており、SSI/DIDにおける概念の名称についても団体によって表す用語が異なる。
 そのため、本調査でのSSI/DIDに関する概念の名称は1-1.節にてISO/IEC24760-1とOpenID Connect Core 1.0を基にした「IMSを構成する主要アクター」での用語を基本は引き続き用いつつ、W3C等による図表や仕様の説明では
当該団体ごとの用語を用いるため、以下の通りに対応させる。
本調査とW3CによるSSI/DIDに関する用語
Claims Provider/
Issuer

ウォレット

本調査での用語

1 クレーム (Claim)

W3Cによる用語

Verifier
クレーム
（VCs）

クレーム
（VCs）

#

Relying Party/

ユーザ[ 凡例 ]
クレーム / Verifiable
Credentialの流れ

DIDs

本調査での用語の定義

 Verifiable
Credential

 アイデンティティであるエンティティの属性集合のうちの一部の属性集合

2

クレームプロバイダー(Claims Provider: CP) Issuer クレームを提供するエンティティ

3

リライングパーティ(Relying Party: RP)

 Verifier 特定のエンティティのアイデンティティ情報のベリフィケーションに依拠するエンティティ

W3Cでの用語の定義※
 暗号学的に検証可能な作成者を持ち、改ざんや盗み見がわかる (tamper-evident)
なエンティティの属性集合
 クレームを主張（assert)、クレームから
Verifiable Credentialを生成、Verifiable
Credentialをホルダーに送るエンティティ
 Verifiable Credentialを受け取る
エンティティ

※ 出所）Verifiable Credentials Data Model 1.0 1.2 Ecosystem Overview https://www.w3.org/TR/vc-data-model/ を基にNRI作成

139

3-1-1. SSI/DIDの全体像「SSIの7原則（Seven Laws of Identity)」と本章の整理方針
 1-3.節でも示した通り、キムキャメロン氏は「アイデンティティの7原則」をベースにした「SSIの7原則」を提示しており、具体的には、原則５及び６が更新されている。
 以降本章では、この2点の原則を踏まえ、SSI/DIDの構成要素について整理していく。
#

原則

内容

1

ユーザによる制御と同意•

アイデンティティ・システムは、ユーザの同意がなければユーザを識別する情報を開示すべきではない2

限定された用途で最低限の公開•

最も安定し、長期にわたって使用できるソリューションとは、開示するアイデンティティ
情報を最小限にし、情報へのアクセスを適切に制限するソリューションである

3

正当な関係者のみへの情報開示•

アイデンティティ・システムは、特定の状況において識別情報を必要とし、かつ入手できる正当な権利を持つ関係者のみに対して情報を開示するように設計されなければならない•

アイデンティティ・システムは、公に使用する「全方位的」な識別子とプライベートで使用する「特定の方向性」を持った識別子の両方をサポートしなければならない。このことにより公共性を維持しながら不必要に関連付けの公開を防止できる

4

方向づけられたアイデンティティ

5「アイデンティティハブ」の統合•

ユーザは、プロバイダー間で一貫した方法で自分自身を表現し、アイデンティティを使用することができ、同時にコンテキスト間でアイデンティティを分離することができる

6

長期のアイデンティティの安定性に向けたDIDの統合•

個人データを事業者に依存しない形で保管したうえで、アイデンティティ事業者を存続させ、サービスとの関係を維持する•

アイデンティティ・システムは、利用者たるユーザを分散システムの1つのコンポーネントとして定義しなければならない。明確なマンマシン・インターフェイスを策定してユーザを分散システムに統合し、アイデンティティを保護しなければならない

7

人間の統合

140

3-1-2. SSI/DIDで実現すべき項目

SSI/DIDで実現すべき項目
 各標準化団体（W3C、DIF、OpenID Foundation等）では、実現のプロトコルは異なるものの、SSIの7原則の項番５「アイデンティティハブ（※）の統合」および項番６「長期のアイデンティティの安定性に向けた
DIDの統合」の実現すべき項目手段として、いずれも以下の４項目について言及している。

実現すべき項目

認証と属性の分離••

項目概要
特定IdPへの依存度を下げるため、Recognition（当人認証）とSelfness（属性）を分離
クレームプロバイダー（CP）からDIDと紐づける形で属性を発行し、その後DIDを用いてリライングパーティ（RP）に対し認証を行うことで、クレームの連携を行う

分散した属性の活用・選択的な提示••

複数CPからのクレーム取得・連携
ウォレットからRPに対し選択的に提示する

提示先の秘匿（Unlinkability）•

ウォレットを介したクレームの連携を行うことで、CPに対し、クレームの送付先となるRPを秘匿しつつクレームの連携を行う•発行されたクレームの検証に用いる資材を分散リポジトリに長期保管することで、仮にCPが存在しなくなった場合でも、過去に発行されたクレーム検証が可能（分散リポジトリにブロックチェーンなど
Immutableな性質を持つ技術を採用することで、検証に必要な資材の完全性・透明性を確保する方式を提案する標準化団体も存在）

長期のデジタルアイデン
ティティの保管・利用（※）アイデンティティハブとは、「個人データの管理をユーザの手に委ねる、分散化されたオフチェーンの個人データストア」のこと。
出所）Microsoft, “Identity Hubs as personal datastores” (Mar. 2019)}
https://techcommunity.microsoft.com/t5/azure-active-directory-identity/identity-hubs-as-personal-datastores/ba-p/389577

141

3-1-2. SSI/DIDで実現すべき項目

ユースケース：就職活動時に就職先に卒業証書を提示【既存モデル】
 就職活動者が、希望企業に対して必要な書類（本ケースでは大学の卒業証書や成績証明書等）を提示するというユースケースにおいて、現在のFederationを用いた既存モデルでは、以下のようなフローにて処理されるのが一般的。

 既存モデルでは、クレームの管理を大学等のIdPに強く依存しており、例えば下記に示すリスクが想定される。
 クレーム提示の際、大学等においてユーザ認証が必要となる。アカウント停止措置等により身分証明書の取得が困難となる。
 企業側に提示する情報について応募者にコントロール権※がない。
 どの企業に応募しているか、大学等に知られてしまう※）例えば、XX年に〇〇大学を卒業したことだけを提示したいのに、成績や応募者の個人情報等が含まれてしまう等懸念がある。

 大学が将来的に統廃合や倒産等で消滅した場合、当該大学から証明書が発行不可能となってしまう
既存モデルで就職活動時に就職先に卒業証書を提示するケース

大学等

応募者

企業
①サービス要求（就職希望申請）②身分証明書の提示要求③提示元（大学等）を指示

1

既存モデルで想定されるリスク
1. IdPである大学にアカウント停止される④身分証明書の取得要求
発行

3⑤デジタル身分証明書返却⑥デジタル身分証明書返却

検証

2. 証明書に含まれる情報提示のコントロール権が無い

2⑦デジタル身分証明書返却⑧サービス提供

統廃合・
倒産等

4
発行NG

3. 発行/検証時の通信で、大学にクレーム提示先（企業）を知られる⑨サービス要求⑪身分証明書の取得要求⑩身分証明書の提示要求

4. クレームの再発行が出来ない142

3-1-2. SSI/DIDで実現すべき項目

ユースケース：就職活動時に就職先に卒業証書を提示【SSIモデル】
 SSIのモデルは、これら既存モデルの課題を解決できるモデルであると言われる。具体的には、SSIモデルが提示する
1. 認証と属性の分離、2.分散した属性の活用・選択的な提示、3. 提示先の秘匿、4. 過去取得したクレームの再提示・検証が可能、といった特徴により、既存モデルの懸念を解消する可能性を有している。
SSIモデルで就職活動時に就職先に卒業証書を提示するケース
大学等

応募者

企業

⓪DID登録※関係者がDID登録※※DIDの登録については
3-2-1.節のSSI/DIDの実現に必要な構成要素の整理にて詳述する。

①サービス要求②身分証明書の提示要求③身分証明書の取得要求

1

発行④デジタル身分証明書返却⑤ウォレットに格納

2

分散リポジトリ（例：ブロックチェーン）⑥デジタル身分証明書の提示⑦デジタル身分証明書の検証要求

3⑧検証の為の情報取得

既存モデルのリスク解消に寄与する
SSIモデルの特徴
1. 認証と属性の分離

検証⑨サービス提供

2. 分散した属性の活用・選択的な提示⑩サービス要求⑪身分証明書の提示要求
統廃合・
倒産等

3. 提示先の秘匿⑫ウォレットに格納⑬デジタル身分証明書の提示

4

検証OK

⑭デジタル身分証明書の検証要求⑮検証の為の情報取得

4. 過去取得したクレームの再提示・検証が可能
143

3-1-2. SSI/DIDで実現すべき項目

SSI/DIDで実現すべき項目 – 1. 認証と属性の分離
 「認証と属性の分離」とは、Recognition（当人認証）とSelfness（属性）の分離を意図する。
 分散型のデータ連携が可能• ユーザの持つ「ウォレット」と呼ばれるデータ保管場所をハブとして、取得したクレームを様々なRPに対し連携することが可能となった。その結果、自分の個人情報を自らがコントロールし、各企業へ必要な情報を連携しながら価値提供が可能となる。
• Peer to Peerの対向認証に必要となるクレデンシャル情報（識別子（ユーザID等）・シークレット（パスワード等））と、連携される属性を分離する。
 既存モデルの抱えるリスクを解消• IdPが行う不合理なユーザアカウント停止等により、ユーザが自らの属性情報を取得できなくなる課題があった。
これに対し、ユーザがDIDを使うことで、アカウント停止の回避が可能となる。
• CP以外にウォレットにもクレームを保持。また分散型台帳技術（DLT）や長期署名等を用いたヒストリカルな署名を付与することで、当該時刻におけるデータの真正性が保証可能となる（IdPによる改ざんが困難）。
アイデンティティの管理

アイデンティティ構成要素

従来

SSI/DID

ユーザ識別子DID

Recognition

ユーザシークレット
ユーザ属性

IdP
Selfness

CP
Wallet（発行元）（保存）144

3-1-2. SSI/DIDで実現すべき項目

SSI/DIDで実現すべき項目 – 2. 分散した属性の活用・選択的な提示 「分散した属性の活用・選択的な提示」とは、点在するCPからクレームを収集し、ユーザが意図したクレームのみをRPに展開可能なことを意図する。
 例えばW3Cの規程する「Verifiable Credentials Data Model」では、ユーザはCPから取得したVerifiable Credentialを束ね自身のペルソナのサブセットとして提示（Verifiable Presentationと呼ばれる）が可能なモデルが示されている。
Verifiable Credentials Data ModelにおけるVerifiable Credentialのライフサイクル

Verifiable Credentials Data ModelにおけるVerifiable Credential(s)と・Verifiable Presentationの概要図

Verifiable
Credential(s)Verifiable
Presentation※W3Cにおいては、クレームを検証可能な形で発行する役割を”Issuer”、
クレームを受領し発行元や真正性等を検証する役割を”Verifier”として定義
出所）Verifiable Credentials Data Model 1.0
3.2 Credential 3.3 Presentations https://www.w3.org/TR/vc-data-model/

1453-1-2. SSI/DIDで実現すべき項目

SSI/DIDで実現すべき項目 – 3. 提示先の秘匿（Unlinkability）
 「提示先の秘匿（Unlinkability）」とは、ホルダーがCPに、発行されたクレームをどのRPに連携したか知られることなく、クレームの連携・検証が可能なことを意図する。
 クレームを受け取ったRPは、その真正性を検証（Verify）する必要がある。その際、付与された署名値の検証に用いる検証鍵を、クレーム発行元であるCPに照会してしまうと、クレームの連携先が露呈する。
 RPに対し、分散リポジトリ等で展開されたメタデータを参照し検証鍵を取得させることで、上記CPから見て、クレームを発行した「ユーザ」とその連携先である「RP」が紐付くことを回避する（CP-RP Unlinkable※を満たす）。
※ ISO/IEC FDIS 27551記法に準拠

Holderを介したクレーム連携概要、およびRPにおけるクレーム検証の仕組み※W3CでのIssuerはCPに該当する

出所）Verifiable Credentials Data Model 1.0
https://www.w3.org/TR/vc-data-model/

146

3-1-2. SSI/DIDで実現すべき項目

SSI/DIDで実現すべき項目 – 4. 長期のデジタルアイデンティティの保管・利用
 「長期のデジタルアイデンティティの保管・利用」とは、一度CPによって発行されウォレットに格納されていたクレームが、CPの状態に関わらず、継続的に利用可能な状態を維持することを意図する。
 例えば発行元（CP）が大学等の場合、統廃合によりCPが存在しなくなる可能性がある。
その場合でも、過去発行されたクレームが正当なものである（真正性が保証されたものである）ことが確認可能。
 仮にCPがクレーム発行後に内容の改ざんを企図したとしても、過去時点で発行されたクレームの真正性検証が可能である。
長期のデジタルアイデンティティの保管の概観
時間

クレーム
プロバイダー（CP）

クレーム検証に必要な検証鍵情報を登録もしCPがビジネスを終了しても、RPは分散リポジトリ上から検証に必要な公開鍵を取得可能

分散リポジトリ（Blockchain等）

リライングパーティ（RP）

受領済クレーム（CP署名鍵で署名付与）

クレーム検証に必要な検証鍵情報を取得

クレーム検証に必要な検証鍵情報を取得

クレーム検証に必要な検証鍵情報で署名検証

クレーム検証に必要な検証鍵情報で署名検証

147

3-2. SSI/DIDの実現に必要な構成要素

148

第3章 自己主権型アイデンティティ(SSI)/分散型アイデンティティ(DID)「3-2. SSI/DIDの実現に必要な構成要素」の要旨
 構成要素の整理
 SSIモデルによるIMSは、現時点で確立した標準が存在しないものの、各標準化団体が提唱するモデルいずれも4つの特性が共通的に登場する。本調査では、代表的なユースケースを踏まえつつ、この特性を実現するための処理フローを定義した。

 技術面での整理
 SSIモデル実現方法として、各団体が上述の処理フロー実現のために策定しているプロトコルとその概要を整理した。
 相互運用性の動向として、団体間での動向（OpenID Foundation / DIFにおけるリエゾン協定）、仕様策定の動向（Presentation Exchange/DID Comm, CHAPI/Verifiable Presentation Request Specificationの仕様統合）等、
一部で協調・収斂の動きもある。但しデータモデルに関する議論は一定検討にあがっているものもあるが、Communication
LayerやUtility Layerについては、今後更なる収斂の動きが期待される状況にある。

 統制面での整理
 SSIモデルのIMS運用に参加するステークホルダー間でアイデンティティインフォメーションの連携を行う際、相互に信頼を維持した
上でデータの連携を行う必要がある。そのためには、「トラストフレームワーク」と呼ばれる、仕組みに参加したステークホルダーを定義し、各ステークホルダーが役割と義務を適切に担うことで、系全体の信頼性を担保するやり方が存在する。
 IMSトラストフレームワークの実務者向けガイドであるOIX Guide to Trust Frameworkでは、SSIモデルに特徴的なアクターであるホルダーを含める形で、各ステークホルダーの定義と付随するロールの定義を行っている。同ガイドを元に、SSIモデルにおいて
ステークホルダーに求められるロールと、充足すべき統制要件の整理を行った。
 その結果、統制要件自体は、従来の集中型・Federation型モデルのIMSから変わらない一方、どのステークホルダーがどのロールを担うかにより、従来のモデルでは想定されなかったステークホルダー間の利害衝突が発生し得る点が明らかになった。

149

3-2-1. SSI/DIDの実現に必要な構成要素の整理

処理フローの定義
 3-1-2.項で述べたユースケースを対象に、DIDの生成およびクレーム連携処理に関する処理フローを定義した。
1. DIDの登録処理
ホルダーがID Proofingを行い、DIDのActivation処理が完了し、DIDが有効状態に遷移するまでの処理を行う。
2. クレームの連携処理ホルダーがDIDを取得後にIdPとなり、CP / ホルダー間, 及びホルダー / RP間でのクレーム連携処理を行う。
処理

処理概要

1. DIDの登録処理（DIDが有効状態に遷移するまでの処理）
1-1. DIDおよびメタデータの生成・登録

DIDおよびメタデータの生成・登録を実施

2. クレームの連携処理

DIDの処理フローの概観
Hold
er

CP

2-1
2-2

2-3

1-1

2-1. CP上のユーザとDID
所有者のBinding• ユーザがCP内のCSPに対し認証を実行• CPは、ユーザから”ユーザのDIDを保持・管理していることを示す
情報” を受け取り、DIDを操作しているエンティティと、CP上のア
カウントを操作しているエンティティが同一であることを確認した
上で、Bindingを実施

2-2. クレーム発行

2-1で受け取った情報を利用し、クレーム発行要求してきたエンティ
ティに対するクレームである点を検証した上で、クレームを発行

2-3. ウォレットへのクレーム
格納2-2) で取得したクレームをウォレットに格納・保持

2-4. RPに対するユーザ認証

ウォレットとRP間で、1-1) のDIDおよびメタデータを用い対向認証

2-5. クレーム連携• 2-4)で対向の認証が完了後、2-3)で取得したクレームを連携。
• RPは、受領したクレームが、2-4) で認証したユーザのDIDとBindingされ発行されたクレームか（Verification）、
および連携されたクレームは有効か（Validation）を検証

RP

2-4
2-5

150

3-2-1. SSI/DIDの実現に必要な構成要素の整理

処理フローの定義 – 1. DIDの登録処理（1-1. DIDおよびメタデータの生成・登録）① ユーザは、自身のクレーム連携の為に用いる分散型アイデンティティ(DID)をRegistration Authority（RA）を介し、生成・登録を実施する。
② 従前のIMSと同じく、何らかのID Proofingを行った上で、ユーザがウォレットの機能を使い、DID及び関連メタデータを発行する（DID生成時には、DIDの所有者であることを示すために用いられる秘密鍵/公開鍵の鍵ペアも生成）。
凡例）

DID秘密鍵
DID公開鍵DID、および関連メタデータ①ID Proofing

IIA&IdP
RA
IIP

RP

ウォレット

リライングパーティ②DID及び関連メタデータを発行

IdP
クレームプロバイダー

1513-2-1. SSI/DIDの実現に必要な構成要素の整理

処理フローの定義 – 2. クレームの連携処理（2-1. CP上のユーザとDID所有者のBinding）
 クレームプロバイダーが、ユーザから提示されたDID所有者情報と、クレームプロバイダー上にあるActiveなユーザのIdentifier間のBindingを実施する。
 ユーザは、クレームプロバイダーのIdPでAuthenticationを行うとともに（①）、クレームプロバイダーに対しクレーム発行要求を行う。
その際併せてユーザは ”ユーザのDIDを保持・管理していることを示す情報” を提示し、DID所有者であることを証明する（②）。

 クレームプロバイダーのIdPは、①，②の結果に問題が無ければIdPの管理するIdentifierとクレーム発行要求をしてきたHolderとのBindingを行う（③）。
①クレームプロバイダーのクレデンシャル（IIPでのAuthentication）③Binding
IIA/IdP②クレーム発行要求（DID及びDID
メタデータも併せて提示）①Proofing,
Verifier

IdP

RP

ウォレット

リライングパーティ

IdP

クレームプロバイダー

1523-2-1. SSI/DIDの実現に必要な構成要素の整理

処理フローの定義 – 2. クレームの連携処理（2-2. クレーム発行、2-3.ウォレットへのクレーム格納） 2-2. クレーム発行：Binding内容を踏まえ、クレームプロバイダーは、DID向けのクレームを発行し、ウォレットに送付する（①）。またその際、下図の様に、複数IdPからクレームを収集することも有りうる。
 収集先のIdPは、別にIIAが存在するケースもあれば、IIAとIIPを兼ねるケースも存在する。

 ユーザ自身が属性情報を主張しクレーム（自己証明のクレーム）として発行するケースも存在（下図クレーム(K)参照）。

 2-3. ウォレットへのクレーム格納：ホルダーは受領したクレームの真正性・有効性検証を行い、ウォレットに格納（②）。

①クレーム発行
IIA/IdP (X)①クレーム発行
クレーム(X)①クレーム発行
IIA(Y)IdP (Y)

クレームプロバイダー

クレーム(Y)

クレーム(K)

IdP (X,Y)&IIA/IdP (K)②Verification,
Validation

ウォレット

RP

リライングパーティ
153

3-2-1. SSI/DIDの実現に必要な構成要素の整理

処理フローの定義 – 2. クレームの連携処理（2-4. RPに対するユーザ認証、2-5. クレーム連携） 2-4. RPに対するユーザ認証：DIDと関連メタデータを用い、ウォレットとRP間でセキュアなチャネルを確立（③）。
対向認証の技術仕様は、各標準化団体が多様な仕様を策定しているが、概して1-1. で生成した秘密鍵/公開鍵ペアを用いた、公開鍵暗号方式に基づく形を提唱している。

 2-5. クレーム連携：ユーザは保持するクレームから提示を許容したもののみリライングパーティに提示（③）。
リライングパーティは、受領したクレームの真正性・有効性検証を行い（④）、問題なければユーザにサービスを提供。

③対向とのチャネル確立、およびクレーム提示

IIA/IdP (X)
IdP (X,Y)&IIA/IdP (K)IIA(Y)

RP(X,Y,K)④Verification,
Validation

IdP (Y)

クレームプロバイダー

クレーム(X, Y, K)

ウォレット

リライングパーティ
154

3-2-1. SSI/DIDの実現に必要な構成要素の整理（参考）Bindingにおける考慮事項 – Bindingの必要性
 3-1-2. 項で述べた通り、SSI/DIDの特性として、 Recognition（当人認証）とSelfness（属性）の分離があげられる。一方で、この二つを分離する場合には、連携されたクレーム（属性）が、当人認証をしている相手（エンティティ）に関するものかどうかを判別可能とするため、紐付け（Binding）を行う必要がある。
 具体的な懸念として、ユーザがクレームをRPに提示する際、RPは「そのクレームが相対しているユーザに対し発行されたクレームか」の検証を行う必要がある。この処理を行わない場合、窃取されたクレームを用いた ”なりすまし” が可能となる これを防ぐためにはクレーム発行要求の段階から、ユーザとクレームを ”Binding” する形で、クレーム発行を行う必要がある。
（次頁で詳述）“当人認証”と”属性”の分離に伴う Binding の実施

従来

対向のエンティティをDIDを用いて認証し、セキュアなチャネルを確立

SSI/DID

DID

同チャネルを介し、クレームを連携

Recognition

IdP
CP
Wallet（発行元）（保存）“Binding“ による窃取したクレームを用いた ”なりすまし” の防止

Selfness

クレーム発行時の段階で、何らかの方法でBindしていることを暗号的証明可能とする必要がある

CP

RPが、”対向のエンティティ” と”クレームの発行対象” が紐づいているか暗号的証明がなされているか検証

ユーザ

RP

何らかの方法でクレームを窃取

攻撃者 攻撃者が正規のエンティティになりすましてクレームを提示

155

3-2-1. SSI/DIDの実現に必要な構成要素の整理（参考）Bindingにおける考慮事項 – Bindingの方式
 ユーザとクレームを ”Binding” のためには、下記2点が必要となる。
1.

CPがクレームを発行する際、相対しているエンティティ（ユーザ）に対しクレームを発行する。

2.

RPがクレームを受領する際、相対しているエンティティ（ユーザ）に対し発行されたクレームであることを検証する。

 上記実現のためには、以下の処理が必要となる。
 クレーム発行要求時：ユーザに紐づく形でCPにクレームを発行して貰うため、後でRPが暗号的に証明されていることを検証可能な、何らかの形で自らのエンティティを示す情報を連携する（処理③） クレーム発行時： CPは、処理③で受け取った情報に紐づける形でクレームの発行を行う（処理④） クレーム検証時：ユーザのウォレットを介しクレームを受け取ったRPは、そのクレームが、相対しているユーザに紐づくものであることを、暗号的に証明されていることの検証を行う（⑦）。これは、クレームがCPにより発行されたものであることを電子署名を用いて検証を行う観点とは別に、考慮すべき観点である。
クレーム発行時におけるBindingの考慮箇所①DIDを持つユーザがサービスを要求④Binding、
クレーム発行CP③クレーム発行要求⑤クレーム発行

ウォレット②クレーム提示を要求

RP⑥クレーム提示⑦クレーム検証

1. CPは、ユーザに紐づける形でクレームを発行

2. RPは、受け取ったクレームがユーザに紐づいているかを検証
156

3-2-1. SSI/DIDの実現に必要な構成要素の整理（参考）Bindingにおける考慮事項 – Bindingの実装例
 例えば OpenID Foundationの策定する ”OpenID Connect Claims Provider“*1)では、それぞれ以下の処理を規定している。
1.

前頁の「処理③：クレーム発行要求」において、OpenID Connect Coreの仕様中に登場する「Request Object」*2)という仕様を用い、リクエストの電文に対しDID秘密鍵で署名を付与し、CPが署名を検証することで、このリクエスト電文が（DID秘密鍵を操作可能な）DID所有者から来たものか否かの判断を可能とする。

2.

前頁の「処理④：Bindingおよびクレーム発行、処理⑦：クレーム検証」において、紐付情報として、ウォレットのUUID（Universally Unique Identifier）やDIDの識別子、或いはDID公開鍵情報等をクレームに含めて発行することで、RPがクレーム受領時に、DID所有者に紐づいたものかどうかの検証を可能とする。

処理③：クレーム発行要求と、DID所有者との紐付け・確認
Credential Endpoint Request Parameters
POST /credential HTTP/1.1
Host: https://issuer.example.com
Authorization: Bearer <access-token>
Content-Type: application/json{"request": <signed-jwt-request-obj>}```

リクエスト内容に対し、Holderが自身の署名鍵（DID秘密鍵）で署名付与

処理④/⑦：クレームと、DID所有者との紐付け・確認
エンティティとの紐付情報
ウォレットに関与するUUID

DID識別子クレーム上での紐付情報記載例*1){（中略）"credentialSubject": {"id": "urn:uuid:dc000c79-xx（中略）",
（中略）
}
{（中略）
"credentialSubject": {"id": "did:example:1234",（中略）}

クレーム内の”credentialSubject” 値に対し、クレームの発行対象である
エンティティのメタデータを格納（例：UUID、DID識別子、DID公開鍵、等）*1) “OpenID Connect Credential Provider”, http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210528/2f163c71/attachment-0001.bin*2) “OpenID Connect Core 1.0 incorporating errata set 1”, https://openid.net/specs/openid-connect-core-1_0.html#RequestUriParameter157

3-2-1. SSI/DIDの実現に必要な構成要素の整理（参考）Bindingにおける考慮事項 – DID識別子を用いたBinding時の懸念（１／３）
 クレームに紐付情報を格納することでエンティティとクレーム間の紐付を証明可能となる一方、同情報を用いた不当な名寄せへの懸念についても、考慮・対策が必要となる。
 DID識別子は、下図の様に複数の使い方が想定される。このうち、RP毎に異なるDID識別子を使用するPairwise
では、クレームの種別によってはクレームに内包されるDID識別子の突合が可能となる懸念がある（次頁にて詳述）。
凡例）

DID識別子の使い方“Ephemeral” なDID識別子の利用ケース“Pairwise” なDID識別子の利用ケース

同一のDID識別子
を利用“Omni Directional” なDID識別子の利用ケース

RP 1

RP 1

RP 1

DID識別子: aaa

DID識別子：aaa
DID識別子：bbb
DID識別子：ccc

RP 2

DID識別子：ddd

DID識別子: bbb

RP 2

DID識別子
: aaa

RP 2

RP 3

ウォレット

RP 3

DID識別子
: ccc

…

RP 3
• RP毎に異なるDID識別子を利用• 同じRPでも毎回異なるDID識別子を利用（One-use）
DID識別子による名寄せ懸念無し

ウォレット• RP毎に異なるDID識別子を利用• 同じRPに対しては、毎回同じ
DID識別子を利用

RP毎にDID識別子を変えることでRP間による名寄せを回避したい• RP毎に同じDID識別子を利用• 同じRPに対しては、毎回同じ
DID識別子を利用
RP間で名寄せされる前提で利用
158

3-2-1. SSI/DIDの実現に必要な構成要素の整理（参考）Bindingにおける考慮事項 – DID識別子を用いたBinding時の懸念（２／３）
 Bindingに“Pairwise”なDID識別子を用いている場合、クレームにBindされるDID識別子はRPに応じ異なる。
 故に、各CPはクレーム生成の段階で、BindするDID識別子を意識し発行する必要がある。

“Pairwise” なDID識別子利用におけるクレーム連携のイメージ
凡例）

aaaを含めクレーム発行bbbを含めクレーム発行

CP 1

CP 2

aaa
向け

bbb
向け
bbb
向け

bbbを含めクレーム発行
cccを含めクレーム発行

CP 3

ccc
向け

DID識別子: aaa
aaa
向けDID識別子: bbb
bbb
向けDID識別子: ccc
ccc
向け

ウォレット

同一のDID識別子
を利用

RP 1
aaa向け
クレーム

RP 2

RP 3

bbb向け
クレーム

ccc向け
クレーム

CPは、指定されたDID識別子をクレームにBindingして、クレーム発行を行う必要がある。
159

3-2-1. SSI/DIDの実現に必要な構成要素の整理（参考）Bindingにおける考慮事項 – DID識別子を用いたBinding時の懸念（３／３）
 RP2 のサービス利用におけるオンボーディング時、ユーザはまずRP2 向けにDID識別子を発行し、クレーム提示の準備を始める。その際、既に発行済のクレームを使おうとしても、同クレームはRP1 向けに新たに作成したDID識別子と紐付いていない為、新たにクレームを取り直す必要が生じる（DID識別子に応じたDynamicなクレームの生成・取得が必須となり、3-1-2.項で述べた「長期のデジタルアイデンティティの保管・利用」の特性への制約となる懸念がある）。
 また、W3C Verifiable Credentials Data Model 1.0のVerifiable Presentation（VP）では、複数VCを格納可能と規定されている*1)。その際、VCにBindingされているDID識別子が異なる場合、受領したRP2において、それらの異なるDID識別子が、「同一エンティティに紐づいている」と露呈してしまう。
懸念②：クレーム集約時に、包含するクレームと紐づいている
DID識別子同士が、紐付いてしまう

懸念①：Staticなクレームの利用が困難
DID識別子: aaa
aaa
向けDID識別子: bbb
bbb
向け

ウォレット

DID識別子：aaaに紐づくクレームの為、RP2向け（DID識別子：
bbb向け）に使えない

DID識別子:bbbとして、
対向認証

Verifiable Presentation
aaa向け
VC
bbb向け
VC

bbb向け
クレーム

RP 2

• RP2はウォレットのDID識別子を ”bbb” と認識し対向認証を行った上でクレーム連携を実施する。
• DID識別子 ”aaa” 向けのクレームでは”bbb” にBindされていないため、
RP2に対し使えない。改めて ”bbb” 向けの形でクレームの再発行が必要。
（クレームの ”Stock & Forward” が出来ず、SSIに求められる特性「長期のデジタルアイデンティティの保管・利用」の実現が困難）*1) “Verifiable Credentials Data Model 1.0”, https://www.w3.org/TR/vc-data-model/

ウォレット

DID識別子 ”aaa” と ”bbb” が同一のエンティティに紐づくことが、VPを受け取ったRP2に露呈。

DID識別子:bbbとして、
対向認証

bbb向け
クレーム
（VP）

RP 2

• RPが結託し上記のBindingに用いる紐付情報を突合することで、
Pairwiseを用い異なるDID識別子をRPに応じ使い分けることで実現していた ”RP+RP’-U Unlinkability” が損なわれてしまう。

160

3-2-1. SSI/DIDの実現に必要な構成要素の整理（参考）Bindingにおける考慮事項：サマリー
 プライバシーを考慮すると、 Binding実現において以下２つの要件への考慮が必要である一方、識別性の高い情報をクレームに含めて発行するだけでは、Bindingとプライバシー確保の両立は困難である。

Bindingにおける要件

DID識別子を用いたBindingにおける懸念事項•
Dynamicなクレーム生成・取得ではなく、Staticなクレームの連携が可能（Stock & forward）

RPが結託し上記のBindingに用いる紐付情報を突合してもユーザの名寄せが出来ないこと（RP+RP’-U Unlinkability）••

Bindingの為に、DID識別子をクレームに含め発行を行う場合、RPとの間で用いるDID識別子が変わると、クレームの再発行が必要となる。
結果、過去にウォレットに格納していたクレームが意味をなさなくなる可能性があるため、3-1-2.項で述べた「長期のデジタルアイデンティティの保管・利用」実現が困難となる懸念がある（毎回動的にCPにクレーム発行を要求する必要が生じ得る）
複数クレームを含める形でのクレーム提示を想定している仕様もあるが（W3C Verifiable presentation*1)）、含まれるクレームにBindされた
DID識別子が異なる場合、それを受領したRPから見て、異なるDID
識別子が同じエンティティに紐づくことが露呈する懸念がある（異なるDID識別子を使い分けていても、名寄せの懸念がある）*1) “Verifiable Credentials Data Model 1.0”, https://www.w3.org/TR/vc-data-model/

161

3-2-2. 技術構成要素に対する各標準化団体の議論動向

技術構成要素の各標準化団体の検討仕様
 以下ユースケースを対象に、各標準化団体の規定している仕様がどこを対象としているかのマッピングを行う。
1. DIDの登録処理
ユーザがID Proofingを行い、DIDのActivation処理が完了し、DIDが有効状態に遷移するまでの処理を行う。
2. クレームの連携処理ホルダーがDIDを取得後にIdPとなり、CP / ホルダー間, 及びホルダー / RP間でのクレーム連携処理を行う。
処理

処理概要

1. DIDの登録処理（DIDが有効状態に遷移するまでの処理）
1-1. DIDおよびメタデータの生成・登録
2. クレームの連携処理

SSI/DIDの処理フローの概観
Holder

CP

2-1
2-3

1-1

2-1. CP上のユーザとDID
所有者のBinding• ユーザがCP内のCSPに対しAuthenticationを実行• CPは、ユーザから”ユーザのDIDを保持・管理していることを示す
情報” を受け取り、DIDを操作しているエンティティと、CP上のア
カウントを操作しているエンティティが同一であることを確認した
上で、Bindingを実施

2-2. クレーム発行

2-1で受け取った情報を利用し、クレーム発行要求してきたエンティ
ティに対するクレームである点を検証した上で、クレームを発行

2-3. ウォレットへのクレーム
格納2-2) で取得したクレームをウォレットに格納・保持

2-4. RPに対するユーザ認証

ウォレットとRP間で、1-1) のDIDおよびメタデータを用い対向認証

2-5. クレーム連携• 2-4)で対向の認証が完了後、2-3)で取得したクレームを連携。
• RPは、受領したクレームが、2-4) で認証したユーザのDIDとBindingされ発行されたクレームか（Verification）、
および連携されたクレームは有効か（Validation）を検証

RP

2-4

2-2

DIDおよびメタデータの生成・登録を実施

2-5

162

3-2-2. 技術構成要素に対する各標準化団体の議論動向

技術構成要素の各標準化団体の検討仕様
点線で囲われた仕様は、他団体で定義された仕様を参照する方針を意味する#

A) OpenID Foundation

1-1) DIDおよびメタデータの生成・登録A-1) OpenID Connect Core
（SIOP）

2-1) クレームプロバイダー上のユーザとDIDのBinding処理
2-2) クレーム発行及びウォレットへの送付

B) W3C/W3C-CCG
B-1) Decentralized Identifiers (DIDs)
v1.0

D) Sovrin (hyperledger、Linux Foundation)B-1) Decentralized Identifiers (DIDs)
v1.0

B-1) Decentralized Identifiers (DIDs)
v1.0

C-1) Self-Issued OpenID Connect
Provider DID Profile v0.1

OpenID Self Issued Identifiers ※OpenID Connect
Credential Provider ※C) DIF

B-2) Verifiable Credentials Data
Model 1.0

OpenID Connect
Credential Provider ※BBS+ Signatures 2020 ※A-1) OpenID Connect Core
（SIOP）

D-1) Aries RFC 0023:
DID Exchange Protocol 1.0
Hyperledger Ursa

B-1) Decentralized Identifiers (DIDs)
v1.0

B-1) Decentralized Identifiers (DIDs)
v1.0

B-1) Decentralized Identifiers (DIDs)
v1.0

vp-request-spec (W3C-CCG) ※C-1) Self-Issued OpenID Connect
Provider DID Profile v0.1

D-1) Aries RFC 0023:
DID Exchange Protocol 1.0
D-2 Aries RFC 0036: Issue Credential
Protocol 1.02-3) ウォレットへのクレーム格納A-3) OpenID Connect Claims
AggregationB-2) Verifiable Credentials Data
Model 1.0

B-2) Verifiable Credentials Data
Model 1.0

B-2) Verifiable Credentials Data
Model 1.0B-1) Decentralized Identifiers (DIDs)
v1.0

B-1) Decentralized Identifiers (DIDs)
v1.0

B-1) Decentralized Identifiers (DIDs)
v1.0

B-3) Credential Handler API(W3C-CCG)

2-4) RPに対するユーザ認証
A-1) OpenID Connect Core
（SIOP）

B-4) Confidential Storage 0.1

B-4) Confidential Storage 0.1

B-1) Decentralized Identifiers (DIDs)
v1.0

B-1) Decentralized Identifiers (DIDs)
v1.02-5) クレーム連携B-1) Decentralized Identifiers (DIDs)
v1.0

DID-SIOP ※A-1) OpenID Connect Core
（SIOP）

B-1) Decentralized Identifiers (DIDs)
v1.0

B-1) Decentralized Identifiers (DIDs)
v1.0

B-1) Decentralized Identifiers (DIDs)
v1.0

vp-request-spec (W3C-CCG) ※C-1) Self-Issued OpenID Connect
Provider DID Profile v0.1

D-3) Aries RFC 0037:
Present Proof Protocol 1.0

B-3) Credential Handler API(W3C-CCG)

C-2) Presentation Exchange※が付いた仕様は2021年4月1日時点で他仕様との統合や重複、策定途上など
今後記載内容の変動が想定されたため、本調査では詳細の記述を割愛する。

163

3-2-2. 技術構成要素に対する各標準化団体の議論動向

W3Cによる実現アプローチ
 W3CとしてはDIDの実現手段として、Decentralized identifiers（DIDs）と呼ばれる、個人や組織が信用するシステムを使用して自身の識別子を生成し、暗号証明 (電子署名、プライバシー保護生体認証プロトコルなど) を使用して識別子をRecognitionできるように設計された新しいタイプのグローバルに一意な識別子を用いた、クレームの連携のためのメカニズムを策定している。なお、DIDsについての詳細は後述する。
 Verifiable Credentials Data Model 1.0（VC Data Model）では、Verifiable Credential (VC) 、Verifiable
Presentation (VP)と呼ばれるクレームのデータモデルを定義しており、ユーザのプロパティを表現する為のデータに関する
定義や、VC / VPのライフサイクルモデルが規定されている。
Decentralized Identifiers (DIDs) v1.0

Verifiable Credentials Data Model 1.0

1643-2-2. 技術構成要素に対する各標準化団体の議論動向

OpenID Foundationによる実現アプローチ
 OpenID Foundationは既存仕様の中にある「Self-Issued OpenID Provider」を使い、ユーザがOpenID Providerとして機能しRecognition（当人認証）を行った上で、ユーザをハブとするクレーム連携の仕様の策定を進めている。
 属性のデータモデルについては、W3CのDIDsを包含する形で拡張を検討しており、DIDとのBinding※に関する部分についても、DIFとのリエゾン締結し共に議論を進めている。
OpenID Connect Core 1.0 – Self Issued OpenID Provider

OpenID Connect Credential Provider
①
②
③
④
⑤
⑥

Credential Holder(CH)がCredential Issuer(CI)に”Credential” を要求
CIがエンドユーザを認証し、Credential Holderを認可
CIがCHに“Credential”を返信
Credential Verifier(CV)がCHに”Credential”を要求
CHがエンドユーザを認証し、Credential Verifierを認可
CHがCVに”Credential”を返信②

End-User
ウォレット①

Credential
Issuer③(OpenID Provider)
Credential

Credential
Holder(Relying
Party)⑤

Credential
Holder
(Open
Provider)④⑥

Credential
Verifier(Relying Party)

Credential※生成されるCredentialとDID間のBindingは、①要求時にOpenID Connect Core 1.0で規定された”Signed Request Object” での実現を想定している

165

3-2-2. 技術構成要素に対する各標準化団体の議論動向

DIFによる実現アプローチ
 DIFは当初、ホルダーの概念と、先述のDIDsやOpenID Connect と組み合わせる為の仕様を検討していたが、OpenID Foundationが広範に活用されている点や高い拡張性持っている点などから、2020年11月にOpenID Foundationとリエゾン協定を結び、上記実現のためにOpenID Connectを用い仕様拡張する方針とした。
 他にも複数Working Groupが仕様策定を行っており、一例として、トランスポートプロトコルやクレームのデータ
フォーマットに依存しない、ホルダーからRPへのクレーム要求/提示が可能な仕様策定も行っている。
OpenID Foundationとのリエゾン背景（OIDC選択理由）• Well-known and mature

クレーム要求/提示に関する仕様策定（Presentation Exchange）
 HolderおよびRP間におけるProofの要求/提示を規定• Widely used, and has a big community 以下の形式に対応することでOpenID Connect,
DID Comm、Credential Handler APIを介し連携可能• Enterprises are familiar with OIDC
• Simple and light-weight JSON Web Tokens (JWTs)• Flexible and extensible through profiles• Additional (optional) support for credentials/ claims exchange Verifiable Credentials (VCs) JWT-VCs• Based on work incubated at RWOT, and IIW
IssuerHolderUser Agent
ID Wallet

Verifier

SIOP

RP

OpenID Connect1663-2-2. 技術構成要素に対する各標準化団体の議論動向

Sovrinによる実現アプローチ
 Sovrin Foundationは、SSIモデルの実現に必要な「Sovrin Governance Framework」を規定し、法的協定や用いる技術仕様・標準・ポリシー、同フレームワークのポリシー適合性評価のための基準とプロセス等を定義している。
また、同フレームワーク内では、構成スタックとして「Sovrin Stack」と呼ばれる4層のLayerを定義している。
 規範的なの構成要素として、W3CのDIDs、VC Data Model、DID Method 1.0 Specificationが言及されている。
また、DID/DID Document管理の為の分散台帳技術としては、Evernym社がSovrin Networkの立ち上げとコード提供を行った後、オープンソースプロジェクト「Hyperledger Indy」として展開されている。
 Peer to Peer Connection / Wallet / Messaging / KeyManagementプロトコルを規定したAriesプロジェクト、ZKPの様な暗号機能のための暗号ライブラリ提供を目的としたUSRAプロジェクトといった拡張仕様に対しても、Contributorとして貢献。
Sovrin FoundationによるSovrin Stack図出所) Sovrin Foundation
https://sovrin.org/wp-content/uploads/Sovrin-Governance-Framework-V2-Master-Document-V2.pdf
https://sovrin.org/2020-how-ssi-went-mainstream/

Hyperledger Indy及び関連プロジェクトの設立経緯

出所) Evernym Hyperledger Aries: The Next Major Step Towards Interoperable SSI
https://www.evernym.com/blog/hyperledger-aries/167

3-2-3. 各標準化団体の検討仕様

各仕様の概要 本項では、以下の仕様の概要についてまとめる。
なお、A-2) OpenID Connect Claims Aggregationについては、セキュリティ考慮事項の項がTBDとなっており、本調査では課題については記述を割愛する。
#

団体名

仕様名

A-1)

OIDF

OpenID Connect Core

A-2)

OIDF

OpenID Connect Claims Aggregation

B-1)

W3C

Decentralized Identifiers (DIDs) v1.0

B-2)

W3C

Verifiable Credentials Data Model 1.0

B-3)

W3C

Credential Handler API

B-4)

W3C, DIF

Confidential Storage 0.1

C-1)

DIF

Self-Issued DID Profile for OpenID v1.0

C-2)

DIF

Presentation Exchange

D-1)

Hyperledger

Aries RFC 0023: DID Exchange Protocol 1.0

D-2)

Hyperledger

Aries RFC 0036: Issue Credential Protocol 1.0

D-3)

Hyperledger

Aries RFC 0037:Present Proof Protocol

168

3-2-3. 各標準化団体の検討仕様

A-1) OpenID Connect Core
 OpenID Connect Core（以下、「OIDC」と記述））はOpenID Foundationにより2014年に策定された仕様であり、OAuth 2.0を土台としてアイデンティティアサーションを可能としたものになっている。
 同仕様の中で、ユーザ自身がIdPとして振る舞う「Self-Issued OpenID Provider」（以下「SIOP」と記述）という方式が言及されている。
 OIDC Core Ch.7 Self-Issued OpenID Provider• 「SIOP」は、自身がself-hostedなOpenID Providerとして振る舞う。
• SIOPを用いることで、自身がOPとして振る舞い、クレームを連携するためのRecognitionに必要なクレデンシャル管理が可能となる。
• 同方式を用いることで、既存のIdPへの依存を下げることに繋がり得るため、SSIの思想の実現手段の一つとして、昨今注目されている。

出所）OpenID Connect Core 1.0 incorporating errata set 1- 7, Self-Issued OpenID Provider
https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued

OpenID Connect Core 1.0 - SIOP

169

3-2-3. 各標準化団体の検討仕様

A-2) OpenID Connect Claims Aggregation
 本仕様は、クレームプロバイダーからOpenID Connect クライアントへアグリゲート（集約）されたクレームを提供するための処理方法を規定している。
 OpenID Providerは、Claims Provider（以下、「CP」）に対してクライアントとして登録し、必要なユーザ情報に対して
OIDC認証リクエストを行うことにより、 Relying Party（以下、「RP」）の役割を果たす。
 同仕様では、CPからOpenID Connect Providerにクレームが提供されるまでの処理が仕様策定範囲であり、OpenID Connect ProviderからRelying Partyへのクレーム提供は仕様策定範囲外となる。

 OpenID Providerはエンドユーザのすべてのクレームを一元化して収集できるため、 CPとRPが直接クレームをやり取りする
必要がなく、ユーザはOPを介して取得したクレーム情報を他のRPに共有できる。
OpenID Connect Claims Aggregationの概観像
仕様スコープClaimsProviderClaimsProviderClaimsProvider

クレームを提供

OpenID
Connect
Provider（ホルダー）（CPから見るとRP、
RPから見るとSIOP）

出所) OpenID Connect Claims Aggregation https://bitbucket.org/openid/connect/src/master/openidconnect-claims-aggregation/openid-connect-claims-aggregation-1_0.md

クレームを提供

OpenID
ConnectclientsRP170

3-2-3. 各標準化団体の検討仕様

B-1) Decentralized Identifiers (DIDs) v1.0
 DIDs v1.0はDIDのシンタックス、データモデル、プロパティ、シリアル化された表現、DIDの操作およびDIDが表すリソースを解決するプロセスを規定している（下表参照）。
 個人や組織が信用するシステムを使用して自身の識別子を生成し暗号証明 (電子署名、プライバシー保護生体認
証プロトコルなど) を使用して認証可能となるグローバルに一意な識別子を、分散型アイデンティファイア(DID)として定義している。
Decentralized Identifiers (DIDs) v1.0

規程対象

概要

DIDs とDID
URLs

DIDはスキーム(did) 、 メソッド識別子(method identifier) 、
DID methodから生成される識別子(method-specific identifier)の3パートから構成されるテキスト形式の文字列。DIDは永続的で不変であり、非活性化後も再利用されないこと要求される。
DIDによって識別されるエンティティ。DID Controllerである場合もある。
人、グループ、組織、物理的、論理的なものでも可能。
DID関連のメタデータ、公開鍵による検証方法、DID subjectとのやり取りに関連したサービスを示す抽象的なデータモデル。

DID Subjects
DID
Documents
DID Methods
DID
Controllers
Verifiable
Data
Registries
DID resolverとDID
resolution
DID URL
dereferencersと DID URL
dereferencing
出所) Decentralized Identifiers (DIDs) v1.0

Verifiable Data Registriesを使って、DIDとそれに関連した
DID Documentsを生成、解決、後進、非活性化する方法を指定する。
DID ControllerはDID Methodで定義されるように、DID Documentを変更可能なエンティティで、人、組織、自律型ソフトウェア。
分散台帳、分散ファイルシステム、データベース、P2Pネットワーク、信頼できるストレージのことで、DIDの記録やDIDドキュメントの生成に必要なデータを返すシステム。
DID resolverはDIDを入力として受け取り、DID Documentsを出力するソフトウェア、ハードウェアコンポーネント。
当該処理をDID resolutionと呼ぶ。
DID URL間接参照は、DID URL(および関連メタデータ)を入力として受け取り、リソース(および関連メタデータ)を出力として生成するソフト
ウェア、ハードウェアコンポーネント。
当該処理をDID URL 間接参照(リファレンス先参照)と呼ぶ。

171

3-2-3. 各標準化団体の検討仕様

B-1) Decentralized Identifiers (DIDs) v1.0 – 課題と新たな取り組み セキュリティ考慮事項として、下記点が挙げられている。
考慮事項

概要(1/2)

DID resolverの選択

DID Method Registryは、DID Method名とそれに対応するDID Method仕様のリストである。実装者は、特定のDID
Method名と対応するDID Method仕様を義務付ける中央機関が存在しないことを考慮する必要がある。DID Resolver
がDID Methodを正しく実装しているか疑問がある場合、DID Specification Registryから十分な情報を得たうえでどの
DID Resolverの実装を使用するか決定することができる。
自己署名されたDID Document上で検証された署名はDIDのコントロールを証明するものではなく、DID Documentがタイムスタンプを付与されてから改ざんされていないこと、タイムスタンプが生成された時点でDID controllerが署名に使われた秘密鍵をコントロールしていたことを証明するだけである。
DID Documentの公開鍵に対応する秘密鍵のコントロールを証明する方法には、静的な方法と動的な方法がある。
静的な方法は、DID Documentを秘密鍵で署名する方法であり、DID Documentが登録された時点の秘密鍵のコント
ロールを証明する。もしDID Documentが署名されていない場合には、DID Documentに記述された公開鍵のコントロール
は動的に証明する必要がある。
DIDおよびDID Documentは、本質的にPII（個人を特定できる情報）を持たない。DIDを実世界、例えば、DIDと同じ
subjectを持つクレデンシャルを用いて人や会社などにバインディングするプロセスは、この仕様の範囲外である。
DID Documentが、DID subjectの認証または認可を目的としたサービスエンドポイントを公開している場合、そのサービスエ
ンドポイントでサポートされている認証プロトコルの要件を遵守することは、サービスエンドポイントの提供者、対象者、または要求する当事者の責任である。
DIDおよびDID Document更新の否認を禁止することは、対象が不正な更新を監視していること、DID methodのアクセス制御機構に従って悪意ある更新をもとに戻せることを想定してサポートされる。
DID Documentへの不正な変更に対する一つの緩和策は、変更時にDID subjectを監視し、積極的に通知することである。これは、メールアドレスにパスワードリセット通知を送信することによって、従来のユーザ名／パスワードのアカウント乗っ取りを防止することをサポートすることに類似している。DIDの場合、このような通知を生成する仲介レジストラやアカウントプロバ
イダーは存在しないが、DIDが登録されているVerifiable Data Registryが直接変更通知をサポートしている場合、サブスク
リプションサービスをDID controllerに提供することができる。DID controllerがサードパーティの監視サービス頼る場合、別の攻撃のベクトルを組み込むことになる。
分散型アイデンティティアーキテクチャでは、鍵または署名の有効期限切れポリシーを強制する中央機関は存在しない。DID
resolverと当事者は、鍵が使用された時点で有効期限が切れていないことを検証する必要がある。
172

DID および DID Documentの証
明
公開鍵のコントロールの証明

認証とVerifiable Claims
認証サービスのエンドポイント
否認の禁止
DID Documentの変更通知

鍵および署名の有効期限

3-2-3. 各標準化団体の検討仕様

B-1) Decentralized Identifiers (DIDs) v1.0 – 課題と新たな取り組み セキュリティ考慮事項として、下記点が挙げられている。
考慮事項

概要(2/2)鍵の失効と復旧

暗号鍵失効の発生を定義するのはDID methodに任されている。さらに、DID methodの仕様は、鍵の回復を可能にするための信頼されたパーティの定足数のサポートを可能にすることも期待されている。DID method仕様におけるアクセス制御
および鍵復旧は、第二の復旧手順を保持することによって鍵の危殆化から保護するタイムロック機能を含めることもできる。

Human-Friendlyな識別子の役
割

Human-Friendlyな識別子をDIDにマッピングする(そして、検証され、信頼される方法でそれを行う)問題は、この仕様の範囲外である。

不変性

不変性がサイバーセキュリティ上の利点をもたらすという考え方は、特にキャッシングに関連する。グローバルな真のソースに結び付いたDID methodでは、DID Documentの最新バージョンを常に検索可能である。しかしキャッシュレイヤーが存在する
場合、オブジェクトの属性が実際には異なっているのに実際に存在すると信じてしまい悪用される可能性がある。

DID Document内の暗号化デー
タ

DID Documentのすべてまたは一部を暗号化することは、長期的にデータを保護する適切な手段ではない。同様に、暗号化データをDID Documentに配置することは、個人を特定できる情報を含む適切な手段ではない。この点から、暗号化データがDID Documentに含まれる場合、実装者は、DIDとの関連付けを望まないエンティティの公開鍵で暗号化しないことが大切である。

173

3-2-3. 各標準化団体の検討仕様

B-1) Decentralized Identifiers (DIDs) v1.0 – 課題と新たな取り組み プライバシー考慮事項として、下記点が挙げられている。
考慮事項

概要

個人を特定できる情報（PII）を非公開にする

DIDメソッド仕様が、すべてのDIDとDID Documentが公開されているpublic verifiable data registryのために書かれている場合、DID Documentには個人データが含まれないことが重要である。すべての個人データは、DID subjectの管理下にあるサービスエンドポイントの後ろに保管されるべきである。個人データは、ＤＩＤ Document内の公開鍵記述によって識別され、かつ安全に保護された通信チャネルを使用して、プライベートなP2Pで交換できる。また、個人データが不変の分散型台帳に書き込まれないため、DID subjectや依頼者はGDPRの忘れられる権利を実行できる。
DIDは相関関係に使用されるかもしれないため、DID controllerは、対となるユニークなDIDを使用することで、このプライバ
シーリスクを軽減できる。各DIDは別名として機能する。

DIDの相関リスクと別名DIDDID Documentの相関リスク

subjectへのタイプの割り当て

プライバシー群

別名DIDの相関防止保護は、対応するDID Document内のデータを相関させることができれば容易に打ち破られる。例えば、複数のDID Documentで同じ公開鍵記述または独自サービスエンドポイントを使用することは、同一DIDの使用と同程度の相関情報が提供される。エンドポイントプライバシーのためのより良い戦略は、多くの異なるsubjectによって数千、数百万のＤＩＤでエンドポイントを共有することかもしれない。
DID subjectのタイプおよび性質を、明示的、あるいは推論によって示すために使用できるプロパティをDID Documentに追加することは危険である。そのようなプロパティは、個人を特定できる情報や相関可能なデータがDID Document内に存在するだけでなく、特定の操作や機能性に含まれたり除外されたりするような方法で特定のDIDをグループ化するために使用できる。これらのリスクを最小化するために、DID Document内のすべてのプロパティは、DIDの使用に関連する暗号材料、
エンドポイント、または検証方法を表現するためのものであるべきである。
DID subjectが群の中で他と区別がつかない場合、プライバシーを利用できる。デジタルフィンガープリントを減らすためには、要求側の実装で共通設定を共有し、有線プロトコルでネゴシエートされたオプションを最小限に抑え、暗号化されたトランス
ポートレイヤーを使用し、メッセージを標準的な長さにパディングする。

174

3-2-3. 各標準化団体の検討仕様

B-2) Verifiable Credentials Data Model 1.0
 Verifiable Credentials Data Modelは、暗号的に安全で、プライバシーを尊重し、machine-readableな方法で、Web上でクレデンシャルを表現するためのメカニズムを提供する。 学歴資格、医療データ、銀行口座等の第三者が検証したmachine-readableな各種個人情報をWeb上で表現することを可能にする。
Actor
HolderVerifiable Credentials Data Model 1.0

IssuerSubject

Verifier

Verifiabledata registry

出所）Verifiable Credentials Data Model 1.0, https://www.w3.org/TR/vc-data-model/

概要
1 つ以上のverifiable credentialを保有し、それらからverifiable presentationを生成するエンティティが担う役割
例：学生、従業員、顧客
1 つ以上のsubjectに関するクレームから作成したverifiable
credentialをholderに送信するエンティティが担う役割
例：企業、非営利団体、業界団体、政府、個人
生成されるクレームのエンティティ
例：人、動物、物
多くの場合、verifiable credentialのholderがsubjectであるが、親（holder）が子供（subject）のverifiable
credentialを所持することや飼い主（holder）がペット(subject)のverifiable credentialを所持することもある
1 つ以上のverifiable credentialを受信するエンティティが担う役割、オプションとしてverifiable presentation内で受信することもある
例：雇用者、セキュリティ担当者、ウェブサイト
識別子、鍵、verifiable credentialスキーマ、失効登録、
issuer公開鍵など、verifiable credentialの使用に必要な
その他関連データの作成と検証を仲介するシステムが担う役割
例：信頼されたデータベース、分散型データベース、政府 ID
データベース、分散型台帳
175

3-2-3. 各標準化団体の検討仕様

B-2) Verifiable Credentials Data Model 1.0 – 課題と新たな取り組み セキュリティ考慮事項として、下記点が挙げられている。
考慮事項

概要

Cryptography Suites
and Libraries

暗号スイートとライブラリには使用期限があり、最終的には新たな攻撃や技術の進歩にさらされることになる。本番システムは、このことを考慮に入れ、暗号スイートやライブラリの簡単かつ積極的にアップグレード、既存クレデンシャルの無効化や更新の仕組みを確認する必要がある。クレデンシャルを処理するシステムの長期的な実行可能性を確保するためには、定期的な監視が重要である。
Verifiable credentialには外部データへのURLが含まれることが多い。Verifiable credential外に存在するリンク先のコンテンツは、Verifiable Credentialの証明の保護から外れるため、改竄から保護されていないことが多い。コンテンツへのリンクの完全性を保護したい場合は、コンテンツの完全性を強制するURLスキームを使用することが推奨される。
この仕様では、いかなる種類の署名または証明も含まないクレデンシャルを生成することができる。これらのタイプのクレデンシャルは、
中間ストレージ、または自己主張された情報に有用であることが多く、これは Web ページのフォームに記入することに似ている。実装者は、これらのタイプのクレデンシャルが、作成者不明、もしくは信頼できないため、検証ができないことに注意が必要である。
Verifierは、自身がVerifiable Presentationの意図された受信者であり、 中間者攻撃のターゲットではないことを確認する必要がある。トークンバインディング(Token Binding [RFC8471])のようなアプローチは、Verifiable Presentationのリクエストと応答を結びつけることでプロトコルを安全にできる。
Issuerがクレデンシャル内の情報を細分化する、または選択的な開示を可能にする署名スキームを使用することはベストプラクティスである。細分化の場合、Issuerによって安全に行われなければ、HolderがIssuerが意図していない方法で異なるクレデンシャルを束ねる可能性がある。
Verifiable Credentialが動的な情報に対して発行される場合、実装者は有効期限が適切に設定されていることを確認する必要がある。Verifiable Credentialの有効期間は、Verifiable Credentialに含まれる情報に対するユースケースおよび予想される有効期間に応じた適切な期限を設定することが重要である。
Verifiable Credentialがデバイスに保存されており、そのデバイスが紛失または盗難にあった場合、攻撃者が被害者のVerifiable
Credentialを使用してシステムにアクセスできる可能性がある。この種の攻撃を緩和する方法としては、以下のようなものがある。
・デバイスでパスワード、PIN、パターン、または生体認証による画面ロック解除保護を有効にする
・Credential Repositoryでパスワード、生体または多要素認証を有効にする
・暗号鍵にアクセスするときにパスワード、生体または多要素認証を有効にする
・別のハードウェアベースの署名デバイスを使用する
・上記のすべてまたは任意の組み合わせをとる

Content Integrity
Protection
Unsigned Claims

Token Binding
Bundling Dependent
ClaimsHighly Dynamic
Information
Device Theft andImpersonation176

3-2-3. 各標準化団体の検討仕様

B-2) Verifiable Credentials Data Model 1.0 – 課題と新たな取り組み プライバシー考慮事項として、下記点が挙げられている。
考慮事項

概要(1/3)

Personally Identifiable
Information

Verifiable Credentialに含まれる一部のデータはVerifierと共有されるときプライバシー侵害の影響を受ける可能性がある。政府発行の識別子、配送先住所、およびフルネームなどの個人を特定できるデータは、エンティティの決定、追跡、および関連付けに使用できる。生年月日と郵便番号などの個人を特定できないと思われる情報であっても、組み合わせによって強力な相関性を持つ。このような特性を持つデータを共有する際には、Holderに警告することが強く推奨される。また、Issuerは、可能な限り、プライバシー保護するVerifiable Credentialを提供することを強く推奨する。

Identifier-Based
Correlation
Signature-Based
Correlation

Verifiable CredentialsのSubject識別子は、長期間、複数Webドメインにまたがって使用されると相関関係のリスクが増加する。

Long-Lived IdentifierBased Correlation

Verifiable Credentialには、個人を関連付けるために永続的に使用可能な能識別子が含まれることがある。Holderにソフトウェアを提供する組織はこれらの情報が共有されたときにHolderに警告することが求められる。

Bundling Dependent
Claimsissuerがクレデンシャル内の情報を細分化する、または選択的な開示を可能にする署名スキームを使用することは、 ベストプラクティ
スであると考えられる。細分化の場合、issuerによって安全に行われなければ、holderはissuerが意図していない方法で異なるクレ
デンシャルを束ねることがある。
インターネットおよびWeb上の個人を追跡、関連づける外部メカニズムが存在する。Internet protocol (IP) address tracking,web browser fingerprintingがある。Verifiable Credentialを使用してもこれらの追跡技術は防止できない。Verifiable
Credentialと一緒に使用することで新たな相関関係が生まれる可能性がある。プライバシーを尊重するシステムでは、Verifiable
Credentialが使用されている場合には、これらの追跡技術を使用しないことが推奨される。

Device Fingerprinting

Favor Abstract Claims

Verifiable Credentialの内容は、proof フィールドを使用して保護される。このフィールドのプロパティは、複数のセッションまたはドメイ
ンにまたがって同じ値が使用され、値が変更されない場合、相関関係のリスクが大きくなるため、署名とメタデータを毎回再生成することが推奨される。

Verifiable Credentialの受信者は、取引に必要以上の PIIを明らかにすることがないよう、Issuerは必要最小限なセットに制限することを検討すべきである。クレデンシャルに PII を入れないように、subjectに関する具体的な情報を提供せずVerifierのニーズを満たす抽象プロパティを使用する。
177

3-2-3. 各標準化団体の検討仕様

B-2) Verifiable Credentials Data Model 1.0 – 課題と新たな取り組み プライバシー考慮事項として、下記点が挙げられている。
考慮事項

概要(2/3)

The Principle of Data
Minimization

プライバシー侵害を防止するためのベストプラクティスとして、要求された情報、および受信した情報を必要最小限に制限することが認められている。Verifiable Credentialでは、Issuerにとってのデータ最小化はVerifierが使用する必要最低限のデータに限定することである。また、Verifierにとってのデータ最小化はサービスアクセス時に要求される情報の範囲を制限することである。Verifierは特定の取引が発生に必要な情報のみを要求することが求められる。
Bearer Credentials
Bearer Credentialは、コンサートチケットのようなプライバシーを強化する情報であり、Bearer CredentialのHolderには、Holderの機密情報を漏らすことなく特定のリソー スを利用する権利が与えられる。Bearer Credentialは、その共有が大きな経済損失やレ
ピュテーション低下を招かない低リスクケースで使用されることが多い。複数のサイトで同じBearer Credentialを繰り返し使用すると、これらのサイトが結託してHolderを不正に追跡したり、相関関係を持たせる可能性がある。Bearer CredentialのIssuerは、Bearer
Credentialが単一使用、個人特定情報を含まないこと、過度に相関性がないことを確実にしなければならない。
Validity Checks
Verifiable Credentialの処理時に、Verifierは以下のような有効性チェックが期待される・Holderの専門職免許のステータス
・ライセンスの更新日又は失効日・個人の下位資格
・HolderとHolderが交流しようとしている事業体間の関係
・Holderに関連する地理的位置情報
これらのチェックプロセスにより、Holderのプライバシー侵害につながる情報漏洩が発生する可能性がある。例えば、失効リストをチェックするような単純な操作では、特定の事業者がHolderと対話しようとしている可能性が高いことをIssuerに通知することができます。これにより、Issuerが知識なしで結託して個人を関連付けできる可能性がある。Issuerは、クレデンシャルごとに固有の失効リス
トのような、プライバシー侵害につながる可能性のあるメカニズムを検証プロセス中に使用しないことが求められる。
Storage Providers and HolderがIssuerから受け取るVerifiable Credentialはどこかに保存する必要がある(例えば、Credential Repository)。Verifiable
Data Mining
Credential内の情報は本質的に機密性が高いことから、Holderはデータマイニングの対象となることがある。Verifiable Credentialの無料保存を謳うサービスは、実際には個人データをマイニングして、人や組織別プロファイルを構築したい組織に販売している可能性がある。データマイニングおよびプロファイリングのための効果的な緩和策には、以下のものがある。
・顧客情報を第三者に販売しないサービスプロバイダー
・サービスプロバイダーがクレデンシャルの内容を表示できないようにverifiable credentialを暗号化するソフトウェア
・顧客管理デバイスにverifiable credentialをローカル保存し想定外に顧客情報をアップロード、分析しないソフトウェア
178

3-2-3. 各標準化団体の検討仕様

B-2) Verifiable Credentials Data Model 1.0 – 課題と新たな取り組み プライバシー考慮事項として、下記点が挙げられている。
考慮事項

概要(3/3)Aggregation ofCredentials

Verifiable Credentialの集約はプライバシーリスクであり、エコシステムすべての参加者はデータ集約のリスクを認識する必要がある。
例えば、2 つのBearer Credentials（1 つはメールアドレス、もう 1 つはHolderが 21 歳以上であることを示す）が複数のセッションに渡って提供された場合、Verifierは、その個人の年齢関連情報だけでなく、一意の識別子を持つようになる。これによりHolderのプロファイリングが容易になり、時間の経過とともに多くの情報が漏洩する。また、クレデンシャルの集約は、複数のサイト間で互いに結託して行われた場合、プライバシー侵害につながる可能性がある。解決策は、技術的なものではなく、ポリシー的な傾向がある。
Holderが自分の情報が集約されることを望まない場合、Holderは自身が送信するVerifiable Presentationの中でその旨を表現しなければならない。
プライバシー保証に努力しても、実際にVerifiable Credentialを使用すると、匿名化が解除されてプライバシーが失われる可能性がある。同じVerifiable Credentialが、同じVerifierに複数回提示されると、VerifierはHolderが同一だと推測できる。同じ
Verifiable Credentialが異なるVerifierに提示されると、それらのVerifierが結託するか、第三者が両Verifierの取引記録にアクセスできる。また、第三者は、Verifiable Credentialを提示した個人が両サービスで同一人物であると推測できる。つまり、アカウントは同一人物によって管理されていることがわかる。
HolderがVerifierと情報共有を選択した場合、Verifierが悪意を持って、Holderに危害を加えるような情報を要求する場合がある。
例えば、VerifierがHolderや銀行からだまし取るために銀行口座番号を要求し、他の情報とともに使用される可能性がある。
Issuerは、Holderが誤ったVerifierにクレデンシャルを送信した場合においても被害が拡大しないよう、可能な限り多くの情報を直接ではなく トークン化して含めるべきである。
利用パターンは特定の種類の動作に相関させることができる。この相関関係の一部は、HolderがIssuerの知識がないVerifiable
Credentialを使用すると緩和される。しかし、Issuerは、Verifiable Credentialを短期間で自動更新することで、この保護を無効にできる。Holderにソフトウェアを提供する組織は、Holderが有効期限の短いクレデンシャルを繰り返し使用すると、行動の相関が生じる可能性がある場合には、Holderに警告する必要がある。Issuerは、使用パターンを相関させるような方法でクレデンシャルを発行することを避けるべきである。
プライバシーを尊重するシステムでは、Verifierとのやりとりに必要な情報のみをHolderが開示することを要求する。Verifierは、開示要求が満たされたことを記録し、開示された機密情報は破棄する。しかし、規制上の負担や長期保存識別子がそれを妨げている
場合がある。Verifiable Credentialエコシステムの設計では、可能な限り1回のみ利用されるVerifiable Credentialを優先すること
で、プライバシーを尊重する努力が必要である。
理想的なプライベートブラウジングでは、PII が明らかにされることはない。ブラウザベンダーごとにプライベートブラウジングの扱いが異なり、ブラウザによってはこの機能が全くない場合もある。多くのクレデンシャルには PII が含まれているため、プライベートブラウジングモードでクレデンシャルやプレゼンテーションを使用したい場合、この情報が明らかになる可能性があることを警告する必要がある。
179

Usage Patterns

Sharing Information
with the Wrong Party
Frequency of Claim
Issuance

Prefer Single-Use
Credentials
Private Browsing

3-2-3. 各標準化団体の検討仕様

B-3) Credential Handler API
 Credential Handler API（CHAPI）はブラウザ上でクレデンシャルの要求および保管に関するイベントをハンドリング
するAPIであり、Payment Handler APIとCredential Management APIの2つをベースとして構成されている。
 本仕様では、下記の点を目的として規定されている。
 ユーザのクレデンシャルの利用をより簡単かつ安全にする。
 ユーザがウォレットプロバイダーを選択できるようにする。
 Webアプリ開発者に標準的なウォレットAPIを提供する。

 その他にもOAuth 2.0/OIDCにおけるNASCAR problemの解決なども規定されている。
Credential Handler API策定のタイムライン
 W3C CCG（Credentials Community Group）にて仕様が公開。
 2014年 – Identity Credentials protocolが提案
 2017年 - Web Payments HandlerがDave Longleyによって
提案

NASCAR problem
 NASCAR problemはサードパーティのアイコンやブランドがウェブサイト上に集まり視覚的なノイズとなる問題である。
具体例としては、Payment UIやサインインUIなどが挙げられている。

 2017年 – CHAPIがDave Longleyによって提案
 2017年 – CHAPIがW3C CCGで仕様の策定が進められる出所) INDIEWEBCAMP - NASCAR problem
https://indieweb.org/NASCAR_problem

1803-2-3. 各標準化団体の検討仕様

B-3) Credential Handler API
 処理内容 CredentialRequestEventやCredentialStoreEventといったCredentialの要求や保管に関するイベントが定義。
 オリジンベースでCredentialの要求および保管のイベントを処理。

 ロール
 Credential Repository (Wallet): ユーザのCredentialの保管と要求を処理。
 Credential Issuer (Issuer): ユーザにCredentialを発行。
 Credential Verifier (Verifier): ユーザにCredentialを要求。
 Mediator (User Agent): Credentialの保管と要求を仲介。
Credential Handler APIの概観像

Issuer

Issue
Credential

Holder(User Agent)

Send
Presentation

Request / Store
Credential

Verifier
Credential Handler APIのカバー範囲

Credential
Repository(Wallet)出所) credential-handler-api
https://github.com/w3c-ccg/credential-handler-api

1813-2-3. 各標準化団体の検討仕様

B-3) Credential Handler API – 課題と新たな取り組み セキュリティおよびプライバシー考慮事項として、下記点が挙げられている。
考慮事項

概要

ユーザ環境に関する情報

Credential Handler APIはユーザの登録済みCredential Handlerに関する情報を共有しない。オリジンからの情報は、ユーザの同意がある場合のみRelying Partyと共有されるべきである

クレデンシャル送信前のユーザの同意

この仕様の目標の一つは、クレデンシャルを送信するために必要なユーザの操作を最小限にすることである。一方で、User
Agentは、ユーザの同意なしにWebサイトを呼び出してクレデンシャルを要求し、それをサイレントに受け取ることを可能にする
構成を許可してはならない。
Credential HandlerはService Workerコードで定義されており、Service WorkerのSecurity Consideration についての考慮が必要となる。
また、WebCredentialセキュリティはこの仕様の範囲外であり、それらの管理をサポートするCredential Handlerによって対処される必要がある。
User Agentは、セキュリティの問題を引き起こすCredential Handlerを利用不可としてよい。セキュリティ上の理由でCredential Handlerが利用できない場合、User AgentはCredential Handlerの開発者に（コンソールやメッセージを通じて）根拠を提供するべきであり、混乱を避けるためにユーザに通知することもできる。

安全な通信

Credential Repositoryの信頼性
データ検証

Relying PartyはCredential Management APIを通じて受信したWebCredentialデータが期待通りであることを検証する必要がある。

プライベートブラウジングモード

Credential Management APIが”private browsing mode”で起動された場合、User Agentは、プライベートコンテキスト
でCredential Handlerを起動する必要がある。これにより、一般的に、サイトが以前に保存された情報にアクセスするのを防ぐことができる。また、ユーザがオリジンにログインするか、詳細を再入力する必要がある

182

3-2-3. 各標準化団体の検討仕様

B-4) Confidential Storage 0.1
 Confidential Storageでは、暗号化されたデータをストレージプロバイダーで保管、インデックス作成、検索するためのプライバシーを尊重したメカニズムを提供する。これは、個人や組織が、ストレージプロバイダーがデータを閲覧、分析、集計、再販できないようにデータを保護したい場合に有用である。このアプローチは、アプリケーションデータがポータブルであり、ストレージプロバイダーのデータ侵害から保護されていることを保証する。
Confidential Storageエコシステム概観

要件

概要

Privacy andmulti-party
encryption

エンティティのデータのプライバシーを確保して、storage providerを含む無認可パーティがアクセスできないよう、データ転送中（ネットワー
ク上）と保管中（ストレージ上）の両方で暗号化されている必要がある。データは複数のエンティティと共有される可能性があるため、暗号化メカニズムが複数のパーティへのデータ暗号化をサポートすることも必要である。
システムは、1つの必須の認証スキームを指定するだけでなく、他の代替認証スキームを許可することが期待されている。
システムは識別子に依存しないものでなければいけなく、一般的には、
URNやURLの形をした識別子が好ましい。
情報の継続的バックアップが求められる。システムは少なくとも1つのmandatory versioning strategyとmandatory replication
strategyをサポートすることが必要であるが、他のalternate
versioning strategyとreplication strategiesも可能にすることが求められる。
本システムを利用して大量のデータを保存し、効率的かつ選択的に検索することが求められる。そのためには、暗号化された検索機構が必要である。クライアントがデータにメタデータを関連付けて検索できるようにすることが重要である。
このシステムは様々な動作環境に常駐することができるので、少なくとも1つのプロトコルが必須であるが、他のプロトコルも設計によって許可されていることが重要である。

Sharing andauthorization
Identifiers

Versioning andreplication

Metadata andsearching
Protocols出所) confidential-storage
https://identity.foundation/confidential-storage/183

3-2-3. 各標準化団体の検討仕様

B-4) Confidential Storage 0.1 – 課題と新たな取り組み セキュリティ考慮事項として、下記点が挙げられている。
考慮事項

概要

Malicious or
accidental
modification of data
Compromised vault• サービスプロバイダーはEncrypted Data Vault内のデータを読み取ることはできないが、サービスプロバイダーが暗号化データを削除、追加、変更することは可能である。暗号化データの削除、追加、変更は、data vault内のデータのグローバルマニフェストを保持することで防げる。
• Encrypted Data Vaultは、data controller(復号鍵と適切な認証情報を保持しているエンティティ) が誤って攻撃者にアクセスを許可した場合に危殆化する可能性がある。例えば、被害者が誤って攻撃者にvault全体へのアクセスを許可したり、暗号化キーを誤操作する可能性がある。攻撃者がシステムにアクセスできると、vaultの構成を変更、削除、変更できる。
• 通常、サーバがエンティティの身元や、そのエンティティがEncrypted Data Vaultにアクセスする目的を特定することは困難であるが、エンティティがEncrypted Data Vaultにアクセスした際に漏洩するアクセスパターンや大まかなファイルサイズ、その他の情報に関連するメタデータは常に存在する。
• すべての暗号化方式が最終的には破られると仮定することは、データを保護する際の安全な仮定である。サーバが暗号化されたデータを保存するためのストレージ戦略として、いかなる種類のpublic storage networkも使用することは推奨しない。
• このシステムでは、暗号化できないフィールドがいくつかある。例えば、データに関連付けられたバージョン番号から、データの更新頻度を知ることができる。暗号化されたコンテンツに関連付けられた識別子により、サーバはdocument間で識別子を関連付けることで知識を得ることができます。実装では、暗号化なしで保存される情報量を最小限に抑えることが推奨される。
• 暗号化されたテキストフィールドの部分一致やスカラー範囲の検索など、暗号化されたインデックスでは利用できない、検索システム
では一般的な操作がある。これらの機能は、将来的にはゼロ知識暗号化スキームを使用して追加されるかもしれない。
• 悪意のあるサービスプロバイダーによる以下の攻撃が考えられる。
 vault内の情報にアクセスしているエンティティの相関関係
 ファイルサイズやアクセスパターンに応じて、vaultに保管されているファイルの種類についての推測 暗号化されたデータの追加・削除・変更
 暗号化されたデータに設定された認証ポリシーを実行しない
 暗号化されたデータを未知の外部システムに流出させる

Data access timing
attacks
Encrypted data on
public networks
Unencrypted data on
serverPartial matching on
encrypted indexes
Threat model for
malicious service
provider184

3-2-3. 各標準化団体の検討仕様

C-1) Self-Issued DID Profile for OpenID v1.0
 Self-Issued DID Profile for OpenID (SIOP DID) はWebアプリケーションにIdentity Walletを統合するための汎用的な方法としてDID AuthN *1)にOpenID Connectを使用するための仕様である。
 RPはWebアプリケーションが想定されており、モバイルアプリケーションやデスクトップブラウザからIdentity Walletアプリケーションを起動して利用する。
 全体的な処理フローはOIDC Core 7. Self-Issued OpenID Providerにしたがって行われる。
SIOP DID処理フロー
1.

UserはRPにアクセス

2.

RPは”Sigin-in with SSI”ボタンを返し、Userがこれを押下するとSIOP Requestが生成

3.

SIOP Request (openid://?<SIOP request>)
によりSIOPが起動

4.

SIOPはOIDC/DID AuthNに従ってSIOP requestを検証しSIOP responseを生成

5.

response_modeの指定に従ってRPに
SIOP Responseがわたされる

6.

RPはOIDC/DID AuthNに従ってSIOP responseを検証する。

出所) Self-Issued OpenID Connect Provider DID Profile v0.1
https://identity.foundation/did-siop/*1) DID Authenticationの略称。接続先がDIDを制御しているエンティティかどうかの確認を行う

185

3-2-3. 各標準化団体の検討仕様

C-1) Self-Issued DID Profile for OpenID v1.0 – 課題と新たな取り組み
 2020年11月9日 OIDFとDIFのLiaison Agreement締結に伴い、SIOP DIDの作業は一時停止することが表明されている。
 今後はOIDF AB/Connect WGによってOIDC Coreの7. SIOPの改訂が進められる。
 AB/C WGによるSIOP仕様の作業が完了した後、DIF Authentication WGで作業が再開される予定である。

OpenID Foundationにおける議論

DIFにおける議論

Requirements for OIDC Self-Issued OpenID
Providerに記載のScopeを中心に議論。

2021年1月 DIF Face to Faceコミュニティイベントにおいて仕様検討状況を公表。

 Scope Current Draft•

A. SIOP request•

OpenID Connect Claims aggregation (adopted)•

B. SIOP response•

OpenID Self Issued Identifiers (adopted)•

C. Key recovery and key rotation•

Self-Issued OpenID Provider v2 draft01 (adopted)•

D. Trust model between RP and SIOP•OpenID Connect Credential Provider•

E. Issuance of the claims•

Smart Credentials•

F. Privacy protection•

Portable Identifiers: WIP

出所) Requirements for OIDC Self-Issued OpenId Provider
https://bitbucket.org/openid/connect/src/master/SIOP/siop-requirements.md

186

3-2-3. 各標準化団体の検討仕様

C-2) Presentation Exchange Presentation ExchangeはVerifierがProofの要件を明確にするためのデータフォーマットおよびHolderが要件に沿ってProofを提示するためのデータフォーマットを定義する。
 Presentation Exchangeはクレームフォーマットやトランスポートプロトコルに依存しないメカニズムとすることで冗長な処理、コード、手間を省くことを目的としている。
 サポートしているClaimフォーマットおよびトランスポートプロトコルの一例は以下の通りである。
 クレームフォーマット: JSON Web Token（JWT）、Verifiable Credential（VC）、JWT Verifiable Credentail（JWT-VC）
 トランスポートプロトコル: OpenID Connect、DIDComm、 Credential Handler API

Presentation Exchangeの概観像※ W3C Credential Community Groupにて
Credential Handler APIでの利用を想定したVerifiable Presentation Request
Specificationが別途存在
出所) Presentation Exchange
https://identity.foundation/presentation-exchange187

3-2-3. 各標準化団体の検討仕様

C-2) Presentation Exchange – Presentation Definition & Presentation Submission
 HolderおよびVerifier間におけるProofの要求と提示は以下の用語で定義される。
•

Presentation Definition: Verifierが必要とするProofを定義。

•

Presentation Request: VerifierからHolderに対するPresentation Definitionの転送方法を定義。

•

Presentation Submission: Verifierが指定したPresentation Definitionに従ってProofを提示する方法を定義。

Presentation Definitionオブジェクトを用いた定義例

Presentation Submissionオブジェクトを用いた定義例{{"comment": "Note: VP, OIDC, DIDComm, or CHAPI outer wrapper would be here.","presentation_definition": {"id": "32f54163-7166-48f1-93d8-ff217bdb0653","input_descriptors": [{"id": "wa_driver_license","name": "Washington State Business License","purpose": "We can only allow licensed Washington State business","schema": [{"uri": "https://licenses.example.com/business-license.json"
}]
}
]
}
}

}
出所）Presentation Exchange - 4. Presentation Definition, 5. Presentation Submission// NOTE: VP, OIDC, DIDComm, or CHAPI outer wrapper properties would be here.
"presentation_submission": {"id": "a30e3b91-fb77-4d22-95fa-871689c322e2","definition_id": "32f54163-7166-48f1-93d8-ff217bdb0653","descriptor_map": [{"id": "banking_input_2","format": "jwt_vc","path": "$.verifiableCredential[0]"},{"id": "employment_input","format": "ldp_vc","path": "$.verifiableCredential[1]"},{"id": "citizenship_input_1","format": "ldp_vc","path": "$.verifiableCredential[2]"}]}https://identity.foundation/presentation-exchange/188

3-2-3. 各標準化団体の検討仕様

C-2) Presentation Exchange – 課題と新たな取り組み セキュリティ考慮事項
 現時点で本仕様にセキュリティ考慮事項の記載は存在しない。セキュリティ考慮事項のセクション追加はGitHubのIssueで取り上げられている。*1)
 また、Issue上では、HolderがVerifierからの要求に自動応答する場合、Verifierが複数回Presentation Exchangeを実行することでHolderのプロファイリングが可能になり、プライバシー保護の目的が失われることが懸念されている。*1)

 今後の取り組み Presentation Exchangeと役割が酷似した仕様としてVerifiable Presentation Request Specificationという仕様がW3C
CCGから公開されており、統合または共存が検討されている。*2)
 GitHubのIssue上ではPresentation ExchangeがサポートするトランスポートプロトコルであるOpenID Connect利用時の処理フローなどに関する質問がいくつか上がっている。*3) *4)*1) Security Considerations, https://github.com/decentralized-identity/presentation-exchange/issues/204*2) IIW30 CHAPI and DID Comm 101, https://docs.google.com/presentation/d/1qPbwx9IXwPlgsZgS2XPXeGgstxrixnC8n0E2I4cxVc8/edit*3) What does PE look like within OpenID Connect? #101, https://github.com/decentralized-identity/presentation-exchange/issues/101*4) Examples that show support for regular OIDC flow, https://github.com/decentralized-identity/presentation-exchange/issues/92

189

3-2-3. 各標準化団体の検討仕様

D) Aries RFC
 HyperledgerはLinux Foundationがサポートするブロックチェーンを構築するためのプロジェクトである。
 Hyperledger Ariesプロジェクトはmessage exchangeプロトコル、エージェントのアーキテクチャおよびテストの定義や共有を目的としている。
 Aries プロジェクトを構成するコンセプトと機能はHyperledger aries-rfcs GitHubリポジトリで文書化されている。
 Aries RFCはconcepts (すべてのプロトコルにまたがる背景情報) とfeatures (特定のプロトコルの仕様) の2つのグループで定義されている。
 Hyper Ledger Indyには、indy-hipeと呼ばれるaries-rfcに相当するリポジトリが別途存在する。

HyperledgerプロジェクトにおけるHyperledger Ariesプロジェクトの立ち位置

出所) Hyperledger Aries
https://github.com/hyperledger/aries-rfcs#

190

3-2-3. 各標準化団体の検討仕様

D-1) Aries RFC 0023: DID Exchange Protocol 1.0
 本仕様では、Agent間でDIDを交換するためのプロトコルを規定している。
 以下の２つのロールを規定している。
 Requester
invitationメッセージを受信し後、またはPublic DIDからの暗黙的な招待を使用して、このプロトコルを開始する当事者。
 Responder
invitationの送信者または暗黙的な招待をもつDIDの発行者。DIDCommを介して他のAgentと対話できる必要がある。

 処理フローの概要は、以下の通りである。
1.

Responderはout-of-band protocolからのinvitationメッセージやResponderのPublic DIDに含まれる招待メッセージを使用して、Requesterに自身の情報を提供する。

2.

Requesterは受け取った情報を元にDIDとDID DocumentをリクエストメッセージとしてResponderに送信する。

3.

Responderは送信されたDID Documentに含まれる情報を使用してDIDとDID DocumentをレスポンスメッセージとしてRequesterに送信する。

4.

Requesterはレスポンスメッセージを受信したことを通知するメッセージをResponderに送信する。

出所) Aries RFC 0023, Aries RFC 0434
https://github.com/hyperledger/aries-rfcs/blob/master/features/0023-did-exchange/README.md
https://github.com/hyperledger/aries-rfcs/blob/master/features/0434-outofband/README.md

191

3-2-3. 各標準化団体の検討仕様

D-2) Aries RFC 0036: Issue Credential Protocol 1.0
 Issue Credential Protocolはクレデンシャルの発行に使用されるメッセージを形式化する。このプロトコルは特定のクレデンシャルの形式に依存するものではない。対応するクレデンシャルの形式の一例としては、JWT、JSON-LD、
ZKPなどがある。また、このプロトコルに適合していないクレデンシャルの形式を使用する場合はGitHubからIssueを提起することができる。
 このプロトコルでは、”Issuer” と ”Holder”の２つのロールを扱っている。
1.

HolderからIssuerに対して送信されるプロトコルを開始する際のリクエスト。
または、 HolderがIssuerに対して要求するクレデンシャルを指定するリクエスト。

2.

IssuerがHolderに対して送信する提供予
定のクレデンシャルや価格に関する連携情報。

3.

HolderからIssuerに対して送信される
クレデンシャルを要求するリクエスト

4.

Credential Requestに対するクレデンシャルを含むレスポンス

12出所) Aries RFC 0036
https://github.com/hyperledger/aries-rfcs/blob/master/features/0036-issue-credential/README.md

3

4

192

3-2-3. 各標準化団体の検討仕様

D-3) Aries RFC 0037: Present Proof Protocol
 Present Proof ProtocolはProofの提示に使用されるメッセージを形式化する。このプロトコルは検証可能なクレームを提示するためのメッセージについてのものであり、特定の提示メカニズムに依存するものではない。ただし、バージョン1.0の段階でサポートされている提示メカニズムはHyperledger Indyのみである。
 このプロトコルでは、”Verifier” と ”Prover“ の２つのロールを扱う。
1.

ProverからVerifierに送信されるProof
Presentationを開始するためのメッセージ。
または、Proverが別のPresentationフォー
マットを使用したい場合のPresentation
Requestに対するレスポンス。

2.

ホルダーからIssuerに対して送信される
クレデンシャルを要求するリクエスト。

3.

2

1
3

VerifierからProverに送信される署名されたPresentationが含まれるPresentation
Requestに対するレスポンス。

出所) Aries RFC 0037
https://github.com/hyperledger/aries-rfcs/blob/master/features/0037-present-proof/README.md

193

3-2-3. 各標準化団体の検討仕様

D) Aries RFC – 課題と新たな取り組み
 AriesとDIFは共同でDID Communicationワーキンググループを主催しており、Ariesを中心に構築されたエコシステム
だけでなく、分散型IDコミュニティ全体の通信プロトコルの仕様策定に参加している。*1)
 Ariesは独自にAries interoperability profileというConformance Testのプロファイルを所持している。ただし、これはAriesのプロトコルやアーキテクチャが正常に実装されていることを示すためのもである。ここでの相互運用性とは、他のAriesシステムとの相互運用性や標準的なVCデータモデルに対するAriesの共通解釈と、その解釈に基づいてコミュニティが定義したプロトコルへの適合性を意味している。
W3C CCGはW3Cのコア仕様に関するテストスイートとしてVC-HTTP-API Test SuiteおよびDID core Test Suiteに取り組んでいる。Aries interoperability profileは独自のインフラに焦点を当てており、ブロックチェーンベースのZKPシ
ステムプライバシー保証に焦点を当てている。この焦点はW3Cテストスイートに取って代わるものではなく、補完するものである。*2)*1) Drilling down: Co-development, https://medium.com/decentralized-identity/drilling-down-co-development-in-the-open-765a86ab153f*2) Setting Interoperability Targets, https://blog.identity.foundation/setting-interoperability-targets/194

3-2-4. 統制構成要素の概要

デジタルアイデンティティのガバナンスフレームワーク（トラストフレームワーク）
 1章で紹介したOpen Identity Exchange(OIX)のトラストフレームワークは、特定技術要素に寄らず、欧州のeIDAS、
英国のVerify、カナダのPCTF、インドのAadhaar等の教訓も踏まえ、規制当局向けにAML等の分野における適切な規制定義に際してトラストフレームワークとの関連性の理解を促すガイドとして活用可能と述べられている。また、SSIへの適用も想定されている。
 こうした特性を考慮し、本調査では、ガバナンスにおける構成要素として、同フレームワークにて規定された項目を踏まえた整理を行う。同時に、SSIモデルにおける、ガバナンス面での考慮事項の整理を行う。
OIXのトラストフレームワークで規定される構成要素
構成要素

項目

1. 原則
2. トラストマークとUX

構成要素

6. リライング
アイデンティティサービスへのパーティサービス ユーザアクセス
レクエスト＆レスポンス(API)

3. 役割と義務
4. 一般ルール 記録保存と監査証跡
不正行為とサイバーコントロール
5. ユーザサービス

トラストの獲得と提示
同意

構成要素

8. 技術・
セキュリティルール
セキュリティ要件 エコシステム参加者のトラストレジストリ

証跡の記録と提示

ライアビリティ

リクエスト及びレスポンススキーム
9. 相互運用性 内部の相互運用性
外部の相互運用性

ヘルプ＆サポート
7. トラストルール

ヘルプ＆サポート

出所）OIX,” OIX Guide to Trust Frameworks(version 0.1 Beta)”

項目

RPによるID保証
サービスレベル

デジタルアイデンティティの選択
IDの作成＆管理

項目

プルーフィング

10. ガバナンス

トラストフレームワークの構築と管理

アイデンティティ保証

トラストフレームワークの強制力

認証

トラストフレームワークの認証

適格性保証

トラストフレームワークの運用

195

3-2-4. 統制構成要素の概要

トラストフレームワークの構成要素概要
構成要素

概要

1. 原則

• マルチステークホルダーのニーズを考慮するにあたっての優先順位を定義する。
（1. ユーザ、2. リライングパーティ、3. フレームワーク、の順）• 1.ユーザに関し4つの原則（4Cs）を定義する。
（Convenience, Choice, Control, Confidence）

2. トラストマークとUX• User, RP, Evidence Issuer が見てトラストフレームワークの運用がなされているのを認識可能とするシグナルを定義する。（シンボル・フレーズなど）• 包括的なトラストマークを作成する、或いはトラストマーク表示時にフレームワーク間の総合合意を一覧表示することで、フレームワーク間のInteroperabilityを示すことも可能。
（例：フレーズ、単語、シンボル等。類似事例では、決済におけるカードブランド等がある。）

3.役割と義務―

4. 一般ルール 記録保存と監査証跡• データトラッキングとトラストフレームワークの完全性確保の為、以下に関する監査記録の保持が必要。
 データの生成、更新、削除、Evidenceの収集・提示、保証の評価（アセス）、
クレデンシャルの発行と利用

不正行為とサイバーコントロール • トラストフレームワーク内のID エコシステム全体を、サイバー攻撃や ID 詐欺から保護する必要がある。
また、トラストフレームワークに参加するエンティティは、担うロールに応じ不正やサイバーリスクの管理に何らかの責任を持つ
 不正に対する防御、不正行為の検知、当事者への通知・報告、不正行為の防止活動を行う機関同士の攻撃情報共有、影響の局所化・対象IDの閉鎖、対処・復旧、証跡の取得、起訴・調査のための証跡の提示等

出所：OIX Governance frameworkをもとにNRI作成

196

3-2-4. 統制構成要素の概要

トラストフレームワークの構成要素概要
構成要素

5. ユーザサービス デジタルアイデンティティの選択

6. リライング
パーティサービス

概要• 自身のニーズに適したIdPの選択、他IdPへのアサーション展開可否、一度オンボーディングを完了した
エンティティの再アクセス時における適切なRecognition実施等が可能なこと。

IDの作成＆管理• Identityのライフサイクル管理、特にクレデンシャル、Account Recovery、属性更新時のRPへの通知等の対応が可能なこと。

トラストの獲得と提示• Evidenceの保持、RPの求める保証レベルの充足。理想は、利用者が保証レベルを意識せず使えるのが望ましい。

同意• 利用者同意の元属性の連携が可能なこと。共有・利用履歴の閲覧権・データ削除権を利用者が有すること。

ヘルプ＆サポート• IdPがいつでも変更可能なこと、またその際Identity Proofing情報のポータビリティを有すること。
• クレデンシャルが危殆化した際、RPへの通知や、クレデンシャルの復旧が可能であること。

アイデンティティサービスへのユーザアクセス• RPによるTrustmark選択が可能なこと。

レクエスト＆レスポンス(API)• IdP/Verifier選択に制約を受けない、インターフェース定義やリクエスト・レスポンスの定義が明確であること。

RPによるID保証• Identity Assurance Modelの定義、RPによる利用者（が意識しなくて保証レベルを済むための）のガイドがあること。

ライアビリティ• 責任モデル、障害時の責任、フレームワークのルール逸脱時に課せられる責任、訴訟、調停・仲裁人の必要性に関する整理がなされていること。

サービスレベル• Trust schemeやBrokerによる差別化・競争力の保持が可能なこと。

ヘルプ＆サポート• RP内アカウントへのアクセスの継続性を維持した状態でのIdPの移植性・選択の自由の実現、コンプライアンス・苦情処理の対応が可能なこと。
• 保証メカニズムによる差別化が図れること。

出所：OIX Governance frameworkをもとにNRI作成

197

3-2-4. 統制構成要素の概要

トラストフレームワークの構成要素概要
7. トラストルール

構成要素

概要

プルーフィング• ID Proofingの技術要素として、Validation, Verification, Identity Risk Assessmentを定義。
Identity Assurance Assessment への Proofing Score 割り当てにも言及。
• フレームワーク間の相互運用性においては、Proofing Scoreの一致／同等性判断で実現される可能性がある。

アイデンティティ保証• Identity Assurance Processにおいて、保証レベルの定義付け、本人確認・当人認証の保証レベル、バインディング処理を考慮する必要がある。
• フレームワーク間の相互運用性においては、保証レベルの一致／同等性判断で実現される可能性がある。

認証• 信頼性／evidence／適格性のレベルをRPに提示する為、およびDigital Identityをmaintainする
ため、クレデンシャルを用いた当人認証処理を行う必要がある。
• 継続的なトラストの確認（Evidenceの有効性検証[validation]および再検証[reverified]）を考慮すべき。

適格性保証• 適格性保証のため、Eligibility Evidence の Validation・Verificationを行う。

出所：OIX Governance frameworkをもとにNRI作成

198

3-2-4. 統制構成要素の概要

トラストフレームワークの構成要素概要
構成要素

8. 技術・
セキュリティルール
セキュリティ要件

概要• フレームワーク内の当事者に適用されるルールの定義と、その遵守が必要。
（休止中のデータ、トランジット中のデータ、運用セキュリティ管理に関するルール規定を行う必要がある）

エコシステム参加者のトラストレジストリ• 参加する当事者を管理するためのレジストリ実装・記録・チェックが必要。

証跡の記録と提示• Evidenceの収集・生成・提示フェーズでどの様にevidence proofの履歴が記録されるかを定義すべき。また履歴は改ざんされない様、暗号技術の考慮も必要となる。
• ゼロ知識証明への対応を行うか考慮すべき。

リクエスト及びレスポンススキーム• Identity Evidenceとeligibility informationが一貫した方法でRPに提示される様、リクエスト／レスポンスのスキーマ定義が必要。
（特に複数Evidence Issuerをサポートするトラストフレームワークでは重要となる）• OIDF／W3C等グローバルに定義されたスキーマを考慮すべき。
• Evidence Typeによってはローカライゼーションが必要となるが、フレームワークはそれに備え、ローカルに適用可能なスキーマの為のキュレーターを実装すべき。

出所：OIX Governance frameworkをもとにNRI作成

199

3-2-4. 統制構成要素の概要

トラストフレームワークの構成要素概要
構成要素

概要

9. 相互運用性 内部の相互運用性

ユースケース・セクター間での相互運用性達成のため、トラストフレームワークレベルでのルール設定に準拠させる、或いは当事者に個別の複数schemeに準拠してもらうことで達成。
トラストフレームワークレベルで設定すべきルールとして、以下を述べている。
 Application of Principles
 Trustmark Rules
 Trust Rules and model, but perhaps leave the setting of acceptable scores within themodel for particular use cases to the trust scheme.
 Technical Rules such as used of common levels of Security and common Schemas

外部の相互運用性

他トラストフレームワークとの外部相互運用性の実現手段として、下記3点に言及。
１）相互合意。フレームワークが保証するトラストを相互に認識
２）ノードアプローチ※を通じた、エージェントが多数フレームワークの整合性と互換性を独立に評価し、複数トラストフレームワークが相互に信頼しあう
３）IdPやevidence verifier等当事者の、複数のトラストフレームワークへの準拠※ノードアプローチは、各フレームワークが共通に合意されたルールに従うことを必要とするのみであり、フレームワーク間の大量の相互運用性実現のための効率的な手段としている。いわゆる”Framework offrameworks”）
相互運用性で考慮すべき設計・実装ポイントとして、以下を述べている。
 Application of Framework Principles
 Trustmark Rules
 Trust Rules
 Record Keeping Fraud Controls
 Response Schema Security Standards

出所：OIX Governance frameworkをもとにNRI作成

200

3-2-4. 統制構成要素の概要

トラストフレームワークの構成要素概要
構成要素

10. ガバナンス

トラストフレームワークの
構築と管理

概要
• トラストフレームワーク生成者として5モデル定義
１）Independent Governing Entity２）Consortium of Participating Entities
３）Single Participant Governing Entity４）Non-Governing Standards or
Certification Organization
５）Mutual Agreement Among All（事例）
１）DIACC
２）CA/Browser Forum３）単一ID Provider, GOV.UK Verify４）Kantara Initiative, tScheme５）- (個別の管理主体は存在せず)

トラストフレームワークの強制力• ルール遵守の為の強制力として、下記3つのケースを想定。
１）民間セクター：契約メカニズムによる強制力
２）政府セクター・政府スポンサー：法令・規則等による強制力
３）官民パートナーシップ：ハイブリッド（主要原則は法律準拠、特定要件は契約で執行等）

トラストフレームワークの認証• トラストフレームワークに参加するエンティティの認証。
（トラストフレームワークが定義する義務を果たしている証跡として）• 認定手法は以下の通り（各レベルは別紙にて詳述）。
 Self-Assessment
 Verified Self-Assessment
 Approved Certified

トラストフレームワークの運用• トラストフレームワーク（TF）の開発・維持に責任を持ち課題発生時に修正するTF Providerが必要。
• 統制機能の例として、以下に分類。
 Governance and Policy Development
 Policy Enforcement
 Participating Entity Management Network Evolvement
 Trust Framework Operations

出所：OIX Governance frameworkをもとにNRI作成

201

3-2-4. 統制構成要素の概要

SSIモデルにおけるトラストフレームワークの適用イメージ
 Open Identity Exchange (OIX)のトラストフレームワークでは、デジタルアイデンティティ管理において必要な構成要素、並びにその実現に必要な役割と義務が述べられている。
 同フレームワークでは、SSIモデルに対するアプローチについても言及されているが、役割と義務の考え方が変わるのではなく、誰が担うか、という点で従来のモデルと異なると述べている。具体的には、ホルダーが以下の役割を担う点である。
① CPからクレームを受け取る、「RP」としての役割を担う② RPに対し、①で取得したクレームを展開する、「CP」としての役割を担う

 ホルダーが上記2つの役割を担うことで、トラストフレームワークの構成要素でのガバナンスの要件の大半を実現する必要が生じる。そのため、実運用を考慮すると、監査対応やクレデンシャルの管理、Liabilityの整理等、克服すべき課題が存在する。詳細は3-4.節にて詳述する。
ホルダーの担う役割イメージ

TrustedClaimsCP①

Trusted Decision Engine（トラストルール）

RP

CP

②

Trust
Presentation

 Claims
 Trusted Evidence
 Level of Assurance Trusted Eligibilities
の展開

RP

ホルダー
出所）「OIX Quarterly Workshop - 15th Dec 2020」資料もとにNRIが作成

202

3-3. SSI/DIDの先行事例/PoC事例203

第3章 自己主権型アイデンティティ(SSI)/分散型アイデンティティ(DID)「3-3. SSI/DIDの先行事例/PoC事例」の要旨
 現在国内外において金融機関等が関与するSSI/DIDを用いた様々な実証実験が進められている。
 金融機関等がSSI/DIDに関心を持っている背景として、主に顧客の登録手続きの効率化やAML対策の観点で取り組んでいることが分かった。
 ただし、現在のところこれら取組の多くは実証レベルであり、実サービスとして取り入れられているのは、カナダのVerified.Meなどごく少数にとどまる。


Verified.Meは、コンソーシアム型としてスタートし、立ち上げ時はIdPとしての金融機関と、サービスプロバイダーとしての政府機関や一部の生保会社のみが参画するモデルである。したがって、ユーザの利用シーンを一定程度限定することで、SSIのコンセプトを実現している。



なお、ガバナンス準拠という観点では、DIACCが策定するPCTFに準拠している点が特徴であると言える。

 今後の実用化に向けて特にEUで注目されている取組の一つが、スペインを中心に検討が進められている
Alastria_IDを用いたプロジェクトで、代表的なものとしてSantander社が推進するプロジェクトDalionが挙げられる。
 AlastriaはEUのGDPRやeIDASへの準拠を謳っており、EUの厳しい規制に準拠できるソリューションとして位置づけられている。
 ただし、Alastria自体はAlastria IDの技術フレームワークを開発・提供しているのみで、実際のユースケースはDalion等の個別のプロジェクトでの検討が進められている。各プロジェクトにおいて、参画するステークホルダーがどのような責任分界のもとビジネスモデルを構築するのかは現時点では明らかになっておらず、今後の課題になっていると考えられる。

204

3-3. SSI/DIDの先行事例/PoC事例

金融機関が関与する主な取組事例
 現在特に海外を中心にSSI/DIDに関連する様々な取組が進められているが、その多くは実証レベルであり、実際のサービスなどに適用されているものは少ないのが現状。
 SSI/DIDに関連して金融機関が関与している主な取組みとして以下の事例がある。
国

ユースケースパートナー

カナダ主要7行

行政や生保等

SecureKey
Technologies

銀行はIdPとして参加

カナダ主要7銀行がコンソーシアムを構築し、Verified.Meというサービスを2019年5月より提供。
主要7銀行が保有する本人確認情報等を生保等に連携。

スペイン

Banco
Santander

レンタカー・保険・ローンの申し込み、行政への申し込み

CaxiaBank、
MAPFRE(保険)、Repsol(エネルギー)、Alastria (非営利ブロックチェー
ンコンソーシアム)

ジョイントベンチャーがIDプラットフォームの役割を果たし、銀行本体はIdPとして参加

安全で信頼性の高いIDプラットフォームにより、ユーザが個人情報をより細かく自らで制御できるようにすることで、プライバシーの保護と、ワンスオンリーによる利便性を提供する。
現在は、実証実験の段階であり、2021年5月にリリース予定であ
る。

金融

スペイン

Veridas（BBVAとdasNanoの合弁会社）

BBVA/Bankia/
Renta 4 Banko

行政ナバラ州政府（スペイン）

DeutscheBank

行政・銀行・
ヘルスヘア等

Barclays

行政（国民年金の受け取り
等）

カナダ

ドイツ

英国

金融機関

出所：各社プレスリリース等をもとにNRI作成

金融機関の役割概要

高度な生体認証機能（顔、声、指紋等）の提供
セキュリティの保護

銀行口座の開設や、オンライン取引時の生体認証などの機能を
BBVAを含めた各金融機関等に提供している。

Deutsche Bahn,
Daimler,LufthansaジョイントベンチャーがIDプラットフォームの役割を果たし、銀行本体はIdPとして参加

他企業と出資して作り上げたVerimiが、デジタルIDプラットフォーム
として、IDを一つに集約する役割を担い、銀行・行政・ヘルスケア・
モビリティ・オンラインゲーム等にデジタルIDを用いたユースケースを提供する予定である。

イギリス政府GOV.UKのアイデンティティと連携

政府のGOV.UK認証イニシアティブの一環としてIdPと認定されており、ID連携がなされているため、イギリス政府のサービスをうけるにあたっての本人確認を簡単にしている。

行政手続きのオンライン化・顔識別技術による国境の管理・安全
で高速の本人確認などの機能をナバラ州に提供している。

205

3-3. SSI/DIDの先行事例/PoC事例

金融機関が関与する主な取組事例
国

グローバル

金融機関

Master
Card
（カード）

JCB

日本

JCB
みずほ

JCB

ユースケース

パートナー

通信会社の
顧客のID管理

Optus（通信会社）

大学の試験におけ
る本人確認

郵便公社
ディーキン大学

行政のデジタルID
連携

北マケドニア共和国

金融機関の役割概要
Optusは、MyOptusアプリをダウンロードしている約600万人の顧客にMasterCardのIDサービスを導入し、デバイスの購入・アカウントの変更・追加サービスの購入などに使用できる安全でポータブルなデジタルIDを提供する。

デジタルIDプラットフォー
ムの提供

郵便公社のID・アプリと、ディーキン大学のポータルサイトを用いてオンラ
インで試験を受ける学生の本人確認を実施することが出来る。
北マケドニア国民が日常のさまざまな活動で使用できる、ローカルのデジタルIDと関連トラストサービスを提供することを目的としている。最初のア
プリケーションの中には、新しい銀行口座のリモート開設をサポートするeKYC機能や新しい携帯電話アカウントがある。

富士通

決済や認証機能や、事業者間の資金精算などの運営スキームの知見を提供

ユーザID情報の連携と活用を可能にするプラットフォームの共同開発の検討と、プラットフォームを活用した新たなサービスやビジネスモデルの検討を2019年10月より開始。

他事業者間の属性の連携・流通富士通

JCB・みずほ銀行が保有する参加者の情報を各社から本人に開示。同時に、同システムを通して、参加者から開示された本人の情報を受領。

2020年4月から2021年1月に、複数事業者が持つ情報の管理や信頼性向上の観点から、ID情報の相互運用モデルに関する実証実験を実施。

オンライン身分証
明書慶應義塾大学伊藤忠テクノソ
リューションズJapan Digital
Design
西日本電信電話
BlockBase

提供する決済サービスとの連携等

慶應義塾大学の学生を対象に在学証明書や卒業見込証明書などをスマートフォンアプリへ発行する、次世代デジタルアイデンティティ基盤の実証実験をマイクロソフトと連携して2020年10月から開始。

本人確認・属性
変更手続き等

出所：各社プレスリリース等をもとにNRI作成

206

3-3. SSI/DIDの先行事例/PoC事例

金融機関が関与する主な取組事例
 上記の主な取組事例のうち、国内外の有識者ヒアリングにおいて金融分野におけるSSI/DIDの事例として示されることが多かった以下2事例について詳述する。
国
カ
ナ
ダ

ス
ペ
イ
ン

金融機関

ユース
ケース

パートナー

金融機関の
役割

概要

選定理由
既にサービスとして提供されており、金融分野におけるSSI/DIDのユースケースの代表的な事例としてグローバルで認識されているため。

EUにおけるSSI/DIDの取組における先進的な取組みとして位置づけられて
いるため。

カナダ主要
7行

行政や
生保等

SecureKey
Technologies

銀行はIdPとして参加

カナダ主要7銀行がコンソーシアムを構築し、Verified.Meというサービスを2019年5月より提供。
主要7銀行が保有する本人確認情報等を生保等に連携。

Banco
Santander

レンタ
カー・保
険・ロー
ンの申
し込み、
行政へ
の申し
込み

CaxiaBank、
MAPFRE(保険)、
Repsol(エネルギー)、Alastria(非営利
ブロックチェーン
コンソーシアム)

ジョイントベンチャーがIDプラットフォームの役割を果たし、
銀行本体はIdPとして参加

安全で信頼性の高いIDプラットフォームにより、ユーザが個人情報をより細かく自らで制御できるようにすることで、プライバシーの保護と、ワンスオンリーによる利便性を提供する。
現在は、実証実験の段階であり、2021年5月にリリース予定である。

207

3-3. SSI/DIDの先行事例/PoC事例

Canada: Verified.Me カナダでは、SecureKey Technologies社が、カナダの主要金融機関7社(BMO, CIBC, Desjardins, National
Bank of Canada, RBC, Scotiabank and TD)のコンソーシアムと共に、Verified.Meというサービスを2019年5月から提供している。
 Verified.Meは、プライバシーを尊重した「デジタルアイデンティティ・属性共有ネットワーク」である。本サービスは、ユーザがサービスにアクセスするために、トラステッドソース（金融機関、携帯電話事業者、信用情報機関、政府など）から、
アイデンティティや属性情報を共有できるようにすることで、アイデンティティベリフィケーションプロセスの簡素化を実現できるもの
として位置づけられている。
 本ネットワークは、コンソーシアムが運営する許可型の分散型台帳をベースにする。具体的には、Linux Foundation の
オープンソースであるHyperledger Fabric をベースにした IBM Blockchain Platform を使用して構築されており、他のネットワークとの相互運用性を可能にするために、W3C の分散型アイデンティティ標準(W3C DIDs and Verifiable
Credentials)に準拠している。
 本サービスは、消費者は無料で利用できる。（App StoreやGoogle Playからアプリをダウンロードして利用）
Verified.Meのサービス概念図
CP

RP

クレームをセキュアに連携

情報提供料の支払い（一部スキームが徴収）

情報提供の同意
サービス利用

一般消費者・ユーザ

出所）DIACC上で公開されているSecureKeyサービス紹介資料等を基に作成
https://diacc.ca/wp-content/uploads/2020/05/DIACC-Identity-Networks-Paper-SelfAssessment_SecureKey-VerifiedMe.pdf

2083-3. SSI/DIDの先行事例/PoC事例

Canada: Verified.Me Verified.Meの基本的な仕組みは以下の通り。

Verified.Meの仕組み

 アイデンティティ＆データプロバイダー(IdPs）• ユーザに関する特定の情報を生成または保持する Verified.Me に参加するカナダの適格組織。IdPの例としては、金融機関、
信用情報機関、電気通信プロバイダー、およびその他の適格なトラステッドソースが該当 リライングパーティ(RP)またはサービスプロバイダー• Verified.Me に参加するカナダの適格な組織であり、Verified.Me を通じてユーザに特定の情報の提供を求める。Verified.Meは、
サービスプロバイダーが、主体に対してサービスや製品を提供する際のアイデンティティや適格性をベリファイするのを支援する
 金融機関の アイデンティティ＆データプロバイダー（金融機関、または「サービス・ホスト」）• カナダの主要金融機関 7 社は、Verified.Me サービスへのアクセスを希望するサブジェクトの認証、およびネットワークのコアコンポー ネントのホスティングを担当する。サービスホストは、ネットワーク上の分散ノードを運営し、一次IdPとしても機能する
 Verified.Me ユーザエージェント• ユーザが Verified.Me ネットワークにアクセスし、ネットワーク（モバイルアプリまたは Web ブラウザ）を介してユーザの属性の共有に同意するために提供されるツール
出所）DIACC上で公開されているSecureKeyサービス紹介資料等を基に作成
https://diacc.ca/wp-content/uploads/2020/05/DIACC-Identity-Networks-Paper-SelfAssessment_SecureKey-VerifiedMe.pdf

209

3-3. SSI/DIDの先行事例/PoC事例

Canada: Verified.Me Verified.Meの利用イメージとして、生保会社(Sun Life Financial)契約時に、銀行(RBC)の本人確認情報を連携して利用する際は以下のような流れで情報が連携される。

Verified.Meの利用イメージ•

生保会社のサイトから”Register using
Verified.Me”を選択•

Verified.Meに登録されているアイデンティティ情報を選択（この場合はRBC）•

RBCに登録されているア
イデンティ情報を確認

出所）https://www.iphoneincanada.ca/news/verifiedme-launch-canada/

•

連携を実行

•

RBCのアイデンティティ情報の連携が成功•

生保会社に情報が連携され、登録完了

210

3-3. SSI/DIDの先行事例/PoC事例

Canada: Verified.Me Verified.Meの主な特徴としては、以下の点が挙げられる。
【サービスが創出された背景】• カナダでは、口座開設時に対面での本人確認を実施している点、KYC情報の更新をしないと口座が凍結されてしまうという事情もあり、銀行の本人確認情報が鮮度・精度ともに高い状態になっており、銀行としてもこうしたKYC情報を上手く活用するという発想が銀行側にあった。
【SSI/DIDとしての特徴】• 本サービスはSSIに基づくモデルではあるが、一般のSSIよりも更に厳しいモデルを取っている。SecureKey社はこれを「Triple Blind」と呼ぶ。すなわち、本サービスモデルに参画する3者（Identity & Data Provider, Service Provider,
Network Operator）のいずれもが、ユーザが連携する情報がどこからどこに提示されるのか分からないような設計となっている。一般にSSIのモデルは、リライングパーティ側はどこのIdentity情報が使われているのかについては制限しない
ため、この点でより強固なプライバシー設計となっている。
【ユースケース】• 主なサービス利用者（サービスプロバイダー）は、政府機関や生保等に限られているが、NationwideなIDインフラとなることを目指している。

211

3-3. SSI/DIDの先行事例/PoC事例【参考】カナダのデジタルアイデンティティ
 カナダでは、政府・民間企業とで構成されるDIACC（Digital ID & Authentication Council of Canada）が、デジタルアイデンティティと認証フレームワークの開発に取組んでいる。
 DIACCの設立の背景には、カナダ財務省が、デジタル時代の金融システムの見直しを目的に立ち上げた「決済システムレビュータスクフォース」が2011年12月に策定した報告書がある。
カナダの決済システムを大幅に近代化するためには、消費者の行動から会計ソリューション、政府がサービスを提供する際に頼りにしている
手続きに至るまで、さまざまな分野で変化が必要である。産業界は、不確実性や協調性の欠如もあって、変革を実施していない。したがって、カナダ政府は、以下のような行動をとることで、変化をリードする必要がある。
• すべての政府機関のサプライヤーと受益者に電子請求書と電子支払（EIP）を導入する。
• 民間企業と協力してモバイルエコシステムを構築する。
• 近代的な決済システムを支え、カナダ人のプライバシーを保護するために、「デジタルアイデンティフィケーションおよびオーセンティフィ
ケーション（DIA）」制度の構築を推進する。
 上記提言の3点目の提言を踏まえ、検討組織として官民組織による非営利組織としてDIACCが2012年に設立された。
出所）https://www.canada.ca/content/dam/fin/migration/n12/data/12-030_1-0_eng.pdf

212

3-3. SSI/DIDの先行事例/PoC事例【参考】 DIACC（Digital ID & Authentication Council of Canada）
 DIACCの参加メンバーと主な取組みは以下の通り。
 財務省のタスクフォースの提言などが背景にあることから、メンバー企業には金融機関等も多く占める。
DIACCの主な参加メンバー

国内主要銀行の参加

DIACCの官民での取組み
情報収集・共有

政府の参加

ユースケースの企画、PoC実施

DIACC内に設置されているコミッティ
DIACC

TFEC

IEC

相互運用性、ベスプラ輸出
OEC

TFEC：Trust Framework Expert Committee
IEC：Innovation Expert Committee
OEC：Outreach Expert Committee
出所）DIACCのHPを元にNRI作成

213

3-3. SSI/DIDの先行事例/PoC事例【参考】 PCTF(Pan-Canadian Trust Framework)とSSI/DIDへの対応
 DIACCは、カナダの官民組織がデジタルアイデンティティを安全に活用するためのガバナンスモデルとしてPCTFを開発し、2020年11月にPCTF 1.0 alphaをローンチ。
 PCTFは、アイデンティティ管理を既存のアナログからデジタルに移行する際に求められる基本原則や基準を策定し、政府機関や事業者がリファレンスアーキテクチャとして参照できるようにすることを目的に策定。
 法的強制力はなく準拠は任意であるが、デジタルアイデンティティのトラストフレームワークとして、カナダ国内のみならず
グローバルでも注目されている。
 また、2021年2月に分散型アイデンティティがどのようにPCTFに準拠するのかについてのガイドラインも公表している。
【PCTFの構成要素】

出所）https://diacc.ca/wp-content/uploads/2020/09/PCTF-Model-FinalRecommendation_V1.0.pdf【DIDに関するガイドライン】

出所）https://diacc.ca/wp-content/uploads/2021/02/Decentralized-Identity-andDIACC-PCTF-Authentication.pdf

214

3-3. SSI/DIDの先行事例/PoC事例【参考】PCTF準拠状況のセルフアセスメント
 デジタルアイデンティティサービスを提供する事業者は、PCTFへの準拠状況をセルフアセスメントし、その結果を公表することで、利用者への安全性等に関する説明責任を果たしている。
 例えば、前述のVerified.Meについて、SecureKey社は以下のセルフアセスメント結果を公表。

出所）https://diacc.ca/wp-content/uploads/2020/05/DIACC-Identity-NetworksPaper-Self-Assessment_SecureKey-VerifiedMe.pdf

215

3-3. SSI/DIDの先行事例/PoC事例

Spain: Alastria_ID/Dalion
 Alastria_IDはSSIでのデジタルアイデンティティのモデルで、Dalionはスペインの金融事業者等によってAlastria_IDを基にサービス化されているプロジェクトの名称である。
 Dalion参加企業
 Alastria、銀行、保険会社、エネルギー事業者、IT開発事業者

Dalionプロジェクト参加企業・団体（Santander社プレスリリースより）

 プロジェクト概観
 2019年に開始、2020年にPoCを実施、2021年5月サービス提供開始予定
 AlastriaのEthereum-Quorumブロックチェーン上で動作（開発時点）

銀行

保険

 利用者へのメリット
 個人の情報を自ら管理可能
 新規サービス登録・利用時の情報入力の手間削減（KYCといった検証含む）

エネルギー

 アイデンティティ盗難対策

 参加企業へのメリット
 利用者登録の手続きなどの効率化 悪意ある利用者による詐称対策 参加企業間の新規ビジネスモデルの開発とユーザエクスペリエンス向上
出所）サンタンデール銀行によるDalionプロジェクトのプレスリリース
https://www.santander.com/en/press-room/press-releases/2020/11/ten-spanishcompanies-join-forces-to-promote-digital-identity-using-blockchain-technology

証券取引所運営

ITサービス216

3-3. SSI/DIDの先行事例/PoC事例

Spain: Alastria_ID/Dalion
DNI 3.0カード例

 スペインに関連するデジタルアイデンティティの取り組みは以下の通り。
 DNI (Documento National de Identidad) 3.0 *1)
 スペイン政府（国家警察総局）が発行 従来のDNIeから2015年頃より移行
 ICチップによって接触型ないし非接触型（NFC）でデータを利用可能• 格納データ：氏名等情報、顔写真、サイン、指紋、電子署名証明書、DNI証明書
 身分情報の提示や電子署名の付与等に使用可能

画像出典：https://www.dnielectronico.es/PDFs/uso_nfc.pdf

 Alastria_ID 2017年に発足した非営利団体のAlastiraにより、2018年からプロジェクトが開始されたSSIのデジタルアイデンティティのモデル*2)• Alastriaのメンバー数は550近くで、主にスペイン（一部はイタリアやドイツ）の金融業含む企業、公共機関、大学等
 Alastiraのメンバーによって運営されるブロックチェーンを用いたオープンソースモデルの自己主権型アイデンティティ基盤*3)
 欧州圏においての法的有効性を持った自己主権型デジタルアイデンティティのインフラと開発フレームワーク提供が目的*3)• スペインの標準化団体（UNE）に提示、欧州電気標準化委員会にも提出され、さらにESSIF (European Commission’s Self-Sovereign Identity Initiative）にも示唆を与えた*4)

 Dalion *4)
 Alastria_IDをベースとしたプロジェクトで、2019年に開始し、2020年にPoCを実施し、2021年5月にサービス提供開始予定
 サンタンデール銀行を含めた多数の銀行業、保険業、証券市場等が参画し、地方自治体や大学等のオブザーバーも参加
 検証済みの属性の受け渡し、つまり他銀行等による身分検証結果を転用可能にして身分検証の手間削減が目標*1) スペイン国家警察総局 https://www.dnielectronico.es*2) Alastria https://alastria.io/*3) Alastria_ID GitHub https://github.com/alastria/alastria-identity/wiki*4) サンタンデール銀行によるDalionプロジェクトのプレスリリース https://www.santander.com/en/press-room/pressreleases/2020/11/ten-spanish-companies-join-forces-to-promote-digital-identity-using-blockchain-technology

217

3-3. SSI/DIDの先行事例/PoC事例

Spain: Alastria_ID/Dalion
 Alastira_IDとはAlastiraのアイデンティティ委員会によるデジタルアイデンティティのプロジェクト
 Alastria参加メンバーが運営するブロックチェーン上で動くSSIのモデル
 欧州圏での法的有効性を持った自己主権型のデジタルアイデンティティのインフラストラクチャと開発フレームワークを提供

 以下の欧州圏の基準等に準拠
 ブロックチェーンを用いた自己主権型アイデンティティのフレームワークとして欧州委員会によるSSI eIDAS法的レポート
 EUBOF（EU Blockchain Observatory and Forum）によるe-Identityワークショップレポート
 GDPR対応としてEUBOFと欧州議会によるブロックチェーンとGDPRについてのレポート
 eIDAS規制

Alastria_ID 役割分担

Alastria_ID 特徴

Alastriaメンバーは
アプリケーションで競争
Alastriaによる策定
標準化団体との協力
Alastriaメンバーは
インフラストラクチャで協力

出所）“Alastria Digital Identity An ongoing project”
https://portal.r2docuo.com/alastria/document?L3110FC15F“Alastria_ID” GitHub https://github.com/alastria/alastria-identity/wiki

Dalionを含む
プロジェクト

欧州の各種委員会等との協力・準拠出所） “Alastria ID Compatibility and interoperability”
https://portal.r2docuo.com/alastria/document?L097EBB43D

218

3-3. SSI/DIDの先行事例/PoC事例

Spain: Alastria_ID/Dalion
 Alastira_IDは一般的なSSI/DIDと同様にクレデンシャル発行者（Issuers）、利用者（User）、
クレデンシャル受領者（Service Provider）に役割分担がなされ、クレデンシャルに関する操作などがAlastriaのブロックチェーンに書き込まれ、ブロックチェーン上の記録を用いてクレデンシャルの真正性を検証することができる。
Alastria_ID 利用概観図

クレデンシャル受け取り

クレデンシャル提示

利用者
受領/削除記録書き込み

送付/削除記録書き込み

発行/無効化記録
書き込み

クレデンシャル発行者

Alastriaブロックチェーン

受領/削除記録
書き込み

サービス提供者（クレデンシャル受領者）

出所）https://alastria-es.medium.com/la-identidad-digital-de-alastria-presenta-su-primer-mvp-696750d687ac

219

3-4. SSI/DIDの長所と実現に向けた課題

220第3章 自己主権型アイデンティティ(SSI)/分散型アイデンティティ(DID)「3-4. SSI/DIDの長所と実現に向けた課題」の要旨
 SSIモデルの長所ならびに実現に向けた課題は、それぞれ以下の通り。
 長所は、主にIdPへの依存度を下げることで、自己制御権の獲得やプライバシーへの配慮実現可能な点が挙げられる。
また、複数クレームプロバイダー間を、ユーザのウォレットをハブに連携するトポロジーを取ることで、業界全体のオンボーディング
コスト抑制に寄与する点が期待出来る。
 実現にむけた課題は、新たなモデルであるが故の技術・法的/制度・運用面で生じる新規課題克服、ならびにビジネスにおける新規取り組みに向けてのオーバーヘッドへの考慮や適合ユースケース探索が挙げられる。

SSIモデルにおける長所
種類

概要

自己制御権
の獲得

• IdPによるロックアウト制約を回避• IdPによる発行後クレームの内容改ざんを回避

プライバシーへの配慮• 既存IdPでの処理の最小化• データ連携における明確な同意管理やデータミニマイ
ゼーション実現策としての活用、自身の意思で保持するクレーム削除を行うことで「忘れられる権利」行使の実現策としての活用• クレームプロバイダーに対し、クレーム提示先の秘匿が可能（Need to knowの原則を遵守可能）

利便性の向上／
業界全体の
コスト抑制

• 取得済クレームを用いた複数リライングパーティへの展開（利便性向上）• 複数クレームプロバイダーからのデータ連携を可能にすることで、業界全体でのオンボーディングコスト抑制

SSIモデルの実現に向けた課題
種類

概要

技術

• SSI/DIDを構成する各レイヤーのトラストアンカー整理・実装• 複数仕様の併存における相互運用性の考慮• 新規策定されるプロトコルに対するセキュリティ実装の確保

法的/制度• 政府および政策立案者の関与• データ保護制度• プライバシー対策

運用• 規制当局や弁護士、公証人の技術の理解• 標準化の推進• トラストフレームワークの整備・開発• ライアビリティの明確化

ビジネス• 現行IT/デジタルシステムの適応• 個人の導入/ユースケースの検討
221

3-4-1. SSI/DID活用のメリット

SSIモデルのメリット
 SSIモデルは、下記項目へのメリットが期待される（下線は2章で言及したデジタル化加速における課題）。
 各メリット獲得のためには、SSI/DIDの4つの特性が必要不可欠となる。
SSIモデルのメリット
SSI/DIDの特性との対応
メリット

概要

自己制御権
の獲得

• 悪意を持ったIdPによるアイデンティファイアのロックアウト処置を受けない• 以下の実現により、IdPの動態に依存しない／ユーザの意図せぬ更新（改ざん）を受けない、クレームの保持が可能となる
 クレームを自身のウォレットに取得
 クレームプロバイダーの署名検証鍵（クレームの真正性検証に必要な）を耐改ざん性を有し信頼できる形で保持可能な分散リポジトリ等に長期保管

プライバシーへの配慮• 既存IdP内での処理の最小化（Recognition処理に限定）• データ連携における明確な同意管理やデータミニマイゼーション実現策としての活用、自身の意思で保持するクレーム削除を行うことで「忘れられる権利」行使の実現策としての活用• クレームプロバイダーに対し、クレーム提示先の秘匿が可能（Need to knowの原則を遵守可能）利便性の向上／
業界全体の
コスト抑制

認証と
属性
の分離

分散情報
活用・
選択的提示

提示先
の秘匿

長期の
保管・利用

• 一度取得したクレームを複数リライングパーティに展開が可能（顧客の利便性向上に寄与）• 複数クレームプロバイダーからのデータ連携を可能にすることで、業界全体でのオンボーディングコスト抑制に寄与
222

3-4-1. SSI/DID活用のメリット

先行事例におけるSSIモデルのメリット
 SSIモデルのメリットに関して、3-3.で取り上げたカナダのVerified.Meでの対応状況は以下の通りと考える。
先行事例での実現例
SSI/DIDの特性との対応
メリット

認証と
属性
の分離

分散情報
活用・
選択的提示

提示先
の秘匿

先行事例（Canada Verified.Me）での実現例※公開情報等をもとにNRI考察

長期の
保管・利用
•

自己制御権
の獲得

•
•

•
プライバシー
への配慮

利便性の向上／
業界全体の
コスト抑制

•
•

•
•

認証と属性の分離は、ユーザエージェントにて格納された属性はユーザのコント
ロール下になっており、CPの管理外となっている。
分散情報活用・選択的提示は、ユーザエージェントにて選択的提示を可能とす
る実装がなされている。
長期の保管・利用については、実施有無含め詳細不明。なお、本特性を有す
るその他事例としては、例えば、慶應義塾大学がJCB等と取り組む「オンライン
身分証明書」のユースケースでは「永続的に検証可能な属性提供基盤」が一つの特徴と位置付けられている。
認証と属性の分離については、既存IdP内での処理の最小化（認証処理に限定）する機能が実装されている。
分散情報活用・選択的提示は、ユーザエージェントにて選択的提示を可能とす
る実装がなされており、ユーザ同意に基づく処理を実現。
提示策の秘匿については、RPに対してどのIdPから取得した属性か分からない
ような匿名処理を実現する機能が実装されている。

認証と属性の分離については、取得したクレームがユーザエージェントに格納され、複数のRPにクレーム展開可能な実装となっている。
分散情報活用・選択的提示は、複数CPからデータ連携を可能とすることでRP側での本人確認にかけるコストを大幅に削減できるようになっている。
223

3-4-2. SSI/DIDの課題 - （１）技術面での課題

技術的課題
 SSI/DIDを構成するレイヤーにおける技術的課題
 DIDを構成する各レイヤにおいて、トラスト、相互運用性、セキュリティの観点で課題を整理する。
※ウォレットアプリケーションの信頼性にも関与

SSIモデルのレイヤーごとの課題観点での技術的課題
レイヤー

トラストアンカー

Claim Presentation Layer
Claim Issuance Layer

バリデーション/ベリフィケーション/
透明性の確保ウォレットアプリケーションの信頼性、クレデンシャル管理

クラウド

Transport/Communication
Layer

DID cryptographic private keyのトラスト確保※Discovery Layer

Universal Resolverの追跡性、透明性、トラストアンカー担保

Utility Layer

アイデンティファイア生成のスキーマにおけるAuthority Model

Formally provable

WebApp

モ
デ
相 ル
互 間
運 ・
用 メ
性 ソ
ッ
へ ド
の 間
考 に
慮 お
け
る

Cryptographic Agility

Local Storage

デ
ー
タ
ス フ
キ ォ
ー ー
マ マ
共 ッ
通 ト
の
統
一

プ
（ロ
ト
コ
ル
の
認
定
・
規
格
適
合
性
の
）確
認

Certificate, Conformance Test

WalletLayer

セキュリティ

相互運用性

224

3-4-2. SSI/DIDの課題 - （１）技術面での課題【参考】実現方式に伴う技術的課題の対象仕様
 標準化団体によってレイヤーの実現方式は異なる。既存方式の活用・展開における課題と、新規方式検討における課題の両面から技術的課題への対策検討が必要となる。
 実現方式は下記組み合わせに限定されるものではなく、各標準化団体においても各スタックに対する実現方式の組み換えに関する議論が行われている（例えば3-2節で述べたOIDF/DIFリエゾン協定等）
モデル

レイヤー

Claim Presentation Layer

OIDC
OpenID Connect

WalletLayer

Local Storage
WebAppTransport/
Communication Layer

OpenID Connect

JWT（JSON-LD, ZKP表現方式としても対応）

Claim Issuance Layer

DID/VCOIDC4IDA
Claims Aggregation

ベンダ実装依存

REST
http(s)OIDC SIOP

VC Data Model(VC / VP / ZKP)

ベンダ実装依存

REST
http(s)OIDC SIOP: Present
Presentation Exchange AriesProofVP Request Spec
Protocol 1.0
VC Data Model(VC / VP / ZKP)

Aries：Issue
Credential
Protocol 2.0

Confidential
Storage
ベンダ実装依存

ベンダ実装
依存
Aries :DID Exchange
Protocol 1.0

DID Comm/
CHAPI

NFC/BLE/QR/http(s)Discovery Layer

OIDC Discovery
WebFinger.well-known

OIDC Discovery
WebFinger.well-known

DID Resolution

Utility Layer

DNS/Domain

DNS/Domain

DIDs

225

3-4-2. SSI/DIDの課題 - （１）技術面での課題

クレームに対するバリデーション/ベリフィケーション/透明性の確保
 SSI/DIDはクレームに対し、1. 有効状態（失効されていない）かを確認するバリデーション、2. 改ざんされていないかを検証するベリフィケーション、3. 生成時に準拠したトラストフレームワークが確認できる透明性、の確保が重要となる。
1.

ブロックチェーン等の分散リポジトリ上にクレームの失効情報を展開し、RP側で参照する、といった実現方式が考えられる。
一方で、CRL*で用いられている有効期限切れの情報は排除される等サイズ肥大化への対処措置を、ブロックチェーンの様にImmutableな特性を持つ方式で実現する場合は、実装面での考慮が必要となる。 *) CRL: Certificate Revocation List (RFC5280)

2.

クレームに対し、CPが署名を実施、RPが署名検証を行うことでの実現方式が考えられる。

3.

クレーム自体に、生成時にCPが準拠した法的要求事項、トラストフレームワーク、商業的合意等を記載し、RPが内容を確認可能とする ”OpenID Connect for Identity Assurance” プロトコル等、透明性を持つ仕様活用による実現方式が検討されている。
分散リポジトリへのValidation実施
CP

HolderOIDC4IDAを用いたクレームのベリフィケーション・透明性の確保

RP

3. CP側で準拠した
トラストフレームワークを記載
1.Validationの実行出所） decentralized-id.com資料を基に作成

2. CPが付与した電子署名
で完全性を検証出所）OpenID Foundation “eKYC & Identity Assurance WG”

226

3-4-2. SSI/DIDの課題 - （１）技術面での課題

ウォレットアプリケーションの信頼性の担保
 アプリの信頼性確保（保証）には、保証の起点となりうるトラストアンカーからの認証パスチェーン確保が必要となる。
想定されるトラストアンカー候補として、例えば以下の表の3つの手法が想定される。
 エコシステムとしての提供を考慮すると、#1.デバイス内の下位レイヤーからの認証パスチェーン構築が望ましい。
他方、同仕様の実現には、ハードウェアやOSベンダー等のプラットフォーマーの協力が不可欠となる。
ウォレットアプリケーションの信頼性の担保
母艦
アプリ

#3.

OS

ウォレット
アプリ

#2.

[ 凡例 ]

トラストアンカー

第三者
機関

認証パス

TEE
#1.
Hardware

デバイス

#

手法

概要

課題

1.

デバイス内の下位レイヤーからの認証パスチェーン構築

OS/TEEなどセキュアエレメント内に格納された署名鍵を使って処理結果への署名・署名検証を実施し、下位レイヤーからのトラストを構築• 特定モデル/製品への依存が発生• ポータビリティ確保が困難• HW/OSベンダーの協力が不可欠

2.

第三者機関による評価プログラムを通じた評価

iOSのApp Store、AndroidのGoogle Play Store等の第三者機関がアプリを確認• 第三者機関の検証プログラムに依存• 別チャネルからの取得によるバイパスが可能• 第三者機関の意向によるウォレットアプリ排除

3.

母艦アプリ等からの呼出し（Deeplink等）

ウォレットをミニアプリとして、信頼された母艦アプリから呼び出す• 母艦アプリのプリインストールが必要（事後導入の場合、#2.と同様の考慮が必要）

出所）奥田哲矢『Confidential Computingの技術動向～TEE/Enclaveの便利な活用例～』
https://www.jnsa.org/seminar/pki-day/2021/data/0415okuda.pdf を基にNRI作成

227

3-4-2. SSI/DIDの課題 - （１）技術面での課題

Universal Resolverの追跡性や透明性、トラストアンカーの担保
 SSI/DIDのUniversal Resolverのトラストアンカーの担保と、追跡性や透明性の確保が課題となりうる。
 DNSのルートサーバからのDNS解決と同様なResolverのトラストアンカーの担保を行う方法の議論が起こりうる。
• エコシステムとしての可用性維持や信頼性担保への考慮が必要。
• グローバルにおける一意性を担保する等の要件を想定した場合、その類似性から
例えばICANNにおけるドメイン取得時の管理等と同等の運用・管理要件が想起される。

DNSの解決（Resolve）概観

・・・

Universal Resolverの概観

13のルートサーバ

example.comのIPアドレスは？

DNSリゾルバ（Resolver）
example.comは93.184.216.34です

ルートサーバが、下位DNSリゾルバ（Resolver）のトラストアンカーとして振る舞う出所）NRI作成

SovrinのDIDは
did:sovです

SovrinのDIDは？

Universal Resolverがトラストアンカーとして振る舞う必要がある
出所）https://medium.com/decentralized-identity/a-universal-resolver-for-self-sovereign-identifiers-48e6b4a5cc3c

228

3-4-2. SSI/DIDの課題 - （１）技術面での課題

アイデンティファイア生成におけるスキーマのAuthority Model Authority ModelとSSI思想との相反（ Subjective consensus ）が起こりうる。
 既存のIdPによるアイデンティティ生成時においては、複数のAuthority Modelが存在する。
 SSI/DIDで自己主権となった場合においても、どこまでレジストリに権限を持たせるか・統制を効かせるかの考慮が必要となりうる。
Identifier のレジストリモデル
種類

#

なし

なし

チェイン
ロジック
利用有無

あり

①
②

あり

レジストリ
初期段階

③

identifier
発行とレジストリが同じタイミング（信頼度高)④

初期登録不要特定の状況下のみでアイデンティファイア
を台帳に登録Subject（主体）

自己登録で、Issuerが発行した
クレデンシャルを受け取るエンティティである
Subjectがレジストリを管理

Curation market③～⑤は参加者による許可の
実装管理の度合いにより変動しうる• Curation market：レジストリの判断を参加者が投票で決める• DAO：単一ではないエンティティがチェーン上のレジストリとロジックを用いて管理する自己持続可能な組織型構成• Consortium：政府、企業、個人（自身）以外のエンティティがレジストリの判断を担う

DAO（Decentralized Autonomous
Organization）（分散自律団体）

Consortium（共同事業体）⑤

初期登録 Subject キュレーション
不要
主体による マーケット

①

②

③

DAO

④

コンソー
シアム

⑤

中央主権

⑥

一般的な
Block
chain

⑦

⑥
⑦

特徴

中央主権

単一ないし一体化したエンティティがレジストリを管理

一般的なブロックチェーン（チェインロジックなし）

チェインロジック（例：スマートコントラクト）のない一般的なブロックチェーンを使ったアイデンティティ登録出所） NIST “A Taxonomic Approach to Understanding Emerging Blockchain Identity Management Systems”

229

3-4-2. SSI/DIDの課題 - （１）技術面での課題

フォーマット、スキーマ、プロパティ等の共通化・統一化
 フォーマット、スキーマ、プロパティ等の統一化がなされていない状態だと、データ連携時における個別スキーマの参照や独自のパース処理実装等、開発が非効率となるため、極力仕様の共通化・統一化が進むことが望ましい。
 共通化・統一化に際しては、標準技術仕様としての策定範囲と、業界・業種等ユースケースに応じた関連団体等で定める範囲との、境界を意識した策定範囲の議論が必要となる。

 OpenID Connectや金融API等ではフォーマットの統一とスキーマが共通されることで、データの受け渡しを容易化。
 OpenID Connectにおけるクレームのやり取りで広く用いられるJWT（JSON Web Token）は、 RFC7519として策定されてスキーマとしてアイデンティティインフォメーションの各種データや扱い方法のフォーマットを定め、相互運用性を保っている。
 日本でも『電子マネー分野のオープンAPIに係る電文仕様標準』が策定され、接続事業者によるデータ利用を推進している。
個別フォーマット・スキーマ等が定義された状態でのデータ連携
個別定義

個別定義

Identity
Provider A
個別定義

Identity
Provider C

Relying
Party a

金融事業者 A

Relying
Party b

金融事業者 B

データ

IT事業者
統一的な
電文仕様

個別定義

Relying
Party c

スキーマ、フォーマット、プロパティ、パラメータ等が異なるとデータ授受のための開発が非効率（個別開発が発生）
出所）NRI作成

電子マネー業者

個別定義

Identity
Provider B
個別定義

統一フォーマット・スキーマ等が定義された状態でのデータ連携

金融事業者 C

API接続先企業
電文仕様を統一することでデータ授受における仕様を標準化
230

3-4-2. SSI/DIDの課題 - （１）技術面での課題

モデル間・メソッド間における相互運用性への考慮
 クレーム連携では、異なるモデル間での相互運用性（External Interoperability）、あるいは共にSSIモデルであっても利用しているメソッド間での相互運用性（Internal Interoperability）への考慮が必要。
 既存事業者のインターフェースにおいてフェデレーションモデルのSSI/DIDの相互運用性が考慮する場合、SSI/DIDへの対応が追加投資となりうる。
 SSI/DIDではDIDメソッドごとにDIDスキーム、DIDsとDIDドキュメントの生成・リゾルブ・更新・無効化の方法が定められており、スキームや方法が異なる場合には連携処理が困難となる。

 SSIモデルとフェデレーションモデルの互換性を持つためには、Gateway機能を持ったモジュールによるスイッチング等の変換処理の考慮が必要となる。他方、SSIモデルは多数の仕様策定が進んでおり、対応するメソッド数によっては、スイッチング機能開発や運用コストが膨大となる懸念がある。
総合運用性の考慮対象例

モデルのスイッチング事例イメージ

External
Interoperability[ 凡例 ]

SSIモデルOpenID Connect Based
Verifiable Credential Based

フェデレーションモデル

2WAY SWITCH
ID Provider

DID Method A(OIDCからVCへ)

DID Method B

Internal
Interoperability

Data Model

Data Model

WalletWalletTransport / Comm

Transport / Comm

Utility

UtilityTransform

RepackageOIDC
ID Assurance

Record ofTransformation

Issuer /Wallets

Transform(VCからOIDCへ)

Repackage出所） OIX Quarterly Workshop - 15th Dec 2020を基にNRI作成

VC

231

3-4-2. SSI/DIDの課題 - （１）技術面での課題

DIDの認定や規格適合性
 既存の標準技術での取り組み同様に、標準化推進の為の施策として、相互運用性や仕様充足性等、透明性を具備し実装負荷を抑える認定制度や規格適合性テストの提供の考慮が望ましい。
 標準の認定と規格適合性確認の事例• 1章で紹介したFIDOのUAF、U2F、FIDO２は適合性、相互運用性、セキュリティ機能をFIDO Allianceによって認定するプログラムが提供されている。また、認定プログラムの一環として自己評価を行うテストツールが提供されており、実装が仕様に準拠していることを確認できる。認定プログラムによって、例えばFIDO2認定サーバは異なるベンダーによって製造されて認定された任意のFIDO2認証器を用いられるようになる等、相互運用性が担保されている。
• OpenID Foundationによって策定されているOpenID ConnectやFAPI（Financial-grade API）についても、実装での相互運用性の担保のために規格適合性テストの提供と認定プログラムの実施がなされている。規格適合性テストではHTTPのリクエストやレスポンス、サーバ設定や鍵の確認等、仕様に照らし合わせて動作を検査する。
OpenID Foundationから提供されている規格適合性テストイメージ出所）OpenID Foundation “OpenID Foundation conformance suite” https://www.certification.openid.net/

232

3-4-2. SSI/DIDの課題 - （１）技術面での課題

Cryptographic Agilityへの考慮
 一般的にアルゴリズムは経時で危殆化のリスクが高まる。危殆化時には、電子署名や暗号化を施された情報に対する改ざんやなりすましの脅威を招くため、長期のクレーム利用を想定したユースケースでは、アルゴリズム危殆化を想定し、安全なアルゴリズムへの移行に対する考慮を要する。
 3-1-2項で述べた「長期のデジタルアイデンティティの保管・利用」実現には、クレームプロバイダーが存在しない状況も考慮した仕組みが必要となる。
Cryptographic Agilityの考慮対象②
クレーム
プロバイダー

③

②
ウォレット

①

①

リライング
パーティ

分散リポジトリ（e.g., ブロックチェーン）①通信経路（対向認証・経路暗号）②クレーム③クレーム検証のための情報（eg, DID、DID Doc等）

 3-2節で述べた処理フローを踏まえると、少なくとも①対向認証・経路暗号、②クレーム、③クレーム検証に必要な情報、の3か所において、用いられるアルゴリズムに対する危殆化への考慮が必要。

 ①は動的な要求に基づく処理であり、移行対応の主体である
クレームプロバイダー・ホルダー・リライングパーティが存在する前提
での、当事者の対応（新しい暗号アルゴリズムへの切り替え
等）を整理する必要がある。
 一方で、②・③は、過去生成された情報も対象となる。危殆化の対応主体エンティティの一つであるクレームプロバイダーが既に存在しない可能性を考慮した対処が必要となる。
例えば③では、パブリックブロックチェーン向けの手法として、
ハッシュアルゴリズムが危殆化した場合でも、信頼できる第三者機関が存在せずとも対応可能な手法が提唱されている(新規アルゴリズムで新ブロックを生成し、危殆化したアルゴリズ
ムを用いて過去に生成されたブロックの有効性を、拡張する*)

出所）Long-term public blockchain: Resilience against Compromise of Underlying Cryptography – Masashi Sato, Shin’ichiro Matsuo

233

3-4-2. SSI/DIDの課題 - （１）技術面での課題【参考】ハッシュアルゴリズム危殆化時の移行方式（Blockchain方式・長期署名方式）
 ブロックチェーンを用いる場合、ハッシュアルゴリズムの危殆化が発生した場合でも、新しいハッシュアルゴリズムを用いたブロックの生成を行う（Hash(n)）ことで、過去のブロックの真正性を含めた形での証明が可能となる。
 DID実現時には、ブロックチェーンだけでなく、長期署名方式を用いた分散リポジトリ等における実装も想定される。
長期署名方式では、新しいハッシュアルゴリズムを用いて再アーカイビングを行う方法が規定されている。一方で、同方式においては、公開鍵証明書の有効期限や、失効情報リスト（CRL）の発行時間等を鑑み、正確な時刻情報が必要となる点について留意が必要である。
Blockchainにおけるアルゴリズム移行方式

Block:
0
Hash
func
(b0)

Block:
1
Tx(DID・
DID Doc)

Block:nHashfunc(b(n-1))

Tx(DID・
DID Doc)

更新前ハッシュアルゴリズムを用いたチェーンブロック

Block:
n+1
Hash
func
(b(n))

Tx(DID・
DID Doc)

更新後ハッシュアルゴリズムを用いたチェーンブロック

長期署名方式（CAdESの例）

ES-T
ES
対象 署名
署名
文書 属性

ES-C

ES-X-L

ES-A

ES-A

アーカイブ アーカイブ
タイム
タイム
検証情報* 検証
STS リファレンス 情報* スタンプ スタンプ
（旧alg）（新alg）検証に必要な情報として、
タイムスタンプ情報も含まれる

出所）Long-term public blockchain: Resilience against Compromise of Underlying Cryptography – Masashi Sato, Shin’ichiro Matsuo元にNRI作成
RFC5126 - CMS Advanced Electronic Signatures (CAdES)’ 元にNRI作成

234

3-4-2. SSI/DIDの課題 - （１）技術面での課題

形式検証によるセキュリティの担保
 プロトコル仕様策定は非常に複雑な作業であり、数学的な証明等を用いた脆弱性検知の手法によるサポートも期待されている。形式検証（Formal Verification）は、与えられた脅威モデルの中で多様な攻撃の可能性のあるシナリオに対する脆弱性の検出を行う手法であり、ISO/IEC9798 における脆弱性検出や、 Financial-Grade
API評価など、多様なシーンにおいて利用実績のある手法である。
 現在仕様策定中のSSI/DIDの関連プロトコルについても、将来的な適用・検証が期待される。
ISO/IEC 9798に対する形式検証適合と検出脅威例
検証対象のISO/IEC 9798 Series• ISO/IEC 9798-1:2010• ISO/IEC 9798-2:2008• ISO/IEC 9798-3:1998• ISO/IEC 9798-4:1999• ISO/IEC 97982:2008/Cor 1:2010• ISO/IEC 97983:1998/Cor 1:2009• ISO/IEC 97983:1998/Amd 1:2010• ISO/IEC 97984:1999/Cor 1:2009

形式検証の概要とFAPIにおける検証事例

ISO/IEC 9798で言及されている考慮すべき
Thread Model
1. Man-in-the-middle attacks
2. Replay attacks
3. Reflection attacks
4. Forced delay attacks

形式検証を適合検出した脅威対策
1. Role-mixup attacks
2. Type flaw attacks
3. Reflection attacks

1. Tagging
2. Removing ambiguityof optional fields
3. Explicitly stating
assumptions on Spec• ISO/IEC 9798シリーズに対し仕様内で言及されたThread Modelを踏まえ検証。 • 検証対象となるモデルを定義の上、Attackerモデルを定義し、検証を実施。
• Role-mixup attacks、Type flaw attacks、Reflection attacksの懸念を抽出。 • Read / Read-Write 両Profileに対し形式手法を展開。
• Attackerモデルとして、Readでは認可リクエスト/認可レスポンス漏洩、併せて、暗号化される保護対象へのタグ付けやOption Fieldの曖昧さ排除、
Read-Writeでは攻撃者によるトークンエンドポイント制御/AT漏洩を定義。
前提条件の明文化など、解決のためのfixを提示。
出所）Evaluation of ISO/IEC 9798 Protocols Version 2.0 David Basin and Cas Cremers April 7, 2011
Formal Security Analysis of the OpenID Financial-grade API - Daniel Fett, Pedram Hosseyni, Ralf Küsters 2019-03-20

235

3-4-2. SSI/DIDの課題 - （２）非技術面での課題

SSI/DIDの非技術面での課題
 SSI/DIDの非技術面での課題として、以下の観点が考えられる
項目

観点

概要

1)法的/制度上の課題

政府および政策立
案者の関与

•
•

プライバシー保護••2)運用上の課題

3)ビジネス上の課題

SSIに対応した国民ID文書の提供を技術的・法的枠組みにも対応できるよう、制度上の課題に対応する必要がある。
例えば、SSI/DIDに対応した電子署名や電子取引の規制、および電子文書などの検証可能な証明書として位置づける等。
SSIを推進・指示する人々のデータ、権利、プライバシーを保護するためのデータ保護規制に向けた既存制度の見直しや必要に応じて改定が必要。例えば、ウォレット操作のための秘密鍵を保護する権利を検討する等。
SSI/DIDに分散型台帳やブロックチェーンネットワークを利用する場合、個人/機密データが分散台帳に登録されてしまう危険性がある。必要に応じて規制の見直しや、利用する際の運用ガイドライン等の策定が求められる。

トラストフレームワーク•

欧州連合の eIDASのような適格ID プロバイダーの認証を確立するために、国や地域の公的および民間のフレー
ムワークを開発することが必要である。

ライアビリティ•

SSIモデルでは、ウォレットを制御するユーザ自身がIdPとして振る舞うことで、従来であれば国・企業・組織等が果たすべき責務を一義的にはユーザ自身が果たす必要が生じる。このためユーザへの支援が重要となるが、誰がどの様に担うのか、またその責務や責任分界点、また有事の際の扱い等の想定が不明瞭。

現行のIT/デジタルシ
ステムの適応•SSI/DIDを利用可能とする、クレデンシャルの発行や検証を可能にするために、現在のITシステムの移行や新規システム構築が必要となる場合があるが、現状その投資に見合う利用が見込まれていない場合が多い。

個人の導入/ユース
ケースの検討•現状SSI/DIDは広く普及しておらず、企業や政府が継続して個人に対して使いやすいソリューションを提案することが必要。

236

3-4-2. SSI/DIDの課題 - （２）非技術面での課題

１）法的/制度上の課題の課題詳細と取り組み事例・得られた示唆
 各課題の詳細および課題解決にあたり参考となる取組事例は以下の通り。
カテゴリ
課題
課題詳細
参考となる取り組み事例
１)法的/ ・政府および政策 • SSI/DIDに対応したナショナルIDの提供を法的 • EUでは欧州委員会がEBP(European Blockchain
制度上の 立案者の関与に対応できるよう、制度上の課題に対応する。
Partnership)と共同で取り組むEBSI(European
課題• 例えば、SSI/DIDに対応した電子署名や電子
Blockchain Service Infrastructure)イニシアティブにお取引の規制、および電子文書などの検証可
いて、欧州SSIフレームワークであるESSIF*1)(European
能な証明書として位置づける等の検討が必要 Self-sovereign Identity Framework)の検討が進めらではないか。
れており、eIDASへの適合を目的としてeIDAS Bridge*2)の策定等が行われている。
・プライバシー保護 • SSIを推進・指示する人々のデータ、権利、プラ • ブロックチェーン関連事業を積極的に後押しする州の一
イバシーを保護するためのデータ保護規制に向つとして有名な米国ワイオミング州は、ブロックチェーン関けた既存制度の見直しや必要に応じて改定が 連の法律をいくつも制定しているが、この中で、「デジタル必要。
アセットに関する法律」（Section 34-29）への追加条• 例えば、ウォレット操作のための秘密鍵を保護
文(34-29-107)として、「秘密鍵の開示」時の条件を限する権利を検討する等。
定する追加条文案が提案され、個人の「秘密鍵」を守• SSI/DIDに分散型台帳やブロックチェーンネット
る権利の保護強化を目指す動きとして注目を集めた。
ワークを利用する場合、個人/機密データが分 • SovrinはGDPRを想定したデータ保護法に準拠するため
散台帳に登録されてしまう危険性がある。必のリーガルフレームワークにおける主要なアクターの役割と要に応じて規制の見直しや、利用する際の運して、Sovrin Legerへの書き込みを行うTransaction
用ガイドライン等の策定が求められる。
Authorsに関し、Permissioned Write Access polices
では法人のみが書き込み可能とし、個人は書き込みをできないようにする旨ガバナンスフレームワークに規定している。
*1) European Commission, https://ec.europa.eu/cefdigital/wiki/pages/viewpage.action?pageId=262505734*2) European Commission, https://joinup.ec.europa.eu/collection/ssi-eidas-bridge/about237

3-4-2. SSI/DIDの課題 - （２）非技術面での課題【参考】政府および政策立案者の関与：EUにおける取組事例
 法的/制度上の課題のうち、現在国内外で最も検討・議論が進んでいる問題の一つが、SSI/DIDに対応した電子
署名や電子取引の規制、および電子文書などの検証可能な証明書として位置づけるための検討。
 例えばEUでは、SSI/DIDとeIDASの接合に向けた検討が欧州委員会で進められている。
• eIDASでは、電子署名を含むトラストサービスとeIDの法的効力を承認するもので、eIDの認証結果をEU加盟
国各国で受け入れあうことができるため、SSI/DIDが本eIDASに適用されるかが論点となっている。
• 本点については、eIDASをSSIエコシステムのトラストフレームワークと位置付ける、eIDAS Bridge*1) や、欧州
SSIフレームワークであるEBSI ESSIF*2) といった取組の中で具体的に検討されているところである。
事例：eIDAS Bridge• 欧州委員会は、eIDASをSSIエコシステムのトラストフレームワークとして利用可能にするために、eIDAS Bridgeを開発。
• eIDAS Bridgeは、イシュアのVerifiable credentialへの署名プロセスを支援し、ベリファイアのクレデンシャルのベリフィケーションプロセスにおけるイシュアのDIDの背後にいるイシュア（本プロジェクトでは法人を対象）の特定を支援する。eIDAS Bridgeを「渡る」ことにより、 Verifiable credentialのトラストが証明される仕組み。

*1) eIDAS Bridge詳細 https://joinup.ec.europa.eu/collection/ssi-eidas-bridge/about*2) ESSIF詳細 https://ec.europa.eu/cefdigital/wiki/pages/viewpage.action?pageId=262505360

238

3-4-2. SSI/DIDの課題 - （２）非技術面での課題【参考】プライバシー保護：米国ワイオミング州の法案
 SSI/DIDについての注目が高まってきているのは、各国のデータ保護法制度が強化され、組織における個人データ管理の重要性が高まっていることが要因の一つに挙げられる。SSI/DIDを推進していくにあたっては、このような思想やアーキテクチャの推進を後押しする制度が必要となる。
 例えば、SSI/DIDにおいては、ウォレットの操作を可能とする秘密鍵を保護することが最も重要となり、これが不必要に開示、提示されてしまった場合、個人データ漏えいと同様の人権被害を及ぼすこととなる。このような観点から法的・制度上の見直しの必要性等についての検討も必要となる可能性がある。
事例：米国ワイオミング州の法案• 米国ワイオミング州はブロックチェーン関連事業を積極的に後押しする州の一つとして有名で、ブロックチェーン関連の法律をいくつも制定している。
• この中で、デジタルアセットに関する法律（Section 34-29）への追加条文(34-29-107)として、「秘密鍵の開示」に関する条文案が示され、個人の「秘密鍵」を守る権利を保障するものとして注目を集めている。
• 本法案は、2021年4月に否決されているが、秘密鍵を守る権利を保障する同様な法案は今後も世界各国で検討されることが想定される。

「秘密鍵の開示(Disclosure of private cryptographic keys)」34-29-107. 秘密鍵の作成、禁止（Production of private keys; prohibition.）
何人も、公開鍵がデジタル資産、その他の利益または権利に関して必要な情報を利用できないまたは開示できない場合を除き、秘密鍵がアクセスを提供するデジタル資産、その他の利益または権利に関連する本州の民事、行政、立法またはその他の手続きにおいて、秘密鍵を提示したり、秘密鍵を他の者に知らせたりすることを強制されない。本項は、秘密鍵がアクセスを提供するデジタル資産、その他の利益
または権利を提示または開示すること、またはデジタル資産、その他の利益または権利に関する情報を開示することを強制する合法的な手続きを禁止するものとは解釈されないものとする。
出所）法案をもとにNRI訳。
https://legiscan.com/WY/text/SF0105/2021

239

3-4-2. SSI/DIDの課題 - （２）非技術面での課題【参考】プライバシー保護：Sovrin財団の取組
 SSI は既存の多くのプライバシー問題を解決することができるものとして注目されている。例えば、代表的なものとしては、EUの一般
個人データ保護規則（GDPR）の第17条で規定される忘れられる権利等への対応等に関しては、SSI/DIDにより個人はデジタル
情報にリンクされた自分の情報をコントロールすることができるため、ユーザにとっても、また不必要な個人データの管理が不要となる
データ管理者にとっても有益なソリューションとなる可能性がある。
 しかしながら、SSI/DIDにブロックチェーンが使用される場合は、個人データやPIIの台帳への登録を確実に回避することが必要となる。
この点に関して、今後SSI/DIDのユースケース等に応じてよい明確化、具体化していくことが必要であると想定される。
事例：Sovrin財団の取組•

Sovrinは、GDPRを想定したデータ保護法に準拠するためのリーガルフレームワークにおける主要なアクターの役割を右図のように整理している。この中で、Sovrin Legerへの書き込みを行うTransaction Authorsに関し、現状Permissioned
Write Access policesでは、法人のみが書き込め、個人は書き込みできない。Sovrin この理由の一つに、以下を挙げている。
“これにより、個人データがSovrin Ledgerに書き込まれるリ
スクが軽減される。これは現在、 Permissioned Write
Access policesで禁止されているためである。Sovrin財団
は、不変的な公開台帳上の個人データに関する現在の規制の不確実性の下で、この保護が必要であると考える。”

出所） https://sovrin.org/data-protection/240

3-4-2. SSI/DIDの課題 - （２）非技術面での課題

２)運用上の課題の課題詳細と取り組み事例・得られた示唆
カテゴリ課題２)運用 ・トラストフ 運用制度上の課題 レームワー
ク

課題詳細
参考となる取り組み事例• 欧州連合の eIDASのような適格 IdPの認証を• 例えば、欧州委員会によって、SSIの技術仕様確立するために、国や地域の公的および民間のフに対し法的観点から適合性を評価し現行規レームワークを開発することが必要である。
則の改正等の必要性に言及した「SSI eIDAS
Legal Report」が発行されている。*1)

運用スキー • トラストフレームワークの構築・管理・更新を維持・ • OIXやDIACCなどの団体が策定しているトラス
ムの整理
継続していく必要がある。
トフレームワークは、非営利組織として官民のス• 誰が同活動に対し責任を負うか（公的/民間）、 テークホルダーが集まって構築されており、一定コスト負担やインセンティブ設計への考慮も必要。
の運用スキームや運用業務遂行に向けた体制は整備されている。ただし、課題詳述に挙げた運用業務 • TFは一度作成して完了するものではなく、その枠統制機能などの一部はまだ議論・策定段階のの遂行
組みを継続的に維持・活用する必要がある。
ものもある。
• TFの維持・活用に際し必要な統制機能として、• SSI/DID以外の分野では、例えば、参加事業
下記点が挙げられる。
者でコンソーシアムを形成するCA/Browser• 参画団体の管理・認定
Forum*1)では、電子証明書を使った通信の安• 策定ポリシーの執行
全性・利便性向上のためのガイドライン策定を• フレームワークの運用行っている。
• 他TFとの相互運用性確立
同フォーラムには主要なWebブラウザー開発ベ
ンダーも参加しており、過去EV SSL証明書のガイドライン策定なども行っている。各社は同フォーラムでの議論を踏まえ、自社のブラウザ仕様実装の検討を行う一方、上述の協調領域
における議論は統一的な仕様を策定・実装することで、相互運用性を確保している。
*1) European Commision - SSI eIDAS Legal Report : https://joinup.ec.europa.eu/sites/default/files/document/2020-04/SSI_eIDAS_legal_report_final_0.pdf

2413-4-2. SSI/DIDの課題 - （２）非技術面での課題

２)運用上の課題の課題詳細と取り組み事例・得られた示唆
カテゴリ課題２)運用 ・ライアビリ 責任分界点
上の課題 ティ

課題詳細
参考となる取り組み事例• SSIモデルでは、ウォレットを制御するユーザ自身が • OIXではトラストフレームワークの中で、SSIモ
IdPとして振る舞うことで、従来であれば国・企業・デルへの対応についても触れており、本課題
組織等が果たすべき責務を一義的にはユーザ自身 についても論点となっている。また、DIACCでが果たす必要が生じる。このためユーザへの支援がは、DIDのPCTFへの準拠の考え方について重要となるが、誰がどの様に担うのか、またその責のガイドラインが公表され、この中で本点へ務や責任分界点、また有事の際の扱い等の想定の対応が課題である点についても触れられが不明瞭。
ている。いずれも課題としては認識されてい• ステークホルダーの適切な参集がなされていない場
るが、具体的な解決案などは議論中の課合、本来考慮すべき担務の欠如や責任分界点が題となっている。
あいまいとなる懸念がある。

ユーザの保護・ • ユーザ自身のITリテラシーも様々であり、社会インフ • OIX Trust frameworkモデルでは、ウォレッ
支援
ラとしての金融においては、利用者包摂を意識した
トがIssuerとしてもVerifierとしても機能する仕組み作りが期待される。
ことを想定しており、AML向けのEvidence• 例えば、の提示等、ウォレットが監査対応という役割
ートラストフレームワークに求める要件を準拠し、認を担うことを想定している。
定を受けた利用者に使いやすいソリューション • 同モデルの検討においては、実ユースケースに提供が可能な事業者のみ参画可能とする
おける上記役割の担い手として、ウォレット
ー自身での管理が困難なユーザについては権限委 ベンダー、3rd Partyのサービス提供者等の想任等による代行の仕組みを検討する定があり得るのではないか、という議論も出といった、包摂やデジタルディバイドを意識した制度ている。
設計が期待される。
開発・運用コス • 金融サービス全体でのオンボーディングコスト抑制に • SecurekeyのVerifie.Meでは、金融機関もト負担寄与する一方、誰がどのようなソリューション開発・共同で出資してVerified.Meを構築するモ
運用コストの負担を担うかの整理が必要となる。
デルを採用している。
242

3-4-2. SSI/DIDの課題 - （２）非技術面での課題【参考】ライアビリティ：OIXのトラストフレームワーク
 SSI/DIDの運用上/ビジネス上の課題の中でもSSI/DID特有の課題として指摘されているが、ライアビリティの問題である。すなわち、
SSIモデルに基づくサービスでは、何か問題が生じた場合の責任分界に関する整理が現時点では不透明である。
• 従前の集中型・Federation型のIMSモデルでは、ライアビリティの問題については、IdP/RP間で直接調整・交渉を行うことで整理することとがるが、SSIモデルでは、ウォレットを制御するユーザ自身がIdPとして振る舞うため、従来のIdPである国や企業・組織等が果たしている責務等をユーザ自身が果たす必要が生じることとなる。
• 実際には、全てのユーザ自身にその調整を期待するのは不可能であり、金融包摂の観点からも何らかの支援が必要となるが、その支援を、誰がどの様に担うのか、またその責務や責任分界点、また有事の際の扱い等の想定が不明瞭である。本課題を解決しない限り、ユーザは安心してSSIモデルのサービスを利用せず、またRPも責任が不明瞭なサービスを提供しないため、本問題の解決の方向性を考えることが、運用上/ビジネス上重要となる。
事例：OIXのトラストフレームワーク• OIXはこのような課題を解決するための一つのツールとして、トラストフレームワークの作成・活用を提唱しており、トラストフレームワーク
を有効に活用・運用するために以下の機能を指摘する。
項目

概要

ガバナンスとポリシー策定• トラストフレームワークのルール策定と修正、意志決定、利害関係者の協力・調整、基準・手続き管理、説明責任の仕組み作り

ポリシーの実施• 既存ポリシーの遵守の確保、実施メカニズム、評価または監査の実施、変更とリリースの管理

参加団体の管理• 参加事業体の管理と登録、認定とトラストマーク、サポート、紛争解決、請求書発行

ネットワークの発展• ネットワークの成長とサポート、マーケティング、コミュニケーション、戦略の開発

トラストフレームワークの運営• 参加事業体や利用者へのサービス提供出所）OIX,” Guide to Trust framework”

2433-4-2. SSI/DIDの課題 - （２）非技術面での課題

３)ビジネス上の課題の課題詳細と取り組み事例・得られた示唆
カテゴリ
課題
課題詳細
参考となる取り組み事例
３)ビジネ ・現行のIT/デ 既存スキームと • SSI/DIDを利用可能とするために、クレデンシャル • OIX Trust Frameworkでは、両スキーム
ス上の課 ジタルシステム の相互運用の発行や検証を可能にする等、現在のITシステに対応するモデルのスイッチングハブを構題の適応性ムの移行や新規システム構築が必要となる場合成するモデルの構想を行っている。
がある。
但し3-4-2項でも述べた通り、同実装に• 連携先のシステムが一律新規スキーム
は、モデル・メソッド間における相互運用（SSI/DID方式）に移行するとは考えにくく、当性への考慮が重要となる。またスイッチン
面は既存スキーム（Federation方式）との併存 グの対象メソッド実装が収斂せずを意識し両スキームへの対応が必要となる事が予 複数仕様が乱立する場合、同改修の想される。
工数増に繋がることが予想される。
新規投資の発 • 新規スキーム構築のためのコスト負担が発生する。 • SecurekeyのVerifie.Meでは、金融機
生
また、上述の既存スキームとの相互運用性への関は共同で出資してVerified.Meを構考慮が無い場合には、両スキーム独立しての運築するモデルを採用することで、自社単用となり、両系の維持・運用コストが発生する。
独開発と比較してコスト低減を実現。

・ユースケースの開拓• 現状SSI/DIDは広く普及しておらず、企業や政 • Sovrin Foundationにおいても、今後の府が個人に対して使いやすいソリューションを提案 ユースケース開拓の継続必要性が議論さすることが必要となる。
れており、例えば、Covid-19の接種証
明書や医療結果の証明への活用といった医療はじめ、金融・その他分野におけるクレデンシャルの活用拡大を予想している*1)。
• 既にCovid-19関連の事例として、IATAの ”Travel Pass” *2)によるデジタルの形での接種証明書の展開といった具体的な事例も出始めている。
244

3-5. SSI/DID活用時の金融規制上の論点

245

3-5. SSI/DID活用時の金融規制上の論点

金融規制上の論点を検討する上でのSSI/DIDを活用したアイデンティティ管理の前提
 前述のSSI/DIDモデルに金融取引主体を当てはめ、下段のモデルを検討の前提とする。
 なお、顧客から受け取ったクレームを金融機関は保管して利用できる前提とする。
（前述のSSI/DIDモデル（一般論））

Claims Provider

ユーザ

Service Provider

Claim
ウォレット

（金融取引におけるSSI/DIDモデル）

分散リポジトリ（例：ブロックチェーン）[ 凡例 ]
クレームの流れDIDのメタデータに関する書込/取得の流れ

公的機関
2章のユースケース（１－１）口座開設
2章のユースケース（２）継続的顧客確認/取引時確認

顧客

金融機関

金融機関（ID連携元）
Claim
2章のユースケース（１－２）口座開設（ID連携）

他社（金融/他業態）
2章のユースケース（３）他社情報を活用したサービス提供

ウォレット

分散リポジトリ（例：ブロックチェーン）246

3-5. SSI/DID活用時の金融規制上の論点

SSI/DID活用モデルにおける金融規制上の論点の考え方
 従来のデジタルアイデンティティ管理モデルとの大きな相違点は、以下２点である。
相違点１）金融機関へ連携されるクレームが全て顧客のウォレット起点になる
相違点２）金融機関へ連携されるデータが顧客が提示したクレームになる 上記２点に起因して、新たに金融規制の対象とする必要がある点を、論点として以降検討する。
相違点１）についての論点：ウォレットに対する金融規制の考え方 （下図の論点１）
相違点２）についての論点：新たな本人確認情報に対する法的手当て （下図の論点２）
従来のデジタルアイデンティティ管理モデル

SSI/DIDを活用したのデジタルアイデンティティ管理モデル
論点１

2章のユースケース（１－１）口座開設、ユースケース（１－２）口座開設（ID連携）、
ユースケース（２）継続的顧客確認/取引時確認

顧客

公的機関

金融機関

顧客

公的機関

デジタルアイデンティティ
エビデンス（ICチップデータ等）(あるいは一次発行元が公的機関であるクレームを有する民間IdP)

金融機関
クレーム

クレーム

発行

論点２

ウォレット

2章のユースケース（３）他社情報を活用したサービス提供

顧客

他社（金融/他業種）

金融機関

他社（金融/他業種）

クレーム

クレーム

連携指示/承認
他社のアイデンティティ情報

金融機関

顧客
ウォレット

247

3-5. SSI/DID活用時の金融規制上の論点

論点１）Walletに対する金融規制の考え方

検討の前提と方法 （１）ウォレット運用形態のパターン
 ウォレット運用の形態を「データの運用管理主体」と「データの保管環境」の2軸で下図４パターンに分類し、ウォレット運用の形態の違いによる金融規制への影響を検討する。
No.

データの運用管理主体
管理者

処理者

ウォレット運用形態のイメージ

データの保管環境
顧客

自己

１

ローカル

データ処理

個人デバイス
ウォレット
DID

DID

委託先

委託先
（ウォレット
プロバイダ）

２

データ処理委託

ローカル

顧客

個人デバイス
ウォレット
DID

自己
（顧客）
３

データ処理

顧客

自己

DID

クラウド
ウォレット

クラウド

DID

DID

委託先

４

委託先
（ウォレットプロバイ
ダ）

データ処理委託

クラウド

顧客

データ処理

クラウド
ウォレット
DID

DID

248

3-5. SSI/DID活用時の金融規制上の論点

論点１）ウォレットに対する金融規制の考え方

検討の前提と方法 （２）金融規制の実現可能性に関する評価項目
 金融機関へ連携されるクレームが全て顧客のウォレット起点となるため、金融システム安定化のためには、ウォレットから提示されるクレームの安全性や調査・責任追及のルートを確保する必要がある。
 そのため、ウォレットに関して金融規制上問題となる以下3点について評価し、金融規制への影響を検討する。

①

ウォレット運用の信頼性

自身のIDと連携元のClaimのBindingが正しく行われ、顧客当人の正しいクレームが金融機関へ連携できるかどうか②

問題発生時の責任追及・対応

クレームの提示元および最終責任者である顧客に対し、なりすまし等の不正利用時の責任追及や対応を求めることができるかどうか③

金融犯罪捜査時のウォレット内データ開示

金融犯罪捜査時に、金融機関が保管していないウォレット内のデータを捜査当局が調査できるかどうか

249

3-5. SSI/DID活用時の金融規制上の論点

論点１）ウォレットに対する金融規制の考え方

ウォレットに対する規制の実現可能性評価結果
 金融規制上は、現状では委託・クラウド型のウォレット運用形態が望ましいと考えられる。
規制の実現性

ウォレット運用形態のパターン
自
己/
ロー
１
カル

顧客
データ処理

委
託/ データ処理委託
ロー
カル
２
顧客
１
２
３
４

金融規制の実現可能性に関する評価項目

個人デバイス
ウォレット
DID

委託先
データ処理

個人デバイス
ウォレット
DID

自
己/
クラ
３
ウド

顧客

委
託/ データ処理委託
クラ
ウド
顧客
４

DID

①ウォレット運用の信頼性②問題発生時の責任追及・対応③金融犯罪捜査時のウォレット内データ開示

低

困難

困難

(運用信頼性の低さにより、なりすまし等不正利用の観点から懸念)(問題発生時の管理責
任や対応を特に個人に対し求めるのは困難)(金融犯罪捜査時の顧客に対する強制的データ開示は難しい)高可

困難(委託先がデータ処理を行うため、自己運用と比較すると懸念は減少)(委託先にも一定の責任を問う余地はあり、自己運用と比較し安定した運用が期待)(金融犯罪捜査時の顧客に対する強制的データ開示は難しい)

低

困難

可

DID

クラウド
ウォレット
DID

DID

委託先
データ処理

クラウド
ウォレット
DID

DID

(運用信頼性の低さにより、なりすまし等不正利用の観点から懸念)(問題発生時の管理責
任や対応を特に個人に対し求めるのは困難)(クラウドベンダの開示方針によっては、個人デバイスより実現性高)

高

可

可

(委託先がデータ処理を行うため、自己運用と比較すると懸念は減少)(委託先にも一定の責任を問う余地はあり、自己運用と比較し安定した運用が期待)(クラウドベンダの開示方針によっては、個人デバイスより実現性高)250

3-5. SSI/DID活用時の金融規制上の論点

論点１）ウォレットに対する金融規制の考え方（補足）データの保管環境による金融犯罪捜査時等のウォレット内データ開示性の違い
 SSI/DIDの仕組み上、基本的にはウォレットの秘密鍵がないとウォレット内のデータ開示はできない。
 しかし、犯罪捜査等に必要なデータは、顧客が秘密鍵の提供を拒否した場合でも強制的に開示させる必要がある。
 犯罪捜査時等に捜査当局が特別に秘密鍵にアクセスできる必要があるため、ウォレットはローカルデバイス内よりもクラウド上での管理が望ましい。
パターンNo.

1

2

秘密鍵の保管環境

顧客のウォレット以外

ウォレットの保管環境

ー

ローカル

クラウド

不可

困難

可

顧客のウォレット

秘密鍵はいかなる理由があろうと他人に管理させないということが基
本的人権に沿った原則になる。
（海外有識者からも指摘あり）
金融犯罪捜査時等のウォレット内データ開示

3

捜査当局

デバイスの管理主体が顧客自身の クラウドベンダにおける金融犯罪時ため、デバイスの種類や設定によっ のデータ開示の対応方針によっては、ては、犯罪捜査に必要なデータを クラウドベンダ経由でのデータ開示
バックドアから取得しようとしても、ア が期待できる。
クセスできない可能性がある。
捜査当局

個人デバイス1
ウォレット1
秘密鍵

公的機関
秘密鍵

禁止

個人デバイス/クラウド
ウォレット
秘密鍵

データ

データ

個人デバイス2
ウォレット2
秘密鍵

データ

捜査当局

クラウド
ウォレット1

秘密鍵

データ

ウォレット2

秘密鍵

データ

251

3-5. SSI/DID活用時の金融規制上の論点

論点１）ウォレットに対する金融規制の考え方（ご参考） Amazon Web Service（AWS）の法律執行情報リクエストに対する考え方
 AWSでは、法的に有効かつ拘束力のある命令に従うために必要な場合には、政府の要請に応えて必要な顧客情報を開示することとなっている。
 法的に有効かつ拘束力のある命令に従うために必要な場合は、政府の要請に応えて顧客情報を開示する（下図赤線部）
 なお、政府の要請に対しても必要な情報のみを文書で正式に要請された場合のみ開示する意思を示している。（下図青線部）
法律執行情報リクエストに対するAWSの説明ページ*1)*1) https://aws.amazon.com/jp/compliance/amazon-information-requests/252

3-5. SSI/DID活用時の金融規制上の論点

論点１）ウォレットに対する金融規制の考え方

ウォレットに対する金融規制の進め方についての示唆
 金融機関に接続するウォレットを適切に規制する必要があるため、まず規制の難易度が最も低い「委託・クラウド型」に絞って金融利用を可能とするのが現実的と考えられる。
 自己管理・個人デバイスの場合、ウォレットアプリや操作の品質確保、犯罪捜査用バックドア確保の難易度が高いため。

 「委託・クラウド型」の場合、委託先であるウォレットプロバイダ、および、ウォレットプロバイダが利用するクラウドベンダ
を金融規制対象とする必要があると考えられる。
 一定の基準を満たしたウォレットプロバイダのみが金融機関へ接続できるよう、ルール化が必要と考えられる。
• 例えば、ウォレットプロバイダを登録制とし、登録済のウォレットプロバイダへ委託されたクレームのみ、口座開設や金融取引に利用可能とするよう、技術的に制限をかける、など。
 ウォレットデータを保管するクラウドベンダが金融犯罪捜査時のデータ開示請求に対応できるよう、ルール化が必要と考えられる。
• 例えば、ウォレットプロバイダと同様、ウォレットデータを保管するクラウドサービスに対しても登録制とする、など
 また、特定のウォレットプロバイダへの依存を回避するため、ウォレットプロバイダの変更が可能な状態（ポータビリティ）を確保する手当ても必要と考えられる。

 また、問題発生時の責任分界、金融犯罪捜査時のデータ開示請求について、あらかじめ定めておく必要があると考えられる。
 なお、ルールの適用方法については、金融サービスにおけるパブリッククラウドの活用に対するガイドライン適用の事例が参考になると考えられる。 (次頁に概略記載)
 パブリッククラウド活用の場合と異なり、ウォレットの場合は金融機関とウォレットプロバイダの間に契約関係はないものの、
ウォレットプロバイダはビジネス上金融機関と接続する必要があるため、ガイドラインを遵守するインセンティブは働くと考えられる。
253

3-5. SSI/DID活用時の金融規制上の論点

論点１）ウォレットに対する金融規制の考え方（ご参考）金融サービスにおけるパブリッククラウド活用に対するガイドラインの手当
 財団法人金融情報システムセンター （以下、FISC）により金融機関等の自主基準として策定された「金融機関等コンピュータシステムの安全対策基準・解説書」（以下、安全対策基準）をガイドラインとして、金融庁による金融機関の監督、金融機関によるパブリッククラウドサービスの評価、が行われている。
FISC安全管理基準を鑑とした金融サービスにおけるパブリッククラウドサービスの安全性評価

金融庁

財団法人 金融情報システムセンター (FISC)
金融機関等コンピュータシステムの安全対策基準・解説書• 金融庁監督指針において、主要行、中小・地域
金融機関等がシステムリスクならびにセキュリティ対策を検討する上での参考文書として取り上げ
管理

参照

金融機関

クラウド事業者
対応説明• 左記解説書に基づきクラウド事業者を管理• 対応状況をWebサイト等で公開し、安全性を説明

FISC安全対策基準
リファレンス文書*1)*1) アマゾン ウェブ サービス ジャパン株式会社 金融機関向け AWS FISC安全対策基準対応リファレンス
https://d1.awsstatic.com/whitepapers/compliance/JP_Whitepapers/AWS_FISC_Guidelines_9thEdition.pdf

254

3-5. SSI/DID活用時の金融規制上の論点

論点２）新たな本人確認情報に対する法的手当て
 金融機関へ提示する本人確認情報が個人がIdPとなるデジタルアイデンティティの形で行われることとなるため、個人発行のデジタルアイデンティティをどのように法的に認めるか、が課題である。
 なお、デジタルアイデンティティとバインドされるClaimの発行元は、現状の発行元／ID連携元と同様と想定される。
従来のデジタルアイデンティティとSSI/DIDにおける金融機関へ連携されるデータの形態と項目の比較
A）2章のユースケース（１－１）口座開設、ユースケース（２）継続的顧客確認/取引時確認の場合
従来のデジタルアイデン
ティティ
SSI/DID

データの形態

データの項目

デジタルアイデンティティエビデンス（ICチップ内のデータなど）

アイデンティティエビデンス記載全項目

個人の発行したデジタルアイデンティティ（公的機関等のClaim）

必要な項目のみB）2章のユースケース（１－２）口座開設（ID連携）の場合
従来のデジタルアイデン
ティティ
SSI/DID

データの形態

データの項目金融機関（ID連携元）のデジタルアイデンティティ

各金融機関の本人確認用項目（顧客には非公開）

個人の発行したデジタルアイデンティティ（公的機関等と金融機関（ID連携元）のClaim）

各金融機関の本人確認用項目（顧客に公開）
255

補論：フェデレーションモデルを用いたSSI/DID特性の充足可否

256

（補論）フェデレーションモデルを用いたSSI/DID特性の充足可否
 SSIモデルでは、第三者がアイデンティティの管理主体に介在することなく、個人が自分自身のアイデンティティをコントロールできるようにする必要がある。この実現のため、属性に関するコントロール権を確保するため、ユーザ自身がIdPとなる形が考えられる。
 ユーザがIdPとなりクレームの連携を行う場合、どこにIdPの機能をデプロイするかによって、トポロジーの実装は複数考えられる。仮に、「ウォレット」などのローカルマシンにデプロイする場合、フェデレーションモデル* を2つ複合することでの実現アプローチが考えられる。実際、過去に同じトポロジーを持つサービスもデプロイされており、実現可能性が期待された。一方で、そうしたサービスが実際のビジネスにおいて広範に利用されているとは言い難い*) Distributed / Aggregated Claims Modelの導入状況がある。
 本項では、こうした背景を踏まえ、SSIモデルの課題整理に先立ち、まずはフェデレーションモデルにおけるSSI/DIDの充足可否を整理の上、実際のビジネスにおける展開の阻害要因となる課題の整理を行う。
ローカルにIdP機能をデプロイする場合のSSIモデル実現像
CP/Holder間のFederation
CP出所） decentralized-id.comにNRI加筆

Holder/RP間のFederation

HolderRP

257

（補論）フェデレーションモデルを用いたSSI/DID特性の充足可否
 OpenID Connectの仕様を用いトポロジーを変えることで、1. 認証と属性の分離、
2. 分散した属性の活用・選択的な提示、3. 提示先の秘匿（Unlinkability）の実装は可能である。
トポロジーを変えたフェデレーションモデル

一般的なフェデレーションモデル
Identity Provider（& クレームプロバイダー）

ユーザ（e.g., Aggregated / Distributed Claims Model ）リライングパーティ

クレームプロバイダー

Relying
Party

OpenID
ProviderOpenID
Providerユーザ

リライングパーティ

RelyingParty②

Claims③

Relying
Party(Self Issued)
Open ID Provider①

SSI/DIDの特性

OpenID Connectの対応仕様

実装概要

1. 認証と属性の分離

Self-Issued Open Provider（SIOP）

ユーザ自身がIdPとなることで、CP/ホルダー間、ホルダー/RP間でのFederationによるクレーム連携を実施

2. 分散した属性の活用・選択的な提示Aggregated Claims

複数のCP上のクレームを集約

Distributed Claims

ホルダーに収集したクレームから、RPに対し選択的にクレームを提示

3. 提示先の秘匿(Unlinkability)

Self-Issued Open Provider（SIOP）

ユーザ自身がIdPとなりCP/RP間の連携ではなく、ホルダー経由のクレーム連携が可能
258

（補論）フェデレーションモデルを用いたSSI/DID特性の充足可否
 4. 長期のデジタルアイデンティティの保管・利用については、OpenID Connectの仕様策定範囲外となっており、実現する場合には、別途長期署名に関連した仕様等を組み合わせた実装の考慮が必要となる。
 長期署名の規格としては、PKCS#7やCMS 等の署名フォーマットに対応した「CAdES」、XML署名フォーマットに対応した「XAdES」、PDF 署名フォーマットに対応した「PAdES」等があり、また近年では JSON Web Token の署名フォーマットにも対応した、「JAdES」 も ETSI にて規定されている。

OpenID Connectでのクレームの仕様策定範囲

長期署名規格例
長期署名規格対象
フォーマット例

主な規格（Technical Specification）

CAdES（CMS Advanced
Electronic Signatures）

CMS, PKCS#7

ETSI TS 101 733 v2.2.1 (2013-04)
ISO 14533-1:2014

XAdES（CMS Advanced
Electronic Signatures）

XML

ETSI TS 101 903 v1.4.1 (2009-06)
ISO 14533-2:2012

PAdES（PDF Advanced
Electronic Signature）

PDF

ETSI TS 102 778-1/2/3/4/5 (2009-07)
ETSI TS 102 778-3 V1.2.1 (2010-07)
ISO 14533-3:2017
ISO32000-2: 2020

JAdES
（JSON Advanced
Electronic Signature）

JSON

ETSI TS 119 182-1 V1.1.1 (2021-03)

5.7. Claim Stability and UniquenessThe sub (subject) and iss (issuer) Claims, used
together, are the only Claims that an RP can rely
upon as a stable identifier for the End-User, since
the sub Claim MUST be locally unique and neverreassigned within the Issuer for a particular EndUser, as described in Section 2.
（中略）All other Claims carry no such guarantees acrossdifferent issuers in terms of stability over time or
uniqueness across users, and Issuers are
permitted to apply local restrictions and policies.

出所）ETSI, ISO

259

（補論）フェデレーションモデルを用いたSSI/DID実現における課題概観
 前頁で述べた通り、OpenID Connectを踏まえた4つの特性をもつIMSのデプロイ可能性を検討した結果、技術的な実装可能ではないかという仮説を導出した。
 仮説の裏付けとして、サービスとして展開された事例※の調査・確認を行った。機能面での充足は一定確認できたものの、ビジネス面、運営面の両面における課題から、広範に展開されず利用が広まっていない実態が明らかとなった。
両面における課題はOpenID Connectに限らず、本項で述べた通り他のSSIモデル向け実装でも生じ得る課題である。
※）Linksafeによる分散型識別子の取得, neustarによるディレクトリサービス等
フェデレーションモデルでのSSI/DID実現における課題箇所
クレームプロバイダー

ユーザ

リライングパーティ

OpenID
ProviderRelyingParty
Relying
Party(Self Issued)
Open ID Provider

フェデレーションモデルの実サービスにおける課題例
 ビジネス面の主な課題は、データブローカーに代表されるクレームプロバイダー
による、データ提供機会の減少・連携先が秘匿される点に対する反発である。
 データ提供件数に応じた課金請求モデルを採るデータブローカーの立場では、ホルダーにクレームを格納し何度も提示可能となると、自分たちのビジネス機会の損失に繋がる。
 データブローカーは、自身のデータがどこに連携されたかのナレッジを元にデータ提供元等ビジネス機会の拡大を図るが、リライングパーティを秘匿される事で、ニーズの把握が困難となる懸念がある。
 運営面の主な課題は、ホルダーの運用主体を完全にユーザに委ねた場合、の運用・管理能力に対する懸念からクレームプロバイダー/リライングパーテホ
ルダーィからの信用を得られないケースがあり得る。
 同モデルでは、ユーザがホルダーとしての運用・管理責任を負い、自らのクレデンシャルを管理する。

クレームプロバイダーにおけるビジネス機会の損失

ホルダーの運用主体がユーザな点に対する運用面の信頼の不足

 ホルダーの運用・管理能力の不足や責任能力の欠如の懸念がある。特にRecognitionに用いられるDID鍵の運用・管理を行う点を考慮すると、当該能力の欠如への懸念は、提示されるCSPとしての提供サービス（認証）に対するトラスト欠如に繋がり得る。
260

第4章

デジタルアイデンティティ活用に向けた今後の論点

261

４－１．本章の構成

262

４－１．本章の構成

本章の構成
 本章の目的 本章では、第1章から3章で実施した分析を総括して、今後の課題について分析する。
 具体的には、SSI/DIDを含むデジタルアイデンティティの活用にあたってさらに検討を要する分野、つまり今後、規制当局やエンジ
ニア、事業者といった様々なステークホルダー関与の下で議論を進めるにあたっての論点の特定を行う。

 本章の分析方法
 上記の論点の特定について、まずは各章での検討の結果、現状明確な解決の方向性が示されていない論点を特定するとともに、これらの課題について、各ステークホルダーが持っている関心事項（Concern）を整理する（4-2）。

263

４－２．各課題のステークホルダーとその関心事項

2644-2. 各課題のステークホルダーとその関心事項

本節の構成
 本頁以降では、2章、3章で挙げられた各課題に対する課題解決の方向性と、各課題に関するステークホルダーとその関心事項を検討する。
 課題解決の方向性は、2-4節で取り上げた先進事例、3章での議論を参考に整理を行った。
 ステークホルダー／関心事項については、課題解決の方向性に影響を与えるステークホルダー・目的を洗い出し、潜在的な利害関係を整理した。
 結果として、SSI/DIDに関連する課題であるか如何によらず、ステークホルダー間での利害関係を調整する必要があると思われる論点が複数存在し、マルチステークホルダーアプローチによる解決の必要性を示唆する結果となった。
 第2章の課題を4-2-1、第3章の課題を4-2-2で分割して扱い、それぞれ以下の内容を記載する。両者には一部重複する課題（責任分界等）もあるが、ステークホルダーが異なっているため、別に記載した。
4-2-1. デジタルアイデンティティの活用に向けた課題とステークホルダの関心事項
 2章で挙がった課題の解決、および2章で挙がった課題をSSI/DIDで解決する際のステークホルダーおよび関心事項の抽出・整理を行った。

4-2-2. SSI/DIDの活用に向けた課題とステークホルダの関心事項
 SSI/DIDを活用する際のステークホルダー・関心事項の抽出・整理を行った。
265

4-2-1. デジタルアイデンティティの活用に向けた課題とステークホルダの関心事項

１）”IAL”の課題解決の方向性とコンフリクト
カテゴリ
1)
IAL

課題

課題解決の方向性

ステークホルダー・デジタルIMSの適切 • 適切なIALの設定およびIALとリンクした• 金融当局な活用を促す規制 AML規制の整備を行う。整備のアプローチ
フレームワーク整備として、信頼性の高い国民IDを広く活用することを前提とし、それを可能とするAML規• 金融機関制の整備も考えられる。(②・③事例)• また、IAL整備の範囲についても、本人確認に特化せず、AML対応に必要な顧客属• 顧客性の保証レベルまで踏み込む等の対応も考えられる(①事例)。

関心事項• プリンシプルベースで技術革新も取りこんだ対応の促進• 信頼性の高いID活用によるAML高度化• 信頼性の高いID活用によるAML高度化• 自社責任範囲の明確化のためのルール
明確化• 利用できるアイデンティティの選択肢の豊富さ266

4-2-1. デジタルアイデンティティの活用に向けた課題とステークホルダの関心事項

２）”ID連携”の課題解決の方向性とコンフリクト
カテゴリ

課題

課題解決の方向性

ステークホルダー

2)
・ID連携当事者間の • 関係者間協議による、責任分界の明確化 • 金融当局
ID連携 ビジネスモデル・責(⑤事例)
任分界の未整備–デジタルIDを用いたKYC共有化を実現した際、各種チェック等を行う最終責任を明 • 金融機関
（デジタルIDの確化–新規口座開設時や継続的顧客管理実 出し手/受け手）
施時にデータの最新化が求められるため、 • 顧客
その担い手・責任を明確化–データ過誤により顧客もしくはIDを利用し • ソリューション
た金融機関において何らかの損害が発生 ベンダー
した場合の責任分界の明確化
・特定の金融機関• 特定のIdPへの依存度を下げるためには、3 • 金融当局
(IdP)への依存度が 章で取り上げられた通り、SSI/DIDが課題
高まる
解決策の一つと考えられる。
• 大手金融機関• 一方、3章で検討した通り、金融規制の実施においては、SSI/DIDのデータの運用管理
はWalletベンダーに委託、Walletの管理環 • 金融機関
境はクラウドにあるといった、より信頼性のある管理体制の構築が望ましいという側面が • 顧客ある。
• Walletベンダー• クラウドベンダー

関心事項• 規制監督の観点から責任の明確化• ビジネス観点からの自社責任範囲の限定• 不利益を被った際の補償の観点から責任の明確化• ビジネス観点からの自社責任範囲の限定• より信頼性のある管理体制の構築• IdPとしてID連携ビジネスの収益拡大• RPとしてIdPに依拠することでコンプラ
イアンスコストを低減• 特定IdPに依存しない管理• 収益拡大• 運用の自由度• 収益拡大• 運用の自由度267

4-2-1. デジタルアイデンティティの活用に向けた課題とステークホルダの関心事項

３）”プライバシー”の課題解決の方向性とコンフリクト
カテゴリ

課題

課題解決の方向性

ステークホルダー

3)
・情報の第三者提供 • SSI/DIDの仕組みを活用し、顧客が自己 • 個人情報保護当局
プライバ に関して、データ提供 主権により各社とデータ利活用について同
シー側として、顧客同意 意する形とすることで、第3者提供という形• 金融機関・事業者
対応の負担が大きい 態を回避し、負担削減を図る。
（情報連携相手）・情報の第三者提供に関して、データ受取側として、データ提供• 顧客
側への説明と確認の対応負担が大きい・データ利活用の目的 • 事業者からのデータ利活用に関する説明 • 個人情報保護当局と範囲に関する、顧 内容の確からしさを、第３者による監査等
客と金融機関の認でカバーする必要がある。
• 金融機関識齟齬リスクの増大

関心事項• 顧客のプライバシー保護• SSI/DIDによる情報の第3者提供にかかる対応負担削減• 新しい仕組みへの移行負担• 法令順守• プライバシー保護• 新しい仕組みへの移行負担• 同意事項の明確化• 顧客のプライバシー保護• 法令に従った対応の実施• 負担の少ない対応• データ利活用促進• 金融機関を監査する • 規制遵守状況の確認
第三者機関• 法令に従った対応の実施• 顧客• プライバシーの確保• 法令に従った対応の実施

268

4-2-1. デジタルアイデンティティの活用に向けた課題とステークホルダの関心事項

４）”金融包摂”の課題解決の方向性とコンフリクト
カテゴリ

課題

課題解決の方向性

ステークホルダー

4)・デジタル対応できな • 各国の現状の金融機関の業務整備状況 • 金融当局
金融包 い人物の金融排除 や各国の政治体制等応じて対応– デジタルアイデンティティを活用した金融に摂必要なインフラ(アイデンティティ管理インフ• 政府当局
ラや決済インフラ)を国を挙げて整備し、全国民をデジタルに取り込む方針に基づき対応(②シンガポール・③インドの事例)– 既存の業務も活用しアナログ・デジタル両 • 金融機関
方の形での受入を行う方針(日本等先進国)• 金融当局および金融機関はデジタル化に• 顧客
よりAMLの高度化を図っている側面もある
ため、AMLの高度化と金融包摂のバランスを取った対応が必要

関心事項• 金融包摂の実現（特に新興国）• AML/CFTの高度化• デジタル化の推進• AML/CFTの高度化• 経済性• 金融サービスの円滑な利用269

4-2-1. デジタルアイデンティティの活用に向けた課題とステークホルダの関心事項

５）”相互運用性”の課題解決の方向性とコンフリクト
カテゴリ

課題

課題解決の方向性

ステークホルダー

5)・煩雑なID連携仕様 • 技術仕様や関連する法制度の整備を官 • 金融当局
民の連携により対応し、社会全体への幅
相互運 への対応負担
広い普及を目指す(⑨オーストラリアの事例)
用性

関心事項• 政府IDを発行するような政府機関と民間の連携によるトラストフレームワークの策定などを通じたID連携環境の整備• 標準化団体• 技術仕様策定• グローバル標準、コスト負担の大きくない
技術仕様• 金融機関• ソリューション利用• グローバル標準、コスト負担の大きくない
技術仕様• ソリューションベ
ンダー• ソリューション提供• グローバル標準、コスト負担の大きくない
技術仕様

270

4-2-1. デジタルアイデンティティの活用に向けた課題とステークホルダの関心事項

６）”新しい業務へ移行するための投資判断”の課題解決の方向性とコンフリクト
カテゴリ

課題

課題解決の方向性

ステークホルダー

関心事項

6)・最適化された既存 • 投資額を費用対効果の面から妥当なもの • 金融当局
• AML高度化等の観点から、デジタルID
新しい 業務をデジタルIMS とするため以下等を検討の利用促進
業務へ 利用のために変更–インフラの共同利用によるコスト削減• 金融機関• 効果に見合った投資
移行す する投資判断が困 –国として整備を進めるよう官の巻き込みるため 難–ID連携による収益化(⑤事例)• ID流通プラット • インフラ整備に妥当な対価の徴取の投資フォーム提供者
判断271

4-2-1. デジタルアイデンティティの活用に向けた課題とステークホルダの関心事項

７）”クロスボーダー取引の諸課題”の課題解決の方向性とコンフリクト
カテゴリ

課題

課題解決の方向性

ステークホルダー

7)・AML/CFT規制の • 広域に適用可能なeIDを活用し取引時確 • 金融当局
クロス
国家毎の差異や、認の統一化を行い、かつ広域に対して取引
ボーダー FATF基準及びその 時確認統一化と平仄を合わせたAML指取引の 他の規制・監督上
令を整備(①EU・⑦北欧の事例)のように、 • 金融機関
諸課題 の要件を実施する
クロスボーダーを行う法域間での協調による際の国境を越えた対応が一つのアプローチとして考えられるか。 • 顧客
データ共有への法的な障壁

関心事項• 規制フレームワーク／トラストフレームワー
クの整備• コスト削減のため法域間の規制ギャップ減少• 利便性確保

272

4-2-2. SSI/DIDの活用に向けた課題とステークホルダの関心

１）法的/制度上の課題
カテゴリ

課題

課題解決の方向性

１)法
的/制
度上の
課題

• 政府および政策立
案者の関与• SSIに対応した国民ID文書の提供を技術
的・法的枠組みにも対応できるよう、制度上の課題に対応する必要がある。
• 例えば、SSI/DIDに対応した電子署名や電子取引の規制、および電子文書などの検証可能な証明書として位置づける等。

•

金融当局

•

金融サービスのデジタル化
の推進

•

金融機関

•

自社サービスへのSSI/DIDの利活用促進

•

ユーザ

•

利便性の向上とプライバ
シー強化• SSI/DIDを活用時における人権等の権利保護に関する制度見直し等。
• 例えば、ウォレット操作のための秘密鍵を保護する権利を設ける等。
• SSI/DIDに分散型台帳やブロックチェーンネッ
トワークを利用する場合、個人/機密データが分散台帳に登録されてしまう危険性がある。
必要に応じて規制の見直しや、運用ガイドラ
イン等の策定が求められる。

•

政府当局

•

金融犯罪等時の情報（例：秘密鍵）開示•

ユーザ/消費者団体•

権利保護（例：表現の自由、人権）•

金融当局•

既存の各種規制・ガイド
ラインで未整備の論点・
課題の特定

•

金融機関/事業者•

各種法規制等に準拠したサービス・ソリューションの
提供

•

ユーザ

•

プライバシー対策が十分なされたサービス判断• プライバシー対策

ステークホルダー

関心事項

273

4-2-2. SSI/DIDの活用に向けた課題とステークホルダの関心

２）運用上の課題
カテゴリ

課題

課題解決の方向性

２)運
用上の
課題

• トラストフレー
ムワーク• 欧州連合の eIDAS のような適格 ID
プロバイダの認証を確立するために、国や地域の公的および民間のフレームワー
クを開発することが必要である。

• ライアビリティ• SSIモデルでは、Walletを制御するユー
ザ自身がIDPとして振る舞うことで、従来であれば国・企業・組織等が果たすべき責務を一義的にはユーザ自身が果たす必要が生じる。このためユーザへの支援が重要となるが、誰がどの様に担うのか、またその責務や責任分界点、また有事の際の扱い等の想定が不明
瞭。

ステークホルダー

関心事項•

金融機関・事業者•

規制遵守・サービス拡大•

各国規制当局•

トラストフレームワークの規制
整備

•

ユーザ

•

利便性確保

•

金融当局

•

規制監督の観点から責任
明確化

•

ユーザ

•

不利益を被った際の補償の観点から責任明確化•

デジタルIDの出し手/受け手の金融機関/ID流通
プラットフォーム提供者/
ウォレットプロバイダー•

リスク回避の観点から責任回避

274

4-2-2. SSI/DIDの活用に向けた課題とステークホルダの関心

２）運用上の課題
カテゴリ
２)運
用上の
課題

課題
• 標準化

課題解決の方向性• DID や VC などが、IEEE、ISO、ITU、NIST などの標準化団体（SDO）に受け入れられ、標準として推奨されるよ
うになることが必要である。

ステークホルダー

関心事項

•

標準化団体

•

技術仕様整備•金融当局•

規制整備・技術の規制へ
の適用評価

•

ID流通プラットフォーム
提供者、ウォレットプロバ
イダー•

アイデンティティソリューショ
ン・機能の提供・事業化

•

金融機関

•

ソリューション利用275

4-2-2. SSI/DIDの活用に向けた課題とステークホルダの関心

３）ビジネス上の課題
カテゴリ

課題

課題解決の方向性

３)ビ
ジネス
上の
課題

• 現行のIT/デジタ
ルシステムの適応• SSI/DIDを利用可能とする、クレデ
ンシャルの発行や検証を可能にするために、現在のITシステムの移行や新規システム構築が必要となる場合があるが、現状その投資に見合う利用が見込まれていない場合
が多い。

•

各金融機関

• 投資対効果の説明できる範囲で投資をとどめたい

•

金融当局

• 業界全体のオンボーディングコ
スト抑制の観点から、DIDの利用促進•

ID流通プラットフォーム提供者・ウォレットプロバイダー• インフラ整備に妥当な対価の徴取• 現状SSI/DIDは広く普及しておらず、企業や政府が継続して個人に対して使いやすいソリューションを提案することが必要。さらに、SSIに適したアプリケーションの市場を開拓することも非常に重要。

•

ユーザ• サービスの円滑な利用

•

消費者団体

• 消費者保護、デジタルディバイ
ド回避

•

政府当局

• デジタル化の推進

•

金融機関

• 金融包摂の推進・AML規制
強化•

ID流通プラットフォーム提供者、ウォレットプロバイダー• 参入障壁の排除• 個人の導入/ユー
スケースの検討不足

ステークホルダー

関心事項

276

4-2-1/2. 各課題のステークホルダーとその関心事項（参考）金融業界は、今後、本調査で検討した論点を扱うにあたり、Tech Provider、Tech
Community及び市民社会や金融以外の政府機関と課題解決を模索する必要がある。
 ステークホルダー（SH）の母集団として、デジタル競争本部で検討が進むTrusted Webの議論を参照した。
 「ステークホルダーには、従来のエンジニア、プラットフォーム事業者のみならず、 サービス提供事業者、インフラ提供事業者、大学
研究機関、利用者、消費者保護団体、シビルソサイエティ、法曹界、政府など様々なものを含む」（Trusted Web ホワイトペーパー Ver1.0、20頁）

 上記を金融を念頭に置き換えて区分すると、次の通りとなる。金融業界は、4-2.で挙げた諸課題について、従来必ずしも交流の多くなかったステークホルダを含めて、議論を行って解決策を模索していく必要がある。
金融分野でのデジタルアイデンティティに関連する主なステークホルダ（オレンジ：従来の金融関連SH、青字：新たに加わるSH）

金融業界
金融機関

金融
業界団体

Civil Society
利用者

消費者団体
法曹界

政府機関

Tech Providers(OS/Wallet/ブラウザ等の提供者）

Tech Community
標準化団体

エンジニア

大学・
研究機関

金融当局
個人情報
保護当局
デジタル政府当局

・・・
277

4-2-1/2. 各課題のステークホルダーとその関心事項（参考）マルチステークホルダーガバナンスの概要
 金融庁「令和元年度：ブロックチェーン技術等を用いた金融システムのガバナンスに関する研究」では、分散型金融システムのガバナ
ンスの検討において、「マルチステークホルダーガバナンス」の有効性について調査しているが、デジタルアイデンティティの課題についても、同様にマルチステークホルダーガバナンスが有効であると考える。
 同調査研究報告書では、マルチステークホルダーガバナンスの長所について以下の通り整理している。
マルチステークホルダー型ガバナンスとは、ある事象に対する3者以上のステークホルダ（利害関係当事者）が、多様性とバランスを重視して構成され、それぞれが対等な立場で参加･議論できる会議を通し、単体もしくは2者間では解決の難しい課題解決のために、合意形成などの意思疎通を図ることを目的とした、継続性のある統治メカニズム。
マルチステークホルダー型ガバナンスの長所

マルチステークホルダー型ガバナンス（以下MSG）を実現するためには、まずもってマルチステークホルダーが集まった会議体が組成される必要がある。また、その会議体
は、多様性とバランスを重視して組成される必要がある。



一方、会議体を構成するステークホルダーの多様性とバランスが担保されるためには、少なくとも①ステークホルダーの直接的な利害、②担当者の社会的属性、③担当者の能力（ケーパビリティ）、等が明確に類型化されていなければならない。とりわけ①と②については、会議体全体を俯瞰したバランス（配分の均衡状態）が期待され、また③については一定以上の水準に達していることが要件となる。



これを裏返せば、MSGを指向するということは、当事者の役割が明らかにされる必要があることを意味する。従って、前項（分散型金融システムがもたらす課題）の「課題の特定」で触れた、当事者の定義について、それが明確にされることを事前に合意することが必要となる。すなわち、分散型金融システムにおいてMSGの導入に合意するということは、分散型金融システムの当事者が自らの役割を相対化し、想定される全体の系の中での位置づけを明らかにしていくという営みに合意するということを、予め含意することになる。



一方、定義や役割が相対的に明確化されていけば、以下が可能となる。


担うべき責任（ある いは免れるべき責任）の分解



責任に対する当事者の有責性と限界領域（無限と有限の区別）の設定



分解された責任に基づく当事者同士の分界点の設定



また、こうした役割と責任の特定が進めば、①相互の尊敬（リスペクト）に基づく分業、②分業に基づく課題解決能力の向上、③MSGへの貢献のインセンティブ拡大、が期待される。



具体的には、たとえば何らかのインシデントが発生した際、技術者、事業者、政府がそれぞれ解決すべきことが役割分担され、それぞれの責任において業務を分業しながら効率的に課題解決に当たることができる。また同時に、消費者を含めたステークホルダー間の責任範囲の有限性（免責の設定）について合意形成が図られれば、事業者を含めたステークホルダーのすべてにとって、MSGへ貢献するインセンティブが形成され、そうしたガバナンス形態に基づく産業化が期待される。

出所）金融庁「令和元年度：ブロックチェーン技術等を用いた金融システムのガバナンスに関する研究

研究成果報告書」

278