Mon, 28 Nov 2016 07:26:26 +0000

DRAFT NIST Special Publication 800-63A

Digital Authentication Guideline (翻訳版)

Enrollment and Identity Proofing Requirements (身元確認と登録時の要件)

Paul A. Grassi
James L. Fenton
Naomi B. Lefkovitz
Jamie M. Danker
Yee-Yin Choong
Kristen K. Greene
Mary F. Theofanos


DRAFT NIST Special Publication 800-63A

Digital Authentication Guideline (翻訳版)

Enrollment and Identity Proofing Requirements (身元確認と登録時の要件)

Paul A. Grassi Applied Cybersecurity Division Information Technology Laboratory

James L. Fenton Altmode Networks Los Altos, CA

Naomi B. Lefkovitz Applied Cybersecurity Division Information Technology Laboratory

Jamie M. Danker National Protection and Programs Directorate Department of Homeland Security

Yee-Yin Choong
Kristen K. Greene
Mary F. Theofanos
Information Access Division
Information Technology Laboratory

Month TBD 2016

U.S. Department of Commerce
Penny Pritzker, Secretary

National Institute of Standards and Technology
Willie E. May, Under Secretary of Commerce for Standards and Technology and Director

Authority

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3541 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-63-3
Natl. Inst. Stand. Technol. Spec. Publ. 800-63-3, xxx pages (MonthTBD 2016)
CODEN: NSPUE2

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST. Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at http://csrc.nist.gov/publications.

Reports on Computer Systems Technology

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in Federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

Abstract

本書ならびに, SP 800-63-3, SP 800-63B そして SP 800-63C は, 電子認証を実装するにあたっての, 技術的そして手続き的なガイドラインである. 本書では電子認証におけるアイデンティティの検証と登録に焦点を当てている. 本書の中心は, Identity Proofing (身元確認) として知られているプロセスであり, 身元確認プロセスにおいては, 申請者が自分自身を確実に特定可能な証拠をクレデンシャルサービスプロバイダ (CSP) に提示することで, CSPは適切な身元保証レベルにおける当人の同一性を保証することが可能となる. 本書は, 3つの身元保証レベルにおいて, それぞれに必要な技術的な要件を定義する. NIST SP 800-63-1 と SP 800-63-2 の対応する章は, 本書の内容で置き換えられる.

Keywords

authentication; credential service provider; electronic authentication; digital authentication; electronic credentials; digital credentials; identity proofing.

Acknowledgements

The authors would like to acknowledge the contributions and guidance of our international peers, including Adam Cooper, Alastair Treharne, and Julian White from the Cabinet Office, United Kingdom, and Tim Bouma from the Treasury Board of Canada Secretariat, Government of Canada.

The authors would also like to acknowledge the thought leadership and innovation of the original authors: Donna F. Dodson, Elaine M. Newton, Ray A. Perlner, W. Timothy Polk, Sarbari Gupta, and Emad A. Nabbus. Without their tireless efforts, we would not have had the incredible baseline from which to evolve 800-63 to the document it is today.

Audience

Compliance with NIST Standards and Guidelines

Conformance Testing

Trademark Information

Requirements Notation and Conventions

The terms “SHALL” and “SHALL NOT” indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted.

The terms “SHOULD” and “SHOULD NOT” indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.

The terms “MAY” and “NEED NOT” indicate a course of action permissible within the limits of the publication.

The terms “CAN” and “CANNOT” indicate a possibility and capability, whether material, physical or causal.

Executive Summary

本ガイドラインは, 申請者である個人を, クレデンシャルサービスプロバイダ (CSP) に対してどのように証明し, 有効な Subscriber として登録するかといった内容を扱っている.

身元保証レベル (IAL: Identity Assurance Level) は, 身元確認のプロセスおよび特定個人と “認証するために必要な識別子” を紐付ける際の堅牢性を示す. 身元保証レベル (IAL) と認証保証レベル (AAL: Authenticator Assurance Level) を分離することによって, 仮名でも構わないものの強力な認証を必要するアプリケーションや, “認証するために必要な識別子” を発行する部分と, クレデンシャルを確立する部分 (個々人とそれらを “認証するために必要な識別子” を紐付ける部分) を分離したいアプリケーションなどにも, 広く対応している.

IAL は3つのレベルに分かれており, リスクプロファイル並びに, 無効なアイデンティティや不正なアイデンティティによるアクセスで損害が発生する可能性に基づいていずれのレベルに該当するかを選択する. 各IALについては以下に示す通り.

IAL 1: このレベルでは, 申請者の身元証明の確認は必須でない. よって, そのアイデンティティの認証プロセス時に提示されるいかなる属性情報も単に申請者自身が主張している内容でしかない.

IAL 2: レベル2におけるアイデンティティでは, 現実世界で実在すること, そのアイデンティティがどの個人に対応するかの識別, ならびにそれが検証されていることが証明される. レベル2からは, リモートあるいは対面によるの身元確認が必須となる. Attributes は RP に対して仮名化された状態で Verified Attributes とともに CSP によって Assert されてもよい (MAY).

IAL 3: レベル3においては, 対面での身元確認が必須である. 属性情報の確認は, 認定されているCSPによって証明される内容で行わなければならない. レベル2と同様, Attributes は RP に対して仮名化された状態で Verified Attributes とともに CSP によって Assert されてもよい (MAY).

Table of Contents

1. Purpose

2. Introduction

3. Definitions and Abbreviations

4. Identity Assurance Level Requirements

5. Identity Resolution, Validation and Verification

6. Leveraging Antecedent Proofing Events

7. Threats and Security Considerations

8. Privacy Considerations

9. Usability Considerations

10. References

1. Purpose

本書は, それぞれの身元保証レベル (IAL: Identity Assurance Level) に応じて, オンライン上にあるリソースへのアクセスを希望する申請者 (Subscriber) の登録と身元確認 (Identity Proofing) のための要件を提示している. この要件は, 個々人が自身の Identity を主張できるように, 提示される本人確認証明書類によるの正当性, 許容性, 有効性についてそれぞれ詳細化されている. また, クレデンシャルサービスプロバイダ (CSP: Credential Service Provider) が登録レコードを確立・管理し, Authenticator (CSP が発行したものあるいは申請者から提供されたもの) と登録レコードを紐付けることに関する CSP の責任についても記述している.

2. Introduction

人々を認証するにあたっての課題の1つは, 物理的な存在である特定人物と彼らのオンライン上での行動を関連付けることである. これは, 必要ではなかったり望ましいくない場合もある一方で (例えば匿名や仮名の利用が必要なケース), 物理的な人物との紐付けを確実に確立することが重要である場合もある. 例えば, 医療関連情報を取得したり, 金融関連の取引を行ったりする場合である. その他, 規定上の理由から紐付けが必要な場合や (金融界における Know Your Customer 要件など), ハイリスクな行動に対する責任の所在を明確にするために必要な場合もある (水力発電ダムからの水の放出など).

RP にとっては, トランザクションを実行しているユーザについてなんらか知ることが望ましい一方, 現実世界での人物のアイデンティティは必要でないようなような場合もある. 例えば, サービスの質を維持するため, 国税調査や公務員からの嘆願でユーザの郵便番号を知る必要が出てきた場合, それぞれのユーザが物理的にどの人物に紐づくかといった情報まで知ることは必要ではないし, 望ましくもない.

2.1. Expected Outcomes of Identity Proofing

身元確認の目的は以下に記す通り:

2.2. Identity Assurance Levels

申請者のアイデンティティの保証レベルは, 以下に記す3つの IAL のうちの1つを利用する:

身元保証レベル1 (Identity Assurance Level 1) このレベルでは, 申請者の身元証明の確認は必須でない. よって, そのアイデンティティの認証プロセス時に提示されるいかなる属性情報も単に申請者自身が主張している内容でしかない.

身元保証レベル2 (Identity Assurance Level 2) レベル2におけるアイデンティティでは, Claimed Identity が現実世界で実在すること, そのアイデンティティがどの個人に対応するかの識別, ならびにそれが検証されていることが証明される. レベル2からは, リモートあるいは対面によるの身元確認が必須となる. Attributes は RP に対して仮名化された状態で Verified Attributes とともに CSP によって Assert されてもよい (MAY).

身元保証レベル3 (Identity Assurance Level 3) レベル3においては, 対面での身元確認が必須である. 識別に用いられる属性は, 認可され訓練された CSP の担当者によって検証されなければならない. レベル2と同様, Attributes は RP に対して仮名化された状態で Verified Attributes とともに CSP によって Assert されてもよい (MAY).

身元保証レベル2と3では, CSP から RP に送る属性情報の数に制限をかけるたり, 属性提供方法を工夫することで, 仮名性を確保することもできる. 例えば, RP が正確な誕生日を必要としているけれども他の詳細な個人情報を必要としていない場合, RP は CSP に要求するのは利用者 (Subscriber) の誕生日だけにとどめるべきである. RP は CSP に Attribute Claim を要求するのが望ましい. 例えば, 利用者が18歳より年上か否かを知流必要がある場合, RP は boolean の値として要求するべきであり, 年齢を確認するためといって生年月日全てを要求するべきではない.

なお, 多くの場合, 各個人は登録時に身元確認プロセスを経て1つ以上の Authenticator と紐づけられることになるため, CSP とのインタラクションに関してはトランザクションが仮名とはならない.

それぞれの身元保証レベル (IAL) に必要な要件の詳細は, Section 4Section 5 を参照のこと.

3. Definitions and Abbreviations

Authentication 分野で使われる用語は幅広く, 多くの用語は SP 800-63 との整合性を保っているものの, いくつかは本リビジョンから定義が変更になっている. 多くの用語に複数の定義がありうるため, 本ドキュメントにおける定義を明確にする必要がある.

本セクションでは, 本ドキュメントで利用される用語の定義を行う. SP 800-63 ドキュメント群のその他のドキュメントで利用される定義や略語は, それぞれのドキュメントにて定義する.

Address of Record

許可された手段によって特定個人とのコミュニケーションに利用可能な, 有効かつ検証済の (物理的またはデジタルの) 場所情報.

Applicant

登録および Identity Proofing のプロセスを受けている主体.

Assurance

[OMB M-04-04] および本ドキュメントのコンテキストにおいては, Assurance とは 1) 当該 Credential を発行された個人の Identity を確立する審査プロセスにおける確からしさの度合い, および 2) 当該 Credential の提示者が当該 Credential の発行対象の個人と同一であることの確からしさの度合い, の2つを持って定義される.

Asymmetric Keys

公開鍵と秘密鍵からなる鍵ペア. 暗号化と復号, 署名生成と署名検証など, 対となるオペレーションに用いられる.

Attack

認可を持たない個人が, Security Control を無効化する試み. 例えば Credential Service Provider を騙して正規の Subscriber として登録するなど.

Attacker

不正な意図を持ち情報システムに不正アクセスする主体.

Attribute

人や物に関する生来の性質や特徴.

Attribute Claim

Subscriber のプロパティをアサートする Statement. Identity Information を含まなくても良く, フォーマットは問わない. 例えば “birthday” という属性に対して, “18歳以上” とか “12月生まれ” などが Attribute Claim となりうる.

Attribute Value

Subscriber のプロパティをアサートする完全な Statement. フォーマットは問わない. 例えば “birthday” という属性に対して, “12/1/1980” や “December 1, 1980” などが Attribute Value となりうる.

Authentication

User や情報システムの Identity について確証を得るプロセス.

Authentication Protocol

Claimant (要求者) が自身の Identity を確立するための正当な Authenticator を保持および制御していることを示す, Claimant と Verifier の間での一連のメッセージのやりとり. セキュアな Authentication Protocol は, Claimant が正規の Verifier とやりとりしていることも明示する.

Authenticator

Claimant が所有および管理するもので, 典型的な例としては暗号モジュールやパスワード等がある. Authenticator は Claimant の Identity を認証するために用いられる. SP 800-63 の前リビジョンにおいて token と呼ばれていたものと同等である.

Authenticity

データが意図された情報源から得られたものであるという性質.

Authoritative Source

CSP が Identity Proofing 実施時に Applicant が提出した身分証の有効性を確認できるように, 身分証 (Identity Evidence) 発行元 (Issuing Source) のもつ十分な量の正確な情報にアクセスできる, もしくは検証済みコピーを所有している主体. Issuing Source 自身が Authoritative Source であることもありうる. Authoritative Source は, Identity Proofing の検証フェーズで用いられる前に, 機関や CSP のポリシーによって決定されることも多い.

Biometrics

個人の行動や生体情報をもとに個人を自動認証すること.

本ドキュメントでは, Biometrics は Authenticator のアンロックや登録の否認防止目的で用いられることもある.

Claimant

1つ以上の Authentication Protocol により Identity を検証される主体.

Claimed Address

ある個人 (Applicant 等) が, 自分に到達可能だと主張する物理的位置. 居住地の住所や郵便の届く住所などを含む.

例えば, 外国籍のパスポートを所持している状態で米国に在住する人物であれば, Identity Proofing プロセスにおいて住所を要求されることになる. そう言った場合の住所は, “address of record” ではなく “claimed address” となろう.

Credential

ある Identity (および付加的属性) を Subscriber が所有ないしは管理する Authenticator に紐付ける信頼の置けるオブジェクトもしくはデータ構造.

一般的に Credential は Subscriber に管理されることが想定されるが, 本ドキュメントでは Subscriber の Authenticator と Identity の紐付けを確立する CSP 管理下の電子レコードを指すこともある.

Credential Service Provider (CSP)

Subscriber の Authenticator を発行もしくは登録し, Subscriber に電子的な Credential を発行する信頼された主体. CSP は自身が運営する Verifier を内包することもある. CSP は独立した第三者となることもあれば, 自身で発行した Credential を用いて自らサービスを提供することもある.

Derived Credential

事前に発行済の Credential に紐づいた Authenticator を所有・管理していることを証明することで発行される Credential. このような Credential を発行することで, 再び Identity Proofing プロセスを繰り返す必要がなくなる.

Digital Authentication

情報システムに対して, 電子的に表現されたユーザーの Identity の確からしさを確立するプロセス. SP 800-63 では以前まで Electronic Authentication と呼ばれていたもの.

Digital Signature

秘密鍵を用いてデータに電子署名を行い, 公開鍵を用いて署名検証を行う, Asymmetric Key を用いたオペレーション. Digital Signature は Authenticity Protection (真正性), Integrity Protection (完全性), Non-Repudication (否認防止) を提供するが, Confidentiality Protection (機密性) は提供しない.

Electronic Authentication (E-Authentication)

Digital Authentication 参照.

Enrollment

Applicant が CSP の Subscriber となるべく申し込み, RA が CSP の代理として Applicant の Identity を確認するプロセス.

Identity

特定のコンテキストにおいてある人物を他と区別できるかたちで表現する属性の集合.

Identity Assurance Level (IAL)

Applicant の Claimed Identity が本人の本物の Identity であることの確からしさの度合いをあらわす指標.

Identity Proofing

CSP が Credential 発行のためにある人物に関する情報を収集および検証するプロセス.

Issuing Source

身分証 (Identity Evidence) として利用可能なデータやドキュメントを責任を持って生成する Authority.

Knowledge Based Verification

Private Database 内で当該個人の Claimed Identity と関連づけられている情報を知っていることを根拠とした Identity Proofing. Knowledge Based Authentication (KBA) や Knowledge Based Proofing (KBP) とも呼ばれる.

Network

オープンなコミュニケーションの伝達手段. Internet がその代表例である. Network は Claimant とその他の主体の間でメッセージを伝達するために用いられる. 特に明示されない限り, Network のセキュリティは前提とされず, オープンであり, 任意の主体 (Claimant, Verifier, CSP および RP) 間の任意の点において自発的な攻撃 (なりすまし, Man-in-the-Middle, Session Hijacking 等) や受動的な攻撃 (盗聴等) にさらされうるものと想定される.

Personally Identifiable Information (PII)

OMB Circular [A-130] で定義されているように, Personally Identifiable Information とは個人の Identity を識別したり追跡するために用いられる情報である. 単体の情報で個人を識別・追跡可能なものもあれば, 特定の個人に紐付け済もしくは紐付け可能なその他の情報と組み合わせることで識別・追跡可能となるものもある.

Practice Statement

Authentication プロセスに関わる主体 (CSP, Verifier etc.) がプロセス実施の規範とする公式の規定. 通常, 各主体のポリシーや実施手法などが記載され, 法的拘束力を持つこともある.

Protected Session

2者間でやりとりされるメッセージを, Session Key と呼ばれる Shared Secret を用いて暗号化し, Integrity を保護するセッション.

当該セッション内で, ある主体が Session Key に加えて1つ以上の Authenticator を所有していることを証明し, もう一方の主体が当該 Authenticator に紐づく Identity を検証できる場合, 当該主体は Authenticated であると言う. もし両主体が共に Authenticated となる場合, この Protected Session は Mutually Authenticated であると言える.

Pseudonym

実名 (Legal Name) 以外の名前.

Public Key

Asymmetric Key ペアの公開鍵. データへの署名検証や暗号化に用いられる.

Remote

(Remote Authentication や Remote Transaction といったコンテキストで) 単一組織によるセキュリティ対策のみでは End-to-End での確実な保護が期待できないような状況下での, ネットワーク接続されたデバイス間の情報交換.

注) Internet を介した情報交換はすべて Remote とみなされる.

Social Engineering

人を欺いてセンシティブな情報を露呈させたり, Unauthorized Access を得たり, 人と付き合いながら信頼を獲得した上で詐欺を行う活動.

Subscriber

CSP によって自身の Credential をある Authenticator に紐づけられる主体.

Token

Authenticator 参照.

Trust Anchor

ハードウェアやソフトウェエアに直接埋め込まれていたり, Out-of-band な手法によりセキュアに提供されたりすることで Trust される, Public Key もしくは Symmetric Key. 他の Trusted Entity の保証を受けて Trust を得るものは Trust Anchor とは呼ばない (Public Key Certificate 等).

Valid

ある ID (身分証明書) について, それが期限切れや失効していないこと.

Virtual In-Person Proofing

Remote の Identity Proofing プロセスのうち, 物理的・技術的・手続き上の手段により Remote Session であっても物理的に対面 (In-person) の Identity Proofing と同等であると考えられるもの.

4. Identity Assurance Level Requirements

本書で扱うパラダイムは, 個人 (この段階では申請者) が, 身元確認を行われて登録されるプロセスである. この段階において, 申請者の身元証明となる書類と属性情報が集められ, 一意に特定されるようなレコードとして登録され, 検証され, 有効になる. これらの属性情報は次に, SP 800-63B に記載されている Authenticator に紐づけられる.

身元確認が必要な唯一の理由は, 身元確認をを行うことで, 申請者が彼/彼女自身が主張する通りの人物であることを確実にするということである. これには身元確認を達成するのに必要となる最低限の属性情報についての, 証明情報の提示, 妥当性の確認, そして検証が含まれている. このような核となる属性情報はこれらを含む (最低限必要な場合はその他の情報も含む):

  1. フルネーム
  2. 生年月日
  3. 住所

Applicant の Identity Proofing を行うプロセスにおいて, CSP が 追加の情報を収集することは許容される. ただし Valication と Verification は本ドキュメントで定める要件に従い, Applicant が CSP の属性収集・保存に対する明示的な同意を行うことが前提である.

4.1. Process Flow

Figure 4-1 は「身元証明」と「登録」についての流れの概要を, 基本的な要件に対応するように記したものである.

Figure 4-1. The Identity Proofing Process

4.2. General Requirements

Table 4-1 は, M-04-04 の保証レベル (LOA) を忠実に厳守した場合, 身元保証レベル (IAL) のどのレベルに対応するかを記している.

Table 4-1. Legacy M-04-04 IAL Requirements

M-04-04 Level of Assurance (LOA) Identity Assurance Level (IAL)
1 1
2 2
3 2
4 3

Table 4-2 は, M-04-04 の保証レベル (LOA) を満たすことが許容されている身元保証レベル (IAL) の拡張セットを記している. 各機関は, M-04-04の保証レベル (LOA) に基づいて, 対応するIALを選択する必要がある (SHALL). また, 各機関は, より強固な身元確認を行うことにおけるプライバシーリスクを考慮するべきであり (SHOULD), 事業目的を敏感に考慮して必要以上に高いIALを選択してはならない (SHOULD NOT).

Table 4-2. Recommended M-04-04 IAL Requirements

M-04-04 Level of Assurance Identity Assurance Level
1 1
2 1 or 2
3 1 or 2
4 1, 2 or 3

以下は, いかなる CSP においても, IAL2 もしくは IAL3 の身元確認を行う場合に必要な要件である.

  1. 身元確認は, サービスや利益を享受するのに適切である/権利があるか否かの決定ために行うのは好ましくない (SHALL NOT).

  2. CSP は, 他のいかなる属性情報をもってしても, ユーザを一意に特定することができない場合を除き, SSN を集めるべきではない (SHOULD NOT).

  3. 個人を特定できる情報 (PII) の収集は, 申請者の主張する内容が実在して有効であることを確認するため, また, 最善策に基づいて, ユーザを適切に一意に特定し, 検証し, 有効性確認を行うために必要な最低限に限定されるべきである (SHALL).

  4. 身元確認のために必要な属性情報を収集し, 記録・維持する目的について, CSP は, 申請者に対して情報を収集する際に明示的に通知を行わなければならない (SHALL). その属性情報が任意な情報の場合はもちろん, 身元確認を行うために必須な場合でも, また, その結果属性情報を提示しないという結果に至ったとしても, 通知を行う必要がある (SHALL).

  5. CSP は, いかなる目的でも次にあげる目的以外に身元確認時に収集し保存した属性情報を利用する際は, ユーザの明示的な同意を得なければならない (SHALL NOT): 身元確認, 認証, 認可, 属性情報の証明, その他法律または法的手続きを遵守するもの. CSP は同意をサービス利用条件とはしないこと (SHALL NOT).

  6. CSP は, 申請者の公平を保つ補償や身元確認で発生する問題に対応するための効果的な手段を提供しなければならない (SHALL). これれの手段は, 申請者からアクセスしやすく見つけやすいところに配置しなければならない (SHALL).

  7. 身元確認ならびに登録のプロセスは, 適切な文書化されたポリシー, あるいは Identity 検証時に実施すべき具体的な手順が指定された practice statement に従って行われるべきである (SHALL).

  8. CSP は申請者への ID 発行時に行った全ての手順の記録を維持しなければならない (SHALL). また, 身元確認時に提示された身分証の種類についても記録しておく必要がある (SHALL). CSP は次のことを決定するために, プライバシーのリスク評価を実施しなければならない (SHALL):

    a) 申請者の ID を発行するために, 本仕様に記載されている必須要件を超える手順を必要とするか否か.

    b) CSP が, PII (生体認証や身分証の画像やスキャンデータ, その他のコピー情報を含む) を身元確認時に登録し維持する必要があるか否か. 注) 特定の国家要件が適用される場合もある.

    c) それらの記録の維持期間. 注) 特定の国立公文書記録管理局 (NARA: Specific National Archives and Records Administration) の記録はその維持期間が適用される.

  9. 登録プロセスにて収集された全ての個人を特定できる情報 (PII) は, 機密性, 完全性, 情報源の帰属を確実にするため, 保護されるべきである (SHALL).

  10. 全ての身元確認のトランザクション (第三者とのトランザクションも含む) は, 認証済みで保護されたチャンネル上 (Authenticated Protected Channel) で行われるべきである (SHALL).

  11. CSP は, 本書に記載されている必須要件の代わりとして追対策を利用しない限り, 詐称に対する対策を適用することで, CSP はリモートでの身元確認に対して追加の信頼情報を得るべきである (SHOULD). 例えば, geolocation の調査, 申請者のデバイス特性の調査, 行動特性の評価, あるいは Death Master File などの重要な統計リポジトリをチェックするなど. そして, それらの対策はプライバシーリスク評価を実施されなければならない (SHALL).

  12. CSP は, 身元確認および登録プロセス実施しなくなった場合には, CSP は PII を含む機微データの完全な破棄, および, 保管期間中の認められていない不正アクセスからの保護について責任を負わなければならない (SHALL).

  13. CSP が公的機関であるか民間機関であるかにかかわらず, 身元認証サービスとして提供され利用される機関は次に挙げる要件が適用される:

    a) プライバシー保護法や個人情報保護法に基づいて, 身元確認を行うために PII の取得が必要であるか否かを決定するため, 公的高等機関に相談するべきである (SHALL).

    b) その結果 PII の取得が必要である場合, 収集し保存する目的についてを公表するべきである (SHALL).

    c) 2002年施行の電子政府法 (the E-Government Act of 2002) に基づいて, 身元確認を行うために PII の取得が必要であるか否かを決定するため, 公的高等機関に相談するべきである (SHALL).

    d) その結果 PII の取得が必要である場合, プライバシーインパクトの評価結果を公表するべきである (SHALL).

4.4. Identity Assurance Level 1

CSP は申請者の身元確認を行ってはならない (SHALL NOT). 申請者が CSP に申請する属性情報の内容は自己申告でよい (MAY).

4.5. Identity Assurance Level 2

IAL2 では, 対面での他リモートでの身元確認も許容されている. このレベルでは, より多くのユーザが対象となるように, 正常な申請者が身元確認を完遂できないといった偽陰性 (false negative) を減らすように, そして悪意のある申請者による不正な身分証の提示は可能な限り検出できるように, 幅広い身元確認方法に対応する. CSP はこれらの要件以上の要件を設定してもよい (MAY).

CSP は Section 4.5.1 にしたがって身元確認を実装すべきである (SHOULD). CSP がサービスを提供する対象によっては, CSP は Section 4.5.2Section 4.5.3 にしたがった身元確認を実装しても良い (MAY).

4.5.1. IAL2 Conventional Proofing Requirements

4.5.1.1. Resolution Requirements

PII の取得は, ユーザを一意に識別するために必要最低限な範囲に限定されるべきである (SHALL). 一般的な要件は Section 5.1 を参照のこと.

4.5.1.2. Evidence Requirements

利用可能な身分証について, 詳細の情報は Section 5.2, Identity Evidence Validation を参照のこと.

4.5.1.3. Validation Requirements

利用可能な身分証について, 詳細の情報は Section 5.2, Identity Evidence Validation を参照のこと.

4.5.1.4. Verification Requirements

利用可能な身分証についての詳細は Section 5.3, Identity Verification を参照のこと.

最低限, 強力な (STRONG) 強度を達成するプロセスにて申請者を検証すること.

4.5.1.5. Presence Requirements

CSP は対面での身元確認を行うべきである (SHOULD) が, リモートで行ってもよい (MAY). CSP は両方の方式での確認手段を提供すべきである (SHOULD).

4.5.1.6. Address Confirmation

4.5.1.7. Biometric Collection

CSP は否認防止や Re-Proofing の目的で Biometrics 情報を収集してもよい (MAY). Biometrics 収集についての詳細は SP 800-63B Section 5.2.3 を参照のこと.

4.5.1.8. Security Controls

CSP は [SP 800-53] やそれと等価の業界標準が定める Security Control の “moderate” レベルをベースとして, 適切に自身のユースケースに適合した対策を行うべきである (SHOULD). また moderate 基準が求める最低限の Assurance 要件を満たすべきである (SHOULD).

4.5.2. IAL2 Antecedent Proofing Requirements

Section 4.5.1. で定義するプロセスに相当する Proofing Transaction によって Proof されたものであれば, 既存 (Antecedent) の対面での身元確認結果を利用してもよい (MAY). 詳細については The Federal Bridge Certification Authority (FBCA) Certificate Policy (CP) の Section 3.2.3.1 Authentication of Human Subscribers for Medium Assurance および FBCA Supplementary Antecedent, In-Person Definition を参照のこと.

4.5.3. IAL2 Trusted Referee Proofing Requirements

Section 4.5.1. の要件を満たす身分証での登録ができない場合, 当該機関は Trusted Referee に身元確認の手助けを求めても良い (MAY). 詳細は Section 5.3.4. を参照のこと.

4.6. Identity Assurance Level 3

IAL3 では, IAL2 で必須なものに加えて, より強度の高い身分証の提示を必要とするなど, さらに厳しい要件が課せられる. 偽装や詐欺, その他影響の大きい損害から RP を守るため, 生体認証の利用を含む特定の追加プロセスが必要となる. 加えて, IAL3 における身元確認では対面での確認が必須となる. 詳細は Section 5.3.3 を参照のこと. CSP はこれらの要件を満たしているべきである (MAY).

4.6.1. Resolution Requirements

PII の取得は, ユーザを一意に識別するために必要最低限な範囲に限定されるべきである (SHALL). 一般的な要件は Section 5.1 を参照のこと.

4.6.2. Evidence Requirements

利用可能な身分証について, 詳細の情報は Section 5.2, Identity Evidence Validation を参照のこと.

4.6.3. Validation Requirements

利用可能な身分証についての詳細は Section 5.2, Identity Evidence Validation を参照のこと.

4.6.4. Verification Requirements

利用可能な身分証についての詳細は Section 5.3, Identity Verification を参照のこと.

最低限, 上級 (SUPERIOR) 強度を達成するプロセスにて申請者を検証すること.

4.6.5. Presence Requirements

全ての身元確認は対面で行うこと (SHALL). 詳細は Section 5.3.3 を参照.

リモートでの身元確認は許容されていない (SHALL NOT).

4.6.6 Address Confirmation

4.6.7. Biometric Collection

CSP は身元確認時, 申請者による登録の否認および Re-Proofing の防止のため, 顔写真や指紋などの生体情報を取得すべきである (SHALL). 生体情報の取得についての詳細は, SP 800-63B の Section 5.2.3 を参照のこと.

4.6.8. Security Controls

CSP は [SP 800-53] やそれと等価の業界標準が定める Security Control の “high” レベルをベースとして, 適切に自身のユースケースに適合した対策を行うべきである (SHOULD). また high 基準が求める最低限の Assurance 要件を満たすべきである (SHOULD).

4.7. Enrollment Code

登録コードにより, CSP はその連絡先 (Address of Record) が申請者の管理下にあることを確認できる. また, 登録レコードによって, 申請者は登録済みの情報 (Enrollment Record) との紐付けを再度確立できる状態になる. 登録レコードとの紐付けは, 身元確認のトランザクションと同じセッションで完遂されるとは限らない.

登録レコードは下記のいずれかにより構成されなければならない (SHALL):

4.8. Summary of Requirements

(Non-normative; refer to preceding sections for normative requirements)

The following table summarizes the requirements for each of the authenticator assurance levels:

Requirement IAL 1 IAL 2 IAL 3
Presence No requirements In-person and remote In-person
Resolution No requirements The minimum attributes necessary to accomplish identity resolution. KBV may be used for added confidence.  
Evidence Identity evidence is not required Two (2) pieces of STRONG evidence
OR
One (1) piece of STRONG evidence plus two (2) pieces of ADEQUATE evidence
One (1) piece of SUPERIOR evidence plus one (1) piece of STRONG evidence
OR
Two (2) pieces of STRONG evidence plus one (1) piece of ADEQUATE evidence
Validation No validation of evidence is required - Each piece of evidence must be validated with a process that is able to achieve the same strength as the evidence presented; For example, if two forms of STRONG identity evidence are presented, each evidence will be validated at a strength of STRONG.

- Validation against a third party data service SHALL only be used for one piece of presented identity evidence.
Same as IAL 2.
Verification No verification of identity is required - At a minimum, the applicant must be verified by a process that is able to achieve a strength of STRONG. - At a minimum, the applicant must be verified by a process that is able to achieve a strength of SUPERIOR.
Address Confirmation No requirements for address confirmation - Self-asserted address data SHALL NOT be used for confirmation.
- An enrollment code consisting of at least 6 random digits SHALL be included in address confirmation.
- May be sent to a mobile telephone (SMS or voice), landline telephone, email, or physical mailing address obtained from records.
- If the enrollment code is also intended to be an authentication factor, it SHALL be reset upon first use.
- Enrollment codes sent by means other than physical mail SHALL be valid for a maximum of 10 minutes; those sent to a postal address of record SHALL be valid for a maximum of 7 days but MAY be made valid up to 21 days via an exception process to accommodate addresses outside the direct reach of the U.S. postal service.
- A notification of proofing SHALL be sent via a different address of record than the destination of the enrollment code
- The CSP SHALL confirm address of record through validation of the address contained on any supplied, valid piece of identity evidence. - Self-asserted address data SHALL NOT be used for confirmation. - A notification of proofing SHALL be sent to the confirmed address of record.
Biometric Collection No No Yes

5. Identity Resolution, Validation and Verification

本章では, それぞれの IAL の要件を満たすよう, 身元証明において CSP が従わなければならない (SHALL) 手順や目的を記す. これらの要件は, 申請者により提示されたアイデンティティは CSP に登録しようとしている人物の実際のアイデンティティであり, 登録済の多くのユーザに対してスケーラブルな攻撃で影響を与えるにはかなりの時間と労力が必要であることを意図している.

5.1. Identity Resolution

  1. 身元確認プロセスにおいて用いられる情報は多岐に渡るため, それらの完全一致を求めるのは困難な場合もある. CSP は, 多様な形式の証明書 (Evidence), Authoritative レコード, 3rd-party レコードにまたがった Personal Information やその他の関連する Proofing データの差異を考慮した, 適切なマッチングアルゴリズムを採用してもよい (MAY). 利用するマッチングアルゴリズム・マッチングルールは, 公開するか何らかの方法で確認できるようにすべきである (SHOULD). 例えば, 上記で参照された規約や約款の一部として記載されているなど (MAY).
  1. “知っていること”に基づいた証明 (KBV) (“知っていること”に基づいた認証 (KBA) を指すこともある) は, 公的なデータベースから取得できる情報と, 申請者に問うて得られた内容を突合して確認することで提示されているアイデンティティが正当なものであることを証明する方法である. CSP は提示されたアイデンティティを一意に識別するためにKBVを利用してもよい (MAY).

5.2. Identity Evidence Validation

身元検証 (Identity Validation) の目的は, 申請者から最も適切な身分証 (パスポート, 免許証等) を取得し, その信憑性・有効性・正確性を確認することである. 身元検証は, 適切な身分証を取得しそれが正規の信頼できるものであることを確認するプロセス, その身分証に記載されているデータが正当かつ最新で現存する個人と結びついているものであることを確認するプロセスの, 2つから成る.

5.2.1. Identity Evidence Characteristic Requirements

本節では, 各強度における身分証の性質および品質の要件を記す.

5.2.1.1. Scoring of Identity Evidence

Table 5-1 では, 有効なユーザとして登録するために取得された身分証の品質について, 弱い (WEAK) ものから上級 (SUPERIOR) のものまで, 記している. 特に明記されていない限り, その強度を達成するためには少なくとも記載されている全ての性質を満たさなければならない (SHALL).

Table 5-1. Properties of Identity Evidence

強度 身分証の性質
受入不可 (UNACCEPTABLE) 身元確認を行わずに発行されたもの
弱い (WEAK) - 身元確認を行わずに発行されたもの

- 申請者の所有する連絡先に送付されたと合理的に認めることができるもの

- 対象者を一意に特定するための番号を1つ以上含んでいるもの
適切 (ADEQUATE) - 身元確認を行って発行されたもの

- 対象者の所有する連絡先に送付されたと合理的に認めることができるもの

- 対象者を一意に特定するための番号を1つ以上含んでいるもの
あるいは
- 対象者の写真, 画像, 生体情報のいずれかを含んでいるもの
あるいは
- 所有権をKBVで認することができるもの

- 電子情報を含む場合, 暗号化 または/かつ 適切な方法で保護されており, 情報の完全性が保証され, 発行元の信頼性が確認できるもの

- 物理的なセキュリティ機能を有する場合, それを複製するには特殊な技術が必要となるもの

- 有効期限切れでないもの
強力 (STRONG) - 対象者の正しいアイデンティティであることを合理的に証明できるよう設計されてた手順書に従って確認されたもの. その際に利用される手順書は, 公的機関あるいは認定機関により定期的に監査を受けるなければならない. 例えば, 2001年の米国愛国者法 (USA PATRIOT Act) やRed Flags Rule, 2003年の公正及び正確信用取引法 (FACT Act) の114章に従って設立された顧客識別プログラムのガイドライン (ustomer Identification Program guidelines) など.

- 対象者の所有する連絡先に送付されたと合理的に認めることができるもの

- 対象者を一意に特定するための番号を1つ以上含んでいるもの

- 身分証に記載されてい申請者の名前が, 発行時に公式にに知られているものであるもの. 偽名や, 名と姓のエイリアスやイニシャル, などは許容されない.

- 対象者の写真, 画像, 生体情報のいずれかを含んでいるもの

- 電子情報を含む場合, 暗号化 または/かつ 適切な方法で保護されており, 情報の完全性が保証され, 発行元の信頼性が確認できるもの

- 物理的なセキュリティ機能を有する場合, それを複製するには特殊な技術が必要となるもの

- 有効期限切れでないもの
上級 (SUPERIOR) - 対象者の正しいアイデンティティであることを合理的に証明できるよう設計されてた手順書に従って確認されたもの. その際に利用される手順書は, 公的機関あるいは認定機関により定期的に監査を受けるなければならない.

- 視覚的に申請者のアイデンティティが正しいことを確認され, されに実在確認がおこなわれたもの.

- 対象者の所有する連絡先に送付されたと合理的に認めることができるもの

- 対象者を一意に特定するための番号を1つ以上含んでいるもの

- 身分証に記載されてい申請者の名前が, 発行時に公式にに知られているものであるもの. 偽名や, 名と姓のエイリアスやイニシャル, などは許容されない.

- 対象者の写真, 画像のいずれかを含んでいるもの

- 対象者の生体情報を含んでいるもの

- 電子情報を含む場合, 暗号化 または/かつ 適切な方法で保護されており, 情報の完全性が保証され, 発行元の信頼性が確認できるもの

- 物理的なセキュリティ機能を有する場合, それを複製するには特殊な技術が必要となるもの

- 有効期限切れでないもの

5.2.2. Validating Identity Evidence

CSPが情報を収集際には, 下記のことが決定できる証明書が提示されていることを決定するため, 正確性・信憑性、関連情報と突合した結果の完全性を信頼出来るソースに対してチェックを行う.

5.2.2.1. Methods to Perform Identity Evidence Validation

Table 5-2 は, 身分証とそこに含まれる情報を検証するために, 許容不可 (UNACCEPTABLE) から上級 (SUPERIOR) までの品質を表示している.

Table 5-2. Validating Identity Evidence

強度 方法
受入不可(UNACCEPTABLE) 検証が失敗するもの.
弱い(WEAK) 身分証から取得できるすべての個人情報は,信頼できる発行元が発行したあるいは保持している情報と比較して有効であることが確認できるもの.
適切(ADEQUATE) - 身分証から取得できるすべての個人情報は,信頼できる発行元が発行したあるいは保持している情報と比較して有効であることが確認できるもの.
あるいは
- 物理的なセキュリティ機能および不正な改変がないことを適切な機能を利用して検証されたもの
あるいは
- 熟練した担当者により確認されたもの
あるいは
- 暗号化セキュリティ機能の完全性を確認することによって本物であると確認されたもの.
強力(STRONG) - 物理的なセキュリティ機能および不正な改変がないことを適切な機能を利用して検証されたもの*あるいは** 熟練した担当者により確認されたもの and appropriate equipment, confirming the integrity of the physical security features and lack of fraudulent modification あるいは 暗号化セキュリティ機能の完全性を確認することによって本物であると確認されたもの.
かつ
- 身分証から取得できるすべての個人情報は,信頼できる発行元が発行したあるいは保持している情報と比較して有効であることが確認できるもの.あるいは 発行元の発行/保持している情報と突合することで詳細情報が確認されたもの
上級(SUPERIOR) - 熟練した担当者により確認されたもの and appropriate equipment including the integrity of any physical and cryptographic security features.
かつ
- 身分証から取得できるすべての個人情報は,信頼できる発行元が発行したあるいは保持している情報と比較して有効であることが確認できるもの.

5.3. Identity Verification

身元検証の目標は, 実際に身分証を提示している実在する個人がClaimed Identity に紐付いていることを確認し, その紐づけを確立することである.

5.3.1. Identity Verification Methods

Table 5-3 details the verification methods necessary to achieve a given identity verification strength.

Table 5-3. Verifying Identity Evidence

Strength Identity Verification Methods
Unacceptable Evidence verification was not performed, or verification of the evidence failed. Unable to confirm that the applicant is the owner of the claimed identity.
Weak The applicant has been confirmed as having access to the evidence provided to support the claimed identity.
Adequate - The applicant’s ownership of the claimed identity has been confirmed by KBV. See Section 5.3.2 for more details.
OR
- The applicant’s ownership of the claimed identity has been confirmed by a physical OR biometric comparison of the applicant to the strongest piece of evidence provided. Physical comparison performed remotely SHALL include presentation attack detection as specified in Section 5.2.3 of SP 800-63B. Biometric comparison performed remotely SHALL adhere to the appropriate requirements as specified in Section 5.2.3 of SP 800-63B.
Strong - The applicant’s ownership of the claimed identity has been confirmed by physical comparison, using appropriate equipment, to a photograph/image. Physical comparison performed remotely SHALL include presentation attack detection as specified in Section 5.2.3 of SP 800-63B.
OR
- Biometric comparison, using appropriate equipment, of the applicant to the strongest piece of evidence provided to support the claimed identity. Biometric comparison performed remotely SHALL adhere to the appropriate requirements as specified in Section 5.2.3 of SP 800-63B.
Superior - The applicant’s ownership of the claimed identity has been confirmed by biometric comparison, using appropriate equipment, of the applicant to the strongest piece of evidence provided to support the claimed identity. Biometric comparison performed remotely SHALL adhere to the appropriate requirements as specified in Section 5.2.3 of SP 800-63B.

The CSP MAY use KBV to verify the identity of an applicant provided the requirements in Section Knowledge Based Verification Requirements are met.

5.3.2. Knowledge Based Verification Requirements

The following requirements apply to the identity verification steps for IAL 2 and 3. There are no restrictions for the use of KBV for identity resolution.

5.3.3. In-person Proofing Requirements

5.3.3.1 General Requirements

  1. The CSP SHALL have the operator view the biometric source (e.g., fingers or face) for presence of non-natural materials and perform such inspections as part of the proofing process.

  2. The CSP SHALL collect biometrics in such a way that ensures that the biometric is collected from the applicant, and not another individual. All biometric performance requirements in SP 800-63B, Section 5.2.3 Biometric Considerations apply.

5.3.3.2. Requirements for in-person proofing performed over remote channels

It is possible for a CSP to achieve the security and confidence comparable to in-peson proofing over remote channels. The following requirements establish comparability between in-person transactions where the enrollee in the same physical location as the CSP or when the enrollee is remote to the CSP.

Virtual in-person identity proofing and enrollment transaction SHALL meet the following requirements, in addition to the IAL 3 validation and verification requirements specified in Section 4.6:

  1. The CSP SHALL monitor the entire identity proofing transaction, from which the applicant SHALL NOT depart during the identity proofing session. For example, by a continuous high-resolution video transmission of the applicant.
  2. The CSP SHALL require all actions taken by the applicant during the enrollment and identity proofing process to be clearly visible to the remote operator. The operator SHALL direct the applicant as required to remove any doubt in the proofing process.
  3. The CSP SHALL require that all digital verification of evidence (e.g., via chip or wireless technologies) be performed by integrated scanners and sensors that are in the entire field of view of the camera and the remote, live operator.
  4. The CSP SHALL have an operator participate remotely with the applicant for the entirety of the enrollment and identity proofing session.
  5. The CSP SHALL require operators to have undergone a training program to detect potential fraud and to properly perform a virtual in-process proofing session.
  6. A CSP MAY have an attendant participate in-person, at the same physical location as the applicant, for the entirety of the enrollment and identity proofing session.
  7. The CSP SHALL employ physical tamper detection and resistance features appropriate for the environment in which it is located. For example, a kiosk located in a restricted area or one where it is monitored by a trusted individual requires less tamper detection than one that is located in a semi-public area such as a retail store.
  8. The CSP SHALL ensure that all communications take place over a mutually authenticated encrypted session.

5.3.4. Trusted Referee Requirements

The CSP MAY use trusted referees, such as notaries, legal guardians, medical professionals, conservators, persons with power of attorney, or some other form of certified/approved individuals that can vouch for or act on behalf of the individual in accordance with applicable laws, regulations, or agency policy. The CSP MAY allow an individual that has successfully completed identity proofing to act as a trusted referee for another individual. The CSP MAY use a trusted referee for both remote and in-person processes.

The CSP SHALL establish written policy and procedures as to how a trusted referee is determined and the lifecycle by which the trusted referee retains his/her status as a valid referee, to include any restrictions, as well as any revocation and suspension requirements.

The CSP SHALL determine the minimum evidence required to bind the relationship between the trusted referee and the applicant.

The trusted referee and applicant SHALL be present together for the entire proofing transaction.

The CSP MAY perform re-proofing on a regular basis, as defined by CSP policy, with the goal of satisfying the requirements of Section 4.5.1.

Considerations for Minors

The CSP SHALL give special consideration to the legal restrictions of interacting with minors unable to meet the evidence requirements of identity proofing.

The CSP SHOULD involve a parent or legal adult guardian as a trusted referee as described in Section 5.4.4.

Minors under age 13 require special consideration to ensure compliance with the Children’s Online Privacy Protection Act of 1998, 15 USC 6501-6505 and 16 CFR Part 312.

5.4. Binding Requirements

ユーザに Authenticator を紐付ける手順については, 800-63B, Section 6.1, Authenticator Binding を参照のこと.

6. Leveraging Antecedent Proofing Events

Possession of an authenticator, bound to an identity proofed at a given IAL, should allow a claimant to obtain additional authenticators, per CSP policy. This section details requirements for two specific use cases:

  1. A claimant obtains a secondary, or derived authenticator, for use only within the limits and authorizations of the primary authenticator. For example, this could be a derived PIV credential in federal use cases, or a temporary authenticator. See Section 6.1 for more details.
  2. An applicant seeks to obtain another primary authenticator from a CSP that did not issue the original authenticator. For example, if an applicant wants to switch CSPs and/or have another authenticator at a new CSP for other uses (e.g. basic browsing vs. financial). See Section 6.2 for more details.

6.1. Issuance Requirements for Derived Authenticators

This section applies when the secondary authenticator is directly tied to the authorizations of having, and proving possession of, a primary authenticator, typically issued by the same CSP.

6.1.1. General Requirements

  1. Before issuance, the CSP SHALL verify the original authenticator status. The CSP SHALL NOT issue a derived authenticator if status indicates any type of termination, disablement, revocation, or expiration.
  2. Before issuance, the CSP SHALL verify that the corresponding authenticator is possessed and controlled by the claimant.
  3. The derived authenticator SHALL be valid only as long as the subscriber is authorized to hold the original authenticator.
  4. The CSP SHALL record the details of the original authenticator used as the basis for derived authenticator issuance.
  5. The CSP SHOULD set the expiration of the derived authenticator to the expiration of the primary authenticator. There are instances where the derived authenticator need not be directly tied to the expiration of the primary authenticator as the derived authenticator can provide authentication services in its place, for example, while the expiring primary credential is being replaced.
  6. The derived authenticator SHOULD be issued at an AAL equivalent to the IAL the primary authenticator is bound to. The derived authenticator MAY be issued at an AAL higher than the IAL the primary authenticator is bound to. For example, if the primary IAL is 2, the authenticator that is issued could be AAL2 or 3. The IAL the derived authenticator is bound to SHALL remain at the IAL of the primary authenticator.

6.1.2. IAL 2 Requirements

6.1.3. IAL 3 Requirements

  1. The CSP SHOULD perform in-person issuance. This is important if the CSP needs to explicitly provision the authenticator to a trusted device and in-person is the only mechanism to ensure delivery and assurance.
  2. The CSP SHOULD check the status of the original authenticator daily.
  3. The CSP SHALL obtain and verify a copy of a biometric recorded when the primary authenticator was issued. An example of such a biometric is the signed biometric data object, however if the biometric reference is not available from the original AAL 3 authenticator, it may be obtained elsewhere, as long as its authenticity is assured.
  4. The CSP SHALL compare a fresh biometric sample obtained in person from the applicant to the reference biometric retained from the original, primary AAL 3 authenticator and determine that they match.
  5. The CSP SHALL determine that the authenticator of the original, primary authenticator meets all requirements of an AAL 3 authenticator.

6.2 Issuance Requirements for Accepting Results of Prior Proofing

Where the applicant already possesses an authenticator from a trusted CSP, the new CSP could choose to “inherit” the successful identity proofing transaction performed in a prior encounter at the original CSP, by verifying possession and control of the authenticator associated with the original CSP. The following details the requirements for the new CSP:

6.2.1. General Requirements

Unless otherwise specified, the term “CSP” referenced below pertains to the new CSP that depends on the identity proofing performed by the original CSP.

  1. Before issuance, the CSP SHALL verify that the corresponding authenticator is possessed and controlled by the claimant.
  2. Before issuance, the CSP SHOULD verify the original authenticator status. The CSP SHALL NOT issue a derived authenticator if status indicates any type of termination, disablement, revocation, or expiration.
  3. The CSP SHOULD query the authenticator status of the original CSP on a regular basis.
  4. The CSP SHALL determine the IAL associated with the original authenticator.
  5. The CSP SHOULD determine the proofing process used by the originating CSP. If the processes are materially different, the CSP SHOULD re-proof the identity.
  6. The CSP SHOULD assert the linear distance from the original proofing event. For example, if the applicant obtains a 3rd authenticator from a 3rd CSP, the 3rd CSP would assert “3” or “twice removed”. The assertion type, attribute name, and corresponding value is not in scope of this document.
  7. The CSP MAY check the status of the original authenticator on an interval basis.
  8. The new authenticator SHOULD be issued at an AAL equivalent to the IAL the primary authenticator is bound to. The new authenticator MAY be issued at an AAL higher than the IAL the primary authenticator is bound to. For example, if the primary IAL is 2, the new authenticator that is issued could be AAL2 or 3. The IAL the new authenticator is bound to SHALL remain at the IAL of the primary authenticator.

6.2.2. IAL 2 Requirements

6.2.3. IAL 3 Requirements

  1. Section 6.1.3. に挙げられている全ての要件に加えて,

  2. 申請者が登録したことを否認できないようにするため, 身元確認を行った時点での生体情報 (顔の画像データや指紋など) のサンプルを取得する (SHALL).

7. Threats and Security Considerations

登録のプロセスにおける脅威は, 2つの一般的なカテゴリのものが存在する. なりすまし, そしてインフラ (CSP) による不正あるいはインフラ (CSP) の乗っ取り. 本章における推奨事項は, なりすましの脅威への対処に焦点を当てている. インフラの脅威は, 一般的なコンピュータセキュリティ管理 (責任分離, 記録保持, 独立監査など) によって対処することとし, 本書の定める範囲外とする.

なりすまし攻撃を含む登録プロセスにおける脅威は, 身元確認時の書類 (データ) 送付時, オーセンティケーターとの結合時, クレデンシャルの発行時に発生する. Table 7-1 は, 登録および身元確認における脅威のリストである.

Table 7-1. 登録および身元確認プロセスにおける脅威

行動 脅威/攻撃
登録 偽装された身分証 偽装した運転免許章を利用して不正な申請が行われる.
  他者の証明書の不正利用 他人のパスポートを利用して不正な申請が行われる.
  登録の否認 登録済のユーザが, CSPに対して登録していないと主張し, 登録を否認する.
  Social engineering A malicious applicant manipulates an individual responsible for identity proofing in order to be enrolled as another individual.
発行 漏えい CSPにより, 登録済みユーザに発行されたキーが攻撃者によってコピーされ, オーセンティケーターを発行する際にCSPからユーザにそれが渡されてしまう.
  改ざん ユーザによって作成された新しいパスワードが攻撃者によって変更され, CSPでのクレデンシャル発行フェーズで登録されてしまう.
  不正発行 実際にはそのユーザではないにもかかわらずそうであると主張する攻撃者に対して, そのユーザのクレデンシャルを発行してしまう.
  Social engineering A malicious person manipulates an individual responsible for issuance in order to obtain a credential bound to another, valid subscriber.
    If social engineering was successful at enrollment, obtaining a credential requires no extra effort.

7.1. Threat Mitigation Strategies

登録プロセスにおける脅威は, なりすましでの完遂を困難にすること, 不正検出の精度を高めることによって抑制することができる. ここでの推奨事項は, 主になりすましをより困難にする方法についてである. とはいえ, 誰がなりすましを行ったのかを証明するのにも役立つ可能性のある手順や方法である. 各レベルにおいてこれらは, 申請中の人物が実在するか否か, 申請者は本当に申請中の人物として識別される権利を有するのかを決定し, 登録後に登録したことを否認できないようにするための方法としても採用される. 保証されるレベルが上がるに伴い, 簡単ななりすまし, 機械的ななりすまし, 関係者によるなりすましに対する抑制効果が高い方法が利用される. Table 7-2 は, 登録時・発行時における脅威の低減策のリストである.

Table 7-2. 登録時・発行時における脅威の低減策

行動 脅威/攻撃 低減策
登録 偽装された身分証 提示された証明書の物理的なセキュリティ機能を検証する.
  他者の証明書の不正利用 他の発行元あるいは信頼できるソースから得られた情報と突合して申請者の提示する身分証を検証する, あるいは生体情報を検証する.
    Verify Applicant-provided non-government issued documentation (e.g. electricity bills in the name of the Applicant with the current address of the Applicant printed on the bill, or a credit card bill) to help in achieving a higher level of confidence in the identity of the applicant.
  登録の否認 Have the applicant sign a form acknowledging participation in the enrollment activity.
  Social engineering Duplicate records check.
     
発行 漏えい Issue the authenticator in person, physically mail it in a sealed envelope to a secure location, or use a protected session to send the authenticator electronically.
  改ざん Issue credentials in person, physically mailing storage media in a sealed envelope, or through the use of a communication protocol that protects the integrity of the session data.
    Establish a procedure that allows the Subscriber to authenticate the CSP as the source of any authenticator and credential data that he or she may receive.
  不正発行 / Social engineering Establish procedures to ensure that the individual who receives the authenticator is the same individual who participated in the enrollment procedure.
    Implement a dual-control issuance process that ensures two independent individuals shall cooperate in order to issue an authenticator.

8. Privacy Considerations

This section is informative.

These privacy considerations provide information regarding the General Requirements set forth in Section 4.2.

8.1. Collection and Data Minimization

Section 4.2(2) does not permit the CSP to collect the SSN unless it is necessary for performing identity resolution and cannot be accomplished by collection of another attribute or combination of attributes. Unnecessary use of the SSN may be particularly vulnerable to misuse and can place the applicant at risk of harm such as through identity theft. The SSN may serve to achieve identity resolution for RPs, in particular federal agencies, that use SSNs to correlate a Subscriber to existing records. Thus, this document recognizes the role of the SSN as an identifier and makes appropriate allowance for its use. Note though that evidence requirements at the higher IALs preclude the usage of the SSN or the Social Security Card as acceptable identity evidence. The initial requirement in Executive Order (EO) 9397 for all federal agencies to use the SSN as a primary means of identification for individuals working for, with, or conducting business with their agency, has since been eliminated. Accordingly, EO 9397 cannot be referenced as the sole authority establishing the collection of the SSN as necessary. Prior to collecting the SSN for identity proofing, organizations should consider any legal obligation to collect the SSN, the necessity of using the SSN for interoperability with third party processes and systems, or operational requirements. Operational requirements should be demonstrated by an inability to alter systems, processes, or forms due to cost or unacceptable levels of risk. Operational necessity should not be justified by ease of use or unwillingness to change. Federal agencies should review any decision to collect the SSN relative to their obligation to reduce the collection and unnecessary use of SSNs under Office of Management and Budget Memorandum M-07-16, “Safeguarding Against and Responding to the Breach of Personally Identifiable Information,” May 22, 2007, which requires agencies to review their use of social security numbers in agency systems and programs to identify instances in which collection or use of the social security number is superfluous.

Section 4.2 (3) permits only the collection of PII necessary to validate the existence of the claimed identity and associate the claimed identity to the applicant, based on best available practices for appropriate identity resolution, validation, and verification. Collection of unnecessary PII can create confusion as to why information is being collected if it is not being used for the identity proofing service and leads to concerns about invasiveness or overreach which can lead to loss of applicant trust. In addition, the retention of any PII can become vulnerable to unauthorized access or use. Data minimization reduces the amount of PII vulnerable to unauthorized access or use and encourages trust in the identity proofing process.

Section 4.2(4) requires the CSP to provide explicit notice at the time of collection to the applicant regarding the purpose for collecting and maintaining a record of the attributes necessary for identity proofing, including whether such attributes are voluntary or mandatory in order to complete the identity proofing transactions and the consequences for not providing the attributes.

An effective notice will take into account user experience design standards and research, as well as an assessment of privacy risks that may arise from the collection. There are various factors that should be considered, including the reliability of the assumptions Applicants may have about the collection, other information that may be collected from other sources and appended to the information collected from the Applicant, etc. However, an effective notice is never only a link that leads to a complex, legalistic privacy policy or general terms and conditions that Applicants are unlikely to read or understand.

8.3. Use Limitation

Section 4.2(5) does not permit the CSP to use attributes collected and maintained in the identity proofing process for any purpose other than identity proofing, authentication, authorization or attribute assertions, or to comply with law or legal process unless the CSP provides clear notice and obtains consent from the subscriber for additional uses.

Care should be taken to ensure that use of attributes collected and maintained in the identity proofing process are limited to its’ original purpose for collection. If use of such information does not fall within uses related to identity proofing, authentication, authorization or attribute assertions, or to comply with law or legal process, the CSP must provide notice and obtain consent from the subscriber. Consult your Senior Agency Official for Privacy if there are questions about whether proposed agency uses fall within the scope of these uses. This notice should follow the same principles as described in effective notice and should not be rolled up into a legalistic privacy policy or general terms and conditions. Rather if there are uses outside the bounds of these explicit purposes, the subscriber should be provided with a meaningful way to understand the purpose for additional uses, and the opportunity to accept or decline. The CSP cannot make acceptance by the subscriber of additional uses a condition of providing identity proofing services.

8.4. Redress

Section 4.2(6) requires the CSP to provide effective mechanisms for redress of applicant complaints or problems arising from the identity proofing and make the mechanisms easy for applicants to find and access.

The Privacy Act requires federal CSPs maintaining a system of records to follow procedures to enable applicants to access and, if the records are incorrect, amend their records. Any Privacy Act Statement should include a reference to the applicable system of records notice(s) (SORN), which provides the applicant with instructions on how to make a request for access or correction. Non-federal CSPs should have comparable procedures, including contact information for any third parties if they are the source of the information. CSPs should make clear to users the availability of alternative methods for completing the process, (e.g., in person at a customer service center, if available), in the event an applicant is unable to establish his/her identity and complete the registration process online.

Note: If the ID proofing process is not successful, CSPs should inform the applicant of the procedures to address the issue but should not inform the applicant as to the specifics of why the registration failed, (e.g., do not inform the applicant, “Your SSN did not match the one that we have on record for you”) as doing so could allow fraudulent applicants to gain more knowledge about the accuracy of the PII.

8.5. Privacy Risk Assessment

Sections 4.2(8) and (11) require the CSP to conduct a privacy risk assessment. In conducting a privacy risk assessment, CSPs should consider:

  1. The likelihood that the action it takes (e.g. additional verification steps or records retention) could create a problem for the applicant such as invasiveness or unauthorized access to the information; and,
  2. The impact if a problem did occur. CSPs should be able to justify any response it takes to identified privacy risks, including accepting the risk, mitigating the risk; and sharing the risk. The use of applicant consent should be considered a form of sharing the risk, and therefore should only be used when an applicant could reasonably be expected to have the capacity to assess and accept the shared risk.

8.6. Agency Specific Privacy Compliance

Section 4.2(13) covers specific compliance obligations for federal CSPs. It is critical to involve your agency’s SAOP in the earliest stages of digital authentication system development to assess and mitigate privacy risks and as advise the agency on compliance requirements such as whether or not the collection of PII to conduct identity proofing triggers the Privacy Act of 1974 or the E-Government Act of 2002 requirement to conduct a Privacy Impact Assessment. For example, with respect to identity proofing, it is likely that the Privacy Act requirements will be triggered and require coverage by either a new or existing Privacy Act system of records due to the collection and maintenance of attributes/PII necessary to conduct identity proofing.

The SAOP can similarly assist the agency in determining whether a PIA is required. These considerations should not be read as a requirement to develop a Privacy Act System of Records Notice or PIA for identity proofing alone; in many cases it will make the most sense to draft a PIA and SORN that encompasses the entire digital authentication process or include the digital authentication process as part of a larger programmatic PIA that discusses the program or benefit the agency is establishing online access to.

Due to the many components of digital authentication, it is important for the SAOP to have an awareness and understanding of each individual component so as to advise appropriately on what compliance requirements apply. Moreover a thorough understanding of the individual components of digital authentication will enable the SAOP to thoroughly assess and mitigate privacy risks either through compliance processes or by other means.

9. Usability Considerations

This section is informative.

ISO/IEC 9241-11 はユーザビリティを “あるプロダクトが, 特定のユーザーによって, 特定の利用コンテキストにおいて, 特定の目標を有効的, 効率的かつ満足できるレベルで達成するため利用できる度合い” と定義している. この定義はユーザー, 目標, 利用コンテキストを有効性, 効率性および満足度達成のためのキー要素として重要視している. ユーザビリティの達成にはこれらのキー要素を考慮した全体的アプローチが必須となる.

登録と身元確認に関するユーザビリティの全体的ゴールは, ユーザーの負担 (時間, フラストレーション etc.) や登録時の摩擦 (ユーザーが乗り越えなければならないステップ数や記録しなければならない情報量など) を最小化し, スムーズかつポジティブな登録プロセスを促進することである.

登録・身元確認プロセスはオンラインサービスにアクセスするための Authenticator とのユーザーインタラクションの開始点となる. ファーストインプレッションがネガティブであれば, その後の当該組織のオンラインサービスとのインタラクションにも悪影響を与える. したがって各組織は登録および身元確認を通じてポジティブな UX を促進するよう努力すべきである.

登録・身元確認の各ステップおよびプロセスは, ユーザーが正しいことをするのは簡単だが誤ったことするのは困難なように, また誤った状態になった場合のリカバリーは簡単で, かつ誰かが他人になりすますのを困難にするように設計・実装すべきである. 登録・身元確認プロセスはユーザー視点での考慮を行うことによって効果的に実現される. ステークホルダーの登録・イモト確認プロセス全体の実装について管轄する組織は, ユーザー, 目標, 利用コンテキストを念頭に起くことで, UX の向上が実現できるであろう. 登録・身元確認プロセスに対するユーザビリティ評価は非常に重要であり, 同時に代表的なユーザー, 現実的な目標とタスク, 適切な利用コンテキストを設定することも, 非常に重要となろう.

本セクションはこういった全体的な視点を持って登録・身元確認プロセスに対してユーザビリティ原則を適用していくことで, 実装者に登録・身元確認に関するユーザビリティを考慮するよう促すことを目的とする. (特定の Authenticator の利用や断続的イベントに関するユーザビリティの考慮点については 800-63-3B を参照のこと)

ASSUMPTIONS

本セクションでは “ユーザー” とは “Applicant” または “Subscriber” を意味する.

ユーザビリティガイドラインはユーザー視点からのみ記述可能なため, 本セクションはエンドユーザー視点でのガイドラインおよび考慮点について述べる.

アクセシビリティとユーザビリティは大きく異なるため, アクセシビリティは本セクションの対象外とする. しかしながら, アクセシビリティも各組織が実装計画段階で取り組むべき事項であるのは明白である.

9.1. User Experience During Enrollment and Identity Proofing

まず最初に取り組むべきは, スムーズでポジティブな登録プロセスの促進のためにユーザーを知ることである. ユーザーが登録・身元確認プロセスを開始する前に, 各組織はユーザーの性質に基づいて適切な CSP を割り当てるべきである. ユーザー視点では, 登録・身元確認には, 登録前準備, 登録・身元確認セッション, 登録後アクションという3つの主要ステージが存在する. これらの各ステージは単一セッション内で起こることもあれば, ステージごとの間にかなりの時間 (数日, 数週間 etc.) が経過することもある.

以降では, 各ステージごとにユーザビリティの考慮点について述べる. ほとんどのユーザビリティ考慮点はすべての身元確認アプローチに適用できるが, いくつかは特定の身元確認方法に特化した考慮点も含まれる.

9.1.1. Pre-Enrollment Preparation

ユーザーの十分な準備なしに登録セッションを成功させるのはチェレンジングかつフラストレーションがたまるものであるため, 本セクションでは登録前に必要な準備に焦点を当てる. ユーザーが登録セッションに際して十分な準備を行うことは, 登録および身元確認プロセス全体の成功およびユーザビリティに大きく影響する. また十分な準備を行うには, 適切なフォーマットかつ適切なタイミングでユーザーに必要な情報 (登録および身元確認の要件等) を届ける必要もある. ユーザーは, 登録セッションが対面かバーチャルな対面 (virtually in-person) かリモートかにかかわらず, 登録時にどのような身分証が必要かを知っておく必要がある. その様な情報は, 実証者視点ではなくユーザー視点で提供すること. 例えば, 組織は特定の情報システムにアクセスする際にどの IAL が求められるかを事前に知る必要がある一方で, ユーザーは必要とされている IAL や利用される身分証が “adequate”, “strong”, “superior” のいずれに分類されているかなどは知る必要がない. ユーザーが知るべきは, 実際に何が必要で, それをどこでどのように提供すべきかである.

ユーザーが登録セッションに際して十分な準備ができるよう, ユーザーに必要な情報を提供すること. その様な情報により, ユーザーは登録プロセスに進みたいかどうか, 詳細な情報を得た上での決断 (informed decision) を行える. ユーザーによる登録セッションへの準備に関するユーザビリティの考慮点としては, 以下の様なものが挙げられる.

9.1.2. Enrollment and Proofing Session

As described above, prior to the actual enrollment session, users should have received the proofing and enrollment requirements and expectations in a usable format, provided at an appropriate time.

Usability considerations for the enrollment session include:

9.1.3. Post-Enrollment

Post-enrollment refers to the stage immediately after enrollment but prior to typical usage of an authenticator (for usability considerations for typical authenticator usage and intermittent events, see 800-63-3B). As described above, users should have already been informed at the end of their enrollment session regarding the expected delivery (or pick-up) mechanism by which they will receive their authenticator. Usability considerations for post-enrollment include:

10. References

[GPG 45] UK Cabinet Office, Good Practice Guide 45, Identity proofing and verification of an individual (November 3, 2014), available at: https://www.gov.uk/government/publications/identity-proofing-and-verification-of-an-individual.

[Canadian Guideline on Identity Assurance] available at: http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=30678&section=HTML.

[OMB M-03-22] OMB Memorandum M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 (September 26, 2003), available at: https://www.whitehouse.gov/omb/memoranda/m03-22.html.

[M-04-04] OMB Memorandum M-04-04, E-Authentication Guidance for Federal Agencies (December 16, 2003), available at: https://www.whitehouse.gov/sites/default/files/omb/memoranda/fy04/m04-04.pdf.

[Red Flags Rule] 15 U.S.C. 1681m(e)(4), Pub. L. 111-319, 124 Stat. 3457, Fair and Accurate Credit Transaction Act of 2003 (December 18, 2010), available at: https://www.ftc.gov/sites/default/files/documents/federal_register_notices/identity-theft-red-flags-and-address-discrepancies-under-fair-and-accurate-credit-transactions-act/071109redflags.pdf.

[FBCACP] X.509 Certificate Policy For The Federal Bridge Certification Authority (FBCA), Version 2.27 (December 2, 2013), available at: https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t0000000TN7cAAG&field=File__Body__s.

[FBCASUP] FBCA Supplementary Antecedent, In-Person Definition (July 16, 2009), available at: https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t0000000TNPgAAO&field=File__Body__s.

[A-130] OMB Circular A-130, Managing Federal Information as a Strategic Resource (July 28, 2016), available at: https://www.whitehouse.gov/omb/circulars_default