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

This section is informative.

This document provides requirements for enrollment and identity proofing of subscribers that wish to gain access to online resources at each Identity Assurance Level (IAL). The requirements detail the acceptability, validation, and verification of identity evidence that will be presented by an individual to support their claim of identity. This document also details the responsibilities of Credential Service Providers (CSPs) with respect to establishing and maintaining enrollment records, and binding of authenticators (either CSP issued or subscriber-provided) to the enrollment record.

2. Introduction

This section is informative.

One of the challenges associated with authenticating people is the association of their online activities with a specific physical person. While there are situations where this is not required or is even undesirable (i.e., use cases where anonymity or pseudonymity are required), there are others where it is important to reliably establish an association with a physical person. Examples include obtaining health care and executing financial transactions. There are also situations where the association is required for regulatory reasons (e.g., Know Your Customer requirements in the financial community) or to establish accountability for high-risk actions (e.g., the release of water from a hydroelectric dam).

There are also instances where it is desirable for a relying party (RP) to know something about a user executing a transaction, but not know the real human identity of the person. For example, in order to maintain integrity of the service, it may be desirable to know the home ZIP Code of a user for purposes of census taking or petitioning an elected official but where it is not necessary or desirable to know the underlying identity of the person. Identity assurance levels provide a method for expressing the level of assurance associated with attributes established by the credential service provider during the proofing process.

2.1. Expected Outcomes of Identity Proofing

The objective of identity proofing is to:

• Resolve a claimed identity to a single, unique identity within the context of the population of users the CSP serves.
• Validate that all evidence that is supplied is valid (correct) and genuine (not counterfeit or misappropriated).
• Validate that the claimed identity exists in the real world.
• Verify that the claimed identity is associated with the real person supplying the identity evidence.

2.2. Identity Assurance Levels

Assurance in a subscriber’s identity is described using one of three IALs:

Identity Assurance Level 1: At this level, there is no requirement for an applicant’s identity to be proven. Any attributes provided in conjunction with the authentication process are self-asserted.

Identity Assurance Level 2: At IAL 2, the claimed identity is proven with evidence that supports the real world existence of the claimed identity and identifies and verifies the person to whom the claimed identity belongs. IAL 2 introduces the need for either remote or in-person identity proofing. Attributes MAY be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.

Identity Assurance Level 3: At Identity Assurance Level 3, in-person identity proofing is required. Identifying attributes must be verified by an authorized and trained representative of the CSP. As with IAL 2, attributes MAY be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.

At IAL 2 and IAL 3, pseudonymity is enabled by CSP limiting the number of attributes sent, or the way they are presented, to the RP. For example, if an RP needs a valid birthdate but no other personal details, the RP should leverage a CSP to request just the birthdate of the subscriber. It is preferred for the RP to ask the CSP for an attribute claim. For example, if an RP needs to know if a claimant is older than 18 they should request a boolean value, not the entire birthdate in order to evaluate age.

Since the individual will have undergone an identity proofing process at enrollment and likely associated with one or more authenticators, transactions are not pseudonymous with respect to individual interactions with the CSP.

Detailed requirements for each of the IALs is given in Section 4 and Section 5.

3. Definitions and Abbreviations

This section is informative.

There is a wide variety of terms used in the area of authentication. While the definitions of many terms are consistent with earlier versions of SP 800-63, some have changed in this revision. Since there is no single, consistent definition of many of these terms, careful attention to how the terms are defined here is warranted.

The definitions in this section are primarily those that are referenced in this document. Refer to the other documents in the SP 800-63 document family for additional definitions and abbreviations specific to their content.

Address of Record

The validated and verified location (physical or digital) where an individual can receive communications using approved mechanisms.

Applicant

A party undergoing the processes of registration and identity proofing.

Assurance

In the context of [OMB M-04-04] and this document, assurance is defined as 1) the degree of confidence in the vetting process used to establish the identity of an individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued.

Asymmetric Keys

Two related keys, consisting of a public key and a private key, that are used to perform complementary operations such as encryption and decryption or signature verification and generation.

Attack

An attempt by an unauthorized individual to defeat security controls. For example, to cause a credential service provider to register an impostor as the subscriber.

Attacker

A party who acts with malicious intent to compromise an information system.

Attribute

A quality or characteristic ascribed to someone or something.

Attribute Claim

A statement asserting a property of a subscriber without necessarily containing identity information, independent of format. For example, for the attribute ‘birthday’, a claim could be ‘older than 18’ or ‘born in December’.

Attribute Value

A complete statement asserting a property of a subscriber, independent of format. For example, for the attribute ‘birthday’, a value could be ‘12/1/1980’ or ‘December 1, 1980’.

Authentication

The process of establishing confidence in the identity of users or information systems.

Authentication Protocol

A defined sequence of messages between a claimant and a verifier that demonstrates that the claimant has possession and control of one or more valid authenticators to establish his/her identity. Secure authentication protocols also demonstrate to the claimant that he or she is communicating with the intended verifier.

Authenticator

Something that a claimant possesses and controls (typically a cryptographic module or password) that is used to authenticate the claimant’s identity. In previous editions of SP 800-63, this was referred to as a token.

Authenticity

The property that data originated from its purported source.

Authoritative Source

An entity that has access to, or verified copies of, a sufficient amount of accurate information from an issuing source such that a CSP can confirm the validity of the identity evidence supplied by an applicant during identity proofing. An issuing source may also be an authoritative source. Often, authoritative sources are determined by a policy decision of the agency or CSP before they can be used in the validation phase of identity proofing.

Biometrics

Automated recognition of individuals based on their behavioral and biological characteristics.

In this document, biometrics may be used to unlock authenticators and prevent repudiation of registration.

Claimant

A party whose identity is to be verified using one or more authentication protocols.

Claimed Address

The physical location asserted by an individual (e.g. an applicant) where he/she can be reached. It includes the residential street address of an individual and may also include the mailing address of the individual.

For example, a person with a foreign passport, living in the U.S., will need to give an address when going through the identity proofing process. This address would not be an “address of record” but a “claimed address.”

Claimed Identity

A declaration of unvalidated and unverified personal attributes by the applicant.

Credential

An object or data structure that authoritatively binds an identity (and optionally, additional attributes) to an authenticator possessed and controlled by a subscriber.

While common usage often assumes that the credential is maintained by the subscriber, this document also uses the term to refer to electronic records maintained by the CSP which establish a binding between the subscriber’s authenticator and identity.

Credential Service Provider (CSP)

A trusted entity that issues or registers subscriber authenticators and issues electronic credentials to subscribers. The CSP may encompass verifiers that it operates. A CSP may be an independent third party, or may issue credentials for its own use.

Derived Credential

A credential issued based on proof of possession and control of an authenticator associated with a previously issued credential, so as not to duplicate the identity proofing process.

Digital Authentication

The process of establishing confidence in user identities electronically presented to an information system. In previous editions of SP 800-63, this was referred to as Electronic Authentication.

Digital Signature

An asymmetric key operation where the private key is used to digitally sign data and the public key is used to verify the signature. Digital signatures provide authenticity protection, integrity protection, and non-repudiation but not confidentiality protection.

Electronic Authentication (E-Authentication)

See Digital Authentication.

Enrollment

The process through which an applicant applies to become a subscriber of a CSP and an RA validates the identity of the applicant on behalf of the CSP.

Identity

A set of attributes that uniquely describe a person within a given context.

Identity Assurance Level (IAL)

A category that conveys the degree of confidence that the applicant’s claimed identity is their real identity.

Identity Proofing

The process by which a CSP collects and verifies information about a person for the purpose of issuing credentials to that person.

Issuing Source

An authority that is responsible for the generation of data and/or documents that can be used as identity evidence.

Knowledge Based Verification

Identity proofing of an individual based on knowledge of information associated with his or her claimed identity in private databases. This is often referred to as knowledge based authentication (KBA) or knowledge based proofing (KBP).

Network

An open communications medium, typically the internet, that is used to transport messages between the claimant and other parties. Unless otherwise stated, no assumptions are made about the security of the network; it is assumed to be open and subject to active (i.e., impersonation, man-in-the-middle, session hijacking) and passive (i.e., eavesdropping) attack at any point between the parties (e.g., claimant, verifier, CSP or RP).

Personally Identifiable Information (PII)

As defined by OMB Circular [A-130], Personally Identifiable Information is information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual.

Practice Statement

A formal statement of the practices followed by the parties to an authentication process (i.e., CSP or verifier). It usually describes the policies and practices of the parties and can become legally binding.

Protected Session

A session wherein messages between two participants are encrypted and integrity is protected using a set of shared secrets called session keys.

A participant is said to be authenticated if, during the session, he, she or it proves possession of one or more authenticators in addition to the session keys, and if the other party can verify the identity associated with the authenticator(s). If both participants are authenticated, the protected session is said to be mutually authenticated.

Pseudonym

A name other than a legal name.

Public Key

The public part of an asymmetric key pair that is used to verify signatures or encrypt data.

Remote

(As in remote authentication or remote transaction) An information exchange between network-connected devices where the information cannot be reliably protected end-to-end by a single organization’s security controls.

Note: Any information exchange across the Internet is considered remote.

Social Engineering

The act of deceiving an individual into revealing sensitive information, obtaining unauthorized access, or committing fraud by associating with the individual to gain confidence and trust.

Subscriber

A party who has had their credential bound to an authenticator by a CSP.

Token

See Authenticator.

Trust Anchor

A public or symmetric key that is trusted because it is directly built into hardware or software, or securely provisioned via out-of-band means, rather than because it is vouched for by another trusted entity (e.g. in a public key certificate).

Valid

In reference to an ID, the quality of not being expired or revoked.

Virtual In-Person Proofing

A remote identity person proofing process that employs physical, technical and procedural measures that provide sufficient confidence that the remote session can be considered equivalent to a physical, in-person identity proofing encounter.

4. Identity Assurance Level Requirements

This section is normative.

The paradigm of this document is that individuals (referred to as applicants at this stage) undergo an identity proofing and enrollment process in which their identity evidence and attributes are collected, uniquely resolved to a single identity record, then validated and verified. These attributes are then bound to an authenticator (described in SP 800-63B).

The only outcome of identity proofing is to ensure that the applicant is who he/she claims to be. This includes presentation, validation and verification of the minimum attributes necessary to accomplish identity proofing. Such core attributes, to the extent they are the minimum necessary, could include:

1. Full name
2. Date of birth
3. Home address

It is permissible for the CSP to collect additional information in the process of identity proofing an applicant, provided validation and verification follow the requirements contained herein, and the applicant explicitly consents to the CSP collecting and storing the attributes.

4.1. Process Flow

Figure 4-1 outlines the basic flow for Identity Proofing and Enrollment, to include the corresponding sections with normative requirements.

4.2. General Requirements

Table 4-1 lists strict adherence to M-04-04 Level of Assurance, mapping the corresponding Identity Assurance Levels.

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

However, Table 4-2 shows the expanded set of IALs that are allowable to meet M-04-04 Levels of Assurance. Agencies SHALL select the corresponding IAL based on the assessed M-04-04 LOA. Agencies SHOULD consider the privacy risks of stronger identity proofing and SHOULD NOT select an IAL that is higher than necessary considering the sensitivity of the business purpose.

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

The following requirements apply to any CSP performing identity proofing at IAL 2 or 3.

1. Identity proofing SHALL NOT be performed to determine suitability/entitlement to gain access to services or benefits.
2. The CSP SHOULD NOT collect the SSN unless it is necessary for performing identity resolution and cannot be accomplished by collection of another attribute or combination of attributes.
3. Collection of personally identifiable information (PII) SHALL be limited to the minimum necessary to validate the existence of the claimed identity and associate the claimed identity to the applicant providing identity evidence based on best available practices for appropriate identity resolution, validation, and verification.
4. The CSP SHALL 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 the such attributes are voluntary or mandatory in order to complete the identity proofing transactions and the consequences for not providing the attributes.
5. The CSP SHALL NOT 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. CSPs SHALL NOT make consent a condition of the service.
6. The CSP SHALL provide effective mechanisms for redress of applicant complaints or problems arising from the identity proofing. These mechanisms SHALL be easy for applicants to find and access.
7. The identity proofing and enrollment processes SHALL be performed according to an applicable written policy or practice statement that specifies the particular steps taken to verify identities.

8. The CSP SHALL maintain a record of all steps taken to verify the identity of the applicant and SHALL record the types of identity evidence presented in the proofing process. The CSP SHALL conduct a privacy risk assessment to determine:

   a) Any steps that it will take to verify the identity of the applicant beyond any mandatory requirements specified herein;

   b) the PII, including any biometrics, images, scans, or other copies of the identity evidence that the CSP will maintain as a record of identity proofing. Note: Specific federal requirements may apply; and

   c) the schedule of retention for these records. Note: Specific National Archives and Records Administration (NARA) records retention schedules may apply.

9. All personally identifiable information (PII) collected as part of the enrollment process SHALL be protected to ensure confidentiality, integrity, and attribution of the information source.
10. The entire proofing transaction, including transactions that involve a third party, SHALL occur over an Authenticated Protected Channel.

11. The CSP SHOULD obtain additional confidence in remote identity proofing using fraud mitigation measures, for example inspecting geolocation, examining the device characteristics of the applicant, evaluating behavioral characteristics, or checking vital statistic repositories such as the Death Master File, so long as any additional mitigations do not substitute for the mandatory requirements contained herein and the CSP SHALL conduct a privacy risk assessment of these mitigation measures. Such assessments SHOULD include any privacy risk mitigations (e.g., limited retention, use limitations, notice, etc.) or other technological mitigations (e.g.,cryptography).

12. In the event a CSP ceases to conduct identity proofing and enrollment processes, the CSP SHALL be responsible for fully disposing of or destroying any sensitive data including PII, or its protection from unauthorized access for the duration of retention.
13. Regardless of whether the CSP is an agency or private sector provider, the following requirements apply to the agency offering or using the proofing service:

a) The agency SHALL consult with their Senior Agency Official for Privacy to conduct an analysis to determine whether the collection of PII to conduct identity proofing triggers the requirements of the Privacy Act.

b) The agency SHALL publish a System of Records Notice to cover such collections, as applicable.

c) The agency SHALL consult with their Senior Agency Official for Privacy to conduct an analysis to determine whether the collection of PII to conduct identity proofing triggers the requirements of the E-Government Act of 2002.

d) The agency SHALL publish a Privacy Impact Assessment to cover such collections, as applicable.

4.4. Identity Assurance Level 1

The CSP SHALL NOT proof applicants. Applicants MAY self-assert zero or more attributes to the CSP.

4.5. Identity Assurance Level 2

IAL 2 allows for remote or in-person identity proofing. IAL supports a wide range of acceptable identity proofing techniques in order to increase user adoption, decrease false negatives (legitimate applicants that cannot successfully complete identity proofing), and detect to the best extent possible the presentation of fraudulent identities by a malicious applicant. A CSP MAY exceed these requirements.

A CSP SHOULD implement identity proofing in accordance with Section 4.5.1. Depending on the population the CSP serves, the CSP MAY implement identity proofing in accordance with Section 4.5.2 or Section 4.5.3.

4.5.1. IAL2 Conventional Proofing Requirements

4.5.1.1. Resolution Requirements

Collection of PII SHALL be limited to the minimum necessary to resolve to a unique identity record. See Section 5.1 for general resolution requirements.

4.5.1.2. Evidence Requirements

See Section 5.2, Identity Evidence Validation for more information on acceptable identity evidence.

• One (1) piece of SUPERIOR or STRONG evidence if the issuing source of the evidence, during its identity proofing event, confirmed the claimed identity by collecting two (2) or more forms of SUPERIOR or STRONG evidence; OR
• Two (2) pieces of STRONG evidence; OR
• One (1) piece of STRONG evidence plus two (2) pieces of ADEQUATE evidence.

4.5.1.3. Validation Requirements

See Section 5.2, Identity Evidence Validation for more information on acceptable identity evidence.

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

4.5.1.4. Verification Requirements

See Section 5.3, Identity Verification for more information on acceptable identity evidence.

At a minimum, the applicant must be verified by a process that is able to achieve a strength of STRONG.

4.5.1.5. Presence Requirements

The CSP SHOULD perform identity proofing in-person. The CSP MAY perform remote identity proofing. The CSP SHOULD offer both in-person and remote proofing.

4.5.1.6. Address Confirmation

• 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 that has not been confirmed in records SHALL NOT be used for confirmation.

• If CSP performed in-person proofing:

  • The CSP SHALL send a notification of proofing to the confirmed address of record.
  • The CSP MAY provide an enrollment code directly to the subscriber if binding to an authenticator will occur at a later time.
  • The enrollment code SHALL be valid for a maximum of 7 days
• If the CSP performed remote proofing:
  • A CSP SHALL send an enrollment code to an address of record of the applicant.
  • The applicant SHALL present a valid enrollment code to complete the identity proofing process.
  • The CSP SHOULD send the enrollment code to the physical mailing address that has been verified in records. The CSP MAY send the enrollment code to a mobile telephone (SMS or voice), landline telephone, or email that has been verified in 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.
  • If delivery of the enrollment code was sent to an address of record that is not physical mail, the CSP SHALL send notification of proofing to a different address of record than the destination of the enrollment code. For example, if the CSP sends an enrollment code to a mobile phone of record, a notification of proofing will be sent to the postal address in records or obtained from validated and verified evidence, like a drivers license.

4.5.1.7. Biometric Collection

The CSP MAY collect biometrics for the purposes of non-repudiation and re-proofing. See Section 5.2.3 of SP 800-63B for more detail on biometric collection.

4.5.1.8. Security Controls

The CSP SHOULD employ appropriately tailored security controls from the moderate baseline of security controls defined in [SP 800-53] or equivalent industry standard and SHOULD ensure that the minimum assurance requirements associated with the moderate baseline are satisfied.

4.5.2. IAL2 Antecedent Proofing Requirements

Antecedent in-person identity proofing MAY be used provided the prior proofing transaction is determined to be comparable to the process defined in Section 4.5.1.. See also The Federal Bridge Certification Authority (FBCA) Certificate Policy (CP), Section 3.2.3.1 Authentication of Human Subscribers for Medium Assurance and FBCA Supplementary Antecedent, In-Person Definition for more details.

4.5.3. IAL2 Trusted Referee Proofing Requirements

In instances where the individual enrolling cannot meet the identity evidence requirements specified in Section 4.5.1., the agency MAY use a trusted referee to assist in identity proofing the enrollee. See Section 5.3.4. for more details.

4.6. Identity Assurance Level 3

IAL 3 adds additional rigor to the steps required at IAL 2, to include providing further evidence of superior strength, and is subjected to additional and specific processes, including the use of biometrics, to further protect the identity and RP from impersonation, fraud, or other significantly harmful damages. In addition, identity proofing at IAL 3 is performed in-person. See Section 5.3.3 for more details. A CSP MAY exceed these requirements.

4.6.1. Resolution Requirements

Collection of PII SHALL be limited to the minimum necessary to resolve to a unique identity record. See Section 5.1 for general resolution requirements.

4.6.2. Evidence Requirements

See Section 5.2, Identity Evidence Validation for more information on acceptable identity evidence.

• Two (2) or more pieces of SUPERIOR evidence; OR
• One (1) piece of SUPERIOR evidence and one (1) piece of STRONG evidence if the issuing source of the evidence, during its identity proofing event, confirmed the claimed identity by collecting two (2) or more forms of SUPERIOR or STRONG evidence; OR
• Two (2) pieces of STRONG evidence plus one (1) piece of ADEQUATE evidence

4.6.3. Validation Requirements

See Section 5.2, Identity Evidence Validation for more information on acceptable identity evidence.

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

4.6.4. Verification Requirements

See Section 5.3, Identity Verification for more information on acceptable identity evidence.

• At a minimum, the applicant must be verified by a process that is able to achieve a strength of SUPERIOR.

4.6.5. Presence Requirements

All identity proofing steps SHALL be performed in person. See Section 5.3.3 for more details.

Remote proofing SHALL NOT be allowed.

4.6.6 Address Confirmation

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

4.6.7. Biometric Collection

The CSP SHALL collect and record a biometric sample at the time of proofing (e.g., facial image or fingerprints) the purposes of non-repudiation and re-proofing. See Section 5.2.3 of SP 800-63B for more detail on biometric collection.

4.6.8. Security Controls

The CSP SHOULD employ appropriately tailored security controls from the high baseline of security controls defined in [SP 800-53] or an equivalent industry standard and SHOULD ensure that the minimum assurance requirements associated with the high baseline are satisfied.

4.7. Enrollment Code

An enrollment code allows the CSP to confirm that the applicant controls an address of record, as well as offers the applicant the ability to reestablish binding to their enrollment record. Binding is not always completed in the same session as the original identity proofing transaction.

An enrollment code SHALL be comprised of one of the following:

• Minimually, a random six (6) character alphanumeric.
• A machine readable optical label, such as a QR Code, that contains data of similar or higher entropy as a random six (6) character alphanumeric.

4.8. Summary of Requirements

This section is informative.

Table 4-3 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	Yes	Yes
Security Controls	N/A	[SP 800-53] Moderate Baseline (or equivalent)	[SP 800-53] High Baseline (or equivalent)

5. Identity Resolution, Validation and Verification

This section is normative.

The following sections list the objectives and steps a CSP SHALL follow to identity proof an individual to meet requirements per IAL. The requirements are intended to ensure the claimed identity is the actual identity of the person attempting to enroll with the CSP and that scalable attacks effecting a large population of enrolled individuals are difficult to execute without significant time and cost.

5.1. Identity Resolution

1. Exact matches of information used in the proofing process may be difficult to achieve due to multiple factors. The CSP MAY employ appropriate matching algorithms to account for differences in personal information and other relevant proofing data across multiple forms of identity evidence, authoritative records, and third party records. Matching algorithms/rules used SHOULD be publicly or community of interest available. For example, they MAY be included as part of the written policy or practice statement referenced above.
2. Knowledge based verification (KBV) (sometimes referred to as knowledge based authentication (KBA)) is typically used to verify a claimed identity by testing the personal knowledge of the applicant against information obtained from public databases. The CSP MAY use KBV to resolve to a unique, claimed identity.

5.2. Identity Evidence Validation

The goal of identity validation is to collect from the applicant the most appropriate identity evidence (for example, a passport or drivers license) and determine its authenticity, validity, and accuracy. Identity validation is made up of two process steps: collecting the appropriate identity evidence, confirming the evidence is genuine and authentic, and confirming the data contained on the identity evidence is valid, current, and related to an actual, live individual.

5.2.1. Identity Evidence Characteristic Requirements

This section provides requirements on the properties and qualities of identity evidence at a given strength.

5.2.1.1. Scoring of Identity Evidence

Table 5-1 lists qualities, ranging from weak to superior, of identity evidence that is collected to establish a valid identity. Unless otherwise noted, to achieve a given strength the evidence SHALL, at a minimum, meet all the properties listed.

Strength	Properties of Identity Evidence
Unacceptable	The issuing source did not perform identity proofing
Weak	- The issuing source of the evidence did not perform identity proofing. - The issuing process for the evidence means that it can reasonably be assumed to have been delivered into the possession of an individual. - The evidence contains at least one reference number that uniquely identifies the person to whom it relates.
Adequate	- The issuing source of the evidence confirmed the claimed identity through an identity proofing process. - The issuing process for the evidence means that it can reasonably be assumed to have been delivered into the possession of the person to whom it relates. - The evidence contains at least one reference number that uniquely identifies the person to whom it relates. OR - The evidence contains a photograph, image, or biometric of the person to whom it relates. OR - Ownership of the evidence can be confirmed through KBV. - Where the evidence includes digital information, that information is protected using cryptographic and/or proprietary methods and those methods ensure the integrity of the information and enable the authenticity of the claimed issuing source to be confirmed. - Where the evidence includes physical security features, it requires proprietary knowledge to be able to reproduce it. -The issued evidence is unexpired.
Strong	- The issuing source of the evidence confirmed the claimed identity through written procedures designed to enable it to form a reasonable belief that it knows the true identity of the individual. Such procedures shall be subject to recurring oversight by regulatory or publicly accountable institutions. For example, the Customer Identification Program guidelines established in response to the USA PATRIOT Act of 2001 or the Red Flags Rule, under Section 114 of the Fair and Accurate Credit Transaction Act of 2003 (FACT Act) - The issuing process for the evidence ensured that it was delivered into the possession of the person to whom it relates. -The issued evidence contains at least one reference number that uniquely identifies the person to whom it relates. - The applicant’s name on the issued evidence must be the name that the identity was officially known at the time of issuance. Pseudonyms, aliases and initials for last name and at least one first name are not permitted. - The issued evidence contains a photograph/image/biometric of the person to whom it relates. - Where the issued evidence includes digital information, that information is protected using cryptographic and/or proprietary methods and those methods ensure the integrity of the information and enable the authenticity of the claimed issuing source to be confirmed. -Where the issued evidence contains physical security features, it requires proprietary knowledge and proprietary equipment to be able to reproduce it. - The evidence is unexpired.
Superior	- The issuing source of the evidence confirmed the claimed identity through written procedures designed to enable it to have high confidence it knows the true identity of the individual. Such procedures shall be subject to recurring oversight by regulatory or publicly accountable institutions. - The issuing source visually identified the applicant and performed further checks to confirm the existence of that identity. - The issuing process for the evidence ensured that it was delivered into the possession of the person to whom it relates. - The evidence contains at least one reference number that uniquely identifies person to whom it relates. - The applicant’s name on the evidence must be the name that the identity was officially known at the time of issuance. Pseudonyms, aliases and initials for first and last names are not permitted. - The evidence contains a photograph/image of the person to whom it relates. - The evidence contains a biometric of the person to whom it relates. - The evidence includes digital information, the information is protected using cryptographic and/or proprietary methods and those methods ensure the integrity of the information and enable the authenticity of the issuing source to be confirmed. - The evidence includes physical security features that requires proprietary knowledge and proprietary equipment to be able to reproduce it. - The evidence is unexpired.

5.2.2. Validating Identity Evidence

Once identity evidence is obtained by the CSP, the accuracy, authenticity, and integrity of the evidence and related information is checked against authoritative sources in order to determine that the presented evidence is:

• Genuine, authentic, and not a counterfeit, fake, or forgery.
• The information is correct.
• The information relates to a real individual.

5.2.2.1. Methods to Perform Identity Evidence Validation

Table 5-2 lists qualities, ranging from unacceptable to superior, of identity validation that is performed to validate evidence and the information contained therein.

Strength	Method(s)
Unacceptable	Evidence validation was not performed, or validation of the evidence failed.
Weak	All personal details from the evidence have been confirmed as valid by comparison with information held or published by an authoritative source.
Adequate	- All personal and evidence details have been confirmed as valid by comparison with information held/published by the issuing source. OR - The evidence has been confirmed as genuine using appropriate equipment, confirming the integrity of physical security features and lack of fraudulent modification. OR - The evidence has been confirmed as genuine by trained personnel. OR - The issued evidence has been confirmed as genuine by confirmation of the integrity of cryptographic security features.
Strong	- The evidence has been confirmed as genuine using appropriate equipment, confirming the integrity of physical security features and lack of fraudulent modification. OR The evidence has been confirmed as genuine by trained personnel and appropriate equipment, confirming the integrity of the physical security features and lack of fraudulent modification OR The evidence has been confirmed as genuine by confirmation of the integrity of cryptographic security features. AND - All personal details and evidence details have been confirmed as valid by comparison with information held/published by the issuing source OR evidence details have been confirmed as valid by comparison with information held/published by the issuing source.
Superior	- The evidence has been confirmed as genuine by trained personnel and appropriate equipment including the integrity of any physical and cryptographic security features. AND - All personal details and evidence details from the evidence have been confirmed as valid by comparison with information held/published by the issuing source.

5.3. Identity Verification

The goal of identity validation is to confirm and establish a linkage between the claimed identity and the physical, live existence of the person actually presenting the evidence.

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/trained/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 CSP MAY perform re-proofing of the subscriber 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

See 800-63B, Section 6.1, Authenticator Binding for instructions on binding authenticators to subscribers.

6. Leveraging Antecedent Proofing Events

This section is normative.

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

• No additional requirements for IAL 2.

6.2.3. IAL 3 Requirements

1. All of the requirements of Section 6.1.3., in addition;
2. The CSP SHALL collect and record a biometric sample at the time of proofing (e.g., facial image or fingerprints) to ensure that the applicant cannot repudiate application. See Section 5.2.3 of SP 800-63B for more detail on biometric collection.

7. Threats and Security Considerations

This section is informative.

There are two general categories of threats to the enrollment process: impersonation and either compromise or malfeasance of the infrastructure (CSPs). This recommendation focuses on addressing impersonation threats. Infrastructure threats are addressed by normal computer security controls (e.g., separation of duties, record keeping, independent audits) and are outside the scope of this document.

The threats to the enrollment process include impersonation attacks and threats to the transport mechanisms for identity proofing, and authenticator binding, and credential issuance. Table 7-1 lists the threats related to enrollment and identity proofing.

Activity	Threat/Attack	Example
Enrollment	Falsified identity proofing evidence	An applicant claims an incorrect identity by using a forged driver’s license.
	Fraudulent use of another’s identity	An applicant uses a passport associated with a different individual
	Repudiation of enrollment	A subscriber denies enrollment, claiming that he or she did not enroll with the CSP.
	Social engineering	A malicious applicant manipulates an individual responsible for identity proofing in order to be enrolled as another individual.
Issuance	Disclosure	A key created by the CSP for a Subscriber is copied by an attacker as it is transported from the CSP to the subscriber during authenticator issuance.
	Tampering	A new password created by the subscriber is modified by an attacker as it is being submitted to the CSP during the credential issuance phase.
	Unauthorized issuance	A person claiming to be the subscriber (but in reality is not the subscriber) is issued credentials for that subscriber.
	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

Enrollment threats can be deterred by making impersonation more difficult to accomplish or by increasing the likelihood of detection. This recommendation deals primarily with methods for making impersonation more difficult; however, it does prescribe certain methods and procedures that may help to prove who carried out an impersonation. At each level, methods are employed to determine that a person with the claimed identity exists, that the Applicant is the person who is entitled to the claimed identity, and that the Applicant cannot later repudiate the enrollment. As the level of assurance increases, the methods employed provide increasing resistance to casual, systematic and insider impersonation. Table 7-2 lists strategies for mitigating threats to the enrollment and issuance processes.

Activity	Threat/Attack	Mitigation Strategy
Enrollment	Falsified identity proofing evidence	CSP validates physical security features of presented evidence.
		CSP validates personal details in the evidence with the issuer or other authoritative source.
	Fraudulent use of another’s identity	CSP verifies identity evidence or biometric of applicant against information on evidence or obtained from issuer or other authoritative source.
		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.
	Repudiation of enrollment	Have the applicant sign a form acknowledging participation in the enrollment activity.
	Social engineering	Duplicate records check.
Issuance	Disclosure	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.
	Tampering	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.
	Unauthorized issuance/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 defines usability as: Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. This definition focuses on users, goals, and context of use as key elements necessary for achieving effectiveness, efficiency and satisfaction. A holistic approach considering these key elements is necessary to achieve usability.

The overarching goal of usability for enrollment and identity proofing is to promote a smooth and positive enrollment process for users by minimizing user burden (for example, their time and frustration), and minimizing enrollment friction (for example, the number of steps a user must complete, and the amount of information they have to keep track of).

The enrollment and identity proofing process will set the stage for a user’s interactions with a given authenticator for access to an online service. Negative first impressions can influence later user perceptions of subsequent interactions with the organizations online services and practices. Therefore, organizations should strive to promote a positive user experience throughout enrollment and identity proofing.

Enrollment and identity proofing steps and processes should be designed and implemented to make it easy for users to do the right thing, hard to do the wrong thing, easy to recover when something goes wrong, and hard for someone to impersonate an individual. Enrollment and identity proofing process are effectively delivered when considered from the user perspective. Organizations that are cognizant of the overall implications of their stakeholders’ entire enrollment and identity proofing process, keeping in mind the combination of users, their goals, and context of use, will benefit from an improved experience for their users. Performing a usability evaluation on the enrollment and identity proofing process is critical, conducting them with representative users, realistic goals and tasks, and appropriate contexts of use.

The current section takes this holistic view in applying usability principles to the enrollment and identity proofing process, with the goal of raising implementers’ awareness of usability considerations associated with enrollment and identity proofing (for usability considerations for typical authenticator usage and intermittent events, see 800-63-3B).

ASSUMPTIONS

In this section, the term “users” means “Applicants” or “Subscribers.”

This section describes guidelines and considerations from the end-users’ perspective, as usability guidelines can only be written from the end-users’ perspective.

Accessibility and usability differ significantly; therefore, accessibility is out of scope for this section. However, organizations should obviously address accessibility in their implementation plans.

9.1. User Experience During Enrollment and Identity Proofing

The first step for organizations is getting to know the user to promote a smooth and positive enrollment process. Before users begin the enrollment and identity proofing process, organizations should match users with suitable CSPs based on users’ characteristics. From the user perspective, there are three primary stages to enrollment and identity proofing: pre-enrollment preparation, the enrollment and proofing session itself, and post-enrollment actions. Note that these stages may occur within a single session or there could be significant time elapsed between each stage (for example, days or weeks).

Usability considerations for each stage are detailed below. Most of the usability considerations apply to all identity proofing approaches. However, additional considerations are provided for specific proofing methods.

9.1.1. Pre-Enrollment Preparation

Since a successful enrollment session is challenging and frustrating without sufficient user preparation, this section is devoted to describing the necessary approach to help ensure sufficient pre-enrollment preparation. Ensuring that users are sufficiently prepared for their enrollment sessions is critical to the overall success and usability of the enrollment and identity proofing process. Such preparation can only be realized if users receive the necessary information (i.e., proofing and enrollment requirements) in a usable format, provided at an appropriate time. Users must be fully informed regarding exactly what identity evidence they need to bring to an enrollment session, regardless of whether it is in-person, virtual in-person, or remote. Such information must be conveyed from the users’ perspectives, not from the implementers’ perspectives. For example, while organizations need to know in advance what type of IAL is required for access to a particular information system, users do not need to know anything about IALs or whether the identity evidence required is scored as ‘adequate’, ‘strong’, or ‘superior’; users simply need to know exactly what materials are required, and how and where to provide them.

Provide users the information necessary to ensure they are fully prepared for their enrollment session. Such information allows users to make an informed decision regarding whether they wish to proceed with the enrollment process. Usability considerations associated with preparing users for their enrollment session include:

• 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