本人確認の基本的枠組み

本人確認の構成要素

本ガイドラインでは、本人確認を構成する要素として「身元確認」と「当人認証」を定義する。さらに、身元確認や当人認証を他者（信頼できるIDプロバイダ）に依拠して実現する要素として「フェデレーション」を定義する。

それぞれの構成要素の定義を表２‑1に改めて示す。また、各要素による本人確認の概念図を図２‑1及び図２‑2に示す。

情報システムにおいて本人確認を実装するためのモデルとして、前述のフェデレーションによる本人確認を行う「連携モデル（Federated Model）」と、フェデレーションを行わない「非連携モデル（Non-Federated Model）」の2つのモデルを定義する。

本ガイドラインに基づく政府情報システムの検討においては、共通機能の活用による開発の効率化や費用負担の軽減等を目的として、まずは「連携モデル」の採用を第一候補として検討するものとする。

「非連携モデル」については、適切なIDプロバイダが存在しないなど「連携モデル」を採用し難い制約がある場合のみ、採用を検討するものとする。

連携モデルは、IDプロバイダとのフェデレーションによって、身元確認や当人認証に関する情報の連携を行うモデルである。

IDプロバイダを共通機能として複数のシステムが共同利用することで、本人確認に必要な機能が、対象手続を提供するそれぞれのシステムにおいて重複して開発・運用されることを回避できる。利用者にとっても本人確認書類の提示が一度で済むなど利便性の向上が期待できる。

なお、連携モデルの採用においては、対象手続が必要としている保証レベルを満たすIDプロバイダが存在していることが前提となる点や、フェデレーションに関する脅威への対策が必要となる点に留意が必要である。詳細については「３.３　フェデレーション（Federation）」を参照すること。

フェデレーションを行わず、サービス提供機能と本人確認機能を自システムのみで構築するモデルである。

自システム専用の本人確認機能を独自に構築できるが、連携モデルのような共同利用のメリットは得られず、利用者にとってもシステムごとに身元確認や当人認証を行う必要が生じるなど、連携モデルと比べて利便性が低下する点に留意が必要である。

前述の連携モデルと非連携モデルは、組み合わせて活用することも可能である。実装モデルを組み合わせる場合の一例を以下に示す。

身元確認は対象手続における独自の要件を満たすため「非連携モデル」として実装しつつ、当人認証は「連携モデル」によりIDプロバイダと連携して実現する
公平性の観点から、「連携モデル」による当人認証手法と「非連携モデル」による当人認証手法をいずれも提供し、利用者が手法を選択できるようにする
「連携モデル」によってIDプロバイダから取得した属性情報と、「非連携モデル」によって対象手続自らが入手・検証した属性情報とを組み合わせることで、申請者の身元確認を行う