agenda - minister of economy, trade and industry...•...

オンラインサービスにおける身元確認手法の整理に関する検討報告書

2020/3/31

Agenda

１．検討会を開始した背景・目的とスコープ

２．身元確認の定義

３．身元確認の必要性に関する事業リスクの判断指標

４．中間強度の身元確認手法のあり方に関する整理

５．その他考慮事項で研究会で挙がったご意見

６．まとめと今後の方向性

７．Appendix：取り扱う財（ヒト・モノ・カネ・情報）ごとの想定される被害

８．Appendix：委員からの発表資料（公開可能な資料のみ抜粋）

2020/3/31

1

• オンライン以前のサービスは、郵便を除けば原則対面でのサービス提供、フィジカルに相手が「見える」存在だった

• インターネット黎明期、オンラインサービス上では掲示板の書き込み等を主として、当初相手が「見えない」存在だったが、だんだんとオンライン上でも実在する本人を前提としたサービスが増加する中で、相手への「信頼」が重要となっており、その人の実在性の確認が必要になってきている

– 1990年代後半：インターネットの匿名性から、なりすましや複数アカウント等による詐欺等が生じ、EC等サービス提供者が経済的被害を受ける形に

– 2000年代後半：一方で人と人をつなぐ、ソーシャルネットワーク

サービスが普及、ネット上でも実名で行うサービスが普及。一方で本当にそれが実在する存在なのか確認するには免許証や保険証といった公的証明書を求める形になり、ユーザーにも事業者にも確認の手間がかかることがネックに

– 2010年代後半：民泊、配車サービスなどシェアリングサービスが普及し、個人がオンラインでつながり、サービスはオフラインで提供されるといったビジネスモデルが誕生。オフラインでのサービス提供を受ける際に、相手が本当に実在するのかといった点がオンラインプラットフォームでもより重要に

EC

匿名性掲示板

リアル/フィジカル空間

マッチング等のプラットフォーム

PF

PF

リアルからオンラインサービスへ

EC

BBS

１－１．背景オンライン上でも実在する本人を前提としたサービスが増加し、その人の実在性の確認が必要になってきている

オンラインサービスでの「実在性の確認」の必要性

2020/3/31

当人認証の課題と身元確認の必要性

• 結果、IDパスワードや、端末認証、生体認証といった「当人認証」により、「手続を行う主体を確認する仕組み」が構築された

• 一方でこれらの仕組みには「本当にその本人が作業しているのかという実在性を確認する仕組み」がなく、パスワードの使いまわし、端末の使いまわし等の手段によってなりすますことも可能である

• この課題を解決するには第3者がその実在を確認している結果を認証するといった手段が必要であり、「身元確認」という概念が重要となる

ユーザーA アカウントA

当人認証?

オンライン/サイバー空間


デジタル技術による身元確認効率化への期待

• これまでは物理的なサービスにおいても身元確認を通じてその人が実在する本人であることを確認していた。法律上も事業の安定的な運営や消費者保護等の観点から公的な身分証明書を確認することをもって存在確認が義務付けられているサービスも存在する

• オンラインサービスにおいても同様の身元確認を行う手段が必要となっており、これらの公的身分証明書の写しをオンラインで送付する、端末画面上で確認するといった形で行われていた。一方でこれらの手法はオンライン取引がより頻繁になる中でユーザー、サービス提供者双方の負担となっており、よりデジタル技術による効率化が期待される

ユーザーA アカウントA

身分証アップロード

オンライン/サイバー空間


１－１．背景実在性の確認には、「当人認証」だけでは不十分であり、デジタル技術による「身元確認」の効率化が期待される

2020/3/31

2

１－２．本検討会の目的

１．身元確認と当人認証の概念の違いを明らかにする

– 当人認証はユーザーが実際にサービスを利用していることを確認する手法。（ID/パスワード、SMSによる電話番号の所持確認、生体認証などはこの手法）

– 一方で身元確認は、実際にその行為を行うユーザーが実在する特定の存在であることを確認する手法であり、なりすましや複数のアカウント保有による犯罪等を防止するためには重要。（マイナンバーカードや免許証の確認等）

– 現在当人認証と身元確認の概念が区別されておらず、社会的にもこの概念を理解していただくことが重要。

２．オンラインサービス事業者に身元確認の必要性に関する事業リスクの判断指標を提供

– オンラインビジネスを行う事業者が自社が行うビジネスのリスクを評価するためのフレームワークを示すことで必要に応じて身元確認を行うべきかを判断しやすくする判断指標を提供。

– フレームワークに自社の事業を当てはめることにより、特に新規事業者にとってなりすましや複数アカウント等による自社の事業リスクを評価しやすくなり、どの程度の身元確認を行っておくべきかの予見可能性が高まる。

３．中間強度の身元確認手法のあり方に関する整理

– 現状、身元確認の手法は公的身分証による確認、もしくは本人による自己申告のふたつの方法しかなく、公的身分証の確認は、一部オンラインベースで確認できるサービスが出てきているものの、依然事業者・ユーザー双方にとって身元確認のコストが高い状況になっている。

– 中間強度の身元確認手法のあり方について整理することで、事業者・ユーザー、双方に利用しやすい身元確認のオプションを提供し、より安心・安全に利用できるサービスの拡大に貢献する。

2020/3/31

• ID• パスワード• 生体情報

（顔・指紋など）• 個人番号

• 氏名• 生年月日• 年齢• 性別• 住所

オンラインサービスにおける「身元確認」の定義と本検討会のスコープ

1)認証要素は「生体」（顔・指紋など）・「所持」（マイナンバーカードなど）・「知識」（パスワードなど）に分かれる2)マイナンバーカードなど、内部の情報に対する不正な読み出しが困難である物理装置

現実空間

仮想空間

現実空間or

仮想空間

オンラインサービス利用者

オンラインサービス提供事業者

身元確認サービス提供事業者• eKYC事業者• 金融機関• 通信会社など

公的文書発行期間• 都道府県公安委員会• 市区町村• 郵便局など




本人が所持（記憶）している個人の属性情報

システムに記録された（一時的記録を含む）個人の属性情報

公的機関が管理する（その信頼できるコピーを含む）個人の属性情報

当人認証

身元確認

当人認証とは

• 認証の3要素1)のいずれかの照合によりその人が作業していることを示すこと

• 認証方法は一般的に3段階でレベル分け




身元確認とは

• 本当に本人が作業しているのかについて確認すること

• 確認方法は一般的に3段階でレベル分け

• デジタル空間をベースに検討するためLv1,2を対象とし、デジタル化による簡素化を検討（左図ではLv1,2を前提として記載）

本検討会のスコープ

Lv3 「対面」で「公的身分証」を基にした身元の確認

Lv2 「郵送等の非対面」で「公的身分証」を活用した身元の確認

Lv1 「自己申告」を基にした身元の確認

本人確認

Lv3 3要素のうち耐タンパ性を持つハードウェア2)を含めた複数を用いる認証

Lv2 3要素のうち複数を用いる認証

Lv1 3要素のうち1つを用いる認証

１－３．検討会のスコープ「本人確認」を構成する「身元確認」と「当人認証」のうち、「身元確認」のみを対象とする

2020/3/31

3

1)全業界共通で適用される法規制（民法、会社法、個人情報保護法など）は当然存在する。また、規制がない領域においても、コストの低い身元確認手法があれば、サービスの拡大やユーザーの安心安全などのメリットにつながり、検討する意義があると考えられる

１－３．検討会のスコープまた、身元確認の規制の観点では、主に「自主規制」「規制なし1)」の領域を中心に検討する

身元確認規制領域と検討会のスコープ

# 法確認項目身元確認方法

証拠手法

1 犯収法氏名・住所・生年月日本人確認書類（公的）規定あり

2 携帯電話不正利用防止法氏名・住所・生年月日本人確認書類（公的）規定あり

3 （たばこ事業法）年齢または生年月日本人確認書類（公的）規定あり

4 戸籍法規定なし本人確認書類（公的）規定あり

5 出入国管理法氏名・生年月日等パスポート規定あり

6 出会い系サイト規制法年齢または生年月日本人確認書類規定あり

7 道路交通法規定なし本人確認書類規定あり

8 古物営業法氏名・住所・職業等規定なし規定あり

9 住宅宿泊事業法氏名・住所・国籍等規定なし規定なし

10 風営法年齢または生年月日規定なし規定なし

11 未成年者喫煙禁止法年齢または生年月日規定なし規定なし

12 未成年者飲酒禁止法年齢または生年月日規定なし規定なし

上記の領域は、法規制があるが具体的な手法が規定されていないためスコープ内


業界団体などによる自主規制

規制なし1)

身元確認規制

業界特有の事業者法規制

法規制によって身元確認の手法まで規定

法規制はあるが

身元確認の手法までは規定されていない

業界団体/自社等による自主的な規制を実施

身元確認を意識的には行っていない

法規制例

規制の強度

高

低

規制がないビジネスは非常に多いため、上記領域を中心に検討会で検討する

2020/3/31

身元確認と適格性評価

1)全業界共通で適用される法規制（民法、会社法、個人情報保護法など）は当然存在する


１－３．検討会のスコープ身元確認行為で活用する情報は、適格性評価の一部にも活用可能だが、適格性評価は本検討会の対象外とする

業界特有の事業者法規制

業界団体などによる自主規制

規制なし1)

規制の強度

高

低

より情報を集めてサービスの適格性を評価するような行為（スコアリング等）は本検討会の対象外

データ項目

利用用途

未成年の酒類購入

配車サービスのドライバー登録

ECサイト利用

銀行口座開設

動画配信サービス利用

家事代行サービスの派遣者登録

マッチングアプリの登録

携帯電話契約

・・・・

身元確認

ローン貸出時における返済能力の調査

ECサイトにおける購買情報の活用

シェアリングサービスの顧客評価、口コミの活用

適格性評価

・・・

・・・

年齢資格収入・・・・・・郵便番号

住所生年月日

氏名

2020/3/31

4

Agenda









2020/3/31

身元確認と当人認証の違い

1)認証要素は「生体」（顔・指紋など）・「所持」（マイナンバーカードなど）・「知識」（パスワードなど）に分かれる2)マイナンバーカードなど、内部の情報に対する不正な読み出しが困難である物理装置

身元確認・当人認証とはなにか

当人認証

身元確認（検討会スコープ）

推奨されているレベル区分（2019年現在）

• 登録する氏名・住所・生年月日等が正しいことを証明/確認すること

• 認証の3要素1)のいずれかの照合で、その人が作業していることを示すこと

Lv3 「対面」で「公的身分証」を基にした身元の確認

Lv2 「郵送等の非対面」で「公的身分証」を活用した身元の確認

Lv1 「自己申告」を基にした身元の確認

Lv33要素のうち耐タンパ性を持つハードウェア2)を含めた複数を用いる認証

Lv2 3要素のうち複数用いる認証

Lv1 3要素のうち1つ用いる認証

身分証

自己申告/顔写真など

ユーザー • 身分証は本物かを確認する(validation)

• 身分証と、自己申告または顔容貌とが一致するかを確認する(verification)

サービス事業者

対面、

郵送、

Upload

ユーザー


ID/パスワードの提示

認証

（例）

（例）

保証レベル

高

両者をあわせて本人確認という

保証レベル高

２．身元確認の定義（「身元確認」の「当人認証」との区別）「身元確認」は、ユーザー当人の実在性を確認し、「当人認証」は、ユーザーの行為を確認する。通常両方の組み合わせを通じて「本人確認」が行われている

2020/3/31

5

Agenda









2020/3/31

オンラインサービス類型と主要なステークホルダー

オンラインサービス類型と関与者

非対称型

対称型

プラットフォームモデル

Webの進化

• 動画投稿/配信サイト

– 2類型を持つケースが存在

（視聴者アカウントで投稿できる一方、プロ用に投稿者向けのアカウントも存在）

• 配車サービス

• SNS

• 出会い系

サービス例

• 乗り換え案内

• 動画配信

• 仲介者がいない直線的モデル

• 受益者のアカウントしか存在しない

• 受益者と生産者の中間にPFが存在

• 受益者と生産者のアカウントが分けれない/分かれていない

• 受益者と生産者の中間にPFが存在

• 受益者と生産者のアカウントが分かれるサービス

提供者サービス受給者

事業者（PF）

サービス提供者/受給者

サービス提供者/受給者

事業者（PF）

事業者伝統的モデルサービス受給者

３－１．誰のリスクを回避するために身元確認が必要かWebの進化とともに、オンラインサービスの関与者は変化してきた

2020/3/31

6

状況によっては二次被害も発生

損害の種類名誉毀損金銭詐取破損・詐取傷害

程度の判断個人情報金額価値身体的コンタクト

情報カネモノヒト

高

中

低

事業で取り扱う財が多いほどより厳格な身元確認が必要

損害の程度

事業で取り扱う財

高いレベルの損害リスクが予見される

ほど、より厳格な身元確認が必要

サービス受給者

サービス提供者

X

オンラインサービスの主な関与者

保険でリスク低減可能

事業リスク（身元確認の必要性）の評価尺度

３－２．事業リスクの判断指標事業者の自己チェック用に、取引する財に応じてサービス受給者・提供者が被る損害リスクをベースに、身元確認の必要性を評価する尺度を用意した

2020/3/31

• 事業ステージにより、優先価値は異なり、身元確認に関するスタンスも異なる

– 創業期〜拡大期：ユーザー数がまだ限定的で、アーリーアダプターが多いため、いかに早く事業を成長させるかが優先され、身元確認のコストを低減する、もしくは行わないインセンティブが高い

– 拡大期〜成熟期：社会的責任が大きくなる中で、事業内でのユーザーとのトラブルが社会的信用を失墜させ、ビジネスに甚大な被害を与えかねず、いかに信頼性を担保するかが優先されるため、身元確認を導入するインセンティブが高い

事業ステージに応じて変化する優先価値の傾向

創業期（事業確立）

いかに社会的責任を果たすか→身元確認によるユーザーからの信頼が優先

いかに早く成長するか→身元確認のコスト低減が優先

ビジネスの拡大・取引量の拡大・社会的インパクト

拡大期（上場前）

成熟期（上場後）

３－２．事業リスクの判断指標事業ステージに応じて変化する優先価値の傾向を整理した

事業者が自社のステージを考慮し判断

2020/3/31

7

３－２．事業リスクの判断指標研究会の主なご意見（1/3）

• 既存の事業者、創業初期の事業者、未来の創業者に、今または将来起こり得る（身元確認に関する）リスクを事前に察知できるような判断指標があった方が良い

– 法令で決まっていない場合に、身元確認をどのレベルまでやるべきか悩ましい時があるため、レベル感の考え方や考慮すべき要素が整理されているものが有用ではないか

– 初めてサービスを始める人にとってもリスクが分析できるような形でリスクが洗い出されていて、そのうちのどこを依拠してどこを自社でやるべきかが判断できるようなものにするといい

– 特に創業期フェーズの会社は、リスクに対する危機感が低く、取引件数が増えてくることで実は危なかったのではないかと気づく場合もある

– SMSによる電話番号の所持確認や、メールアドレスの送達確認などをしていたが、それでも不正利用などの被害にあった後に、初めて身元確認の問い合わせをするケースが多い

– 自社の業態や他社の導入状況を見て、どの程度やらないとリスクをコントロールできないかという見方をしているところもある

2020/3/31


• 評価する場合には、①扱う財とその内容や関与者、②事業フェーズや規模、を主としたうえで、③保険/補償の有無、④二次被害の可能性、でのより細かい被害程度も見ていく必要があるか

– ①扱う財とその内容や関与者

• オンラインで受発注が完結するものと対面で実際に会うものというところでリスクのグラデーションがあり、特に対面型のCtoCサービスはリスクが高くなる認識

• マッチングプレイスサービスだと、事業者だけでなく、売った人、買った人、もしくは第三者まで被害にあう可能性が多く影響範囲が大きくなる

– ②事業フェーズや規模

• スタートアップではIPOやシリーズが上がっていくときなど、各企業の事業のフェイズによって身元確認の重要性が異なることが想定されるため、時間軸も考慮したほうがいいのではないか

• 取引が1-2回のユーザーや少額利用の場合には厳密にやらないが、繰り返しの利用や一定の金額が出てきた場合にはリスクが高まる

– ③保険/補償の有無

• 事業者によっては損害が出てもそれを全部補償するから身元確認をせずにユーザーを増やすというスタンスを取ることもでき、その場合には補償の提示があるかも含めてリスクを評価をする必要があるか

• モノ・カネについては保険等で対応できるということを加味する必要がある

– ④二次被害の可能性

• モノ・カネについては保険等で対応できるということを加味する必要がある

2020/3/31

8


• ただし、事業リスクの判断指標の活用は、あくまで事業者の判断に任せた方が良い

– 安心安全は大事だが、スタートアップを含めて事業者はコストがかかることを避けたいため、基準を作ったうえで、各社の判断によって身元確認の手法を選べるような形にしたほうがいいのではないか

– ヒト・モノ・カネ・情報という軸でリスクを分類する時には、それらの軸のうちどれが重要なのか、という判断が難しいのではないか

– オンラインサービスに対して点数付けを行うような評価手法については、「このサービスは危険だ」というメッセージになってしまうので実施すべきではないのではないか

• リスクの評価には具体的なビジネスを想定した例示もあったほうがよい

– レーティングの有無などもリスクに影響を与える要素だと考えると、類型化するのではなく、具体的なビジネスの例を示した方が分かりやすいのではないか

2020/3/31

Agenda









2020/3/31

9

現在の本人確認手法一覧（身元確認＋当人認証）とユーザーの手間・コスト身元確認当人認証

イメージ

４－１．現在の本人確認手法一覧と課題現状、身元確認は自己申告もしくは公的身分証の確認のいずれかであり、身元確認の厳格化とあわせて手間・コストのハードルが大きく上がることが課題である

ログインID/パスワード

メール認証1)

自己申告


自己申告

端末認証or

生体認証


自己申告


SMS認証2)

自己申告

対面での公的

身分証確認3)

自己申告

端末認証or

生体認証

自己申告

ユーザーの手間・コスト


ハードウェアトークンを含む認証

自己申告




オンラインによる遠隔での公的

身分証確認3)

郵送による遠隔での公的身分証

確認3)

※近年、デジタル化に伴い、オンライン完結の身元確認が増えてきている

身元確認は自己申告レベルで、氏名・住所・生年月日は不確か

確からしい氏名・住所・生年月日等を把握でき、実ユーザーを特定可能

本人確認手法（身元確認＋当人認証）の一覧

1)メールアドレスの送達確認 2)SMSによる電話番号の所持確認3)マイナンバーカード、免許証など

2020/3/31

本人確認手法（身元確認＋当人認証）のユーザーの手間・コスト身元確認当人認証

イメージ（再掲）


メール認証1)

自己申告


自己申告

端末認証or

生体認証


自己申告


SMS認証2)

自己申告自己申告


中間強度の身元確認手法（検討対象）

対面での公的

身分証確認3)

端末認証or

生体認証


自己申告

端末認証or

生体認証

自己申告

ユーザーの手間・コスト

本人確認手法（身元確認＋当人認証）の一覧



自己申告



オンラインによる遠隔での公的

身分証確認3)

郵送による遠隔での公的身分証

確認3)

※近年、デジタル化に伴い、オンライン完結の身元確認が増えてきている

身元確認は自己申告レベルで、氏名・住所・生年月日は不確か

確からしい氏名・住所・生年月日等を把握でき、実ユーザーを特定可能

４－２．課題への対応策“適度に簡易で信頼性のある”手法=中間強度の手法がないかの検討を行い、手法の普及を図る必要性がある

1)メールアドレスの送達確認 2)SMSによる電話番号の所持確認3)マイナンバーカード、免許証など

2020/3/31

10

「簡易で低コストな中間強度の身元確認の手法が普及」することは、全てのステージの事業者にとってメリット

• 簡易で低コストな中間強度の身元確認の手法があれば、創業間もない成長を優先する事業者や、成熟期にあるコストをかけてでも信頼性を優先する事業者など、全ての事業者にとって有用な身元確認手法を提示できる

事業ステージに応じて優先する価値変化の傾向

４－３．中間強度の身元確認手法の活用者簡易で低コストな身元確認手法は、全てのステージの事業者にとって有用となる

いかに社会的責任を果たすか→身元確認によるユーザーからの信頼が優先

いかに早く成長するか→身元確認のコスト低減が優先

ビジネスの拡大・取引量の拡大・社会的インパクト

拡大期（上場前）

成熟期（上場後）

創業期（事業確立）

2020/3/31

1)ここでの依拠とは、第三者の身元確認済みデータを活用し、身元確認を行うことを指しており、責任区分などを含むことは意図していない

４－４．中間強度の身元確認手法の検討に関する論点

• 公的身分証の確認（オフライン・オンライン）ほど負担ではなく、一方で自己申告よりは厳格に身元確認ができる、“適度に簡易で信頼性のある”手法=中間強度がないか。また、その実現には何が課題か。

• 金融機関や通信キャリアが提供している身元確認APIを中間強度の身元確認手法として活用することができるのではないか。

• 身元確認APIを活用する場合以下論点についてどのように考えるか。

①公的身分証への依拠1)のあり方：第三者の身元確認済みデータを活用し、身元確認を行うことはできるか

②APIで返すデータのあり方：実際の確認方法として、身元確認済みデータを返すのか、情報突合の結果を返すのか

③当人認証(Authentication)との連携の仕方 : 認証システムとのAPI連携の方法についてどう整理すべきか

④トランザクションコスト：普及に当たってのコストのあり方はどうあるべきか

⑤身元確認の結果に関する責任分界点：API提供者としては全ての責任を負うことはできないのではないか

⑥その他

2020/3/31

11

自社で照合

結果のみもらう

通信キャリア

金融機関

その他

身元確認APIを利用

通信キャリア

金融機関

その他

中間強度の手法

公的身分証1)

のUpload簡素化

身元確認API+

自己申告

４－５．①公的身分証への依拠のあり方中間強度の身元確認手法は、何に基づくか、誰が照合するか、IDの提供先、などの観点から、以下のパターンが考えられる

中間強度として考えられる手法一覧

1)マイナンバーカード、免許証など

何に基づくか誰が照合するかAPIの

提供元は

• 公的身分証1)への依拠のあり方をどのように捉えるか

– 法令に従って身元確認したデータに依拠したものは身元確認済みデータとして扱うか

– 上記の整理に従った場合APIを提供できる事業者は法令上身元確認を行うことが義務付けられている事業者と整理できるか

問題意識

2020/3/31

①公的身分証への依拠のあり方：第三者の身元確認済みデータを活用し、身元確認を行うことはできるか（現状はどのようになっているか）

• 金融機関と通信キャリアは、法令に従い身元確認を行ってきており、身元確認済みデータとして既に提供

– 銀行APIは、金融機関（犯収法対象業者）に対して、犯収法に準拠できる形で提供している

– 通信キャリアAPIは、金融機関・公営競技・たばこ業界などに対して、身分証Uploadの代わりや、認証強度を高める目的で提供している

– ただし、全ての金融機関と通信キャリアがAPI提供しているわけではない

• 会社としてのデータのオープン化戦略や開発コスト等を踏まえて、提供していない事業者もいる

• 一部のeKYC事業者においても、法律規制の要件を満たす本人確認プロセスを内包することで、身元確認済みデータとしてAPI提供を行っている

①今後の検討論点

• API連携により他社から提供された情報を、さらに提供するサービスも今後出てくる可能性があり、これらのデータを身元確認済みデータとして取り扱えるか

４－５．①公的身分証への依拠のあり方研究会の主なご意見と今後の検討論点

2020/3/31

12

４－６．②APIで返すデータのあり方APIによる身元確認済みデータを活用した確認手法は、データの返し方によって2種類考えられる

1)オンラインサービス事業者2)基本3情報とは、氏名・住所・生年月日を指す

サービス事業者の確認方法

自分で照合

身元確認済みDB照合結果（〇、×）

のみもらう

第三者が照合

基本3情報2)

第三者ID

基本3情報2)

身元確認済みDB•自己申告

•第三者IDを情報提供

第三者ID

基本3情報2)をもらう

サービス事業者身元確認済み

API提供事業者

データを自社1)

で照合

データの照合結果のみもらう

ユーザー

•自己申告•第三者IDを情報提供

API提供者のデータの返し方

2020/3/31

②APIで返すデータのあり方：実際の確認方法として、身元確認済みデータを返すのか、情報突合の結果を返すのか

• どちらのケースを提供しているかは事業者によって異なる

– 現状は通信キャリアは両方（身元確認済みデータ・情報突合の結果）の形式とも、提供している

– 現状は金融機関は身元確認済みデータを返す形式のみ提供している

• 身元確認済みデータを返すことにより、身元確認以外の効率化のメリットも存在する

– 身元確認済みデータを返し、会員登録に反映させることにより、ユーザーの負担が軽減され、登録者の離脱率低減につながる

②今後の検討論点

• 住所・氏名の異体文字等の形式が異なるため情報突合せが難しく、形式を共通化すべきではないか（③の「身元確認APIの標準化」でも、同様のご意見あり）

４－６．②APIで返すデータのあり方研究会の主なご意見と今後の検討論点

2020/3/31

13

• オンラインサービス事業者が、金融機関や通信キャリアからAPI連携し身元確認を行う場合、何らかの標準化されたAPIの形式があった方が、システムの標準化がしやすく、機能の普及が図られるのではないか

• ユーザーのログインの都度、APIを確認に行く仕組みにするのか、最初のユーザー登録時のみ

確認するかによってトランザクション量が異なってくるが、システム負荷等を考えた場合どう整理すべきか

• API提供側のデータクオリティがサービスに対して十分であるかは、どのように考えるべきか

• API提供先の身元情報が更新された場合、オンラインサービス事業者に登録されているデータとの不整合が起きる可能性があるが、どう整理すべきか

４－７．③当人認証(Authentication)との連携の仕方身元確認APIのあり方を議論する際、当人認証機能とどのように連携させるか

2020/3/31

③認証(Authentication)との連携の仕方：認証システムとのAPI連携の方法についてどう整理すべきか（1/2）

• 簡易に連携する方法としては「身元確認APIの標準化」、「アグリゲーターの活用」が考えられる

• 「身元確認APIの標準化」は、一定程度必要ではないか

– 現在身元確認APIは標準化されて提供されておらず、バラバラに存在し、標準化の難易度は高い

• データ利用企業だけでなく、API利用企業も、開発レベルやセキュリティポリシーが異なる

• データベースの設計が異なり、データ自体の細かな仕様も異なるため、統一は難しい

• データ内容も、同じ住所でも、異体字や地番の書き方など事業者によって異なる

• どこまでデータを提供できるかも事業者の戦略によって異なる

• 現状、金融機関における電文仕様の標準化や、OAuthの標準化においても、実態は揃えられていない

– 一方で、国際的な身元確認APIの標準化動向や、先行しているプレイヤーに合わせられる範囲で合わせていくことが必要である

• 現状では、Open ID foundationなどの団体で、標準化の検討が進展している

• ガラパゴス化しないよう、デファクトスタンダードになりそうなもの（国際的な標準化動向や先行しているプレイヤーなど）に乗っかることが重要

– 例えば、UI/UXにおいても可能な範囲で各社そろえることで、顧客離脱を防げる可能性

• 以上より、「どの標準化動向に、どこまで合わせていくか」といった整理が必要

４－７．③当人認証(Authentication)との連携の仕方研究会の主なご意見と今後の検討論点(1/2)

2020/3/31

14

③認証(Authentication)との連携の仕方：認証システムとのAPI連携の方法についてどう整理すべきか（2/2）

• 「身元確認APIの標準化」とあわせて「アグリゲーターの活用」も必要ではないか

– API仕様・データ仕様は各社異なり、すり合わせが必要であることに加えて、1社のAPI提供者では、利用できるユーザーが限られてしまう• ある最大手１社の国民のカバー率は40%程度にとどまる（他社は10数%やそれ以下も多数存在）

– またサービス事業者にとってワンストップで契約・接続が可能なプラットフォーム構築があると便利

– さらに仮に標準化したとしても、細かい仕様が異なる可能性もあり、アグリゲーターがゲートウェイを整えるというのは必須

• ただし、アグリゲーターは「API提供企業側の代理人」となるか「ユーザー側の代理人」となるかの検討も必要

– データの送信においては、ユーザー同意のもと企業にデータを提供するというスキームが一般的であり、ユーザー側の代理人という形になっている

• アグリゲーター機能を誰に、どこまで任せるか、といった整理が必要である

③今後の検討論点

• どの標準化動向に、どこまで合わせていくか

• アグリゲーター機能を誰にどこまで任せるか

４－７．③当人認証(Authentication)との連携の仕方研究会の主なご意見と今後の検討論点(2/2)

A

B

2020/3/31

トランザクションコストの論点問題意識

• トランザクションコストが高すぎると利用されず、普及しないのではないか。

• 一方である程度のマネタイズができなければAPI提供事業者もやる意義が見出せないのではないか。

支払うコスト（直接費用）

API利用料

いくら支払うか？サービス事業者 API提供者

オペレーションの手間（例）（間接費用）

サービス事業者第三者

身元確認済み

DB

（〇、×）結果のみもらう

第三者が照合

基本3情報

第三者ID


基本3情報

第三者

身元確認済み

DB• 自己申告• 第三者IDを情報提供

第三者ID第三者から基本3情報をもらう

自分で照合

ユーザー自社で照合

照合結果のみ

どちらが照合するか？

ユーザー

• 身元確認の間接コストは①オンラインサービス事業者が自社で照合するか、②API提供者側で照合するかで異なる。（一般にコストは①＞②と考えられるか）

• 自己申告• 第三者IDを情報提供

４－８．④トランザクションコスト事業者の支払うコストやオペレーションの手間における課題が存在する

2020/3/31

15

1)全業界共通で適用される法規制（民法、会社法、個人情報保護法など）は当然存在する

④トランザクションコスト：普及に当たってのコストのあり方はどうあるべきか

• コスト負担方法は、イニシャルや初期費用ではなく、トランザクションベースが望ましい

– 初回・利用に限らず、取引内容に応じた身元確認が必要なため、利用毎（トランザクションベース）の料金設定が望ましい。実際に、現状でもトランザクションベースで利用料が発生

• コスト金額の妥当性は、法規制のある業界と法規制のない業界1)で考え方が異なり、法規制のない業界1)に関してはニーズの確認が必要

– 法規制のある業界にとっては、規制対応のためにコストが発生する認識はあり、コストをいかに低減するかという発想で、身元確認APIの費用負担を検討する

– 一方、法規制のない業界にとっては、事業リスクに見合う形での身元確認（＋当人認証）が必要であり、そのリスクに見合うコストがいくらであったら支払うのかという点を確認する必要がある

– 特に法規制のない業界に関しては、補助金などの制度が必要になる可能性もあるか

• 本研究会で10社程度のヒアリングを行った結果、法規制がない業界1)でもニーズがある事業者は存在した

– 身元確認導入のニーズは、「サービスの安全安心の担保をするため」「複数アカウントへの対策」などが存在し、また導入済みの企業も「従来の身元確認の手間やコスト削減」のニーズが存在した

– 実際に導入を検討する際には、提供される身元確認の「情報が最新か」「ユーザーカバレッジが十分か」などを考慮する、という意見も挙がった

– その他の意見としては、身元確認だけでなく、追加で反社等のチェック情報も欲しいという意見や、シェアリングエコノミーの業界においてはコスト感は100～200円程度という意見が挙がった

– 上記は10社程度のヒアリングのため、サービス提供にあたってはサービス提供者がさらなる顧客のニーズを深掘りすることが推奨される

４－８．④トランザクションコスト研究会の主なご意見と今後の検討論点

2020/3/31

責任分界点の論点

1)オンラインサービス事業者2)基本3情報とは、氏名・住所・生年月日を指す

サービス事業者の責任範囲

自分で照合

基本3情報2)


第三者ID

第三者から基本3情報2)を

もらう

データを自社で照合

データの

照合結果のみもらう

API提供者ユーザーサービス事業者

身元確認済みDB

第三者が照合

基本3情報2)


第三者ID


照合結果（〇、×）のみもらう

サービス事業者が情報または結果に責任を持つ

自分で照合

基本3情報2)


第三者ID

第三者から基本3情報2)を

もらう


第三者が照合

基本3情報2)


第三者ID


照合結果（〇、×）のみもらう

API提供者が情報または結果に責任を持つ

オペレーション実施者

API提供者ユーザーサービス事業者

オペレーション実施者

問題意識・だれがどこまで責任を持つか？・各事業者責任の負担はなるべく持ちたくない？

４－９．⑤身元確認の結果に関する責任分界点だれがどこまで責任をもつかという責任分界点に課題が存在する

2020/3/31

16

⑤身元確認の結果に関する責任分界点：API提供者としては全ての責任を負うことはできないのではないか

• API提供者が全ての責任を持つことは難しく、最終的な責任は事業者がもつことが必要。但し、提供情報に関してはAPI提供者が責任を持ち、具体的な責任分界点は個別ケース毎に判断する必要がある

– 原則、身元確認API提供者は、身元確認済みデータを提供する立場であり、確認の当事者は、あくまでサービスの提供者であるべき

– その上で、どこまで結果を保証するかは個別のやり取りの中で、事業者と相談するのが良い

– さらに、API提供者の情報が、提供先において必要十分であるか、API提供者には判断がつかない

• 通信キャリアの事例では、携帯電話不正利用防止法に基づき行った身元確認が、提供先の法令に準拠しているか、または十分なレベルか否かの判断がつかない

– そのため、照合をAPI提供者側が実施する場合においても、最終的な責任は事業者がもつのが良いのではないか

• 上記の原則論はあるものの、一方で様々な関連法令が存在する為、明示的にできるかはわからないが、事業責任や情報の扱い方を仮に定めるのであれば、関連法令との整理・整合は必要ではないか

⑤今後の検討論点

• 実際に実装していく際には、オンライン事業者・API提供者等の関与者が動きやすくなるように、アーキテクチャだけではなく、法律の適用範囲の整理が必要

– 業界共通の法規制（個人情報保護法など）や、民事上の責任、その他関連法規（電子商取引の準則1)、電気事業法2)など）との整合性など

４－９．⑤身元確認の結果に関する責任分界点研究会の主なご意見と今後の検討論点

2020/3/31

信頼性で序列をつける場合の評価の観点（NIST Special Publication 800-63A Digital Identity Guidelinesより抜粋)

どのような情報・証拠を集めるか（住所・氏名・生年月日などを免許証で確認等）

証拠の有効性をどのように判断するか

（免許証が本物であることの確認等）

証拠が本人であるとどのように確認するか

（免許書の顔と、顔写真を照合する等）

４－１０．⑥その他中間強度の手法の信頼性を評価する場合、NISTを参考にすると大きく3つの観点がある

2020/3/31

17

⑥その他手法に関して挙がった論点

6-1:中間強度の身元確認手法に関して序列をどの程度つけるべきか

• オンラインサービス事業者とその活用状況によって、どのような手法が最適かは異なるため、一律の序列はつけられない

• どの手法が最適かをオンラインサービス事業者が判断する際は、どの本人確認書類で、何の情報を、いつ、どのように確認したかなどの確認プロセスや、どのような法的根拠に基づくか、などの観点で判断することになる

6-2:身元確認APIの普及にあたり、身元確認の知名度をどのようにあげるべきか

• 身元確認の認知度の低さがAPI手法の普及の課題になっている可能性

– 一般的に、身元確認・当人認証・本人確認といった概念が浸透されておらず、顧客へAPI提案時には身元確認や当人認証に関する説明から始まっており、導入までの時間がかかる

• 身元確認の認知度は、本件の活動を通して身元確認・当人認証の概念から広く普及していく（後述）

４－１０．⑥その他研究会の主なご意見と今後の検討論点

2020/3/31

⑥その他手法に関して挙がった論点

6-3:API提供者側は、誰に情報を提供してよいかを、どの様に判断するべきか

• 金融機関・通信キャリア共に、情報提供先の提供可否を判断するために一定のセキュリティチェックを個別に行っている

• 金融機関・通信キャリア・eKYC事業者で、提供者側が事業者（API提供先）に求めるレベルはある程度水準を合わせた方が望ましく、例えばその水準を判断するにあたっては外部評価機関の既存の認証制度を活用することも一案か。一方で、サービス提供にあたって事業者や業界によって要求される水準は異なっていることが一般的であり、それらを考慮することも必要

6-3：今後の検討論点

• API提供者が誰に情報を提供してよいか判断するための統一的な水準を策定するかから検討を行う

– 統一的な水準を策定するか、API提供者の個社に任せるか

– 統一的な水準を策定するなら、判断のための新たな枠組みを作成するべきか。または、既存の仕組みを活用するなら、どのような認定・認証制度を活用するべきか

４－１０．⑥その他研究会の主なご意見と今後の検討論点

2020/3/31

18

Agenda









2020/3/31


プラットフォームサービスを利用する外国人が多く、国内サービスを海外の人が利用する場合の身元確認手法についてもカバーしていくべきではないか

クラウドソーシングや民泊などのサービスでは法人がアカウントを持つことも多く、その際の身元確認では登記簿謄本のコピーの提出などコストがかかっているケースがある

事業者視点では反社情報を得られないことが本人確認で一番困っていることで、金融機関だけが見られる仕組みをもっと拡大できないか

事業者は裁判や訴訟などダウンサイドのリスクにフォーカスを当てているため平時の本人確認については関心が薄い

通常の考え方として本人確認はCDD（カスタマーデューデリジェンス）の一部であり、顧客の

確認や審査を通して総合的な判断を行うため、属性の評価と適格性評価を分けてしまうとリスクを評価しにくい

プラットフォームビジネス全体としてのリスクや安全をどう考えるか、という全体像がないと、身元確認のみガイドラインを示しても、事業者に意識を持ってもらうことは難しい

身元情報を提供した後に確認記録義務をどこまで対応するかも、法令（個人情報保護法）も含めて検討が必要

適格性評価も考慮すれば、年齢情報や、士業・在留資格などの資格情報、医療情報などとの連携も考えられ、既存のシステムとの連携を含めた検討が必要

2020/3/31

19

Agenda









2020/3/31

６－１．本検討会のまとめ

1. 身元確認と当人認証の概念の違い

• リアルと結びつくオンラインサービスが増加する中で、ユーザーがサービスを利用していることを確認する「当人認証」とサービス利用者の実在性を確認する「身元確認」を分けて理解することが重要。

• なりすまし、複数アカウント等による事業者の損害リスク、オンラインサービスを利用するユーザーの保護の観点からは特に「身元確認」がなされていることが、サービス提供者、利用者双方のリスクを低減することにつながる。

2. 身元確認の必要性に関する事業リスクの判断指標

• 既存の事業者、創業初期の事業者、未来の創業者に、今または将来起こり得る身元確認に関するリスクを事前に判断できるような判断指標があることは有用。

• リスク評価の際には、①扱う財とその内容や関与者、②事業フェーズや規模、を主としたうえで、③保険/補償の有無、④二次被害の可能性、等を踏まえた被害程度も見ていく必要あり。

• 事業リスクの評価尺度は、身元確認に伴う事業コスト等も鑑み、事業者の自主的な判断によって活用するものとし、今回は身元確認手法をリスクレベルに紐づけることはしないボランタリーな枠組みとして整理。

2020/3/31

20

６－１．本検討会のまとめ

3. 中間強度の身元確認手法のあり方

• 自己申告と、公的身分証明書の確認以外の中間的な身元確認の手法がないため、事業者にとって身元確認のコストが高くなっている。簡易かつ低コストな中間強度の身元確認手法の確立は、より信頼性の高いオンラインサービスの普及に貢献。

• 金融機関や通信キャリアは法令に基づいて身元確認を行っており、当該事業者の身元確認済みデータのAPIを通じてデジタルで完結する身元確認手法の活用が可能性として存在。その際、以下の点について留意が必要。

①API提供者は、データの信頼性の観点から法による義務付けに基づいて身元確認を行っている必要があるのではないか（但し、一定の条件の下法令の義務がない事業者の参画は排除しない）。

②APIの活用については１）オンライン事業者がユーザーの情報を照合するパターンと２）API提供事業者が照合結果のみを返すパターンあり。オンライン事業者が事業のニーズに応じて選べる方が良いのではないか。

③現状のAPI提供事業者のユーザーカバー率は限定的。アグリゲーターの存在が必要ではないか。またデータの形式やAPIも提供事業者によって異なるため、アグリゲーターは、国際的な標準化やデータ連

携技術の動向も踏まえながら、これを実装することで民間の当人認証機能とも連携しやすい形にすべきではないか。

④身元確認APIの利用コストは高額なイニシャルコストが生じないよう、トランザクションベースで課金され

るべきではないか。またユーザーであるオンライン事業者のニーズ等の実態を踏まえて利用料金が適切に設定されるよう検討すべきではないか。

⑤API提供者が全ての責任を持つことは難しく、最終的な責任は事業者がもつことが必要ではないか。但し、提供情報に関してはAPI提供者が責任を持ち、具体的な責任分界点は個別ケース毎に判断する必要がある。

2020/3/31

６－２．今回の議論を踏まえた取組の方向性

1. 身元確認の重要性に関する周知や、事業リスクの判断指標の展開

• ユーザー、オンライン事業者及びAPIの提供プレーヤーがそれぞれメリットを受けることを明

確にしつつ、本報告書の公開やメディアへの露出を通じて、リスクに応じた身元確認の重要性について社会一般、事業家に対して発信。

• 身元確認の必要性に関する事業リスクの判断指標について紹介。例えば、シェアリングエコノミー協会における、シェアリングエコノミーの認証制度における事前評価で活用。またFintech協会においても、犯収法対象事業者の情報提供を後押しをしつつ、非対象事業者の利用について周知を展開。

2. 身元確認APIの活用環境の整備

• 事業者やエンドユーザーにとって使いやすくする為には、ユーザーカバー率の増加が重要。その為、金融業界、通信キャリアの主要事業者に今回の報告書を共有し、身元確認済みAPIの提供プレーヤーの拡大を目指す。

• アグリゲーターの位置付け、情報の標準化、データ連携技術（API含）等の方向性、中間強度

の身元確認手法等、オンライン事業者が使いやすい形でのサービス全体のアーキテクチャー整理が必要。また検討においては、令和2年度に立ち上がる予定であるIPA産業アーキテクチャーセンターとの連携が必要と思われる。

2020/3/31

21

ステークホルダーと論点論点詳細

• どの標準化動向に、どこまで合わせていくか

– 国際標準、先行プレイヤー等のどの基準にあわせていくか

– 合わせる場合はどこまで合わせていくか

• アグリゲーターの必要性と、どこまで任せるか

– 官、民どちらが行うか、民で行う場合の競争環境をどう考えるか

– APIを取りまとめるだけなのか、ユーザー情報のアグリゲートまで行うのか

– e-KYC事業者等の認定の仕組みが必要ではないか

– 産業毎・アグリゲーター毎の相互接続性を担保できるようにすべきではないか

– データ連携技術で、実装としての共通I/F化が必要ではないか

• UI/UXを向上し、どう利便性向上を図るか

– 国際標準、先行プレイヤー等のどの基準にあわせていくか

– 事業者間の協調及び、ユーザーへの普及をどうやって推進するか

• 身元確認に関連した法令・法規は、それぞれどのように整合しているか

A

B

• 対象

– オンラインサービス等の身元確認を活用する事業者

– 身元確認API事業者

• 効果

– 開発、接続、カバレッジ、オペレーション等が全て効率化される• API・データの仕様を詳細レベルで揃

え、共通I/Fで事業者へ提供• 複数の身元確認API提供者を束ねて、

ユーザーカバレッジが向上• 身元確認API業者と事業者との契約・

請求業務が一本化される

(参考)標準化・アグリゲーター設置のメリット

API事業者

API事業者

API事業者

アグリゲーター

事業者

事業者

事業者

・・・

・・・

共通I/F(標準化)

共通I/F(標準化)

B

A

A

啓蒙とUI/UX向上C

ユーザー

C

６－３．中間強度の身元確認手法普及に向けた検討多くのステークホルダー間で調整が必要であり、アーキテクチャ設計とその共通理解を深めながら、普及を進めていく必要があるのではないか

1)本検討会では、資格情報の連携（士業・在留資格の連携）などの「適格性評価」はスコープ外としたが、アグリゲーターのアーキテクチャを考える上では、これらの連携を含めて考える必要がある

D

(参考)中長期的な検討事項

• マイナンバーカードとの連携、保険証や資格情報1)との連携、在留外国人のデジタルアイデンティティの活用、更には海外での活用等の観点も考慮をしておくことが必要か

身元確認に関連した

法令・法規

D

中間強度の身元確認を普及させるにあたって検討すべきこと

2020/3/31

• 委員（50音順、敬称略）

– 石山アンジュ一般社団法人シェアリングエコノミー協会

– 小木曽稔一般社団法人新経済連盟

– 落合孝文渥美坂井法律事務所・外国法共同事業

– 栗山盛行株式会社NTTドコモ

– 古賀正明株式会社三井住友フィナンシャルグループ

– 千葉孝浩株式会社TRUSTDOCK

– 福島直央 LINE株式会社

– 丸山弘毅一般社団法人Fintech協会

– 水野祐シティライツ法律事務所

– 柳澤隆株式会社三菱UFJ銀行

• オブザーバー

– 一般社団法人全国銀行協会

– 独立行政法人情報処理推進機構

本報告書は、オンラインサービスに関わる関連協会・団体、身元確認の情報を提供しえる事業者、その他有識者に委員として参画頂き、3回の研究会の討議を通じて報告書として取りまとめた。尚、事業者へのニーズヒアリングはシェアリングエコノミー協会の会員企業様にもご協力頂いた

• 運営事務局

– 瀧島勇樹経済産業省商務情報政策局情報技術利用促進課（ITイノベーション課）課長

– 吉田泰己経済産業省商務情報政策局総務課情報プロジェクト室室長補佐

– 小泉誠経済産業省商務情報政策局情報経済課課長補佐

– 千家寛也経済産業省商務情報政策局情報技術利用促進課（ITイノベーション課）係長

– 満塩尚史経済産業省 CIO補佐官

– 工藤祥裕国立研究開発法人新エネルギー・産業技術総合開発機構 IoT推進部主査

– 山岡靖志国立研究開発法人新エネルギー・産業技術総合開発機構 IoT推進部専門調査員

– 樋崎充 PwCコンサルティング合同会社パートナー

– 岸洋人 PwCコンサルティング合同会社ディレクター

– 大塚悠也 PwCコンサルティング合同会社マネージャー

– 長山東哲 PwCコンサルティング合同会社シニアアソシエイト

– 門倉諒 PwCコンサルティング合同会社アソシエイト

– 岩田太地日本電気株式会社デジタルインテグレーション本部ディレクター

– 佐藤規夫日本電気株式会社官公営業本部営業課長

2020/3/31

22

Agenda









2020/3/31

７－１．「情報」のやり取りが発生するケースでのリスク「情報」は常にやり取りされるが、情報特性でリスクは異なる

「情報」のやり取りが発生するケースでのリスク（例）

事業者生産者（真）

受益者（真）

受益者（偽）

事業者

生産者（真）

生産者（偽）

受益者（真）

漏洩・改ざんリスクあり

特定ユーザーと関連しない情報

アカウントに紐づく情報

• 氏名・年齢・住所

• 顔写真

• 位置等

• 口コミ

• 匿名ブログ等

• 映画

• 広告等

個人を特定できる情報

情報レベル

想定されるリスクフリマアプリの売り手になりすまし、買い手に嘘情報を流す/不正に情報取得

フリマアプリの買い手になりすまし、売り手に嘘情報を流す/不正に情報取得

漏洩

改ざん・嘘

漏洩

改ざん・嘘

• 事業者の評判低下• 損害賠償リスク

• 個人情報を流出させてしまう

• 改ざん・嘘の情報にだまされる


• 改ざん・嘘の情報を流される

• 情報が受け取れない• 改ざん・嘘の情報にだまされる

• 個人情報を流出させてしまう

• 情報が受け取れない• 改ざん・嘘の情報を流される

• 情報のレベル（粒度）は大きく３段階に分かれ、発生しうるリスクが異なる

情報例

2020/3/31

23

７－２．「カネ」のやり取りが発生するケースでのリスク「カネ」のやり取りがある場合、生産者と受益者のどちらがなりすまされたかにより、リスクは異なる

「カネ」のやり取りが発生するケースでのリスク（例）

• 生産者がなりすまされた場合、「カネ」が盗まれる程度の被害にとどまる

– 但し、扱う金額で被害規模が変わる

• 受益者がなりすまされた場合は、「カネ」が際限なく支払われる可能性

事業者

生産者（真）

生産者（偽）

受益者（真）


受益者（真）

受益者（偽）

想定されるリスクサービス対価として支払ったカネが他人にぬすまれる

ECサイトでモノを大量購入される / フリマアプリでモノを大量購入される

カネが盗まれる

認識しないまま不正に支払われる


• カネを受け取れない

• 支払ったカネが他の人に盗まれる


• 被害なし

• 際限なく支払われる

￥

￥

2020/3/31

７－３．「モノ」のやり取りが発生するケースでのリスク「モノ」のやり取りがある場合、生産者と受益者のどちらがなりすまされたかにより、リスクは異なる

「モノ」のやり取りが発生するケースでのリスク（例）

事業者

生産者（真）

生産者（偽）

受益者（真）


受益者（真）

受益者（偽）

• 生産者がなりすまされた場合、不審物が配達される等、サービスレベル（契約の範囲）を超えた被害が起こりえる

• 受益者がなりすまされた場合、「モノ」が盗まれる程度の被害にとどまる

– 但し、ぬすまれる「モノ」の金銭的価値によって変わる

想定されるリスクフリマアプリで危険物が送られる / 偽ECサイトで購入し不審物が送られる

フリマアプリで購入物が盗まれる / ECサイトで購入物が盗まれる

不審物・危険物が配達される

盗まれる


• 不審物・危険物を受け取る


• 送ったモノが届かない

• 「モノ」がぬすまれる

• 評価がさがる

2020/3/31

24

７－４．「ヒト」のやり取りが発生するケースでのリスク「ヒト（によるサービス）」のやり取りがある場合、つねに傷害等のリスクが起こりえる

「ヒト」のやり取りが発生するケースでのリスク（例）

• 「ヒト」の接触があれば、誰かしらに傷害等のリスクは起こり得る

（どちらがなりすまされるかによらず、被害は発生しうる）

家事代行で不審者が派遣される / マッチングアプリで不審者が来る

家事代行で不審者の家に派遣される / マッチングアプリで不審者に会う

事業者

生産者（真）

生産者（偽）

受益者（真）

事業者


生産者（真）

• 傷害、けが（殺人のリスクも）

受益者（真）

受益者（偽）

想定されるリスク

不審者が派遣される

派遣者が不審者に会う

• 評価がさがる


• 傷害、けが（殺人のリスクも）

• サービスをうけられない• または、評判がさがる

2020/3/31

Agenda









2020/3/31

25

2020年２⽉３⽇政策部⻑⼩⽊曽稔

オンラインにおける⾝元確認について

議論のスコープ①

1

今回の議論のゴール/ＫＰＩ/出⼝は何か︖データ駆動型経済への転換と⽇本発プラットフォームサービスの振興のための環境整備になっているかを常に振り帰って議論することが⼤前提であるべき

そもそもガイドラインって何︖あえて議論します-名宛⼈は誰︖-競争領域と⾮競争領域の適切な整理は︖-ビジネスモデル競争との関係は︖-⾃主規制なの︖-確認するべき場⾯を国が⼀律に決めることが⽬的なのか︖

それとも、データ連携・ＩＤ連携のための論点の洗い出しと環境整備か︖-技術中⽴性の確保/新しい技術動向等への対応

26

議論のスコープ②

2

政府全体の各種検討の中での今回の検討の位置づけは︖『トラストサービスの制度化』との関係『官⺠ＩＤ連携』との関係

規制改⾰等の必要性/他施策との連動は︖規制改⾰会議等で提起議論されてきている本⼈確認の議論の進捗も重要であることを念のため付⾔

【ご参考】新経済連盟が政府の各種会議で提起してきた資料から抜粋

27

2013年産業競争⼒会議での提案資料①

5

2013年産業競争⼒会議での提案資料②

28

2013年規制改⾰会議での提案資料①

2013年規制改⾰会議での提案資料②

29

2013年規制改⾰会議での提案資料③

2013年規制改⾰会議での提案資料④

30

2019年規制改⾰会議での提案資料

31

本⼈確認アシストAPIのご紹介

2020年2⽉19⽇

株式会社NTTドコモプラットフォームビジネス推進部

ウォレットビジネス推進室

1© 2020 NTT DOCOMO, INC. All Ｒights Reserved.

本⼈確認アシストAPIとは携帯電話の申込み時に本⼈確認したお客さま情報を活⽤して導⼊企業の本⼈確認を⽀援する有償のサービス（2017年6⽉提供開始）

導⼊企業

導⼊企業サービス

ドコモ

本⼈確認書類(原本)-運転免許証-マイナンバーカードなどドコモで保有する情報

-⽒名 , -住所-⽣年⽉⽇など

本⼈確認アシストAPI

ドコモのお客さま情報を活⽤する事で

⾮対⾯での本⼈確認が簡単かつ迅速に

【本⼈確認アシストAPIの機能タイプ】

〇フィルインタイプドコモが保有する本⼈確認済みのお客さま情報を提供

〇マッチングタイプ導⼊企業のお客さま情報と、ドコモが保有する本⼈確認済みのお客さま情報との照合結果を提供

API連携

⾮対⾯での本⼈確認が必要なお客さま情報

携帯電話不正利⽤防⽌法に基づき

回線契約時に対⾯で本⼈確認を⾏った

お客さま情報を保有

お客さま情報

32


本⼈確認アシストAPIの導⼊効果

⾝分証明書のアップロードや⼊⼒項⽬の多さによる途中離脱を改善したい

例① 会員登録（フィルインタイプ）例② 2段階認証（マッチングタイプ）

本⼈確認済のお客さま情報でお客さまの負担を軽減

⾝分証明書のアップロードを不要になりお客さまの負担軽減

⾃動⼊⼒による登録完了率の向上

⾼いセキュリティと利便性、コスト削減を両⽴した認証を実現したい

回線認証での⾼いセキュリティ初期設定が不要⾃⾝の携帯電話があれば操作完了

課題

機能群

解決⼿段

導⼊効果

ドコモのお客さま情報との照合でセキュリティ向上


本⼈確認アシストAPIの画⾯遷移（例）

フィルイン結果表⽰

ドコモ太郎

⽒名

東京都千代⽥区・・・

住所

090-1234-5678

電話番号

新規会員登録

1234567890・・・・

免許証番号

1991.08.14

⽣年⽉⽇

お客さまの個別同意2

⽒名

住所

電話番号

新規会員登録

免許証番号

⽣年⽉⽇

dアカウント認証（お客さまの特定）1

ドコモの提供ページ導⼊企業サービスの提供ページ導⼊企業サービスの提供ページ

導⼊企業サービスにID連携のボタンを⽤意いただき、ドコモでdアカウント認証、お客さまの個別同意を得た上で、APIコール

導⼊企業サービスにボタンを⽤意

○×カンパニー

サービスロゴ○×サービス

※本⼈確認アシストAPIは、導⼊企業サービスのご利⽤者様がdアカウント認証をした後に実⾏可能 ※同意は導⼊企業ごとに実施し、事後の同意解除が可能

▼携帯キャリア機能で⼊⼒・確認(⾝分証アップロードが省略できます)

▼⼊⼒フォーム

＜WiFi︓dアカウントのID/PWD＞

＜3G/LTE︓ネットワーク暗証番号＞

ドコモで会員登録

33


本⼈確認アシストAPIの強み⾝元確認・当⼈認証・ID連携を兼ね備えた本⼈確認⽀援を提供

⾝元確認当⼈認証 ID連携携帯電話不正利⽤防⽌法に基づき本⼈確認（⽒名・住所・⽣年⽉⽇）

スマートフォンに親和性の⾼い認証⽅法を提供

dポイント・d払い・ドコモ払いで加盟店と連携

運転免許証

マイナンバーカード

健康保険証

在留カード

のいずれか1点

のいずれか1点

補助書類

または

dアカウント認証（ID/パスワード）

回線認証＋暗証番号

⽣体認証(FIDO認証)

OpenID Connect準拠のdアカウントログイン

本⼈確認アシストAPIで提供

ドコモの通信設備下(3G/LTE)に限って当⼈認証を⾏う。スマホ・タブレット

の利⽤者に限定可能

スマホの⽣体認証機能を利⽤した認証⽅法


本⼈確認書類画像確認

登録内容確認⽒名ドコモ太郎

ふりがなどこもたろう

（例）フィルインタイプを導⼊した場合の効果

現状

導⼊後

画像選択画像登録

お客さま情報の登録

「ドコモで確認」押下

数時間…

⽬視確認

⾃動化

判定ロジック

⼈が確認

暗証番号確認

確認

同意画⾯

暗証番号

本⼈確認アシストAPI連携（ドコモ画⾯）

同意

下記情報を○○社に提供します

本⼈確認書類のアップロードや⼊⼒項⽬の多さに抵抗感を抱き、途中離脱する⼈が多い。確認に時間がかかる。

本⼈確認書類のアップロードが「不要」となり、お客さまの「負担が軽減」され⾮対⾯での本⼈確認が効率よく⾏えます。本⼈確認が「即時完了」します。


基本情報⼊⼒

導⼊効果

課題

ドコモで確認

NTTドコモのご契約者は、本⼈確認書類のアップロードが不要です

携帯電話番号

*******6789


⽒名

ふりがな

電話番号

⽣年⽉⽇

住所

本⼈確認

お名前

ふりがな

登録内容確認

⽒名ドコモ太郎

ふりがなどこもたろう

電話番号 ******6789

⽣年⽉⽇ 19910814

住所 XXXXXXX

• ⽒名• ⽣年⽉⽇

撮影

▼⽅法本⼈確認書類画像の登録をお願いします。

画像の選択

ご本⼈確認

登録戻る

ご本⼈確認画像の確認

利⽤規約に同意

即時︕︕

本⼈確認書類撮影不要

本⼈確認完了

本⼈確認完了

34


（例）マッチングタイプを導⼊した場合の効果

現状

2段階認証起動 OTP/SMS/乱数表確認ワンタイムパスワード⼊⼒

認証画⾯ 2段階認証ログイン画⾯

ユーザーID

パスワード

ログイン

ログイン

2段階認証を導⼊すると、利便性が「低下」し、運⽤コストが「増加」する。

「ドコモで確認」押下ログイン画⾯

ユーザーID

パスワード

ログイン

ログイン

導⼊後

WiFi環境からのアクセスは無効とし、ご利⽤中の携帯電話からのアクセスのみを有効とする設定、「回線認証限定オプション」をご利⽤頂くことにより、「⾼いセキュリティ」を実現することができます。

WiFi環境からのアクセスは無効とし、ご利⽤中の携帯電話からのアクセスのみを有効とする設定、「回線認証限定オプション」をご利⽤頂くことにより、「⾼いセキュリティ」を実現することができます。

同意画⾯

本⼈確認アシストAPI連携（ドコモ画⾯）

同意

下記情報を○○社に提供します。

• ⽒名• ⽣年⽉⽇

ログイン

ワンタイムパスワード

123987ログイン

ワンタイムパスワード

回線認証

2段階認証

ドコモで確認

暗証番号確認

確認

暗証番号

携帯電話番号

*******6789

導⼊効果

課題

ドコモのお客さま情報

マッチング結果

ログイン成功

ログイン成功

登録済情報との⼀致確認

OK

照合


本⼈確認アシストAPIで利⽤できる情報フィルイン・マッチングともに、契約者情報・本⼈確認書類情報・利⽤者情報が利⽤可能

カテゴリ提供情報詳細

契約者情報

携帯電話番号携帯電話番号

⽒名姓、名、姓(かな)、名(かな)

住所住所(すべて)、住所(⼤字通称・字丁⽬・⼩字・番地・枝番・⼩枝番・⽅書)、住所(市区町村、都道府県、郵便番号)

⽣年⽉⽇回線を契約している⽅の⽣年⽉⽇

連絡先電話番号契約者住所などの連絡先電話番号(市外局番、市内局番、加⼊者番号)

本⼈確認書類情報

証明書区分回線契約時にお客さまからご提⽰頂いた本⼈確認書類の区分

証明書番号回線契約時にお客さまからご提⽰頂いた本⼈確認書類の番号

⼿続き⽇お客さまが回線契約をした⼿続き⽇

利⽤者情報⽒名姓、名、姓(かな)、名(かな)

⽣年⽉⽇回線を利⽤している⽅の⽣年⽉⽇

35


【参考】本⼈確認アシストAPIの技術仕様概要本⼈確認アシストAPI（マッチングタイプ・フィルインタイプ）は下記条件のもとに提供条件概要詳細

対象ドコモの個⼈回線契約者(利⽤者) 携帯電話回線契約時の本⼈確認ができる個⼈の回線契約者(利⽤者)を対象※ドコモ以外のお客さまや、法⼈回線契約者(利⽤者)は⾮対象

お客さま認証⽅式 dアカウント認証 dアカウント認証にて、OpenID Connectに準拠した認証⽅式を採⽤

お客さま同意認証時に都度お客さま同意 dアカウントの認証シーケンスの中で、お客さま同意画⾯を表⽰する

導⼊企業認証⽅式 OpenID Connect OpenID Connectにおけるclient_id、client_secretにて導⼊企業を認証

(OpenID ConnectはOAuth2.0の上位互換)

通信⽅式 HTTP(S) データ保護の観点からHTTPSによる通信の暗号化を利⽤

データ形式 JSON形式 OpenID ConnectがJSON形式を利⽤しているため、APIについても同様にJSON形式を採⽤

⽂字コード UTF-8 APIの各項⽬の⽂字コードはUTF-8を利⽤

通信路インターネット経由インターネット経由でのアクセスをすることを想定し、専⽤線等の利⽤は必要ない。リクエスト元のIPアドレスでアクセス制御を⾏う

お客さま

導⼊企業ドコモインターネット

導⼊企業認証(client_id, client_secret)HTTPS POST⽅式(JSON)

dアカウント認証(OpenID Connect)お客さま同意サービス利⽤


【参考】JSON形式によるAPI項⽬の表現APIの項⽬はJSON形式で返却されます。各APIの電⽂イメージは下図のとおりです。

HTTP/1.1 200 OKContent-Type: application/jsonContent-Length: xxxDate: Mon, 13 Apr 2015 04:26:04 GMTCache-Control: no-storePragma: no-cacheConnection: close

{“subscriber_name_match”:”true”,“subscriber_phone_match”:”true”,“subscriber_birthdate_match”:”false”}

HTTP/1.1 200 OKContent-Type: application/jsonContent-Length: xxxDate: Mon, 13 Apr 2015 04:26:04 GMTCache-Control: no-storePragma: no-cacheConnection: close{“subscriber_family_name”:”ドコモ”,“subscriber_given_name”:”太郎”,“subscriber_mobile_phone”:”+81 90 1234 5678”,“subscriber_birthdate”:”1980-10-01”,“subscriber_address”:{

“formatted”:”東京都港区港南⼆丁⽬１ドコモ品川ビル”,”street_address":"港南⼆丁⽬¥n１¥nドコモ品川ビル”,”locality”:”港区”,”region”:”東京都”,”postal_code”:”1080075”,”country”:”JP”},

“identification_1_type”:”01”,“identification_1_number”:”1234567890”}

POST /docomo/prod/v1/customerinfo/match1HTTP/1.1Host: api.apl01.spmode.ne.jpAuthorization: Bearer exampleAccessToken12345678901234x-ibm-client-id: example-client-idx-ibm-client-secret: example-client-secretContent-Type: application/jsonContent-Length: XX{“subscriber_name_match”:”ドコモ太郎”,“subscriber_phone_match”:”0312345678”,“subscriber_birthdate_match”:”19801001”}

マッチングタイプリクエスト︓

レスポンス︓

フィルインタイプ

JSONオブジェクト

レスポンス︓

POST /docomo/prod/v1/customerinfo/provide1 HTTP/1.1Host: api.apl01.spmode.ne.jpAuthorization: Bearer exampleAccessToken12345678901234x-ibm-client-id: example-client-idx-ibm-client-secret: example-client-secret

リクエスト︓

36


【参考】シーケンス図

お客さま導⼊企業ドコモ

リダイレクト

Token 払出要求

Token 払出応答(ユーザ識別⼦)

フィルイン要求

フィルイン応答

ドコモで確認ボタン押下

顧客DB

1

2

3

4

会員登録

認証

個別同意

登録完了

認証要求

リダイレクト

登録完了画⾯を返す

Redirect URIにアクセス

認証画⾯

個別同意画⾯

登録完了画⾯

2

3

4

新規会員登録画⾯1

課⾦対象

顧客DB登録完了4

⾝元確認

当⼈認証


ご清聴ありがとうございました

https://www.nttdocomo.co.jp/biz/service/kyc/

詳しくは下記のWebサイトでご確認ください

本⼈確認アシストAPI 検索

https://id.smt.docomo.ne.jp/src/index_business.html

■dアカウントについては

dアカウント・コネクト検索

■本⼈確認アシストAPIについては

37

1

API

2020 2 19

2

I.

1.

2.

3.

4.

5.

6.

53

3

I.

4

TRUST

54

5

API https://developer.portal.bk.mufg.jp

OAuth2.0

JSON

REST

DS/IPS WAF API SSL/TLS

2 21 00 7 00

1call 10call/

API

string 102

string 142

string YYYY-MM-DD

string 999-9999

string 140

string 184

string 162

boolean 0 1

6

API

API

API

55

7

ID:PW:

8

56

9

2020 2 2

2020 8

EC

1010

57

Thank you

58

agenda - minister of economy, trade and industry...•...

Documents