Table of Contents

1. Purpose

2. Introduction

3. Definitions and Abbreviations

4. Digital Authentication Model

5. A New Approach to Levels of Assurance

6. References

1. Purpose

Sections 1 - 5 are informative.

This recommendation and its companion documents, SP 800-63A, SP 800-63B, and SP 800-63C, provide technical guidelines to agencies for the implementation of digital authentication.

2. Introduction

Digital authentication is the process of establishing confidence in user identities presented to an information system. Digital authentication presents a technical challenge when this process involves the remote authentication of individual people over a network. This recommendation provides technical guidelines to agencies to allow an individual person to remotely authenticate his/her identity to a Federal Information Technology (IT) system. This recommendation also provides guidelines for credential service providers (CSPs), verifiers, and relying parties (RPs).

Current government systems do not separate the functions of authentication and attribute providers. However, in some applications, these functions are provided by different parties. This document suite describes authenticator assurance and identity assurance as separate metrics, and provides a mapping between these metrics and overall level of assurance. These technical guidelines supplement OMB guidance, E-Authentication Guidance for Federal Agencies [OMB M-04-04] and supersede NIST SP 800-63-1 and SP 800-63-2. OMB M-04-04 defines four levels of assurance, Levels 1 to 4, in terms of the consequences of authentication errors and misuse of credentials. Level 1 is the lowest assurance level and Level 4 is the highest. The guidance defines the required level of assurance in terms of the likely consequences of an authentication error. As the consequences of an authentication error become more serious, the required level of assurance increases. The OMB guidance provides agencies with criteria for determining the level of assurance required for specific digital transactions and systems, based on the risks and their likelihood of occurrence.

SP 800-63 is organized as a suite of documents as follows:

• SP 800-63-3 Digital Authentication Guideline - Provides an overview of general authentication frameworks, for using authenticators, credentials, and assertions together in an information system, and possible methods of selecting discrete assurance levels. This document is informative.

• SP 800-63A Enrollment and Identity Proofing - Provides guidelines on processes by which an individual is enrolled in an identity system and identity proofed. This document contains both normative and informative material.

• SP 800-63B Authentication and Lifecycle Management - Provides guidelines on the selection, use, and management of authenticators (formerly called tokens) to authenticate a remote subscriber to an identity system at specified authenticator assurance levels. This document contains both normative and informative material.

• SP 800-63C Federation and Assertions - Provides guidelines on the use of federated identity and assertions to convey the results of authentication processes to a relying party. This document contains both normative and informative material.

It is anticipated that SP 800-63A, SP 800-63B, and SP 800-63C will be revised asynchronously with each other and with this document. The latest revision of each should be used.

OMB guidance outlines a five-step process by which agencies should meet their authentication assurance requirements:

1. Conduct a risk assessment of the government system – No specific risk assessment methodology is prescribed for this purpose; however, NIST Special Publication (SP) 800-30 [SP 800-30] offers a general process for risk assessment and risk mitigation, and NIST Special Publication (SP) 800-37 Revision 1 [SP 800-37] provides guidelines on the selection and specification of security controls for an information system as part of an organization-wide information security program. This guideline supports the identification of risk to the organization or to individuals associated with the operation of an information system.

2. Map identified risks to the appropriate assurance level – Section 2.2 of OMB M-04-04 provides the guidance necessary for agencies to perform this mapping.

3. Select technology based on digital authentication technical guidance – After the appropriate assurance level has been determined, OMB guidance states that agencies should select technologies that meet the corresponding technical requirements, as specified by this document suite. Some agencies may possess existing digital authentication technology. Agencies should verify that any existing technology meets the requirements specified in this document suite.

4. Validate that the implemented system has met the required assurance level – As some implementations may create or compound particular risks, agencies should conduct a final validation to confirm that the system achieves the required assurance level for the user-to-agency process. NIST SP 800-53A [SP 800-53A] provides guidelines for the assessment of the implemented system during the validation process. Validation should be performed as part of a security authorization process as described in NIST SP 800-37, Revision 1 [SP 800-37].

5. Periodically reassess the information system to determine technology refresh requirements – The agency shall periodically reassess the information system to ensure that the identity authentication requirements continue to be satisfied. NIST SP 800-37, Revision 1 [SP 800-37] provides guidelines on the frequency, depth and breadth of periodic reassessments. As with the initial validation process, agencies should follow the assessment guidelines specified in SP 800-53A [SP 800-53A] for conducting the security assessment.

This suite of documents provides guidelines for implementing the third step of the above process. In particular, this document maps the four Levels of Assurance defined in OMB M-04-04 into corresponding authenticator assurance and identity assurance levels. Other documents in the suite state specific technical requirements for identity assurance and authenticator assurance in the following areas:

• Identity proofing and registration of applicants (covered in SP 800-63A)

• Credential lifecycle and management mechanisms (covered in SP 800-63A)

• Authenticators (typically a cryptographic key or password) for authentication (covered in SP 800-63B)

• Authenticator lifecycle and management mechanisms (covered in SP 800-63B)

• Protocols used to support the authentication mechanism between the claimant and the verifier (covered in SP 800-63B)

• Assertion mechanisms used to communicate the results of a remote authentication if these results are sent to other parties (covered in SP 800-63C).

The M-04-04 Level of Assurance is determined by considering the identity assurance level, authenticator assurance level, and federation assurance level achieved for each of the elements listed above, and determining the Level of Assurance satisfied by all elements.

Within a given level of assurance, agencies may employ additional risk mitigation measures and compensating controls. Easing credential assurance level requirements may result in benefits such as increasing the size of the enabled customer pool, but agencies shall ensure that mitigations and compensating controls do not degrade the intended security and privacy of the selected assurance levels. Alternatively, agencies may consider partitioning the functionality of a digital authentication enabled application to allow less sensitive functions to be available at a lower level of authentication and identity assurance, while more sensitive functions are available only at a higher level of assurance.

These technical guidelines cover remote digital authentication of human users to IT systems over a network. They do not address the authentication of a person who is physically present, for example, for access to buildings, although some credentials and authenticators that are used remotely may also be used for local authentication. These technical guidelines establish requirements that Federal IT systems and service providers participating in authentication protocols be authenticated to subscribers. However, these guidelines do not specifically address machine-to-machine (such as router-to-router) authentication, or establish specific requirements for issuing authentication credentials and authenticators to machines and servers when they are used in authentication protocols with people.

The paradigm of this document suite is that individuals are enrolled, issued one or more authenticators, and undergo a registration process in which their identity is bound to the authenticator(s). Higher identity assurance levels require stronger registration procedures. Thereafter, the individuals are remotely authenticated to systems and applications over a network, using the authenticator(s) in an authentication protocol. The authentication protocol allows an individual to demonstrate to a verifier that he or she has possession and control of the authenticator(s), in a manner that protects the authenticator secrets from compromise by different kinds of attacks. Higher authenticator assurance levels require use of stronger authentication mechanisms, better protocols, and better protection of the authenticator(s) and related secrets from attacks.

This document suite focuses on authenticators that are difficult to forge because they contain some type of secret information that is not available to unauthorized parties and that is preferably not used in unrelated contexts. Biometric authentication uses human characteristics that, in some cases, may be available to an attacker. Accordingly, the use of biometrics for authentication is limited to activation of a specific physical authenticator to which it is strongly bound, and the number of consecutive activation failures is limited, beyond which another activation factor or authenticator is required. This document suite also supports the use of biometrics to prevent repudiation of registration, and to verify that the same individual participates in all phases of the registration process.

Knowledge based authentication achieves authentication by testing the personal knowledge of the individual against information obtained from public databases. As this information is considered private but not actually secret, confidence in the identity of an individual can be hard to achieve. In addition, the complexity and interdependencies of knowledge based authentication systems are difficult to quantify. However, knowledge based verification techniques are included as part of registration in SP 800-63A.

This document suite identifies minimum technical requirements for remotely authenticating users. Agencies may determine based on their risk analysis that additional measures are appropriate in certain contexts. In particular, privacy requirements and legal risks may lead agencies to determine that additional authentication measures or other process safeguards are appropriate. When developing digital authentication processes and systems, agencies should consult OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 [M-03-22]. See the Guide to Federal Agencies on Implementing Electronic Processes [DOJ 2000] for additional information on legal risks, especially those that are related to the need to satisfy legal standards of proof and prevent repudiation, as well as Use of Electronic Signatures in Federal Organization Transactions [ESIG].

Additionally, Federal agencies implementing these guidelines should adhere to the requirements of Title III of the E-Government Act, entitled the Federal Information Security Management Act [FISMA], and related NIST standards and guidelines. FISMA directs Federal agencies to develop, document, and implement agency-wide programs to provide information security for the information and information systems that support the operations and assets of the agency. This includes the security authorization of IT systems that support digital authentication. It is recommended that non-Federal entities implementing these guidelines follow equivalent standards of security management, certification and accreditation to ensure the secure operations of their digital systems.

2.1. How to Use this Suite of Special Publications

The business model, marketplace, and the composition of the way identity services are delivered has drastically changed since initial versions of Special Publication 800-63 were released. Notably, CSPs can be componentized and composed of multiple independently operated and owned business entities. In addition, there is a significant benefit to the use of strong authenticators even if no identity proofing is required. Therefore, a suite of special publications under the 800-63 moniker has been created to facilitate these new models and make it easy to access the specific requirements for the function an entity may serve under the overall digital authentication model. Each document stands alone. However, it is expected that all CSPs, even componentized, will be required to meet the guidelines in SP 800-63A and SP 800-63B. If the CSP also participates in an identity federation, which is preferred over use of a standalone CSP, meeting the requirements of SP 800-63C also applies.

2.2. Relationship to Other Standards and Guidelines

This document has been written to satisfy the needs of federal agencies. However, with the expansion of citizen services throughout the world that require identity and authentication assurance, as well as an increasing number of use cases that promote international identity federation and interoperability, this guideline is intended to achieve alignment to national and international standards that describe levels of identity assurance. Table 2-1 provides a representative snapshot of mappings to various international and national assurance documents. This is not meant to imply that there is direct correlation between the IALs and AALs in this document and the levels in those standards, but that it is seen that this document fulfills the criteria as demonstrated in those standards.

SP 800-63	[GPG 45]	[RSDOPS]	[STORK 2.0]	[ISO 29115]	[ISO 29003]	[Canada]
N/A	N/A	Level 01	N/A	N/A	N/A	N/A
AAL/IAL 1	Level 1	Level 1	QAA Level 1	LoA 1	LoA 1	IAL/CAL 1
AAL/IAL 1	Level 2	Level 2	QAA Level 2	LoA 2	LoA 2	IAL/CAL 2
AAL/IAL 2	Level 3	Level 3	QAA Level 3	LoA 3	LoA 3	IAL/CAL 3
AAL/IAL 3	Level 4	N/A2	QAA Level 4	LoA 4	LoA 4	IAL/CAL 4

2.2. Change History

2.2.1. SP 800-63-1

NIST SP 800-63-1 updated NIST SP 800-63 to reflect current authenticator (then referred to as token) technologies and restructured to provide a better understanding of the digital authentication architectural model used here. Additional (minimum) technical requirements were specified for the CSP, protocols utilized to transport authentication information, and assertions if implemented within the digital authentication model. Other changes to NIST SP 800-63 included:

• Recognition of more types of tokens, including pre-registered knowledge token, look-up secret token, out-of-band token, as well as some terminology changes for more conventional token types;

• Detailed requirements for assertion protocols and Kerberos;

• A new section on token and credential management;

• Simplification of guidelines for password entropy and throttling;

• Emphasis that the document is aimed at Federal IT systems;

• Recognition of different models, including a broader digital authentication model (in contrast to the simpler model common among Federal IT systems shown in Figure 1) and an additional assertion model, the Proxy Model, presented in Figure 6;

• Clarification of differences between Levels 3 and 4 in Table 12; and

• New guidelines that permit leveraging existing credentials to issue derived credentials.

The subsequent sections of NIST SP 800-63-1 presented a series of recommendations for the secure implementation of RAs, CSPs, Verifiers, and RPs. It should be noted that secure implementation of any one of these can only provide the desired level of assurance if the others are also implemented securely. Therefore, the following assumptions were made in NIST SP 800-63-1:

• RAs, CSPs, and Verifiers are trusted entities. Agencies implementing any of the above trusted entities have some assurance that all other trusted entities with which the agency interacts are also implemented appropriately for the desired security level.

• The RP is not considered a trusted entity. However, in some authentication systems the Verifier maintains a relationship with the RP to facilitate secure communications and may employ security controls which only attain their full value when the RP acts responsibly. The subscriber also trusts the RP to properly perform the requested service and to follow all relevant privacy policy.

• It is assumed that there exists a process of certification through which agencies can obtain the above assurance for trusted entities which they do not implement themselves.

• A trusted entity is considered to be implemented appropriately if it complies with the recommendations in this document and does not behave maliciously.

• While it is generally assumed that trusted entities will not behave maliciously, this document does contain some recommendations to reduce and isolate any damage done by a malicious or negligent trusted entity.

2.2.2. SP 800-63-2

NIST SP 800-63-2 was a limited update of Special Publication 800-63-1 and substantive changes were made only in section 5. Registration and Issuance Processes. The substantive changes in the revised draft were intended to facilitate the use of professional credentials in the identity proofing process, and to reduce the need to use postal mail to an address of record to issue credentials for level 3 remote registration. Other changes to section 5 were minor explanations and clarifications.

2.2.3. SP 800-63-3

NIST SP 800-63-3 is a substantial update and restructuring of Special Publication 800-63-2. It introduces the concepts of authenticator assurance level, identity assurance level, and federation assurance level to support the growing need for independent treatment of authentication strength and confidence in the claimant’s identity (for example, in strong pseudonymous authentication). It also moves from a single document describing authentication to a suite of four documents, of which SP 800-63-3 is the top-level document.

Other areas of update to SP 800-63-2 include:

• Terminology changes, primarily the use of authenticator in place of token to avoid conflicting use of the word token in assertion technologies
• Updates to authentication and assertion requirements to reflect advances in both security technology and threats
• Requirements on the storage of long-term secrets by verifiers
• Restructured identity proofing model
• Updated requirements regarding remote identity proofing
• Clarification on the use of independent channels and devices as “something you have”
• Removal of pre-registered knowledge tokens (authenticators), with the recognition that they are special cases of (often very weak) passwords.
• Requirements regarding account recovery in the event of loss or theft of an authenticator
• Expanded discussion of reauthentication and session management
• Expanded discussion of identity federation; restructuring of assertions in the context of federation

3. Definitions and Abbreviations

There is a wide variety of terms used in the area of authentication. While the definitions of many terms are consistent with the 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 suite 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.

Assertion

A statement from a verifier to a relying party (RP) that contains identity information about a subscriber. Assertions may also contain verified attributes.

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 fool a verifier or a relying party into believing that the unauthorized individual in question is 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.

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, and optionally, demonstrates to the claimant that he or she is communicating with the intended verifier.

Authentication Secret

A generic term for any secret value that could be used by an attacker to impersonate the subscriber in an authentication protocol.

These are further divided into short-term authentication secrets, which are only useful to an attacker for a limited period of time, and long-term authentication secrets, which allow an attacker to impersonate the subscriber until they are manually reset. The authenticator secret is the canonical example of a long term authentication secret, while the authenticator output, if it is different from the authenticator secret, is usually a short term authentication secret.

Authenticator

Something that the 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.

Authenticator Assurance Level (AAL)

A metric describing robustness of the authentication process proving that the claimant is in control of a given subscriber’s authenticator(s).

Authenticator Secret

The secret value contained within an authenticator.

Authenticity

The property that data originated from its purported source.

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 Identity

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

Credential

An object or data structure that authoritatively binds an identity (via an identifier) (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(s) 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 Registration Authorities (RAs) and verifiers that it operates. A CSP may be an independent third party, or may issue credentials for its own use.

Cryptographic Key

A value used to control cryptographic operations, such as decryption, encryption, signature generation or signature verification. For the purposes of this document, key requirements shall meet the minimum requirements stated in Table 2 of NIST SP 800-57 Part 1.

See also Asymmetric keys, Symmetric key.

Cryptographic Authenticator

An authenticator where the secret is a cryptographic key.

Digital Authentication

The process of establishing confidence in user identities digitally 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.

Federal Information Security Management Act (FISMA)

Title III of the E-Government Act requiring each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.

Federal Information Processing Standard (FIPS)

Under the Information Technology Management Reform Act (Public Law 104-106), the Secretary of Commerce approves standards and guidelines that are developed by the National Institute of Standards and Technology (NIST) for Federal computer systems. These standards and guidelines are issued by NIST as Federal Information Processing Standards (FIPS) for use government-wide. NIST develops FIPS when there are compelling Federal government requirements such as for security and interoperability and there are no acceptable industry standards or solutions. See background information for more details.

FIPS documents are available online through the FIPS home page: http://www.nist.gov/itl/fips.cfm

Federation

A process that allows for the conveyance of identity and authentication information across a set of networked systems.

Federation Assurance Level

A metric describing the robustness of the assertion protocol utilized by the federation to communicate authentication and attribute information (if applicable) to a relying party.

Identity

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

Identity Assurance Level (IAL)

An ordinal that conveys the degree of confidence that the applicant’s claimed identity is their real identity.

Identity Proofing

The process by which a CSP and a Registration Authority (RA) collect and verify information about a person for the purpose of issuing credentials to that person.

Memorized Secret

A type of authenticator consisting of a character string that is intended to be memorized or memorizable by the subscriber, permitting the subscriber to demonstrate something they know as part of an authentication process.

Multi-Factor

A characteristic of an authentication system or an authenticator that requires more than one authentication factor for successful authentication. Multi-factor authentication can be performed using a single authenticator that provides more than one factor or by a combination of authenticators that provide different factors.

The three authentication factors are something you know, something you have, and something you are.

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

Password

A memorized secret. In some contexts, passwords are restricted in length and composition.

Personal Identification Number (PIN)

A memorized secret typically consisting only of decimal digits.

Personally Identifiable Information (PII)

As defined by OMB Circular [A-130], Personally Identifiable Information means 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.

Private Key

The secret part of an asymmetric key pair that is used to digitally sign or decrypt data.

Pseudonymous Identifier

A meaningless, but unique number that does not allow the RP to infer the subscriber but which does permit the RP to associate multiple interactions with the subscriber’s claimed identity.

Public Key

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

Public Key Certificate

A digital document issued and digitally signed by the private key of a Certificate authority that binds an identifier to a subscriber to a public key. The certificate indicates that the subscriber identified in the certificate has sole control and access to the private key. See also [RFC 5280].

Public Key Infrastructure (PKI)

A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.

Registration

The process through which an applicant applies to become a subscriber of a CSP and has their identity validated by the CSP.

Relying Party (RP)

An entity that relies upon the subscriber’s authenticator(s) and credentials or a verifier’s assertion of a claimant’s identity, typically to process a transaction or grant access to information or a system.

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.

Risk Assessment

The process of identifying the risks to system security and determining the probability of occurrence, the resulting impact, and additional safeguards that would mitigate this impact. Part of Risk Management and synonymous with Risk Analysis.

Shared Secret

A secret used in authentication that is known to the subscriber and the verifier.

Special Publication (SP)

A type of publication issued by NIST. Specifically, the Special Publication 800-series reports on the Information Technology Laboratory’s research, guidelines, and outreach efforts in computer security, and its collaborative activities with industry, government, and academic organizations.

Subscriber

A party who has received a credential or authenticator from a CSP.

Symmetric Key

A cryptographic key that is used to perform both the cryptographic operation and its inverse, for example to encrypt and decrypt, or create a message authentication code and to verify the code.

Token

See Authenticator.

Valid

In reference to identity evidence, the quality of not being expired or revoked.

Verifier

An entity that verifies the claimant’s identity by verifying the claimant’s possession and control of one or two authenticators using an authentication protocol. To do this, the verifier may also need to validate credentials that link the authenticator(s) to the subscriber’s identifier and check their status.

4. Digital Authentication Model

4.1. Overview

In accordance with OMB M-04-04, digital authentication is the process of establishing confidence in individual identities presented to a digital system. Systems can use the authenticated identity to determine if that individual is authorized to perform an online transaction. In most cases, the authentication and transaction take place across an open network such as the Internet; however, in some cases access to the network may be limited and access control decisions may take this into account.

The digital authentication model used in these guidelines reflects current technologies and architectures used in government. More complex models that separate functions, such as issuing credentials and providing attributes, among larger numbers of parties are also available and may have advantages in some classes of applications. While a simpler model is used in this document, it does not preclude agencies from separating these functions. In addition, certain enrollment, identity proofing, and issuance processes performed by the credential service provider (CSP) are sometimes delegated to an entity known as the registration authority (RA) or identity manager (IM). A close relationship between the RA/IM and CSP is typical, and the nature of this relationship may differ among RAs, IMs, and CSPs. The types of relationship and their requirements is outside of the scope of this document. Accordingly, the term CSP will be used to be inclusive of RA/IM functions.

Digital authentication begins with enrollment. The usual sequence for enrollment proceeds as follows. An applicant applies to a CSP. If approved, the CSP creates a credential and binds it to one or more authenticators. The credential includes an identifier, which can be pseudonymous, and possibly one or more attributes that the CSP has verified. The authenticators may be issued by the CSP, generated/provided directly by the subscriber, or provided by a third party. The authenticators and credential may be used in subsequent authentication events.

The process used to verify an applicant’s association with their real world identity is called identity proofing. The strength of identity proofing is described by a categorization called the identity assurance level (IAL). At IAL 1, identity proofing is not required, therefore any attribute information provided by the subscriber is self-asserted and not verified. At IAL 2 and 3, identity proofing is required, but the CSP may assert verified attribute values, verified attribute claims, pseudonymous identifiers, or nothing. This information assists Relying Parties (RPs) in making access control or authorization decisions. RPs may decide that their required IAL is 2 or 3, but may only need specific attributes, perhaps those that retain a degree of pseudonymity for the individual. This privacy enhancing approach is one of the benefits of separating the strength of the proofing process from that of the authentication process. A relying party may also employ a federated identity approach where the RP outsources all identity proofing, attribute collection, and attribute storage to a CSP.

In this document suite, the party to be authenticated is called a claimant and the party verifying that identity is called a verifier. When a claimant successfully demonstrates possession and control of one or more authenticators to a verifier through an authentication protocol, the verifier can verify that the claimant is a valid subscriber. The verifier passes on an assertion about the subscriber, who may be either pseudonymous or non-pseudonymous, to the RP. That assertion includes an identifier, and may include identity information about the subscriber, such as the name, or other attributes that were verified in the enrollment process (subject to the policies of the CSP and the needs of the application). Where the verifier is also the RP, the assertion may be implicit. The RP can use the authenticated information provided by the verifier to make access control or authorization decisions.

Authentication establishes confidence in the claimant’s identity, and in some cases in the claimant’s attributes (for example if the subscriber is a US Citizen, is a student at a particular university, or is assigned a particular number or code by an agency or organization). Authentication does not determine the claimant’s authorizations or access privileges; this is a separate decision. RPs (e.g., government agencies) will use a subscriber’s authenticated identity and attributes with other factors to make access control or authorization decisions. Nothing in this document suite precludes RPs from requesting additional information from a subscriber that has successfully authenticated.

The strength of the authentication process is described by a categorization called the authenticator assurance level (AAL). AAL 1 requires single-factor authentication and is permitted with a variety of different authenticator types. At AAL 2, authentication requires two authentication factors for additional security. Authentication at the highest level, AAL 3, requires the use of a hardware-based authenticator and one other factor.

As part of authentication, mechanisms such as device identity or geo-location may be used to identify or prevent possible authentication false positives. While these mechanisms do not directly increase the authenticator assurance level, they can aid in enforcing security policies and mitigate risks. In many cases, the authentication process and services will be shared by many applications and agencies. However, it is the individual agency or application acting as the RP that shall make the decision to grant access or process a transaction based on the specific application requirements.

The various entities and interactions that comprise the digital authentication model used here are illustrated below in Figure 4-1. The left side of the diagram shows the enrollment, credential issuance, lifecycle management activities, and the various states an individual transitions among based on the phase of identity proofing and authentication they are in. The usual sequence of interactions is as follows:

1. An individual (applicant) applies to a CSP through an enrollment process.
2. The CSP identity proofs that applicant. Upon successful proofing, the applicant becomes a subscriber.
3. Authenticator(s) and a corresponding credential are established between the CSP and the new subscriber.
4. The CSP maintains the credential, its status, and the enrollment data collected for the lifetime of the credential (at a minimum). The subscriber maintains his or her authenticator(s).

Other sequences are less common, but could also achieve the same functional requirements.

The right side of Figure 4-1 shows the entities and the interactions related to using a authenticator to perform digital authentication. When the subscriber needs to authenticate to perform a transaction, he or she becomes a claimant to a verifier. The interactions are as follows:

1. The claimant proves to the verifier that he or she possesses and controls the authenticator(s) through an authentication protocol.
2. The verifier interacts with the CSP to validate the credential that binds the subscriber’s identity to his or her authenticator and to optionally obtain claimant attributes.
3. In a federated identity architecture, the CSP/verifier provides an assertion about the subscriber to the RP, which may use the information in the assertion to make an access control or authorization decision.
4. An authenticated session is established between the subscriber and the RP.

In all cases, the RP should request the attributes it requires from a CSP prior to authentication of the claimant. In addition, the claimant should be requested to consent to the release of those attribute prior to generation and release of an assertion.

In some cases, the verifier does not need to communicate in real time with the CSP to complete the authentication activity (e.g., some uses of digital certificates). Therefore, the dashed line between the verifier and the CSP represents a logical link between the two entities rather than a physical link. In some implementations, the verifier, RP and the CSP functions may be distributed and separated as shown in Figure 4-1; however, if these functions reside on the same platform, the interactions between the components are local messages between applications running on the same system rather than protocols over shared untrusted networks.

As noted above, CSPs maintain status information about credentials they issue. CSPs will generally assign a finite lifetime when issuing credentials to limit the maintenance period. When the status changes, or when the credentials near expiration, credentials may be renewed or re-issued; or, the credential may be revoked and/or destroyed. Typically, the subscriber authenticates to the CSP using his or her existing, unexpired authenticator and credential in order to request issuance of a new authenticator and credential. If the subscriber fails to request authenticator and credential re-issuance prior to their expiration or revocation, he or she may be required to repeat the enrollment process to obtain a new authenticator and credential. Alternatively, the CSP may choose to accept a request during a grace period after expiration.

4.2. Enrollment and Identity Proofing

Normative requirements can be found in Special Publication 800-63A, Enrollment and Identity Proofing.

The previous section introduced the different participants in the conceptual digital authentication model. This section provides additional details regarding the relationships and responsibilities of the participants involved with enrollment and identity proofing.

An individual, referred to as an applicant at this stage, requests credentials from a CSP. If the applicant is successfully proofed and a credential is created by a CSP and authenticator(s) are bound to it, the individual is then termed a subscriber of that CSP.

The CSP establishes a mechanism to uniquely identify each subscriber, register the subscriber’s credentials, and track the authenticators issued to that subscriber. The subscriber may be given authenticators at the time of enrollment, the CSP may bind authenticators the subscriber already has, or they may be generated later as needed. Subscribers have a duty to maintain control of their authenticators and comply with their responsibilities to the CSP. The CSP maintains enrollment records for each subscriber to allow recovery of enrollment records.

4.3. Authentication and Lifecycle Management

Normative requirements can be found in Special Publication 800-63B, Authentication and Lifecycle Management.

4.3.1. Authenticators

The classic paradigm for authentication systems identifies three factors as the cornerstone of authentication:

• Something you know (for example, a password)
• Something you have (for example, an ID badge or a cryptographic key)
• Something you are (for example, a fingerprint or other biometric data)

Multi-factor authentication refers to the use of more than one of the factors listed above. The strength of authentication systems is largely determined by the number of factors incorporated by the system. Implementations that use two different factors are considered to be stronger than those that use only one factor; systems that incorporate all three factors are stronger than systems that only incorporate two of the factors. As discussed in Section 5.1, other types of information, such as location data or device identity, may be used by an RP or verifier to evaluate the risk in a claimed identity, but they are not considered authentication factors.

In digital authentication the claimant possesses and controls one or more authenticators that have been registered with the CSP and are used to prove the claimant’s identity. The authenticator(s) contains secrets the claimant can use to prove that he or she is a valid subscriber, the claimant authenticates to a system or application over a network by proving that he or she has possession and control of one or more authenticators.

The secrets contained in authenticators are based on either public key pairs (asymmetric keys) or shared secrets (symmetric keys). A public key and a related private key comprise a public key pair. The private key is stored on the authenticator and is used by the claimant to prove possession and control of the authenticator. A verifier, knowing the claimant’s public key through some credential (typically a public key certificate), can use an authentication protocol to verify the claimant’s identity, by proving that the claimant has possession and control of the associated private key authenticator.

Shared secrets stored on authenticators may be either symmetric keys or memorized secrets (e.g., passwords and PINs), as opposed to the asymmetric keys described above, which subscribers need not share with the authenticator. While both keys and passwords can be used in similar protocols, one important difference between the two is how they relate to the subscriber. While symmetric keys are generally stored in hardware or software that the subscriber controls, passwords are intended to be memorized by the subscriber. Since most users choose short passwords to facilitate memorization and ease of entry, passwords typically have fewer characters than cryptographic keys. Further, whereas systems choose keys at random, users attempting to choose memorable passwords will often select from a very small subset of the possible passwords of a given length, and many will choose very similar values. As such, whereas cryptographic keys are typically long enough to make network-based guessing attacks untenable, user-chosen passwords may be vulnerable—especially if no defenses are in place.

In this document, authenticators always contain a secret. Some of the classic authentication factors do not apply directly to digital authentication. For example, an ID badge is something you have, and is useful when authenticating to a human (e.g., a guard), but is not a authenticator for digital authentication. Authentication factors classified as something you know are not necessarily secrets, either. Knowledge based authentication, where the claimant is prompted to answer questions that can be confirmed from public databases, also does not constitute an acceptable secret for digital authentication. More generally, something you are does not generally constitute a secret. Accordingly, this guideline does not permit the use of biometrics as a authenticator.

However, this guideline does recognize that authentication systems that incorporate all three factors offer better security than systems that only incorporate two of the factors. A digital authentication system may incorporate multiple factors in either of two ways. The system may be implemented so that multiple factors are presented to the verifier, or some factors may be used to protect a secret that will be presented to the verifier. If multiple factors are presented to the verifier, each will need to be a authenticator (and therefore contain a secret). If a single factor is presented to the verifier, the additional factors are used to protect the authenticator and need not themselves be authenticators.

For example, consider a piece of hardware (the authenticator) that contains a cryptographic key (the authenticator secret) where access is protected with a fingerprint. When used with the biometric, the cryptographic key produces an output that is used in the authentication process to authenticate the claimant. An impostor must steal the encrypted key (by stealing the hardware) and replicate the fingerprint to use the authenticator. This specification considers such a device to effectively provide two factor authentication, although the actual authentication protocol between the verifier and the claimant simply proves possession of the key.

As noted above, biometrics, when employed as a single factor of authentication, do not constitute acceptable secrets for digital authentication, but they do have their place in this specification. Biometric characteristics are unique personal attributes that can be used to verify the identity of a person who is physically present at the point of verification. They include facial features, fingerprints, iris patterns, voiceprints, and many other characteristics. Special Publication 800-63A, Enrollment and Identity Proofing recommends that biometrics be used in the enrollment process for higher levels of assurance to later help prevent a subscriber who is registered from repudiating the enrollment, to help identify those who commit enrollment fraud, and to unlock authenticators.

4.3.2. Credentials

As described in the preceding sections, credentials bind an authenticator to the subscriber, via an identifier, as part of the issuance process. Credentials are stored and maintained by the CSP. The claimant possesses a authenticator, but is not necessarily in possession of the electronic credentials. For example, database entries containing the user attributes are considered to be credentials for the purpose of this document but are possessed by the verifier. X.509 public key certificates are a classic example of credentials the claimant can (and often does) possess.

4.3.3. Authentication Process

The authentication process begins with the claimant demonstrating to the verifier possession and control of a authenticator that is bound to the asserted identity through an authentication protocol. Once possession and control has been demonstrated, the verifier verifies that the credential remains valid, usually by interacting with the CSP.

The exact nature of the interaction between the verifier and the claimant during the authentication protocol is extremely important in determining the overall security of the system. Well-designed protocols can protect the integrity and confidentiality of traffic between the claimant and the verifier both during and after the authentication exchange, and it can help limit the damage that can be done by an attacker masquerading as a legitimate verifier.

Additionally, mechanisms located at the verifier can mitigate online guessing attacks against lower entropy secrets like passwords and PINs by limiting the rate at which an attacker can make authentication attempts or otherwise delaying incorrect attempts. Generally, this is done by keeping track of and limiting the number of unsuccessful attempts, since the premise of an online guessing attack is that most attempts will fail.

The verifier is a functional role, but is frequently implemented in combination with the CSP and/or the RP. If the verifier is a separate entity from the CSP, it is often desirable to ensure that the verifier does not learn the subscriber’s authenticator secret in the process of authentication, or at least to ensure that the verifier does not have unrestricted access to secrets stored by the CSP.

4.4. Federation and Assertions

Normative requirements can be found in Special Publication 800-63C, Federation and Assertions.

Overall, SP 800-63-3 does not presuppose a federated identity architecture; rather, the guideline is agnostic to the types of models that exist in the marketplace, allowing agencies to deploy a digital authentication scheme according to their own requirements. However, identity federation, consistent with the National Strategy for Trusted Identities in Cyberspace (NSTIC) [NSTIC], is preferred over a number of siloed identity systems that each serve a single agency or RP.

Federated architectures have many significant benefits, including, but not limited to:

• Enhanced user experience. For example, an individual can be identity proofed once and can reuse the issued credential at multiple RPs
• Cost reduction, to both the user (one authenticator) and the agency (reduction in IT infrastructure)
• Data minimization: agencies do not need to pay for collection, storage, disposal, and compliance activities related to storing personal information
• Privacy enhancing
• Pseudonymous attribute assertions. Agencies can request a minimized set of attributes, to include claims, to fulfill service delivery.
• Mission enablement. Agencies can focus on mission, rather than the business of identity management.

The following sections discuss the components of a federated identity architecture should an agency elect this type of model.

4.4.1 Assertions

Upon completion of the authentication process, the verifier generates an assertion containing the result of the authentication and provides it to the RP. If the verifier is implemented in combination with the RP, the assertion is implicit. If the verifier is a separate entity from the RP, as in typical federated identity models, the assertion is used to communicate the result of the authentication process, and optionally information about the subscriber, from the verifier to the RP. Assertions may be communicated directly to the RP, or can be forwarded through the subscriber, which has further implications for system design.

An RP trusts an assertion based on the source, the time of creation, and the corresponding trust framework that governs the policies and process of CSPs and RPs. The verifier is responsible for providing a mechanism by which the integrity of the assertion can be confirmed.

The RP is responsible for authenticating the source (the verifier) and for confirming the integrity of the assertion. When the verifier passes the assertion through the subscriber, the verifier must protect the integrity of the assertion in such a way that it cannot be modified by the subscriber. However, if the verifier and the RP communicate directly, a protected session may be used to provide the integrity protection. When sending assertions across an open network, the verifier is responsible for ensuring that any sensitive subscriber information contained in the assertion can only be extracted by an RP that it trusts to maintain the information’s confidentiality.

Examples of assertions include:

• SAML Assertions – SAML assertions are specified using a mark-up language intended for describing security assertions. They can be used by a verifier to make a statement to an RP about the identity of a claimant. SAML assertions may optionally be digitally signed.
• OpenID Connect Claims - OpenID Connect claims are specified using JavaScript Object Notation (JSON) for describing security, and optionally, user claims. JSON user info claims may optionally be digitally signed.
• Kerberos Tickets – Kerberos Tickets allow a ticket granting authority to issue session keys to two authenticated parties using symmetric key based encapsulation schemes.

4.4.2. Relying Parties

An RP relies on results of an authentication protocol to establish confidence in the identity or attributes of a subscriber for the purpose of conducting an online transaction. RPs may use a subscriber’s authenticated identity (pseudonymous or non-pseudonymous), the IAL, AAL and/or FAL (federation assurance level, indicating the strength of the assertion protocol), and other factors to make access control or authorization decisions. The verifier and the RP may be the same entity, or they may be separate entities. If they are separate entities, the RP normally receives an assertion from the verifier. The RP ensures that the assertion came from a verifier trusted by the RP. The RP also processes any additional information in the assertion, such as personal attributes or expiration times. The RP is the final arbiter concerning whether a specific assertion presented by a verifier meets the RP’s established criteria for system access regardless of IAL, AAL, and/or FAL.

5. Determining Levels of Assurance

OMB M-04-04 requires agencies to select transaction or system authentication Level of Assurance (LOA) by conducting a risk assessment to determine the potential impact of an authentication error. In the context of M-04-04, LOA is defined as:

1. The degree of confidence in the vetting process used to establish the identity of the individual to whom the authenticator was issued, and
2. the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued.

Per M-04-04, once an LOA is selected, the agency is required to follow the identity proofing, credentialing, and federation technical requirements specified by NIST at that level. For example, if the impact of an authentication error results in an application assessed at LOA 3, the agency must identity proof and provide authenticators that meet the requirements for LOA 3.

However, in today’s digital services, combining proofing and authenticator requirements into a single bundle sometimes creates unintended consequences as well as putting unneccessary implementation burden upon the implementing entity. It is quite possible that an agency can deliver the most effective set of identity services by assessing the risk and impacts of failures for each individual component of digital authentication, not as a single, all encompassing LOA. An authentication error is not a singleton that drives all requirements. This guideline recommends that agencies meet M-04-04 requirements by separately evaluating the impact that could result from (1) a true authentication error (the wrong individual using someone else’s credential) and (2) an identity proofing error. From the perspective of an identity proofing failure, there are two dimensions of potential risk:

• The impact of providing a service to the wrong person (e.g. an attacker successfully proofs as someone else)
• The impact of excessive identity proofing (i.e. collecting more information about a person than is required to successfully provide the digital service.)

As such, agencies should assess the risk of authentication and proofing errors separately to determine the appropriate technical solutions that should be applied to their system.

5.1. Categories of Assurance Levels

To determine the process and system requirements that reduce the risk of an authentication or identity proofing failure, this guideline introduces distinct categories of assurance which drive the technical solutions an agency may implement. They are:

• Identity Assurance Level (IAL) - the robustness of the identity proofing process to confidently determine the identity of an individual
• Authenticator Assurance Level (AAL) - the robustness of the authentication process itself, and the binding between an authenticator and the identifier of a specific individual.
• Federation Assurance Level (FAL) - the robustness of the assertion protocol utilized by the federation to communicate authentication and attribute information (if applicable) to a relying party. FAL is optional as not all digital systems will leverage federated identity architectures.

A summary of each of the identity, authenticator, and federation assurance levels is provided below.

Identity Assurance Level
IAL1 - At this level, attributes provided in conjunction with the authentication process, if any, are self-asserted.
IAL2 - IAL 2 introduces the need for either remote or in-person identity proofing. IAL 2 requires identifying attributes to have been verified in person or remotely using, at a minimum, the procedures given in SP 800-63A.
IAL3 - At IAL 3, in-person identity proofing is required. Identifying attributes must be verified by an authorized representative of the CSP through examination of physical documentation as described in SP 800-63A.

Authenticator Assurance Level
AAL1 - AAL 1 provides some assurance that the claimant controls the authenticator registered to a subscriber. AAL 1 uses single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove through a secure authentication protocol that he or she possesses and controls the authenticator.
AAL2 – AAL 2 provides high confidence that the claimant controls the authenticator registered to a subscriber. Two different authentication factors are required. Approved cryptographic techniques are required at AAL 2 and above.
AAL3 – AAL 3 provides very high confidence that the claimant controls the authenticator registered to a subscriber. Authentication at AAL 3 is based on proof of possession of a key through a cryptographic protocol. AAL 3 is similar to AAL 2 except that a “hard” cryptographic authenticator that also provides impersonation resistance is required.

Federation Assurance Level
FAL1 - FAL 1 allows for the subscriber to retrieve and present a bearer assertion directly to the relying party (RP) in the front channel. The assertion must be signed with using approved cryptography.
FAL2 - FAL 2 requires the subscriber to retrieve an assertion artifact to present to the RP, which the RP then presents to the CSP to fetch the bearer assertion in the back channel. The assertion must be signed using approved cryptography. Alternatively, if the assertion is presented in the front channel, the assertion is required to be encrypted such that the RP is the only party that can decrypt it.
FAL3 - FAL 3 builds on FAL 2 and adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party that can decrypt it.
FAL4 - FAL 4 requires the subscriber to present proof of possession of a cryptographic key referenced in the assertion in addition to the assertion artifact itself. The assertion must be signed using approved cryptography and encrypted to the RP using approved cryptography.

When described generically or bundled, this guideline will refer to the combination of IAL, AAL, and FAL as xAL.

A risk assessment to determine each xAL is recommended. Section 5.3. provides details on how agencies may going about making xAL selections.

5.2. Mapping xAL to M-04-04 Levels of Assurance

This guideline introduces a model where individual xALs can be selected without parity to each other in order to protect a digital service, as opposed to applying a single LOA where all xALs are equal. While options exist to select varying xALs for a system in many instances the same level will be chosen for all xALs. This provides an opportunity to directly map to the LOAs specified in M-04-04. Table 5-1 shows strict adherence to M-04-04 by mapping the corresponding Identity, Authenticator, and Federation Assurance Levels to LOA.

M-04-04 Level of Assurance (LOA)	Identity Assurance Level (IAL)	Authenticator Assurance Level (AAL)	Federation Assurance Level (FAL)
1	1	1	1
2	2	2	2
3	2	2	2
4	3	3	4

Note: LOA2 is now equivalent to LOA3. Higher AALs than specified can always be used.

The ability to combine varying xALs offer significant flexibility to agencies, but not all combinations are possible due to the nature of the data collected from an individual and the authenticators to protect that data. Table 5-2 details valid combinations of IAL and AAL to ensure personal information remains protected by multi-factor authentication.

	IAL 1	IAL 2	IAL 3
AAL 1	Allowed	NO	NO
AAL 2	Allowed	Allowed	See Note
AAL 3	Allowed	Allowed	Allowed

Note: Per Executive Order 13681 [EO 13681], the release of personal information requires protection with multifactor authentication. Therefore, it should not be possible to use an authenticator at a lower assurance level then the IAL. However, depending on the use case, specifically that the transaction that the user authenticates to does not release or manage any personal information, it could be possible for these combinations to exist, though unlikely and not recommended.

5.3. Selecting the Appropriate xAL

Agency mission and risk tolerance should drive the most advantageous selection of xALs to minimize risk. This could include the selection of an IAL that is lower than the selected AAL. For example, an agency may establish a “health tracker” application. In line with the terms of Executive Order 13681 requiring “…that all agencies making personal data accessible to citizens through digital applications require the use of multiple factors of authentication…”, the agency is required to implement multi-factor authentication at AAL 2 or 3. The EO also requires agencies employ “…an effective identity proofing process, as appropriate.” when personal information is released. This does not mean that proofing at IAL 2 or 3 (to match the required AAL) is required for all scenarios when personal information is made available. In the above example, there may be no need for the agency system to know the true identity of the user. Therefore, an effective proofing process would be to not proof at all. In the past, an LOA3 assessment would equate to identity proofing the user at IAL2. This is no longer necessary and the agency is encouraged to not perform any identity proofing and allow the user of the health tracker system to be pseudonymous at IAL1.

Separating IAL and AAL also works for traditional M-04-04 LOA use cases, such as HSPD-12 requirements for federal employees to obtain a Personal Identity Verification (PIV) smart card. The requirement for PIV is that agencies meet LOA4; therefore, an authenticator at AAL3 and identity proofing at IAL 3 sufficiently meets the LOA4 requirements.

Note: An agency can accept a higher assurance level than those required in the table above. For example, in a federated transaction, an agency can accept an IAL3 identity if their application is assessed at IAL2. The same holds true for authenticators; stronger authenticators can be used at RP’s that have lower authenticator requirements. However, RPs will have to ensure that this only occurs in federated scenarios with appropriate privacy protections by the CSP such that only the requested attributes are provided to the RP and that excessive personal information does not leak from the authenticator or the assertion. See privacy requirements in SP 800-63C for more details.

Note: Since agencies are encouraged to consider each distinct element of assurance, the notion of the ‘low watermark’ to determine LOA no longer applies. An IAL1/AAL2 application should not be considered any less secure or privacy enhancing than an IAL2/AAL2 application. The only difference between these applications is the amount of proofing required, which may not impact the security and privacy of each application. That said, if an agency incorrectly determines the xAL, security and privacy could very well be impacted.

5.3.1. Business Process vs. Online Transaction

An online transaction may not equate to a complete business process that requires offline processing, or online processing in a completely segmented system. In selecting the appropriate assurance levels, the agency should assess the risk associated with the online transactions they are offering via the digital service, not the entire business process associated with the provided benefit or service. For example, in an online survey, sensitive personally identifiable information may be collected, but it is never made available online to the person after the information is submitted. In this instance, it is important for the information to be carefully protected in backend systems, but there is no reason to identity proof or even authenticate the user providing the information. The online transaction is solely a submission of the data only. The entire business process may require a significant amount of data validation, without ever needing to know if the correct person submitted the correct information regarding their family. In this scenario, there is no need for any xAL.

Another example where the assessed risk could differ if the agency evaluated the entire business process rather than the online transaction requirements, is a digital service that accepts resumes in order to apply for open job postings. In this use case, the digital service allows any individual to submit a resume on behalf of anyone else, and in subsequent visits to the site, access the resume for various purposes. Since the resume information is provided in later sessions, and is considered personal information, the agency must select an AAL that requires MFA. In this case, the requirements of [EO 13681] apply, driving the AAL to be at least level 2. However, the identity proofing requirements remain unclear. The entire business process of examining a resume and ultimately interviewing a person requires a significant amount of identity proofing. The agency needs a high level of confidence that the job applicant/interviewee is in fact the subject of the resume submitted online if a decision to hire is made. Yet this level of proofing is not required to actually submit the resume online. Identity proofing is not required to complete the digital transaction successfully. The resume could be submitted by the applicant, but may also be submitted by a surrogate. Identity proofing the submitter would create more risk than required in the online system as excess personal information would be collected, such as from the surrogate, when no such information is needed. Therefore, the most appropriate IAL selection would be 1. There is no need to identity proof the user to successfully complete the online transaction, nor is there any potential negative impact as a result of offering the online transaction if a proofing failure occurred. Yet, there would be significant impact if the entire business process failed to correctly identity proof the person - a job may be offered to a fraudulent applicant - but that risk should not be applied holistically to the online system via a higher IAL.

In this use case, it is assumed the system allows surrogates. If the use case is that the only person that can submit is the actual subject of the resume, then identity proofing requirements for the online transaction would be significantly different.

5.3.2. Selecting Authenticator Assurance Level

The AAL decision tree in Figure 5-1 offers agencies a possible path to determine the most appropriate authentication requirements for their digital service offering. This analysis is not intended to substitute M-04-04 risk assessments or any other risk management process in use by the agency. Nor is it expected to cover all the identity service needs of each agencies unique mission. Descriptions follow for specific steps that fall outside the risk management process documented in M-04-04.

The AAL selection does not mean the digital service provider will need to issue authenticators themselves. More information of whether the agency can federate or not is provided in Section 5.4.

5.3.3. Selecting Identity Assurance Level

The IAL decision tree in Figure 5-2 offers agencies a possible path to determine the most appropriate identity proofing requirements for their digital service offering. This analysis is not intended to be a substitute for M-04-04 risk assessments or any other risk management process in use by the agency. Nor is it expected to cover all the identity service needs of each agencies unique mission. Descriptions follow for specific steps that fall outside the required risk management process documented in M-04-04.

The IAL selection does not mean the digital service provider will need to perform the proofing themselves. More information on whether the agency can federate or not is provided in Section 5.4.

5.3.4. Selecting Federation Assurance Level

Coming Soon

5.4. Federation Considerations

The technical guidelines detailed in NIST SP 800-63-3 and its companion volumes are agnostic to the authentication and identity proofing architecture an agency selects. However, there are scenarios an agency may encounter which make identity federation potentially more attractive than establishing identity services local to the agency or individual applications. The following list details the scenarios where an agency may consider federation as a viable option. This list does not factor in any economic benefits or weaknesses of federation vs. localized identity architectures.

Federate Authenticators:

• Potential users already have an authenticator at or above required AAL
• Multiple credential form factors are required to cover all possible user communities
• Agency does not have infrastructure to support authentication management (e.g., account recovery, authenticator issuance, help desk)

Federate Attributes:

• Pseudonymity is important to stakeholders accessing the service
• Access to the service only requires a partial attribute list
• Access to the service only requires at least one attribute claim
• Agency is not the authoritative source or issuing source for required attributes
• Attributes are only required temporarily during use (such as to make an access decision), such that agency does not need to locally persist the data

6. References

[EO 13681] Executive Order 13681, Improving the Security of Consumer Financial Transactions (October 17, 2014), available at: https://www.whitehouse.gov/the-press-office/2014/10/17/executive-order-improving-security-consumer-financial-transactions.

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

[NSTIC] National Strategy for Trusted Identities in Cyberspace (April, 2011), available at: https://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf.

[DOJ 2000] Guide to Federal Agencies on Implementing Electronic Processes (November 2000), available at: http://www.usdoj.gov/criminal/cybercrime/ecommerce.html URL not found; obsolete document?

[ESIG] Federal CIO Council, Use of Electronic Signatures in Federal Organization Transactions (January 25, 2013), available at: https://cio.gov/wp-content/uploads/downloads/2014/03/Use_of_ESignatures_in_Federal_Agency_Transactions_v1-0_20130125.pdf

[FISMA] Federal Information Security Management Act, available at: http://csrc.nist.gov/drivers/documents/FISMA-final.pdf

[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: http://www.whitehouse.gov/omb/memoranda/m03-22.html.

<a name-“A-130”></a>[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

[SP 800-30] NIST Special Publication 800-30, Guide for Conducting Risk Assessments (September 2012), available at: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf.

[SP 800-37] NIST Special Publication 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems, A Security Life Cycle Approach (February 2010), available at: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf.

[SP 800-53A] NIST Special Publication 800-53A, Assessing Security and Privacy Controls in Federal Information Systems and Organizations, Building Effective Assessment Plans (December 2014), available at: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.

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

[RSDOPS] UK Cabinet Office, Good Practice Guide 43, Requirements for Secure Delivery of Online Public Services (RSDOPS), November 3, 2014, available at: https://www.gov.uk/government/publications/requirements-for-secure-delivery-of-online-public-services.

[STORK 2.0] European Union, Secure idenTity acrOss boRders linKed 2.0, 2014, available at: https://www.eid-stork2.eu/.

[ISO 29115] International Standards Organization, ISO/IEC 29115 Information technology – Security techniques – Entity authentication assurance framework, April 1, 2013, available from http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=45138

[ISO 29003] International Standards Organization, ISO/IEC DIS 29003 Information technology – Security techniques – Identity proofing (under development)

[Canada] Government of Canada, Standard on Identity and Credential Assurance, February 1, 2013, available at: https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=26776