NIST PIV and digital identity SP 800-63-3
All1 Purpose2 Introduction3 Definitions and Abbreviations4 Digital Identity Model5 Digital Identity Risk Management6 Selecting Assurance Levels7 Federation Considerations8 References
| Ref | Title | Text | |
|---|---|---|---|
| 1 | Purpose | This section is informative. This recommendation and its companion volumes, Special Publication (SP) 800-63A , SP 800- 63B , and SP 800-63C , provide technical guidelines to agencies for the implementation of digital authentication. | |
| 2 | Introduction | This section is informative. Digital identity is the unique representation of a subject engaged in an online transaction. A digital identity is always unique in the context of a digital service, but does not necessarily need to uniquely id | |
| 2.1 in 2 |
Applicability | Not all digital services require authentication or identity proofing; however, this guidance applies to all such transactions for which digital identity or authentication are required, regardless of the constituency (e.g. citizens, business | |
| 2.2 in 2 |
Considerations, Other Requirements, and Flexibilities | Agencies may employ other risk mitigation measures and compensating controls not specified herein. Agencies need to ensure that any mitigations and compensating controls do not degrade the selected assurance level’s intended security and pr | |
| 2.3 in 2 |
A Few Limitations | These technical guidelines do not address the authentication of subjects for physical access (e.g., to buildings), though some authenticators used for digital access may also be used for physical access authentication. Additionally, this re | |
| 2.4 in 2 |
How to Use this Suite of SPs | The business model, marketplace, and composition of how identity services are delivered has drastically changed since the first version of SP 800-63 was released. Notably, CSPs can be componentized and comprised of multiple independently-op | |
| 2.5 in 2 |
Change History | ||
| 2.5.1 in 2.5 |
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 it to provide a better understanding of the digital identity architectural model used here. Additional (min | |
| 2.5.2 in 2.5 |
SP 800-63-2 | NIST SP 800-63-2 was a limited update of SP 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 | |
| 2.5.3 in 2.5 |
SP 800-63-3 | NIST SP 800-63-3 is a substantial update and restructuring of SP 800-63-2. SP 800-63-3 introduces individual components of digital authentication assurance — AAL, IAL, and FAL — to support the growing need for independent treatment of authe | |
| 3 | Definitions and Abbreviations | See Appendix A for a complete set of definitions and abbreviations. | |
| 4 | Digital Identity Model | This section is informative. | |
| 4.1 in 4 |
Overview | The digital identity model used in these guidelines reflects technologies and architectures currently available in the market. More complex models that separate functions — such as issuing credentials and providing attributes — among a larg | |
| 4.2 in 4 |
Enrollment and Identity Proofing | Normative requirements can be found in SP 800-63A , Enrollment and Identity Proofing . The previous section introduced the participants in the conceptual digital identity model. This section provides additional details regarding the partic | |
| 4.3 in 4 |
Authentication and Lifecycle Management | Normative requirements can be found in SP 800-63B , Authentication and Lifecycle Management . | |
| 4.3.1 in 4.3 |
Authenticators | The classic paradigm for authentication systems identifies three factors as the cornerstones of authentication: • Something you know (e.g., a password). • Something you have (e.g., an ID badge or a cryptographic key). • Something you are ( | |
| 4.3.2 in 4.3 |
Credentials | As described in the preceding sections, a credential binds an authenticator to the subscriber, via an identifier, as part of the issuance process. A credential is stored and maintained by the CSP, though the claimant may possess it. The cla | |
| 4.3.3 in 4.3 |
Authentication Process | The authentication process begins with the claimant demonstrating to the verifier possession and control of an authenticator that is bound to the asserted identity through an authentication protocol. Once possession and control have been de | |
| 4.4 in 4 |
Federation and Assertions | Normative requirements can be found in SP 800-63C , Federation and Assertions . Overall, SP 800-63 does not presuppose a federated identity architecture; rather, these guidelines are agnostic to the types of models that exist in the market | |
| 4.4.1 in 4.4 |
Assertions | Upon completion of the authentication process, the verifier generates an assertion containing the result of the authentication and provides it to the RP. The assertion is used to communicate the result of the authentication process, and opt | |
| 4.4.2 in 4.4 |
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 | |
| 5 | Digital Identity Risk Management | This section is normative. This section and the corresponding risk assessment guidance supplement the NIST Risk Management Framework [ NIST RMF ] and its component special publications. This does not establish additional risk management pr | |
| 5.1 in 5 |
Overview | In today’s digital services, combining proofing, authenticator, and federation requirements into a single bundle sometimes has unintended consequences and can put unnecessary implementation burden on the implementing organization. It is qui | |
| 5.2 in 5 |
Assurance Levels | An agency RP SHALL select, based on risk, the following individual assurance levels: • IAL: The robustness of the identity proofing process to confidently determine the identity of an individual. IAL is selected to mitigate potential ident | |
| 5.3 in 5 |
Risk and Impacts | This section provides details on the impact categories used to determine IAL, AAL, and FAL. Potential Impact Categories: To determine the appropriate level of assurance of the user’s asserted identity, agencies SHALL assess the potential r | |
| 5.3.1 in 5.3 |
Business Process vs. Online Transaction | The assurance level determination is only based on transactions that are part of a digital system. An online transaction may not be equivalent to a complete business process that requires offline processing, or online processing in a comple | |
| 5.3.2 in 5.3 |
Impacts per Category | This section defines the potential impacts for each category of harm. Each assurance level, IAL, AAL, and FAL (if accepting or asserting a federated identity) SHALL be evaluated separately. Note: If an error in the identity system causes n | |
| 5.4 in 5 |
Risk Acceptance and Compensating Controls | The SP 800-63 suite specifies baseline requirements for digital identity services based on assurance level. Agencies SHOULD implement identity services per the requirements in these guidelines and SHOULD consider additional techniques and t | |
| 5.5 in 5 |
Digital Identity Acceptance Statement | Agencies SHOULD include this information in existing artifacts required to achieve a SA&A. The statement SHALL include, at a minimum: 1. Assessed x AL, 2. Implemented x AL, 3. Rationale, if implemented x AL differs from assessed x AL, 4. | |
| 5.6 in 5 |
Migrating Identities | As these guidelines are revised, CSPs SHALL consider how changes in requirements affect their user population. In some instances, the user population will be unaffected, yet in others, the CSP will require users undergo a transitional activ | |
| 6 | Selecting Assurance Levels | This section is normative. The risk assessment results are the primary factor in selecting the most appropriate levels. This section details how to apply the results of the risk assessment with additional factors unrelated to risk to deter | |
| 6.1 in 6 |
Selecting IAL | The IAL decision tree in Figure 6-1 combines the results from the risk assessment with additional considerations related to identity proofing services to allow agencies to select the most appropriate identity proofing requirements for their | |
| 6.2 in 6 |
Selecting AAL | The AAL decision tree in Figure 6-2 combines the results from the risk assessment with additional considerations related to authentication to allow agencies to select the most appropriate authentication requirements for their digital servic | |
| 6.3 in 6 |
Selecting FAL | The FAL decision tree in Figure 6-3 combines the results from the risk assessment with additional considerations related to federation to allow agencies to select the most appropriate requirements for their digital service offering. Figure | |
| 6.4 in 6 |
Combining x ALs | This guideline introduces a model where individual x ALs can be selected without requiring parity to each other. While options exist to select varying x ALs for a system, in many instances the same level will be chosen for all x ALs. The a | |
| 7 | Federation Considerations | This section is informative. This guideline and its companion volumes are agnostic to the authentication and identity proofing architecture an agency selects. However, there are scenarios an agency may encounter that make identity federati | |
| 8 | References | This section is informative. |
37 of 37.