Thu, 29 Aug 2019 02:59:56 +0000

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

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

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

2.1. Expected Outcomes of Identity Proofing

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

• 主張されたアイデンティティ (Claimed Identity) を, CSP がサービスを提供するユーザー群の中から一意に特定すること.
• 提示された全ての証明書類が有効であり (正しく), 本物である (偽造や不正流用されていない) ことを検証すること.
• 主張されたアイデンティティは, 現実世界に存在する旨を検証すること.
• 主張されたアイデンティティが, 提示されたアイデンティティの証明書類を提示している現実世界の人物と紐付けられている旨を確認すること.

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

4.2. General Requirements

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

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).

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.2 や Section 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 を参照のこと.

• もし 証明書発行元が発行時の身元確認プロセスにおいて, 上級 (SUPERIOR) 証明書あるいは強力な (STRONG) 証明書を2つ以上用いて Claimed Identity の確認を行っていた ならば, そのようなプロセスを経て発行された上級 (SUPERIOR) 証明書あるいは強力な (STRONG) 証明書を1つ. あるいは

• 強力な (STRONG) 証明書を2つ. あるいは

• 強力な (STRONG) 証明書1つに加えて, 適切な (ADEQUATE) 証明書2つ.

4.5.1.3. Validation Requirements

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

• 各身分証は, 提示されている身分証と同じ強度になるような手順で検証されなければならない. 例えば, 2つの強力な (STRONG) 身分証が提示された場合, それぞれ検証方法にも強力な (STRONG) 強度が要求される.

• 第三者のデータサービスを利用した検証は, 提示された身分証のうちの1つのみに限定する (SHALL).

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

• CSP は提示された何らかの正規の身分証に含まれる住所を検証することで, 住所レコードの確認を行うべきである (SHALL).
• Self-asserted な住所データは住所確認のために用いるべきではない (SHALL NOT).

• CSP が対面での Proofing を行う場合

  • CSP は確認済の連絡先 (Address of Record) に対して Proofing 通知を送付すること (SHALL).
  • Authenticator への紐づけが後日起こりうる場合, CSP は Subscriber に登録コード (Enrollment Code) を直接提供しても良い (MAY).
  • 登録コードの有効期限は最大7日間とする (SHALL).

• CSP がリモートでの Proofing を行う場合

  • CSP は登録コードを, 申請者の連絡先 (Address of Record) に送付すること (SHALL).
  • 申請者は身元確認プロセスを完遂するため, 有効な登録コードを提示すること (SHALL).
  • CSP は登録コードを検証済みの住所 (Physical Mailing Address) に送るべきである (SHOULD). CSP は登録コードの送信に, 検証済みの携帯電話 (SMS / 音声), 固定電話, Email アドレスなどを利用しても良い (MAY).
  • 登録コードが認証の要素として利用される場合, 初回利用時にリセットすること (SHALL).
  • 物理的ではない方法で登録コードを送る場合, 有効期間は最大でも10分とする (SHALL). 郵送での送付の場合は, 最大7日とする (SHALL). ただし, 例外として, 米国の郵便サービスが直接配送できる範囲外への郵送により確認する場合, 21日まで有効期間を延ばしてもよい (MAY).
  • 登録コードを住所 (Physical Mailing Address) 以外の連絡先 (Address of Record) に送付する場合, CSP は登録コード送付先とは別の連絡先 (Address of Record) に Proofing 通知を送ること (SHALL). 例えば登録コードを携帯電話に送付した場合, Proofing 通知は免許書の住所に送付するなどが考えられる.

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 を参照のこと.

• 上級 (SUPERIOR) 証明書2つ以上. あるいは
• もし 証明書発行元が発行時の身元確認プロセスにおいて, 上級 (SUPERIOR) 証明書あるいは強力な (STRONG) 証明書を2つ以上用いて Claimed Identity の確認を行っていた ならば, そのようなプロセスを経て発行された上級 (SUPERIOR) 証明書および強力な (STRONG) 証明書を1つずつ. あるいは
• 強力な (STRONG) 証明書2つと, 適切な (ADEQUATE) 証明書1つ.

4.6.3. Validation Requirements

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

• 各身分証は, 提示されている身分証と同じ強度になるような手順で検証されなければならない. 例えば, 2つの強力な (STRONG) 身分証が提示された場合, それぞれ検証方法にも強力な (STRONG) 強度が要求される.
• 第三者のデータサービスを利用した検証は, 提示された身分証のうちの1つのみに限定する (SHALL).

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

• CSP は身分証 (任意提示のもの含む) から取得した有効な連絡先 (Address of Record) に対して, 連絡先の確認を行うべきである (SHALL).
• 申請者による自己申告である連絡先情報は, 確認のために使うべきではない (SHALL NOT).
• 身元確認完了の通知は, 確認済みの連絡先 (Address of Record) に対して行うべきである (SHALL).

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):

• 最低でも, 6文字以上のランダムな英数字により構成
• 6文字以上のランダム英数字と同様のエントロピーが確保可能な, 機械が読み取り可能なラベル (QR コードなど).

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).

強度	身分証の性質
受入不可 (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) までの品質を表示している.

強度	方法
受入不可(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.

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.

• KBV SHALL NOT be used if the CSP is not, or does not maintain a relationship with, an authoritative source.
• KBV SHALL NOT be based on data held by the issuing source of an applicant’s supplied identity evidence.
• The CSP SHALL only use information that is expected to be known only to the applicant, to include any information that in needed to trigger KBV processes. Information accessible freely or for any fee in the public domain SHALL NOT be used.
• The CSP SHALL allow a resolved, validated, or verified identity to opt-out of KBV.
• The CSP SHOULD perform KBV by verifying knowledge of recent transactional history that the CSP is a participant in. The CSP SHALL ensure that transaction information has at least 20 bits of entropy. For example, to reach minimum entropy requirements, the CSP could ask the applicant for verification of the amount and confirmation number of a micro-deposit to a valid bank account. The CSP MAY perform KBV by asking the applicant questions to demonstrate they are the owner of the claimed information. However, the following requirements apply:
  • The CSP SHALL require a minimum of four (4) KBV questions each requiring a correct answer to successfully complete the KBV step.
  • The CSP SHOULD require a free form response to a KBV question. The CSP MAY allow multiple choice answers, however, the CSP SHALL require a minimum of four (4) multiple choice KBV answers per question.
  • The CSP SHOULD allow two (2) attempts for an applicant to complete the KBV. A CSP MAY allow no more than three (3) attempts to complete the KBV.
  • The CSP MAY use KBV to verify an applicant’s identity against only one (1) piece of validated identity evidence.
  • The CSP SHALL NOT present diversionary KBV questions. The CSP SHALL NOT allow answers to KBV questions be ‘None of the Above’, ‘Not Applicable (N/A)’, or similar to be regarded as correct.
  • The CSP SHOULD NOT ask the same KBV questions in subsequent attempts.

  • The CSP SHALL NOT ask a KBV question that effectively answers any future KBV question in a single session.

  • The CSP SHALL NOT use KBV questions whose answers do not change regularly over a period of time.
  • The CSP SHALL ensure that any KBV approach does not reveal PII that the applicant has not already provided.
  • The CSP SHALL time out KBV sessions after 2 minutes of inactivity per question. In cases of session timeout, the CSP SHALL restart the entire KBV process.

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

• The CSP SHOULD check the status of the original authenticator weekly.

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

• IAL2に対する追加の要件はない．

6.2.3. IAL 3 Requirements

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

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

7. Threats and Security Considerations

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

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

行動	脅威/攻撃	低減策
登録	偽装された身分証	提示された証明書の物理的なセキュリティ機能を検証する.
	他者の証明書の不正利用	他の発行元あるいは信頼できるソースから得られた情報と突合して申請者の提示する身分証を検証する, あるいは生体情報を検証する.
		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.

8.2. Notice and Consent

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) を行える. ユーザーによる登録セッションへの準備に関するユーザビリティの考慮点としては, 以下の様なものが挙げられる.

• Inform users of the entire enrollment process. Users need to know what to expect throughout the enrollment process, including what they will experience at each individual step of the process.
  • It is especially important to clearly explain expected timeframes to users. Users need to understand how long the enrollment process will take, so they can plan accordingly.
• Inform users why they need to participate in the enrollment process. Users need to understand the necessity for identity proofing and how it can benefit them.
• Minimize the number of steps required for enrollment, and make each step as clear and easy as possible for users. Users are easily frustrated by large numbers of confusing steps.
• If there is a fee for enrollment, users must be informed of the monetary amount of the fee, and the acceptable forms of payment. Offering a larger variety of acceptable forms of payment allows users to choose their preferred payment option.
• Inform users whether their enrollment session will be in-person, virtual in-person, or remote (and whether a user is allowed to choose). Only provide information relevant to the allowable session option(s). For example, if a user is best suited to complete an in-person session, do not provide information about virtual in-person or remote sessions, as superfluous information will confuse users.
  • For in-person or virtual in-person sessions, provide users information regarding the location(s) where the session will take place (and whether a user is allowed to choose their preferred location). Provide users with logistical information necessary to reach the enrollment session location(s). For example, provide directions for arrival via a variety of transportation means (e.g., car, public transportation) and parking and entrance information if applicable.
  • For remote sessions, provide users information regarding the technical requirements they must meet to complete a remote session (e.g., requirements for internet access).
  • Appointments for in-person or virtual in-person identity proofing sessions should be offered. Users should be encouraged to set up an appointment in order to minimize wait times at enrollment sessions. If walk-ins are allowed, it should be made clear to users that their wait times may be increased without an appointment.
    • Provide clear instructions to users regarding setting up an enrollment session appointment and reminders, and how to reschedule existing appointments.
    • Provide users with appointment reminders and allow users to specify their preferred appointment reminder format(s) (e.g., postal mail, voicemail, email, text message). Appointment reminders should include all enrollment session information pertinent to the user’s session: date, time, and location (or technical requirements for a virtual in-person session, for example a link to join a virtual session), description of required identity evidence.
• Inform users of the exact identity evidence and attributes needed for enrollment, and whether each piece is voluntary or mandatory in order to complete the identity proofing process. Inform users of the consequences for not providing the complete set of identity evidence.
  • All allowed and required identity evidence must be clearly described. Users need to know the specific combinations of identity evidence allowed and required for enrollment, including requirements specific to a particular piece of identity evidence (for example, a raised seal required on a birth certificate; or an original authenticator for obtaining a derived authenticator). This is especially important because users may face significant difficulty procuring the identity evidence necessary for enrollment.
  • Where possible, implement tools to make it easier for users to obtain the necessary identity evidence.
  • Inform users of any special requirements for minors and people with unique needs. For example, provide users with the information necessary to utilize trusted referees, such as a notary, legal guardian, or some other form of certified individual that can legally vouch for and/or act on behalf of the individual (see Section 5.4.4).
  • If forms are required:
    • Provide users fillable forms prior to their enrollment session. However, forms must also be available at the enrollment session (if it’s in-person), as users should not be required to have access to a printer.
    • Minimize the amount of information users must enter on a form, as users are easily frustrated and more error-prone with longer forms. Where possible, pre-populate forms to reduce the amount of information a user must enter.
• Characteristics of information presented to users, either digitally or in physical form.
  • Follow good information design practice for all user-facing materials (for example, information provided in preparation for enrollment, enrollment appointment reminders, enrollment codes, data collection notices, fillable forms).
  • Any user facing materials should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level. For example, keep writing style simple; use active voice and conversational style; sequence main points in a logical manner; use short words and sentences; avoid double negative expressions; use the same word consistently rather than synonyms to avoid confusion; use bullets, numbers, and formatting where appropriate to aid readability.
  • Legibility of user facing text or text entered by users should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user comprehension errors or user entry errors (e.g., when completing fillable forms). For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for electronic materials; serif fonts are recommended for paper materials.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use. This is especially important for the use of enrollment codes.
    • If possible depending on the size of the display medium, a minimum font size of 12 points is recommended as long as the text fits for display.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature, chat sessions, and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to answer their own enrollment preparation questions without outside intervention.

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:

• At the start of the enrollment session (regardless of whether it is in-person, virtual in-person, or remote), remind users of the enrollment session procedure. Do not expect them to remember all of the information they received during the pre-enrollment preparation stage. Users need to know what to expect throughout the enrollment session, including what they will experience at each individual step of the session.
  • If the enrollment session does not follow immediately after the pre-enrollment preparation stage, it is especially important to clearly remind users of the typical timeframe to complete the proofing and enrollment phase. Users need to understand how long the enrollment session will take, so they can plan accordingly.
    • Provide rescheduling options (for in-person or virtual in-person), as users may need to reschedule their enrollment session appointment if they do not have adequate time to complete the enrollment session.
  • Provide a checklist with the allowed and required identity evidence to ensure that users have the requisite identity evidence to proceed with the enrollment session, including enrollment codes if applicable. If users do not have the complete set of identity evidence, they must be informed regarding whether they can complete a partial identity proofing session. Users should be notified regarding what information will be destroyed and what, if any, information will be retained for future follow-up sessions, and what identity evidence they will need to bring to complete a future session. Ideally, users should be allowed to choose whether they would like to complete a partial identity proofing session or not.
  • It is important to set user expectations regarding the outcome of the enrollment session. For example, will the user receive a authenticator immediately at the end of a successful enrollment session, will they have to schedule an appointment to pick it up in person, or will they receive it in the mail weeks later? Setting user expectations is critical, as many users have prior experience with identity verification that may drive their expectations (e.g., receiving a drivers license in person, receiving a passport in the mail).
• Characteristics of information presented to users, either digitally or in physical form.
  • Follow good information design practice for all user-facing materials (for example, data collection notices, fillable forms).
  • Any user facing materials should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level. For example, keep writing style simple; use active voice and conversational style; sequence main points in a logical manner; use short words and sentences; avoid double negative expressions; use the same word consistently rather than synonyms to avoid confusion; use bullets, numbers, and formatting where appropriate to aid readability.
  • Legibility of user facing text or text entered by users should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user comprehension errors or user entry errors (e.g., when completing fillable forms). For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for electronic materials; serif fonts are recommended for paper materials.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use. This is especially important for the use of enrollment codes.
    • If possible depending on the size of the display medium, a minimum font size of 12 points is recommended as long as the text fits for display.
• During the enrollment session, there are several requirements to provide users with explicit notice at the time of identity proofing, such as what data will be retained on record by the CSP (see Section 4.2 and Section 8 for detailed requirements on notices). For each notice, as described above, usability considerations for characteristics of information presented to users, either digitally or in physical form, applies. The use of plain language and usable formatting is especially important for notices, since users have a tendency to gloss over and ignore complex legalistic text in long paragraph form. If CSPs seek consent from a user for additional attributes or uses of their attributes for any purpose other than identity proofing, authentication, authorization or attribute assertions, per 4.2(5), CSPs should be aware that requesting additional attributes or uses may be unexpected or make users uncomfortable. If users do not perceive benefit(s) to the additional collection or uses, but only perceive extra risk to their information, they may be unwilling or hesitant to provide consent or continue the process. CSPs should provide users with explicit notice of the additional requirements. For each notice, as described above, usability considerations for characteristics of information presented to users, either digitally or in physical form, applies. The use of plain language and usable formatting is especially important for notices, since users have a tendency to gloss over and ignore complex legalistic text in long paragraph form.
• If at all possible, avoid using KBV, as KBV is extremely problematic from a usability perspective. It is error-prone and frustrating for users given the limitations of human memory, and has a low probability of success.
  • The types of questions used in KBV are often extremely difficult for users to answer correctly. The questions often ask users to recall old, infrequently used information, or information that changes over time. Although such information may be available in private databases, it does not necessarily mean that users can accurately recall, recognize, or find the requested information. KBV questions must still have relevance to users for them to be able to answer correctly. For example, if users lived somewhere for a very short period of time many years ago, it is very unlikely they will remember the address.
  • As described above, usability considerations for characteristics of information presented to users, either digitally or in physical form, apply to the phrasing of all KBV questions. It is especially important that KBV questions are clearly phrased, as ambiguity can lead to user errors when answering. For example, if asking about a user’s remaining mortgage balance, the KBV question should clearly specify which mortgage because users may have multiple mortgages. This question can be phrased as “What is the remaining mortgage balance on your primary residence?” to reduce ambiguity without compromising the integrity of the proofing process and without revealing unnecessary details about the individual.
  • Free form versus multiple choice KBV questions have different usability implications. Free form responses require recall memory, whereas multiple choice responses require recognition memory.
    • If free form responses are required, all semantically correct answers should be accepted. For example, accept all aliases for a user’s school name: full name, short name, and widely used nickname. Acceptable responses should not be case-sensitive and should ignore the use of pronouns such as ‘the’ or ‘a’.
    • If multiple choice KBV responses are used, they should be written to limit confusion.
  • If users are eligible to opt-out of KBV questions, they should be informed. As described above, usability considerations for characteristics of information presented to users, either or in physical form, apply to the phrasing of the KBV opt-out option.
  • Prior to being asked KBV questions, users must be informed of the number of allowed attempts. As they progress through the KBV process, users must be informed of the number of remaining attempt(s).
  • Prior to being asked KBV questions, users must be informed that KBV questions will change on subsequent attempts.
  • Prior to being asked KBV questions, users must be informed about timeouts. During the KBV session, users should be given timeout inactivity warnings prior to timeout.
• If an enrollment code is issued:
  • Users should be notified in advance that they will receive an enrollment code, when they should expect it, the length of time for which the code is valid, and the means by which it will arrive (physical mail, mobile telephone (SMS or voice), landline telephone, email, or physical mailing address).
  • When an enrollment code is delivered to a user, it should include instructions on how to use the code, and the length of time for which the code is valid. This is especially important given the short validity timeframes specified in Section 4.5.6.
    • If a machine readable optical label, such as a QR Code, is used (see Section 4.7), then provide users with information on how to obtain QR code scanning capabilities (e.g., acceptable QR code applications).
  • If enrollment codes expire or are lost before use, users should be informed that they will be required to repeat the enrollment process.
• At the end of the enrollment session,
  • If enrollment is successful,
    • Users should receive confirmation regarding the successful enrollment and be informed regarding next steps. For example, when and where to pick up their authenticator, or when it will arrive in the mail.
  • If enrollment is partial (due to users not having the complete set of identity evidence, users choosing to stop the process, or session timeouts),
    • Users should be notified regarding what information will be destroyed and what, if any, information will be retained for future follow-up sessions, and what identity evidence they will need to bring to complete a future session.
  • If enrollment is unsuccessful,
    • Users should be provided with clear instructions for alternative enrollment session type(s), for example, offering in-person proofing if users failed remote proofing.
• If users receive the authenticator during the enrollment session, they should be given information relevant to the use and maintenance of the authenticator. For example, instructions for use (especially if there are different requirements for first-time use or initialization), information on authenticator expiration, what to do if the authenticator is lost or stolen.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature, chat sessions, and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to answer their own enrollment questions without outside intervention.
• Depending on enrollment session type (in-person, virtual in-person, or remote), additional usability considerations apply.
  • In-person
    • At the start of the enrollment session, operators should explain their role to users. For example, will operators walk users through the enrollment session step by step, or will they observe silently and only interact with users as needed?
    • If users choose to complete a partial enrollment session (due to not having the requisite set of identity evidence), provisions to schedule a follow-up session to complete the enrollment process should be offered. The previously identified usability considerations for appointments still apply.
    • If biometrics are being collected during the enrollment session, provide users clear instructions on how to complete the collection process. Instructions should be provided just prior to the collection process. Verbal instructions with corrective feedback from a live operator are the most effective. For example, instruct users where the biometric sensor is, when to start, how to interact with the sensor, and when the biometric collection is completed.
    • If users receive the authenticator during the enrollment session, operators should demonstrate use of the authenticator. Operators should help users test the authenticator during enrollment sessions to ensure the authenticator works correctly and users understand its operation.
  • Virtual in-person
    • If enrollment sessions are conducted in publicly observable spaces (e.g., a kiosk in a bank or supermarket), users may be concerned that others can view their activity and identity evidence. Care should be taken in the design and placement of the enrollment station to minimize user concern of being observed by others. Users may be reluctant to bring identity evidence to certain public places (bank versus supermarket), as it increases exposure to loss or theft.
    • At the start of the enrollment session, users need to be informed that they must not depart during the session, and that all their actions must be visible throughout the session.
    • At the start of the enrollment session, operators should explain their role to users. For example, will operators walk users through the enrollment session step by step, or will they observe silently and only interact with users as needed?
    • If users choose to complete a partial enrollment session (due to not having the requisite set of identity evidence), provisions must be made to schedule a follow-up session to complete the enrollment process. The previously identified usability considerations for appointments still apply.
    • If biometrics are being collected during the enrollment session, provide users clear instructions on how to complete the collection process. Instructions should be provided just prior to the collection process. Verbal instructions with corrective feedback from a live operator are the most effective. For example, instruct users where the biometric sensor is, when to start, how to interact with the sensor, and when the biometric collection is completed.
    • If users receive the authenticator during the enrollment session, operators should demonstrate use of the authenticator. Operators should help users test the authenticator during enrollment sessions to ensure the authenticator works correctly and users understand its operation.
  • Remote
    • Since remote identity proofing sessions are conducted online, general web usability principles should be followed. For example, design the user interface to walk users through the enrollment process; reduce users’ memory load; make the interface consistent; clearly label sequential steps; make the starting point clear; design to support multiple platforms and device sizes; and make the navigation consistent, easy to find, and easy to follow.
    • At the start of the enrollment session, information on how and where to acquire technical assistance should be clearly communicated to users. This is especially important since there is not an operator present for remote sessions. The previously identified usability considerations for providing technical assistance still apply.
    • Explain clearly to the users who is collecting and who is retaining which information they’re providing. For instance, if a user is going to stay on the CSP site to enter financial information that will be sent to a 3rd party vendor, explain this to users so they understand the path their data will take.

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:

• CSPs should strive to minimize the amount of time that users wait for their authenticator to arrive. Shorter wait times will allow users to access information systems and services more quickly.
• Users should be informed if they need to go to a physical location to pick up their authenticators. The previously identified usability considerations for appointments and reminders still apply.
• Along with the authenticator, users should be given information relevant to the use and maintenance of the authenticator. For example, instructions for use (especially if there are different requirements for first-time use or initialization), information on authenticator expiration, what to do if the authenticator is lost or stolen.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature, chat sessions, and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to answer their own authenticator questions without outside intervention.

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