sp800-63.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta name="theme-color" media="(prefers-color-scheme: light)" content="white">
    <meta name="theme-color" media="(prefers-color-scheme: dark)" content="black">
    <link rel="canonical" href="/800-63-4/sp800-63.html">

    <!-- Google Analytics -->
    <!--<script type="text/javascript" id="_fed_an_js_tag" src="http://www.nist.gov/js/federated-analytics.all.min.js?agency=NIST&subagency=mml&pua=UA-66610693-1&yt=true&exts=ppsx,pps,f90,sch,rtf,wrl,txz,m1v,xlsm,msi,xsd,f,tif,eps,mpg,xml,pl,xlt,c"></script> -->
    <!-- DAP Analytics -->
    <script type="text/javascript" id="_fed_an_ua_tag"
            src="https://dap.digitalgov.gov/Universal-Federated-Analytics-Min.js?agency=DOC&subagency=NIST&pua=UA-66610693-1&yt=true&exts=ppsx,pps,f90,sch,rtf,wrl,txz,m1v,xlsm,msi,xsd,f,tif,eps,mpg,xml,pl,xlt,c"></script>

	<link rel="stylesheet" href="https://pages.nist.gov/nist-header-footer/css/nist-combined.css">
	<script src="https://code.jquery.com/jquery-3.6.2.min.js" type="text/javascript"></script>
	<script src="https://pages.nist.gov/nist-header-footer/js/nist-header-footer.js" type="text/javascript" defer="defer"></script>
	<script src="https://unpkg.com/simple-jekyll-search/dest/simple-jekyll-search.min.js"></script>

    <!-- Custom CSS -->
    <link rel="stylesheet" href="/800-63-4/static/font-awesome/css/font-awesome.min.css">
    <link rel="stylesheet" href="/800-63-4/static/css/NISTStyle.css">
    <link rel="stylesheet" href="/800-63-4/static/css/NISTPages.css">

    <!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
    <!--[if lt IE 9]>
    <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
    <script src="https://oss.maxcdn.com/libs/respond.js/1.4.2/respond.min.js"></script>
    <![endif]-->

    
    <title>NIST Special Publication 800-63-4</title>
    <meta property="og:title" content="NIST Special Publication 800-63-4"/>
    

    <meta name="description" content="NIST Special Publication 800-63-4">
    <meta property="og:description" content="NIST Special Publication 800-63-4"/>
    
</head>


<body>

<nav class="navbar navbar-default navbar-fixed-left" role="navigation">
	<ul class="nav navbar-nav">
      <li id="search-box">
        <input type="text" id="search-input" placeholder="Search..." onFocus="loadSearch()">
        <ul id="results-container"></ul>
      </li>
      
        
        <li class="">
          
              <a href="/800-63-4/">Home</a>
          
          
        </li>
      
        
        <li class="active">
          
              <a href="/800-63-4/sp800-63.html">SP 800-63</a>
          
          
            <ul class="subnav">
            
              
                    <li class=""><a href="/800-63-4/sp800-63.html#abstract">Abstract</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63.html#reviewers">Reviewers</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63.html#preface">Preface</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63.html#introduction"><span class="section">1</span>Introduction</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63.html#sec4"><span class="section">2</span>Model</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63.html#sec5"><span class="section">3</span>DIRM</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63.html#references">References</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63.html#abbr"><span class="section">A</span>Abbreviations</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63.html#def"><span class="section">B</span>Glossary</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63.html#changelog"><span class="section">C</span>Change Log</a></li>
                
              
            </ul>
          
          
        </li>
      
        
        <li class="">
          
              <a href="/800-63-4/sp800-63a.html">SP 800-63A</a>
          
          
        </li>
      
        
        <li class="">
          
              <a href="/800-63-4/sp800-63b.html">SP 800-63B</a>
          
          
        </li>
      
        
        <li class="">
          
              <a href="/800-63-4/sp800-63c.html">SP 800-63C</a>
          
          
        </li>
      
      
  </ul>

</nav>


<div class="page-switch">

View this document as: <b>a single page</b> | <a href="/800-63-4/sp800-63/introduction/">multiple pages</a>.

</div>

<div class="container">
  <div class="row">


<p>Wed, 28 Aug 2024 20:39:12 -0500</p>

<h1 id="abstract">
  
  
    ABSTRACT <a href="#abstract" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<p>These guidelines cover identity proofing and authentication of users (such as employees, contractors, or private individuals) interacting with government information systems over networks. They define technical requirements in each of the areas of identity proofing, registration, authenticators, management processes, authentication protocols, federation, and related assertions. They also offer technical recommendations and other informative text intended as helpful suggestions. The guidelines are not intended to constrain the development or use of standards outside of this purpose. This publication supersedes NIST Special Publication (SP) 800-63-3.</p>
<h1 id="keywords">
  
  
    Keywords <a href="#keywords" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<p>authentication; authentication assurance; authenticator; assertions; credential service provider; digital authentication; digital credentials; identity proofing; federation; passwords; PKI.</p>

<h1 id="reviewers" class="no_toc">
  
  
    Note to Reviewers <a href="#reviewers" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<p>In December 2022, NIST released the Initial Public Draft (IPD) of SP 800-63, Revision 4. Over the course of a 119-day public comment period, the authors received exceptional feedback from a broad community of interested entities and individuals. The input from nearly 4,000 specific comments has helped advance the improvement of these Digital Identity Guidelines in a manner that supports NIST’s critical goals of providing foundational risk management processes and requirements that enable the implementation of secure, private, equitable, and accessible identity systems. Based on this initial wave of feedback, several substantive changes have been made across all of the volumes. These changes include but are not limited to the following:</p>

<ol>
  <li>Updated text and context setting for risk management. Specifically, the authors have modified the process defined in the IPD to include a context-setting step of defining and understanding the online service that the organization is offering and intending to potentially protect with identity systems.</li>
  <li>Added recommended continuous evaluation metrics. The continuous improvement section introduced by the IPD has been expanded to include a set of recommended metrics for holistically evaluating identity solution performance. These are recommended due to the complexities of data streams and variances in solution deployments.</li>
  <li>Expanded fraud requirements and recommendations. Programmatic fraud management requirements for credential service providers and relying parties now address issues and challenges that may result from the implementation of fraud checks.</li>
  <li>Restructured the identity proofing controls. There is a new taxonomy and structure for the requirements at each assurance level based on the means of providing the proofing: Remote Unattended, Remote Attended (e.g., video session), Onsite Unattended (e.g., kiosk), and Onsite Attended (e.g., in-person).</li>
  <li>Integrated syncable authenticators. In April 2024, NIST published interim guidance for syncable authenticators. This guidance has been integrated into SP 800-63B as normative text and is provided for public feedback as part of the Revision 4 volume set.</li>
  <li>Added user-controlled wallets to the federation model. Digital wallets and credentials (called “attribute bundles” in SP 800-63C) are seeing increased attention and adoption. At their core, they function like a federated IdP, generating signed assertions about a subject. Specific requirements for this presentation and the emerging context are presented in SP 800-63C-4.</li>
</ol>

<p>The rapid proliferation of online services over the past few years has heightened the need for reliable, equitable, secure, and privacy-protective digital identity solutions.
Revision 4 of NIST Special Publication SP 800-63, <em>Digital Identity Guidelines</em>, intends to respond to the changing digital landscape that has emerged since the last major revision of this suite was published in 2017, including the real-world implications of online risks. The guidelines present the process and technical requirements for meeting digital identity management assurance levels for identity proofing, authentication, and federation, including requirements for security and privacy as well as considerations for fostering equity and the usability of digital identity solutions and technology.</p>

<p>Based on the feedback provided in response to the June 2020 Pre-Draft Call for Comments, research into real-world implementations of the guidelines, market innovation, and the current threat environment, this draft seeks to:</p>

<ul>
  <li>Address comments received in response to the IPD of Revision 4 of SP 800-63</li>
  <li>Clarify the text to address the questions and issues raised in the public comments</li>
  <li>Update all four volumes of SP 800-63 based on current technology and market developments, the changing digital identity threat landscape, and organizational needs for digital identity solutions to address online security, privacy, usability, and equity</li>
</ul>

<p>NIST is specifically interested in comments and recommendations on the following topics:</p>

<ol>
  <li>
    <p>Risk Management and Identity Models</p>

    <ul>
      <li>Is the “user controlled” wallet model sufficiently described to allow entities to understand its alignment to real-world implementations of wallet-based solutions such as mobile driver’s licenses and verifiable credentials?</li>
      <li>Is the updated risk management process sufficiently well-defined to support an effective, repeatable, real-world process for organizations seeking to implement digital identity system solutions to protect online services and systems?</li>
    </ul>
  </li>
  <li>
    <p>Identity Proofing and Enrollment</p>

    <ul>
      <li>Is the updated structure of the requirements around defined types of proofing sufficiently clear? Are the types sufficiently described?</li>
      <li>Are there additional fraud program requirements that need to be introduced as a common baseline for CSPs and other organizations?</li>
      <li>Are the fraud requirements sufficiently described to allow for appropriate balancing of fraud, privacy, and usability trade-offs?</li>
      <li>Are the added identity evidence validation and authenticity requirements and performance metrics realistic and achievable with existing technology capabilities?</li>
    </ul>
  </li>
  <li>
    <p>Authentication and Authenticator Management</p>

    <ul>
      <li>Are the syncable authenticator requirements sufficiently defined to allow for reasonable risk-based acceptance of syncable authenticators for public and enterprise-facing uses?</li>
      <li>Are there additional recommended controls that should be applied? Are there specific implementation recommendations or considerations that should be captured?</li>
      <li>Are wallet-based authentication mechanisms and “attribute bundles” sufficiently described as authenticators? Are there additional requirements that need to be added or clarified?</li>
    </ul>
  </li>
  <li>
    <p>Federation and Assertions</p>

    <ul>
      <li>Is the concept of user-controlled wallets and attribute bundles sufficiently and clearly described to support real-world implementations? Are there additional requirements or considerations that should be added to improve the security, usability, and privacy of these technologies?</li>
    </ul>
  </li>
  <li>
    <p>General</p>

    <ul>
      <li>What specific implementation guidance, reference architectures, metrics, or other supporting resources could enable more rapid adoption and implementation of this and future iterations of the Digital Identity Guidelines?</li>
      <li>What applied research and measurement efforts would provide the greatest impacts on the identity market and advancement of these guidelines?</li>
    </ul>
  </li>
</ol>

<p>Reviewers are encouraged to comment and suggest changes to the text of all four draft volumes of the SP 800-63-4 suite. NIST requests that all comments be submitted by 11:59pm Eastern Time on October 7th, 2024. Please submit your comments to <a href="mailto:dig-comments@nist.gov">dig-comments@nist.gov</a>. NIST will review all comments and make them available on the <a href="https://www.nist.gov/identity-access-management">NIST Identity and Access Management website</a>. Commenters are encouraged to use the comment template provided on the NIST Computer Security Resource Center website for responses to these notes to reviewers and for specific comments on the text of the four-volume suite.</p>

<h1 id="preface">
  
  
    Preface <a href="#preface" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<p>This publication and its companion volumes, <a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a>, <a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a>, and <a href="/800-63-4/sp800-63c/introduction/#introduction" latex-href="#ref-SP800-63C">[SP800-63C]</a>, provide technical guidelines to organizations for the implementation of digital identity services.</p>

<h1 id="introduction" data-section="1">
  
  
    Introduction <a href="#introduction" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<p><em>This section is informative.</em></p>

<p>The rapid proliferation of online services over the past few years has heightened the need for reliable, equitable, secure, and privacy-protective digital identity solutions. A digital identity is always unique in the context of an online service. However, a person may have multiple digital identities and while a digital identity may relay a unique and specific meaning within the context of an online service, the real-life identity of the individual behind the digital identity may not be known. When confidence in a person’s real-life identity is not required to provide access to an online service, organizations may use anonymous or pseudonymous accounts. In all other use cases, a digital identity is intended to demonstrate trust between the holder of the digital identity and the person, organization, or system on the other side of the online service. However, this process can present challenges. There are multiple opportunities for mistakes, miscommunication, impersonation, and other attacks that fraudulently claim another person’s digital identity. Additionally, given the broad range of individual needs, constraints, capacities, and preferences, online services must be designed with equity, usability, and flexibility to ensure broad and enduring participation and access to digital devices and services.</p>

<p>Digital identity risks are dynamic and exist along a continuum; consequently, organizations’ digital identity risk management approach should seek to manage risks using outcome-based approaches that are designed to meet the organization’s unique needs. This guidance defines specific assurance levels which operate as baseline control sets designed to provide a common point for organizations seeking to address identity-related risks. Assurance levels provide multiple benefits, including a starting point for agencies in their risk management journey and a common structure for supporting interoperability between different entities. It is, however, impractical to create assurance levels that can comprehensively address the entire spectrum of risks, threats, or considerations and organization will face when deploying an identity solution. For this reason, these guidelines promote a risk-oriented approach to digital identity solution implementation rather than a compliance-oriented approach, and organizations are encouraged to tailor their control implementations based on the processes defined in these guidelines.</p>

<p>Additionally, risks associated with digital identity stretch beyond the potential impacts to the organization providing online services. These guidelines endeavor to account for risks to individuals, communities, and other organizations more robustly and explicitly. Organizations should consider how digital identity decisions that prioritize security might affect, or need to accommodate, the individuals who interact with the organization’s programs and services. Privacy, equity, and usability for individuals should be considered along with security. Additionally, organizations should consider their digital identity approach alongside other mechanisms for identity management, such as those used in call centers and in-person interactions. By taking a human-centric and continuously informed approach to mission delivery, organizations have an opportunity to incrementally build trust with the variety of populations they serve, improve customer satisfaction, identify issues more quickly, and provide individuals with culturally appropriate and effective redress options.</p>

<p>The composition, models, and availability of identity services has significantly changed since the first version of SP 800-63 was released, as have the considerations and challenges of deploying secure, private, usable, and equitable services to diverse user communities. This revision addresses these challenges by clarifying requirements based on the function that an entity may serve under the overall digital identity model.</p>

<p>Additionally, this publication provides instruction for credential service providers (CSPs), verifiers, and relying parties (RPs), that supplement the <em>NIST Risk Management Framework</em> <a href="/800-63-4/sp800-63/references/#ref-NIST-RMF">[NISTRMF]</a> and its component special publications. It describes the risk management processes that organizations should follow to implement digital identity services and expands upon the NIST RMF by outlining how equity and usability considerations should be incorporated. It also highlights the importance of considering impacts, not only on enterprise operations and assets, but also on individuals, other organizations, and — more broadly — society. Furthermore, digital identity management processes for identity proofing, authentication, and federation typically involve processing personal information, which can present privacy risks. Therefore, these guidelines include privacy requirements and considerations to help mitigate potential associated privacy risks.</p>

<p>Finally, while these guidelines provide organizations with technical requirements and recommendations for establishing, maintaining, and authenticating the digital identity of subjects who access digital systems over a network, additional support options outside of the purview of information technology teams may be needed to address barriers and adverse impacts, foster equity, and successfully deliver on mission objectives.</p>
<h2 id="scope-and-applicability" data-section="1">
  
  
    Scope and Applicability <a href="#scope-and-applicability" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>This guidance applies to all online services for which some level of digital identity is required, regardless of the constituency (e.g., residents, business partners, and government entities). For this publication, “person” refers only to natural persons.</p>

<p>These guidelines primarily focus on organizational services that interact with external users, such as residents accessing public benefits or private-sector partners accessing collaboration spaces. However, it also applies to federal systems accessed by employees and contractors. The <em>Personal Identity Verification (PIV) of Federal Employees and Contractors</em> standard <a href="/800-63-4/sp800-63/references/#ref-FIPS201">[FIPS201]</a> and its corresponding set of Special Publications and organization-specific instructions extend these guidelines for the federal enterprise, by providing additional technical controls and processes for issuing and managing Personal Identity Verification (PIV) Cards, binding additional authenticators as derived PIV credentials, and using federation architectures and protocols with PIV systems.</p>

<p>Online services not covered by this guidance include those associated with national security systems as defined in 44 U.S.C. § 3552(b)(6). Private-sector organizations and state, local, and tribal governments whose digital processes require varying levels of digital identity assurance may consider the use of these standards where appropriate.</p>

<p>These guidelines address logical access to online systems, services, and applications. They do not specifically address physical access control processes. However, the processes specified in these guidelines can be applied to physical access use cases where appropriate. Additionally, these guidelines do not explicitly address some subjects including, but not limited to, machine-to-machine authentication, interconnected devices (e.g., Internet of Things (IoT) devices), or access to Application Programming Interfaces (APIs) on behalf of subjects.</p>
<h2 id="how-to-use-this-suite-of-sps" data-section="1">
  
  
    How to Use This Suite of SPs <a href="#how-to-use-this-suite-of-sps" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>These guidelines support the mitigation of the negative impacts of errors that occur during the identity system functions of identity proofing, authentication, and federation. <a href="/800-63-4/sp800-63/dirm/#sec5">Sec. 3</a>, Digital Identity Risk Management, provides details on the risk assessment process and how the results of the risk assessment and additional context inform the selection of controls to secure the identity proofing, authentication, and federation processes. Controls are selected by determining the assurance level required to mitigate each applicable type of digital identity error for a particular service based on risk and mission.</p>

<p>Specifically, organizations are required to individually select assurance levels<sup id="fnref:xALs" role="doc-noteref"><a href="#fn:xALs" class="footnote">1</a></sup> that correspond to each function being performed:</p>

<ul>
  <li>Identity Assurance Level (IAL) refers to the identity proofing process.</li>
  <li>Authentication Assurance Level (AAL) refers to the authentication process.</li>
  <li>Federation Assurance Level (FAL) refers to the federation process when the RP is connected to a CSP or an IdP through a federated protocol.</li>
</ul>

<p>SP 800-63 is organized as the following suite of volumes:</p>

<ul>
  <li>SP 800-63 <em>Digital Identity Guidelines</em> provides the digital identity models, risk assessment methodology, and process for selecting assurance levels for identity proofing, authentication, and federation. <em>SP 800-63 contains both normative and informative material.</em></li>
  <li><a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a>: provides requirements for identity proofing and the enrollment of applicants, either remotely or in-person, that wish to gain access to resources at each of the three IALs. It details the responsibilities of CSPs with respect to establishing and maintaining subscriber accounts and binding CSP issued or subscriber-provided authenticators to the subscriber account.
<em>SP 800-63A contains both normative and informative material.</em></li>
  <li><a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a> provides requirements for authentication processes, including choices of authenticators, that may be used at each of the three AALs. It also provides recommendations on events that may occur during the lifetime of authenticators, including invalidation in the event of loss or theft.
<em>SP 800-63B contains both normative and informative material.</em></li>
  <li><a href="/800-63-4/sp800-63c/introduction/#introduction" latex-href="#ref-SP800-63C">[SP800-63C]</a> provides requirements on the use of federated identity architectures and assertions to convey the results of authentication processes and relevant identity information to an agency application. This volume offers privacy-enhancing techniques for sharing information about a valid, authenticated subject, and describes methods that allow for strong multi-factor authentication (MFA) while the subject remains pseudonymous to the online service.
<em>SP 800-63C contains both normative and informative material.</em></li>
</ul>
<h2 id="ERMreqs" data-section="1">
  
  
    Enterprise Risk Management Requirements and Considerations <a href="#ERMreqs" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Effective enterprise risk management is multidisciplinary by design and involves the consideration of diverse sets of factors and equities. In a digital identity risk management context, these factors include, but are not limited to, information security, privacy, equity, and usability. It is important for risk management efforts to weigh these factors as they relate to enterprise assets and operations, individuals, other organizations, and society.</p>

<p>During the process of analyzing factors relevant to digital identity, organizations may determine that measures outside of those specified in this publication are appropriate in certain contexts (e.g., where privacy or other legal requirements exist or where the output of a risk assessment leads the organization to determine that additional measures or alternative procedural safeguards are appropriate). Organizations, including federal agencies, may employ compensating or supplemental controls that are not specified in this publication. They may also consider partitioning the functionality of an online service to allow less sensitive functions to be available at a lower level of assurance in order to improve equity and access without compromising security.</p>

<p>The considerations detailed below support enterprise risk management efforts and encourage informed, inclusive, and human-centered service delivery. While this list of considerations is not exhaustive, it highlights a set of cross-cutting factors that are likely to impact decision-making associated with digital identity management.</p>
<h3 id="security-fraud-and-threat-prevention" data-section="1">
  
  
    Security, Fraud, and Threat Prevention <a href="#security-fraud-and-threat-prevention" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>It is increasingly important for organizations to assess and manage digital identity security risks, such as unauthorized access due to impersonation. As organizations consult this guidance, they should consider potential impacts to the confidentiality, integrity, and availability of information and information systems that they manage and that their service providers and business partners manage on behalf of the individuals and communities that they serve.</p>

<p>Federal agencies implementing these guidelines are required to meet statutory responsibilities, including those under the <em>Federal Information Security Modernization Act (FISMA) of 2014</em> <a href="/800-63-4/sp800-63/references/#ref-FISMA">[FISMA]</a> and related NIST standards and guidelines. NIST recommends that non-federal organizations implementing these guidelines follow comparable standards (e.g., ISO 27001) to ensure the secure operation of their digital systems.</p>

<p>FISMA requires federal agencies to implement appropriate controls to protect federal information and information systems from unauthorized access, use, disclosure, disruption, or modification. The NIST RMF <a href="/800-63-4/sp800-63/references/#ref-NIST-RMF">[NISTRMF]</a> provides a process that integrates security, privacy, and cyber supply-chain risk management activities into the system development life cycle. It is expected that federal agencies and organizations that provide services under these guidelines have already implemented the controls and processes required under FISMA and associated NIST risk management processes and publications.</p>

<p>The controls and requirements encompassed by the identity, authentication, and Federation Assurance Levels under these guidelines augment, but do not replace or alter, the information and information system controls determined under FISMA and the RMF.</p>

<p>It is increasingly important for organizations to assess and manage identity-related fraud risks associated with identity proofing and authentication processes. As organizations consult this guidance, they should consider the evolving threat environment, the availability of innovative anti-fraud measures in the digital identity market, and the potential impact of identity-related fraud. This is particularly important with respect to public-facing online services where the impact of identity-related fraud on e-government service delivery, public trust, and agency reputation can be substantial. This version enhances measures to combat identity theft and identity-related fraud by repurposing IAL1 as a new assurance level, updating authentication risk and threat models to account for new attacks, providing new options for phishing resistant authentication, introducing requirements to prevent automated attacks against enrollment processes, and preparing for new technologies (e.g., mobile driver’s licenses and verifiable credentials) that can leverage strong identity proofing and authentication.</p>
<h3 id="privacy" data-section="1">
  
  
    Privacy <a href="#privacy" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>When designing, engineering, and managing digital identity systems, it is imperative to consider the potential of that system to create privacy-related problems for individuals when processing (e.g., collection, storage, use, and destruction) personally identifiable information (PII) and the potential impacts of problematic data actions. If a breach of PII or a release of sensitive information occurs, organizations need to ensure that the privacy notices describe, in plain language, what information was improperly released and, if known, how the information was exploited.</p>

<p>Organizations need to demonstrate how organizational privacy policies and system privacy requirements have been implemented in their systems. These guidelines recommend that organizations employ the full set of legal and regulatory mandates that may affect their users and technology providers including:</p>

<ul>
  <li>The <em>NIST Privacy Framework</em> <a href="/800-63-4/sp800-63/references/#ref-NIST-PF">[NISTPF]</a>, which enables privacy engineering practices that support privacy by design concepts and helps organizations protect individuals’ privacy.</li>
  <li>The <em><a href="/800-63-4/sp800-63/references/#ref-PrivacyAct">[PrivacyAct]</a> of 1974, 2020 Edition</em> which established a set of fair information practices for the collection, maintenance, use, and disclosure of information about individuals that is maintained by federal agencies in systems of records.</li>
  <li><em>OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002</em> <a href="/800-63-4/sp800-63/references/#ref-M-03-22">[M-03-22]</a>, which describes the Privacy Impact Assessments that are supported by the privacy risk assessments that are required for PII processing or storing.</li>
  <li><a href="/800-63-4/sp800-63/references/#ref-SP800-53">[SP800-53]</a> <em>Security and Privacy Controls for Information Systems and Organizations</em> , which lists privacy controls that can be implemented to mitigate the risks identified in the privacy risk and impact assessments.</li>
  <li><a href="/800-63-4/sp800-63/references/#ref-SP800-122">[SP800-122]</a> <em>Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)</em>, which assists federal agencies in understanding what PII is, the relationship between protecting the confidentiality of PII, privacy, and the Fair Information Practices, and safeguards for protecting PII.</li>
</ul>

<p>Furthermore, each volume of SP 800-63, (<a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a>, <a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a>, and <a href="/800-63-4/sp800-63c/introduction/#introduction" latex-href="#ref-SP800-63C">[SP800-63C]</a>) contains a specific section providing detailed privacy guidance and considerations for the implementation of the processes, controls, and requirements presented in that volume as well as normative requirements on data collection, retention, and minimization.</p>
<h3 id="equity" data-section="1">
  
  
    Equity <a href="#equity" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Equity has been defined as “the consistent and systematic fair, just, and impartial treatment of all individuals, including individuals who belong to underserved communities that have been denied such treatment” <a href="/800-63-4/sp800-63/references/#ref-EO13985">[EO13985]</a>. Incorporating equity considerations when designing or operating a digital identity service helps ensure a person’s ability to engage in an online service, such as accessing a critical service like healthcare. Accessing online services is often dependent on a person’s ability to present a digital identity and use the required technologies successfully and safely. Many populations are either unable to successfully present a digital identity or face a higher degree of burden in navigating online services than their more privileged peers. In a public service context, this poses a direct risk to successful mission delivery. In a broader societal context, challenges related to digital access can exacerbate existing inequities and continue systemic cycles of exclusion for historically marginalized and underserved groups.</p>

<p>To support the continuous evaluation and improvement program described in <a href="/800-63-4/sp800-63/dirm/#sec5">Sec. 3</a>, it is important to maintain awareness of existing inequities faced by served populations and potential new inequities or disparities between populations that could be caused or exacerbated by the design or operation of digital identity systems. This can help identify the opportunities, processes, business partners, and multi-channel identity proofing and service delivery methods that best support the needs of those populations while also managing privacy, security, and fraud risks.</p>

<p>Further, section 508 of the Rehabilitation Act of 1973 (2011) <a href="/800-63-4/sp800-63/references/#ref-Section508">[Section508]</a> was enacted to eliminate barriers in information technology and require federal agencies to make electronic and information technologies accessible to people with disabilities. While these guidelines do not directly assert requirements from <a href="/800-63-4/sp800-63/references/#ref-Section508">[Section508]</a>, federal agencies and their identity service providers are expected to design online  services and systems with the experiences of people with disabilities in mind to ensure that accessibility is prioritized.</p>
<h3 id="usability" data-section="1">
  
  
    Usability <a href="#usability" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Usability refers to the extent to which a system, product, or service can be used to achieve goals with effectiveness, efficiency, and satisfaction in a specified context of use. Usability also supports major objectives such as equity, service delivery, and security. Like equity, usability requires an understanding of the people who interact with a digital identity system or process, as well as their unique goals and context of use.</p>

<p>Readers of this guidance should take a holistic approach to considering the interactions that each user will engage in throughout the process of enrolling in and authenticating to a service. Throughout the design and development of a digital identity system or process, it is important to conduct usability evaluations with demographically representative users, from all communities served and perform realistic scenarios and tasks in appropriate contexts of use. Additionally, following usability guidelines and considerations can help organizations meet customer experience goals articulated in federal policy <a href="/800-63-4/sp800-63/references/#ref-EO14058">[EO14058]</a>. Digital identity management processes should be designed and implemented so that it is easy for users to do the right thing, hard to do the wrong thing, and easy to recover when the wrong thing happens.</p>
<h2 id="notations" data-section="1">
  
  
    Notations <a href="#notations" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>This guideline uses the following typographical conventions in text:</p>

<ul>
  <li>Specific terms in <strong>CAPITALS</strong> represent normative requirements. When these same terms are not in <strong>CAPITALS</strong>, the term does not represent a normative requirement.
    <ul>
      <li>The terms “<strong>SHALL</strong>” and “<strong>SHALL NOT</strong>” indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted.</li>
      <li>The terms “<strong>SHOULD</strong>” and “<strong>SHOULD NOT</strong>” indicate that among several possibilities, one is recommended as particularly suitable without mentioning or excluding others, that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.</li>
      <li>The terms “<strong>MAY</strong>” and “<strong>NEED NOT</strong>” indicate a course of action that is permissible within the limits of the publication.</li>
      <li>The terms “<strong>CAN</strong>” and “<strong>CANNOT</strong>” indicate a material, physical, or causal possibility and capability or — in the negative — the absence of that possibility or capability.</li>
    </ul>
  </li>
</ul>

<div latex-literal="true" class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>\clearpage
</code></pre></div></div>
<h2 id="document-structure" data-section="1">
  
  
    Document Structure <a href="#document-structure" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>This document is organized as follows. Each section is labeled as either normative (i.e., mandatory for compliance) or informative (i.e., not mandatory).</p>

<ul>
  <li>Section 1 provides an introduction to the document. This section is <em>informative</em>.</li>
  <li>Section 2 describes a general model for digital identity. This section is <em>informative</em>.</li>
  <li>Section 3 describes the digital identity risk model. This section is <em>normative</em>.</li>
  <li>The References section contains a list of publications that are cited in this document. This section is <em>informative</em>.</li>
  <li>Appendix A contains a selected list of abbreviations used in this document. This appendix is <em>informative</em>.</li>
  <li>Appendix B contains a glossary of selected terms used in this document. This appendix is <em>informative</em>.</li>
  <li>Appendix C contains a summarized list of changes in this document’s history. This appendix is <em>informative</em>.</li>
</ul>
<div class="footnotes" role="doc-endnotes">
  <ol>
    <li id="fn:xALs" role="doc-endnote">
      <p>When described generically or bundled, these guidelines will refer to IAL, AAL, and FAL as <strong><em>xAL</em></strong>. <a href="#fnref:xALs" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
  </ol>
</div>

<h1 id="sec4" data-section="2">
  
  
    Digital Identity Model <a href="#sec4" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<p><em>This section is informative.</em></p>
<h2 id="s-4-1" data-section="2">
  
  
    Overview <a href="#s-4-1" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The SP 800-63 guidelines use digital identity models that reflect technologies and architectures that already currently available in the market. These models have a variety of entities and functions and vary in complexity. Simple models group functions, such as creating subscriber accounts and providing attributes, under a single entity. More complex models separate these functions among a larger number of entities. The entities, and their associated functions, found in digital identity models include:</p>

<p><strong>Subject</strong>: In these guidelines, a subject is a person and is represented by one of three roles, depending on where they are in the digital identity process.</p>

<ul>
  <li>Applicant — The subject to be identity-proofed and enrolled.</li>
  <li>Subscriber — - The subject who has successfully completed the identity proofing and enrollment process or authentication (i.e., when the subject is in an active on-line session).</li>
  <li>Claimant — The subject “making a claim” to be eligible for authentication.</li>
</ul>

<p><strong>Service provider</strong>: Service providers can perform any combination of functions involved in granting access to and delivering online services, such as a credential service provider, relyin party, verifier, and Identity provider.</p>

<p><strong>Credential service provider (CSP)</strong>: CSP functions include identity proofing applicants to the identity service and registering authenticators to subscriber accounts. A <em>subscriber account</em> is the CSP’s established record of the subscriber, the subscriber’s attributes, and associated authenticators. CSP functions may be performed by an independent third party.</p>

<p><strong>Relying party (RP)</strong>: RP functions rely on the information in the subscriber account from the CSP, typically to process a digital transaction or grant access to information or a system. When using federation, the RP accesses the information in the subscriber account through assertions from an identity provider.</p>

<p><strong>Verifier</strong>: The function of a verifier is to verify the claimant’s identity by verifying the claimant’s possession and control of one or more authenticators using an authentication protocol. To do this, the verifier needs to confirm the binding of the authenticators with the subscriber account and check that the subscriber account is active.</p>

<p><strong>Identity provider (IdP)</strong>: When using federation, the IdP manages the subscriber’s primary authenticators and issues assertions derived from the subscriber account.</p>
<h2 id="identity-proofing-and-enrollment" data-section="2">
  
  
    Identity Proofing and Enrollment <a href="#identity-proofing-and-enrollment" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Normative requirements can be found in <a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a>, <em>Identity Proofing and Enrollment</em>.</p>

<p><a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a> provides general information and normative requirements for the identity proofing and enrollment processes as well as requirements that are specific to IALs.</p>

<p><a href="/800-63-4/sp800-63/model/#fig-1">Figure 1</a> shows a sample of interactions for identity proofing and enrollment.</p>

<p>To start, an <em>applicant</em> opts to enroll with a CSP by requesting access. The CSP or the entity fulfilling CSP functions requests identity evidence and attributes, which the applicant provides. If the applicant is successfully identity-proofed, they are enrolled in the identity service as a <em>subscriber</em> of that CSP. A unique subscriber account is then created and one or more authenticators are registered to the subscriber account.</p>

<p>Subscribers have a responsibility to maintain control of their authenticators (e.g., guard against theft) and comply with CSP policies to remain in good standing with the CSP.</p>

<p latex-ignore="true"><a href="/800-63-4/sp800-63/model/#fig-1" name="fig-1">Fig. 1. Sample Identity Proofing and Enrollment Digital Identity Model</a></p>

<p><img src="/800-63-4/sp800-63/images/ID_Proofing.png" alt="Sequence diagram of identity proofing and enrollment showing the parties involved and the major steps in the process." title="Sample Identity Proofing and Enrollment Digital Identity Model" latex-src="ID_Proofing.pdf" latex-fig="1" latex-place="h" /></p>
<h3 id="subscriber-accounts" data-section="2">
  
  
    Subscriber Accounts <a href="#subscriber-accounts" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>At the time of enrollment, the CSP establishes a subscriber account to uniquely identify each subscriber and record any authenticators registered (bound) to that subscriber account. The CSP may:</p>

<ul>
  <li>Issue and register one or more authenticators to the subscriber at the time of enrollment,</li>
  <li>Register authenticators provided by the subscriber to the subscriber account,</li>
  <li>Register additional authenticators to the subscriber account at a later time as needed, or</li>
  <li>Provision the subscriber account to one or more general-purpose or subscriber-controlled wallets, for use in a federated protocol system.</li>
</ul>

<p>See <a href="/800-63-4/sp800-63a/accounts/#accounts" latex-href="#ref-SP800-63A">Sec. 5 of [SP800-63A]</a>, <em>Subscriber-Accounts</em>, for more information and normative requirements.</p>
<h2 id="authentication-and-authenticator-management" data-section="2">
  
  
    Authentication and Authenticator Management <a href="#authentication-and-authenticator-management" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Normative requirements can be found in <a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a>, <em>Authentication and Authenticator Management</em>.</p>
<h3 id="authenticators" data-section="2">
  
  
    Authenticators <a href="#authenticators" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p><a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a> provides normative descriptions of permitted authenticator types, their characteristics (e.g.,  phishing resistance), and authentication processes appropriate for each AAL.</p>

<p>This guidance defines three types of authentication factors used for authentication:</p>

<ul>
  <li>Something you know (e.g., a password)</li>
  <li>Something you have (e.g., a device containing a cryptographic key)</li>
  <li>Something you are (e.g., a fingerprint or other biometric characteristic data)</li>
</ul>

<p>Single-factor authentication requires only one of the above factors, most often “something you know”. Multiple instances of the same factor still constitute single-factor authentication. For example, a user-generated PIN and a password do not constitute two factors as they are both “something you know.” Multi-factor authentication (MFA) refers to the use of more than one distinct factor.</p>

<p>This guidance specifies that authenticators always contain or comprise a secret. The secrets contained in an authenticator are based on either key pairs (i.e., asymmetric cryptographic keys) or shared secrets (including symmetric cryptographic keys, seeds for generating one-time passwords (OTP), and passwords). Asymmetric key pairs are comprised of a public key and a related private key. The private key is stored on the authenticator and is only available for use by the claimant who possesses and controls the authenticators. A verifier that has the subscriber’s public key (e.g., through a public key certificate) can use an authentication protocol to verify that the claimant is a subscriber who has possession and control of the associated private key contained in the authenticator. Symmetric keys are generally chosen at random, complex and long enough to thwart network-based guessing attacks, and stored in hardware or software that the subscriber controls. Passwords typically have fewer characters and less complexity than cryptographic keys resulting in increased vulnerabilities that require additional defenses to mitigate.</p>

<p>Passwords used as activation factors for multi-factor authenticators are referred to as <em>activation secrets</em>. An activation secret is used to decrypt a stored key used for authentication or is compared against a locally held and stored verifier to provide access to the authentication key. In either of these cases, the activation secret remains within the authenticator and its associated user endpoint. An example of an activation secret would be the PIN used to activate a PIV card.</p>

<p>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 authentication. This includes, but is not limited to, facial features, fingerprints, and iris patterns. While biometric characteristics cannot be used for single-factor authentication, they can be used as an authentication factor for multi-factor authentication when used in combination with a physical authenticator (i.e., something you have).</p>

<p>Some authentication methods used for in-person interactions do not apply directly to digital authentication. For example, a physical driver’s license is something you have and may be useful when authenticating to a human (e.g., a security guard), but it is not an authenticator for online services.</p>

<p>Some commonly used authentication methods do not contain or comprise secrets and are therefore not acceptable for use under these guidelines. For example:</p>

<ul>
  <li>Knowledge-based authentication, where the claimant is prompted to answer questions that are presumably known only by the claimant, does not constitute an acceptable secret for digital authentication.</li>
  <li>A biometric characteristic does not constitute a secret and cannot be used as a single-factor authenticator.</li>
</ul>
<h3 id="authentication-process" data-section="2">
  
  
    Authentication Process <a href="#authentication-process" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>The authentication process enables an RP to trust that a claimant is who they say they are.  Some approaches are described in <a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a>, <em>Authentication and Authenticator Management</em>. The sample authentication process in <a href="/800-63-4/sp800-63/model/#fig-2">Fig. 2</a> shows interactions between the RP, a claimant, and a verifier/CSP. The verifier is a functional role and is frequently implemented in combination with the CSP, the RP, or both (as shown in <a href="/800-63-4/sp800-63/model/#fig-4">Fig. 4</a>).</p>

<p latex-ignore="true"><a href="/800-63-4/sp800-63/model/#fig-2" name="fig-2">Fig. 2. Sample Authentication Process</a></p>

<p><img src="/800-63-4/sp800-63/images/Sample_Authn_Process.png" alt="Sequence diagram of a sample authentication process showing parties involved and major steps in the process." title="Sample Authentication Process" latex-src="Sample_Authn_Process.pdf" latex-fig="2" latex-place="h" /></p>

<p>A successful authentication process demonstrates that the claimant has possession and control of one or more valid authenticators that are bound to the subscriber’s identity. In general, this is done using an authentication protocol that involves an interaction between the verifier and the claimant. The exact nature of the interaction is extremely important in determining the overall security of the system. Well-designed protocols can protect the integrity and confidentiality of communication between the claimant and the verifier both during and after the authentication and can help limit the damage done by an attacker masquerading as a legitimate verifier.</p>

<p>Additionally, mechanisms located at the verifier can mitigate online guessing attacks against lower entropy secrets (e.g., 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.</p>
<h2 id="Federation" data-section="2">
  
  
    Federation and Assertions <a href="#Federation" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Normative requirements can be found in <a href="/800-63-4/sp800-63c/introduction/#introduction" latex-href="#ref-SP800-63C">[SP800-63C]</a>, <em>Federation and Assertions</em>.</p>

<p>Section III of OMB <a href="/800-63-4/sp800-63/references/#ref-M-19-17">[M-19-17]</a> <em>Enabling Mission Delivery through Improved Identity, Credential, and Access Management</em> directs agencies to support cross-government identity federation and interoperability. The term <em>federation</em> can be applied to several different approaches that involve the sharing of information between different trust domains. These approaches differ based on the kind of information that is being shared between the domains. These guidelines address the federation processes that allow for the conveyance of identity and authentication information based on trust agreements across a set of networked systems through federation assertions.</p>

<p>There are many benefits to using federated architectures including, but not limited to:</p>

<ul>
  <li>Enhanced user experience (e.g., a subject can be identity proofed once but their subscriber account used at multiple RPs).</li>
  <li>Cost reduction to both the subscriber (e.g., reduction in authenticators) and the organization (e.g., reduction in information technology infrastructure and a streamlined architecture).</li>
  <li>Minimizing data in RPs that do not need to collect, store, or dispose of personal information.</li>
  <li>Minimizing data exposed to RPs by using pseudonymous identifiers and derived attribute values instead of copying account values to each application.</li>
  <li>Mission enablement, since organizations will need to focus fewer resources on complex identity management processes.</li>
</ul>

<p>While the federation process is generally the preferred approach to authentication when the RP and IdP are not administered together under a common security domain, federation can also be applied within a single security domain for a variety of benefits including centralized account management and technical integration.</p>

<p>The SP 800-63 guidelines are agnostic to the identity proofing, authentication, and federation architectures that an organization selects, and they allow organizations to deploy a digital identity scheme according to their own requirements. However, there are scenarios that an organization may encounter that make federation potentially more efficient and effective than establishing identity services that are local to the organization or individual applications. The following lists detailed potential scenarios in which the organization may consider federation to be a viable option:</p>

<ul>
  <li>Potential users already have an authenticator at or above the required AAL.</li>
  <li>Multiple types of authenticators are required to cover all possible user communities.</li>
  <li>An organization does not have the necessary infrastructure to support management of subscriber accounts (e.g., account recovery, authenticator issuance, help desk).</li>
  <li>There is a desire to allow primary authenticators to be added and upgraded over time without changing the RP’s implementation.</li>
  <li>There are different environments to be supported, since federation protocols are network-based and allow for implementation on a wide variety of platforms and languages.</li>
  <li>Potential users come from multiple communities, each with its own existing identity infrastructure.</li>
  <li>The organization needs the ability to centrally manage account lifecycles, including account revocation and the binding of new authenticators.</li>
</ul>

<p>An organization may want to consider accepting federated identity attributes if any of the following apply:</p>

<ul>
  <li>Pseudonymity is required, necessary, feasible, or important to stakeholders accessing the service.</li>
  <li>Access to the service requires a defined list of attributes.</li>
  <li>Access to the service requires at least one derived attribute value.</li>
  <li>The organization is not the authoritative source or issuing source for required attributes.</li>
  <li>Attributes are only required temporarily during use (e.g., to make an access decision), and the organization does not need to retain the data.</li>
</ul>
<h2 id="examples-of-digital-identity-models" data-section="2">
  
  
    Examples of Digital Identity Models <a href="#examples-of-digital-identity-models" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The entities and interactions that comprise the non-federated digital identity model are illustrated in <a href="/800-63-4/sp800-63/model/#fig-3">Fig. 3</a>. The general-purpose federated digital identity model is illustrated in <a href="/800-63-4/sp800-63/model/#fig-4">Fig. 4</a>, and a federated digital identity model with a subscriber-controlled wallet is illustrated in <a href="/800-63-4/sp800-63/model/#fig-5">Fig. 5</a>.</p>

<p latex-ignore="true"><a href="/800-63-4/sp800-63/model/#fig-3" name="fig-3">Fig. 3. Non-Federated Digital Identity Model Example</a></p>

<p><img src="/800-63-4/sp800-63/images/Non-Federated.png" alt="High-level diagram of a non-federated digital identity model showing the entities and interactions between entities of the entire digital identity process, in which the verifier function is done by the RP." title="Non-Federated Digital Identity Model Example" latex-src="Non-Federated.pdf" latex-fig="3" latex-place="h" /></p>

<p><a href="/800-63-4/sp800-63/model/#fig-3">Figure 3</a> shows an example of a common sequence of interactions in the non-federated model. Other sequences could also achieve the same functional requirements. One common sequence of interactions for identity proofing and enrollment activities is as follows:</p>

<ul>
  <li>Step 1: An applicant applies to a CSP through an identity proofing and enrollment process. The CSP identity proofs that applicant.</li>
  <li>Step 2: Upon successful identity proofing, the applicant is enrolled in the identity service as a subscriber.
    <ul>
      <li>A subscriber account and corresponding authenticators are established between the CSP and the subscriber. The CSP maintains the subscriber account, its status, and the enrollment data. The subscriber maintains their authenticators.</li>
    </ul>
  </li>
</ul>

<p>Steps 3 through 5 may immediately follow steps 1 and 2 or they may be done at a later time. The usual sequence of interactions involved in using one or more authenticators to perform digital authentication in the non-federated model is as follows:</p>

<ul>
  <li>Step 3: The claimant initiates an online interaction with the RP and the RP requests that the claimant authenticate.</li>
  <li>Step 4: The claimant proves possession and control of the authenticators to the verifier through an authentication process:
    <ul>
      <li>The verifier interacts with the CSP to verify the binding of the claimant’s identity to their authenticators in the subscriber account and to optionally obtain additional subscriber attributes.</li>
      <li>The CSP or verifier functions of the service provider give information about the subscriber. The RP requests the attributes it requires from the CSP. The RP optionally uses this information to make authorization decisions.</li>
    </ul>
  </li>
  <li>Step 5: An authenticated session is established between the subscriber and the RP.</li>
</ul>

<p latex-ignore="true"><a href="/800-63-4/sp800-63/model/#fig-4" name="fig-4">Fig. 4. Federated Digital Identity Model Example</a></p>

<p><img src="/800-63-4/sp800-63/images/Federated.png" alt="High-level diagram of a federated digital identity model showing the entities and interactions between entities of the entire digital identity process, in which the CSP and verifier functions are done by the IdP." title="Federated Digital Identity Model Example" latex-src="Federated.pdf" latex-fig="4" latex-place="h" /></p>

<p><a href="/800-63-4/sp800-63/model/#fig-4">Figure 4</a> shows an example of those same common interactions in a federated model.</p>

<ul>
  <li>Step 1: An applicant applies to a CSP through an identity proofing and enrollment process. The CSP identity proofs that applicant.</li>
  <li>Step 2: Upon successful identity proofing, the applicant is enrolled in the identity service as a subscriber.
    <ul>
      <li>A subscriber account and corresponding authenticators are established between the CSP and the subscriber.</li>
      <li>Unlike in <a href="/800-63-4/sp800-63/model/#fig-3">Fig. 3</a>, the IdP is provisioned either directly by the CSP or indirectly through access to attributes of the subscriber account. The CSP maintains the subscriber account, its status, and the enrollment data collected in accordance with the record retention and disposal requirements described in <a href="/800-63-4/sp800-63a/ial-general/#DocRecReqs" latex-href="#ref-SP800-63A">Sec. 3.1.1 of [SP800-63A]</a>. The subscriber maintains their authenticators. The IdP maintains its view of the subscriber account, any federated identifiers assigned to the subscriber account, and authorizations to RPs.</li>
    </ul>
  </li>
</ul>

<p>The usual sequence of interactions involved in using one or more authenticators in the federated model to perform digital authentication is as follows:</p>

<ul>
  <li>Step 3: The RP requests that the claimant authenticate. This triggers a request for federated authentication to the IdP.</li>
  <li>Step 4: The claimant proves possession and control of the authenticators to the verifier function of the IdP through an authentication process.
    <ul>
      <li>Within the IdP, the verifier and CSP functions interact to verify the binding of the claimant’s authenticators with those bound to the claimed subscriber account and optionally to obtain additional subscriber attributes.</li>
    </ul>
  </li>
  <li>Step 5: The RP and the IdP communicate through a federation protocol. The IdP provides an assertion and optionally additional attributes to the RP through a federation protocol. The RP verifies the assertion to establish confidence in the identity and attributes of a subscriber for an online service at the RP. RPs may use a subscriber’s federated identity (pseudonymous or non-pseudonymous), IAL, AAL, FAL, and other factors to make authorization decisions.</li>
  <li>Step 6: An authenticated session is established between the subscriber and the RP.</li>
</ul>

<p>In the two cases described in <a href="/800-63-4/sp800-63/model/#fig-3">Fig. 3</a> and <a href="/800-63-4/sp800-63/model/#fig-4">Fig. 4</a>, the verifier does not always need to communicate in real time with the CSP to complete the authentication activity (e.g., digital certificates can be used). Therefore, the line between the verifier and the CSP represents a logical link between the two entities. In some implementations, the verifier, RP, and CSP functions may be distributed and separated. However, if these functions reside on the same platform, the interactions between the functions are signals between applications or application modules that run on the same system rather than using network protocols.</p>

<p latex-ignore="true"><a href="/800-63-4/sp800-63/model/#fig-5" name="fig-5">Fig. 5. Federated Digital Identity Model With Subscriber-Controlled Wallet Example</a></p>

<p><img src="/800-63-4/sp800-63/images/Wallet.png" alt="High-level diagram of a federated digital identity model with a subscriber-controlled wallet showing the entities and interactions between entities of the entire digital identity process in which the subscriber controls a device with software (commonly known as a digital wallet) that acts as the IdP." title="Federated Digital Identity Model with Subscriber-Controlled Wallet Example" latex-src="Wallet.pdf" latex-fig="5" latex-place="h" /></p>

<p><a href="/800-63-4/sp800-63/model/#fig-5">Figure 5</a> shows an example of the interactions in a federated digital identity model in which the subscriber controls a device with software (i.e., a digital wallet) that acts as the IdP. In the terminology of the “three-party model”, the CSP is the issuer, the IdP is the holder, and the RP is the verifier. In this model, it is common for the RP to establish a trust agreement with the CSP through the use of a federation authority as defined in <a href="/800-63-4/sp800-63c/Federation/#trust-agreement" latex-href="#ref-SP800-63C">[SP800-63C]</a>. This arrangement allows the RP to accept assertions from the subscriber-controlled wallet without needing a direct trust relationship with the wallet.</p>

<ul>
  <li>Step 1: An applicant applies to a CSP identity proofing and enrollment process.</li>
  <li>Step 2: Upon successful identity proofing, the applicant goes through an onboarding process and is enrolled in the identity service as a subscriber.</li>
  <li>Step 3: The subscriber-controlled wallet is onboarded by the CSP.
    <ul>
      <li>The subscriber authenticates to the CSP’s onboarding function.</li>
      <li>The subscriber activates the subscriber-controlled wallet using an activation factor.</li>
      <li>The wallet sends a request to the CSP, including proof of a key held by the wallet.</li>
      <li>The CSP creates an attribute bundle that contains a reference for the key of the wallet and any additional attributes.</li>
    </ul>
  </li>
</ul>

<p>The usual sequence of interactions involved in providing an assertion to the RP from a subscriber-controlled wallet is as follows:</p>

<ul>
  <li>Step 4: The RP requests that the claimant authenticate. This triggers a request for federated authentication to the wallet.</li>
  <li>Step 5: The claimant proves possession and control of the subscriber-controlled wallet.
    <ul>
      <li>The subscriber activates the wallet using an activation factor.</li>
      <li>The wallet prepares an assertion including the attribute bundle provided by the CSP for the subscriber account.</li>
    </ul>
  </li>
  <li>Step 6: The RP and the wallet communicate through a federation protocol. The wallet provides an assertion and optionally additional attributes to the RP through a federation protocol. The RP verifies the assertion to establish confidence in the identity and attributes of a subscriber for an online service at the RP. RPs may use a subscriber’s federated identity (pseudonymous or non-pseudonymous), IAL, AAL, FAL, and other factors to make authorization decisions.</li>
  <li>Step 7: An authenticated session is established between the subscriber and the RP.</li>
</ul>

<blockquote>
  <p>Note: Other protocols and specifications often refer to attribute bundles as <em>credentials</em>. These guidelines use the term <em>credentials</em> for a different concept. To avoid a conflict, the term <em>attribute bundle</em> is used within these guidelines. Normative requirements for attribute bundles can be found including <a href="/800-63-4/sp800-63c/Federation/#attribute-bundles" latex-href="#ref-SP800-63C">Sec. 3.11.1 of [SP800-63C]</a>.</p>
</blockquote>

<h1 id="sec5" data-section="3">
  
  
    Digital Identity Risk Management <a href="#sec5" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<p><em>This section is normative.</em></p>

<p>This section provides details on the methodology for assessing digital identity risks associated with online services and the residual risks to users of the online service, communities impacted by the service, the service provider organization, and its mission and business partners. It offers guidance on selecting usable, equitable, and privacy-enhancing security and anti-fraud controls that mitigate those risks.  Additionally, it emphasizes the importance of continuously evaluating the performance of the selected controls.</p>

<p>The Digital Identity Risk Management (DIRM) process focuses on the identification and management of risks according to two dimensions: (1) risks to the online service that might be addressed by an identity system; and (2) risks from the identity system to be implemented.</p>

<p>The first dimension of risk informs initial assurance level selections and seeks to identify the risks associated with a compromise of the online service that might be addressed by an identity system. For example:</p>

<ul>
  <li>Identity proofing: What negative impacts would reasonably be expected if an imposter were to gain access to a service or receive a credential using the identity of a legitimate user (e.g., an attacker successfully impersonates someone)?</li>
  <li>Authentication: What negative impacts would reasonably be expected if a false claimant accessed an account that was not rightfully theirs (e.g., an attacker who compromises or steals an authenticator)?</li>
  <li>Federation: What negative impacts would reasonably be expected if the wrong subject successfully accessed an online service, system, or data (e.g., compromising or replaying an assertion)?</li>
</ul>

<p>All three types of errors can result in the wrong subject successfully accessing an online service, system, or data.</p>

<p>If it is determined that there are risks associated with a compromise of the online service that could be addressed by an identity system, an initial assurance level is selected and the second dimension of risk is then considered. The second dimension of risk seeks to identify the risks posed by the identity system and informs the tailoring process. Tailoring provides a process to modify an initially assessed assurance level, implement compensating or supplemental controls, or modify selected controls based on ongoing detailed risk assessments.</p>

<div latex-literal="true" class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>\clearpage
</code></pre></div></div>

<p>For example, assuming that aspects of the identity system are not sufficiently privacy-enhancing, usable, equitable, or able or necessary to address specific real-world threats:</p>

<ul>
  <li>Identity proofing: What is the impact of not successfully identity proofing and enrolling a legitimate subject due to barriers faced by the subject throughout the process of identity proofing, including biases? What is the impact of falling victim to a breach of information that was excessively collected and retained to support identity proofing processes? What is the impact if the initial IAL does not completely address specific threats, threat actors, and fraud?</li>
  <li>Authentication: What is the impact of failing to authenticate the correct subject due to barriers faced by the subject in presenting their authenticator, including biases or usability issues? What is the impact if the initial AAL does not completely address targeted account takeover models or specific authenticator types fail to mitigate anticipated attacks?</li>
  <li>Federation: What is the impact of releasing subscriber attributes to the wrong online service or system?</li>
</ul>

<p>The outcomes of the DIRM process depend on the role that an entity plays within the digital identity model.</p>

<ol>
  <li>For <strong>relying parties</strong>, the intent of this process is to determine the assurance levels and any tailoring required to protect online services and the applications, transactions, and systems that comprise or are impacted by those services. This directly contributes to the selection, development, and procurement of CSP services. Federal RPs <strong>SHALL</strong> implement the DIRM process for all online services.</li>
  <li>For <strong>credential service providers and identity providers</strong>, the intent of this process is to design service offerings that meet the requirements of the defined assurance levels, continuously guard against compromises to the identity system, and meet the needs of RPs.  Whenever a service offering deviates from normative guidance, those deviations must be clearly communicated to the RPs that utilize the service. All CSPs <strong>SHALL</strong> implement the DIRM process for the services they offer and <strong>SHALL</strong> make a Digital Identity Acceptance Statement (DIAS) for each offering available to all current or potential RPs. CSPs <strong>MAY</strong> base their assessment on anticipated or representative digital identity services they wish to support. In creating this risk assessment, CSPs <strong>SHOULD</strong> seek input from real-world RPs on their user populations and their anticipated context.</li>
</ol>

<p>This process augments the risk management processes required by the Federal Information Security Modernization Act <a href="/800-63-4/sp800-63/references/#ref-FISMA">[FISMA]</a>. The results of the DIRM impact assessment for the online service may be different from the FISMA impact level for the underlying application or system. Identity process failures may result in different levels of impact for various user groups. For example, the overall assessed FISMA impact level for a payment system may result in a ‘FISMA Moderate’ impact category due to sensitive financial data processed by the system. However, for individuals who are making guest payments where no persistent account is established, the authentication and proofing impact levels may be lower as associated data may not be retained or made accessible. Agency authorizing officials <strong>SHOULD</strong> require documentation demonstrating adherence to the DIRM process as a part of the Authority to Operate (ATO) for the underlying information system that supports an online service. Agency authorizing officials <strong>SHOULD</strong> require documentation from CSPs demonstrating adherence to the DIRM as part of procurement or ATO processes for integration with CSPs.</p>

<p>There are 5 steps in the DIRM process:</p>

<ol>
  <li><strong>Define the online service</strong>: As a starting point, the organization documents a description of the online service in terms of its functional scope, the user groups it is intended to serve, the types of online transactions available to each user group, and the underlying data that the online service processes through its interfaces. If the online service is one element of a broader business process, its role is documented, as are the impacts of any data collected and processed by the online service. Additionally, an organization needs to determine the entities that will be impacted by the online service and the broader business process of which it is a part. The outcome is a description of the online service, its users, and the entities that may be impacted by its functionality.</li>
  <li><strong>Conduct initial impact assessment</strong>: In this step, organizations evaluate their user population and assess the impacts of a compromise of the online service that might be addressed by an identity system (i.e., identity proofing, authentication, or federation). Each function of the online service is assessed against a defined set of harms and impact categories. Each user group of the online service is considered separately based on the transactions available to that user group (i.e., the permissions that the group is granted relative to the data and functions of the online service). The outcome of this step is a documented set of impact categories and associated impact levels (i.e., Low, Moderate, or High) for each user group of the online service.</li>
  <li><strong>Select initial assurance levels</strong>: In this step, the impact categories and impact levels are evaluated to determine the initial assurance levels to protect the online service from unauthorized access and fraud. Using the assurance levels, the organization identifies the baseline controls for the IAL, AAL, and FAL for each user group based on the requirements from companion volumes <a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a>, <a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a>, and <a href="/800-63-4/sp800-63c/introduction/#introduction" latex-href="#ref-SP800-63C">[SP800-63C]</a>, respectively. The outcome of this step is an identified initial IAL, AAL, and FAL, as applicable, for each user group.</li>
  <li><strong>Tailor and document assurance level determinations</strong>: In this step, detailed assessments are conducted or leveraged to determine the potential impact of the initially selected assurance levels and their associated controls on privacy, equity, usability, and resistance to the current threat environment. Tailoring may result in a modification of the initially assessed assurance level, the identification of compensating or supplemental controls, or both. All assessments and final decisions are documented and justified. The outcome is a DIAS (see <a href="/800-63-4/sp800-63/dirm/#IDacceptStmt">Sec. 3.4.4</a>) with a defined and implementable set of assurance levels and a final set of controls for the online service.</li>
  <li><strong>Continuously evaluate and improve</strong>: In this step, information on the performance of the identity management approach is gathered and evaluated. This evaluation considers a diverse set of factors, including business impacts, effects on fraud rates, and impacts on user communities. This information is crucial in determining if the selected assurance level and controls meet mission, business, security, and — where applicable — program integrity needs. It also helps monitor for unintended harms that impact privacy and equitable access. Opportunities for improvement should also be considered by closely monitoring the evolving threat landscape and investigating new technologies and methodologies that can counter those threats or improve usability, equity, or privacy.  The outcomes of this step are performance metrics, documented and transparent processes for evaluation and redress, and ongoing improvements to the identity management approach.</li>
</ol>

<p latex-ignore="true"><a href="/800-63-4/sp800-63/dirm/#fig-6" name="fig-6">Fig. 6. High-level diagram of the Digital Identity Risk Management process flow</a></p>

<p><img src="/800-63-4/sp800-63/images/dirm.png" alt="High-level diagram of the Digital Identity Risk Management Process Flow showing the five steps along with major activities and outcomes for each step" title="High-level diagram of the Digital Identity Risk Management Process Flow" latex-src="dirm.pdf" latex-fig="6" latex-place="p" /></p>

<p><a href="/800-63-4/sp800-63/dirm/#fig-6">Figure 6</a> illustrates the major actions and outcomes for each step of the DIRM process flow. While presented as a “stepwise” approach, there can be many points in the process that require divergence from the sequential order, including the need for iterative cycles between initial task execution and revisiting tasks. For example, the introduction of new regulations or requirements while an assessment is ongoing may require organizations to revisit a step in the process. Additionally, new functionality, changes in data usage, and changes to the threat environment may require an organization to revisit steps in the Digital Identity Risk Management process at any point, including potentially modifying the assurance level and/or the related controls of the online service.</p>

<p>Organizations <strong>SHOULD</strong> adapt and modify this overall approach to meet organizational processes, governance, and enterprise risk management practices. At a minimum, organizations <strong>SHALL</strong> execute and document each step, consult with a representative sample of the online service’s user population  to inform the design and performance evaluation of the identity management approach, and complete and document the normative mandates and outcomes of each step regardless of operational approach or enabling tools.</p>
<h2 id="defServ" data-section="3">
  
  
    Define the Online Service <a href="#defServ" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The purpose of defining the online service is to establish a common understanding of the context and circumstances that influence the organization’s risk management decisions. The context-rich information ascertained during this step is intended to inform subsequent steps of the DIRM process. The role of the online service is contextualized as part of the broader business environment and associated processes, resulting in a documented description of the online service functionality, user groups and their expectations, data processed and other pertinent details.</p>

<p>RPs <strong>SHALL</strong> develop a description of the online service that includes, at minimum:</p>

<ul>
  <li>Organizational mission and business objectives supported by the online service</li>
  <li>Mission and business partner dependencies associated with the online service</li>
  <li>Legal, regulatory, and contractual requirements, including privacy and civil liberties obligations that apply to the online service</li>
  <li>Functionality of the online service and the underlying data that it is expected to process</li>
  <li>User groups that need to have access to the online service as well as the types of online transactions and privileges available to each user group</li>
  <li>User expectations for the online service, including functionality, features, identity verification and authentication options, accessibility and language requirements, and culturally responsive communication alternatives</li>
  <li>The results of any pre-existing DIRA assessments (as an input) and the current state of any pre-existing identity technologies (i.e., proofing, authentication, or federation)</li>
  <li>Across all users served, the estimated availability of forms of identity evidence to support the identity proofing process for services that require identity proofing.</li>
</ul>

<p>Additionally, an organization needs to determine the entities that will be impacted by the online service and the broader business process of which it is a part. It is imperative to consider the unexpected and undesirable impacts on different entities, populations, or demographic groups that result from an unauthorized user gaining access to the online service due to a failure of the digital identity system. For example, if an attacker obtained unauthorized access to an application that controls a power plant, the actions taken by the bad actor could have devastating environmental impacts on the local populations that live near the facility as well as cause power outages for the localities served by the plant.</p>

<p>It is important to differentiate between <em>user groups</em> and <em>impacted entities</em> as described in this document. The online service will allow access to a set of users who may be partitioned into a few user groups based on the kind of functionality that is offered to that user group. For example, an income tax filing and review online service may have the following user groups: (i) citizens who need to check on the status of their personal tax returns; (2) tax preparers who file tax returns on behalf of their clients; and (3) system administrators who assign privileges to different groups of users or create new user groups as needed. In contrast, impacted entities include all populations impacted by the online service and its functionality. For example, an online service that allows remote access to control, operate and monitor a water treatment facility may have the following types of impacted entities: (1) populations that drink the water from that water treatment facility; (2) technicians who control and operate the water treatment facility; (3) the organization that owns and operates the facility; and (4) auditors and other officials who provide oversight of the facility and its compliance with applicable regulations.</p>

<p>Accordingly, impact assessments <strong>SHALL</strong> include individuals who use the online application as well as the organization itself. Additionally, organizations <strong>SHOULD</strong> identify other entities (e.g., mission partners, communities, and those identified in <a href="/800-63-4/sp800-63/references/#ref-SP800-30">[SP800-30]</a>) that need to be specifically included based on mission and business needs. At a minimum, agencies <strong>SHALL</strong> document all impacted when conducting their impact assessments.</p>

<p><strong>The output of this step is a documented description of the online service including a list of entities that are impacted by the functionality provided by the online service. This information will serve as a basis and establish the context for effectively applying the impact assessments as detailed in the following sections.</strong></p>
<h2 id="intlAssess" data-section="3">
  
  
    Conduct Initial Impact Assessment <a href="#intlAssess" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>This step of the DIRM process addresses the first dimension of risk (i.e., risks to the identity system) and seeks to identify the risks to the online service that might be addressed by an identity system.</p>

<p>The purpose of the initial impact assessment is to identify the potential adverse impacts of failures in identity proofing, authentication, and federation that are specific to an online service, yielding an initial set of assurance levels. RPs <strong>SHOULD</strong> consider historical data and results from user focus groups when performing this step.
The impact assessment <strong>SHALL</strong> include:</p>

<ul>
  <li>Identifying a set of impact categories and the potential harms for each impact category,</li>
  <li>Identifying the levels of impact, and</li>
  <li>Assessing the level of impact for each user group.</li>
</ul>

<p>The level of impact for each user group identified in <a href="/800-63-4/sp800-63/dirm/#defServ">Sec. 3.1</a> <strong>SHALL</strong> be considered separately based on the transactions available to that user group. Assessing the user groups separately allows organizations maximum flexibility in selecting and implementing an identity approach and assurance levels that are appropriate for each user group.</p>

<p><strong>The output of this assessment is a defined impact level (i.e., Low, Moderate, or High) for each user group. This serves as the primary input to the initial assurance level selection. The effort focuses on defining and documenting the impact assessment to promote consistent application across an organization.</strong></p>
<h3 id="impactCatHarms" data-section="3">
  
  
    Identify Impact Categories and Potential Harms <a href="#impactCatHarms" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Initial assurance levels for online services <strong>SHALL</strong> be determined by assessing the potential impact of — at a minimum — each of the following categories:</p>

<ul>
  <li>Degradation of mission delivery</li>
  <li>Damage to trust, standing or reputation</li>
  <li>Unauthorized access to information</li>
  <li>Financial loss or financial liability</li>
  <li>Loss of life or danger to human safety, human health, or environmental health</li>
</ul>

<p>Organizations <strong>SHOULD</strong> include additional impact categories, as appropriate, based on their mission and business objectives. Each impact category <strong>SHALL</strong> be documented and consistently applied when implementing the DIRM process across different online services offered by the organization.</p>

<p>Harms refer to any adverse effects that would be experienced by an entity. They provide a means to effectively understand the impact categories and how they may apply to specific entities impacted by the online service. For each impact category, agencies <strong>SHALL</strong> consider potential harms for each of the impacted entities identified in <a href="/800-63-4/sp800-63/dirm/#defServ">Sec. 3.1</a>.</p>

<p>Examples of harms associated with each category include, but are not limited to:</p>

<ul>
  <li>Degradation of mission delivery:
    <ul>
      <li>Harms to individuals may include the inability to access government services or benefits for which they are eligible.</li>
      <li>Harms to the organization (including the organization offering the online service as well as organizations supported by the online service) may include an inability to perform current mission/business functions in a sufficiently timely manner, with sufficient confidence and/or correctness, or within planned resource constraints or an inability or limited ability to perform mission/business functions in the future.</li>
    </ul>
  </li>
  <li>Damage to trust, standing or reputation:
    <ul>
      <li>Harms to individuals may include damage to image or reputation as a result of impersonation.</li>
      <li>Harms to the organization may include damage to reputation resulting in damage to existing trust relationships, image, or reputation or the inability to forge future, potential trust relationships.</li>
    </ul>
  </li>
  <li>Unauthorized access to information:
    <ul>
      <li>Harms to individuals may include breach of PII or other sensitive information, which may result in secondary harms such as financial loss, loss of life, physical or psychological injury, impersonation, identity theft, or persistent inconvenience.</li>
      <li>Harms to the organization may include exfiltration, deletion, degradation, or exposure of intellectual property or unauthorized disclosure of other information assets such as classified materials or controlled unclassified information (CUI).</li>
    </ul>
  </li>
  <li>Financial loss or liability:
    <ul>
      <li>Harms to individuals may include debts incurred or assets lost as a result of fraud or other harm, damage to or loss of credit, actual or potential employment, or sources of income, loss of accessible affordable housing and/or other financial loss.</li>
      <li>Harms to the organization may include costs related to fraud or other criminal activity, loss of assets, devaluation, or loss of business.</li>
    </ul>
  </li>
  <li>Loss of life or danger to human safety, human health, or environmental health:
    <ul>
      <li>Harms to individuals may include death; damage to or loss of physical, mental, or emotional well-being; or impact to environmental health that could result in uninhabitability of the local environment and require some level of intervention to address potential or actual damage.</li>
      <li>Harms to the organization may include damage to or loss of the organization’s workforce or the impact of unsafe conditions that render the organization unable to operate or reduce its capacity to operate.</li>
    </ul>
  </li>
</ul>

<p><strong>The outcome of this activity will be a list of impact categories and harms that will be used to assess impacts on entities identified in <a href="/800-63-4/sp800-63/dirm/#defServ">Sec. 3.1</a>.</strong></p>
<h3 id="impLvls" data-section="3">
  
  
    Identify Potential Impact Levels <a href="#impLvls" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Initial assurance levels for digital transactions are determined by assessing the potential level of impact caused by a compromise of the online service that might be addressed by an identity system for each of the impact categories selected for consideration by the organization (from <a href="/800-63-4/sp800-63/dirm/#impactCatHarms">Sec. 3.2.1</a>). Impact levels can be assigned using one of the following potential impact values:</p>

<ul>
  <li><strong>Low</strong>: Could be expected to have a limited adverse effect</li>
  <li><strong>Moderate</strong>: Could be expected to have a serious adverse effect</li>
  <li><strong>High</strong>: Could be expected to have a severe or catastrophic adverse effect</li>
</ul>

<p>In this step, the impact of access by an unauthorized individual <strong>SHALL</strong> be considered for each user group, each impact category, and each of the impacted entities. Examples of potential impacts in each of the categories are provided below. However, to provide a more objective basis for impact level assignments, organizations <strong>SHOULD</strong> develop thresholds and examples for the impact levels for each impact category. Where this is done, particularly with specifically defined quantifiable values, these thresholds <strong>SHALL</strong> be documented and used consistently in the DIRM assessments across an organization to allow for a common understanding of risks.</p>

<ul>
  <li><strong>Degradation of mission delivery:</strong>
    <ul>
      <li><strong>Low</strong>:  Expected to result in limited mission capability degradation such that the organization is still able to perform its primary functions but with noticeably reduced effectiveness.</li>
      <li><strong>Moderate</strong>: Expected to result in serious mission capability degradation such that the organization is still able to perform its primary functions but with significantly reduced effectiveness.</li>
      <li><strong>High</strong>: Expected to result in severe or catastrophic mission capability degradation or loss over a duration such that the organization is unable to perform one or more of its primary functions.</li>
    </ul>
  </li>
  <li><strong>Damage to trust, standing or reputation:</strong>
    <ul>
      <li><strong>Low</strong>: Expected to result in limited, short-term inconvenience, distress, or embarrassment to any party.</li>
      <li><strong>Moderate</strong>: Expected to result in serious short-term or limited long-term inconvenience, distress, or damage to the standing or reputation of any party.</li>
      <li><strong>High</strong>: Expected to result in severe or serious long-term inconvenience, distress, or damage to the standing or reputation of any party; ordinarily reserved for situations with particularly severe effects or that potentially affect many individuals.</li>
    </ul>
  </li>
  <li><strong>Unauthorized access to information:</strong>
    <ul>
      <li><strong>Low</strong>: Expected to have a limited adverse effect on organizational operations, organizational assets, or individuals as defined in <a href="/800-63-4/sp800-63/references/#ref-FIPS199">[FIPS199]</a>.</li>
      <li><strong>Moderate</strong>: Expected to have a serious adverse effect on organizational operations, organizational assets, or individuals as defined in <a href="/800-63-4/sp800-63/references/#ref-FIPS199">[FIPS199]</a>.</li>
      <li><strong>High</strong>: Expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals as defined in <a href="/800-63-4/sp800-63/references/#ref-FIPS199">[FIPS199]</a>.</li>
    </ul>
  </li>
  <li><strong>Financial loss or financial liability:</strong>
    <ul>
      <li><strong>Low</strong>: Expected to result in limited financial loss or liability to any party.</li>
      <li><strong>Moderate</strong>: Expected to result in a serious financial loss or liability to any party.</li>
      <li><strong>High</strong>: Expected to result in severe or catastrophic financial loss or liability to any party.</li>
    </ul>
  </li>
  <li><strong>Loss of life or danger to human safety, human health, or environmental health:</strong>
    <ul>
      <li><strong>Low</strong>: Expected to result in minor injury or an acute health issue that resolves itself and does not require medical attention, including mental health treatment; or an impact to environmental health that requires at most some limited intervention to prevent further or reverse existing damage.</li>
      <li><strong>Moderate</strong>: Expected to result in moderate risk of minor injury or limited risk of injury that requires medical attention, including mental health treatment; an impact to environmental health that results in a period of uninhabitability and requires intervention to prevent further or reverse existing damage; or the compounding impacts of multiple low-impact events.</li>
      <li><strong>High</strong>: Expected to result in serious injury, trauma, or death; impacts to environmental health that results in long-term or permanent uninhabitability and require significant intervention to prevent further or reverse existing damage, if possible; or the compounding impacts of multiple moderate impact events.</li>
    </ul>
  </li>
</ul>

<p>This guidance provides three impact levels. However, agencies <strong>MAY</strong> define more granular impact levels and develop their own methodologies for their initial impact assessment activities.</p>
<h3 id="impAnalysis" data-section="3">
  
  
    Impact Analysis <a href="#impAnalysis" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>The impact analysis considers the level of impact (i.e., Low, Moderate or High) of compromises of the online service that might be addressed by the identity system functions (i.e., identity proofing, authentication, and federation). The impact analysis considers the following dimensions:</p>

<ul>
  <li>User groups <a href="/800-63-4/sp800-63/dirm/#defServ">Sec. 3.1</a></li>
  <li>Impacted entities <a href="/800-63-4/sp800-63/dirm/#defServ">Sec. 3.1</a></li>
  <li>Impact categories <a href="/800-63-4/sp800-63/dirm/#impactCatHarms">Sec. 3.2.1</a></li>
  <li>Impact levels <a href="/800-63-4/sp800-63/dirm/#impLvls">Sec. 3.2.2</a></li>
</ul>

<p>If there is no harm or impact for a given impact category for any entity, the impact level can be marked as None.</p>

<p>For each user group, the impact analysis <strong>SHALL</strong> consider the level of impact for each impact category for each type of impacted entity. Because different sets of transactions are available to each user group, it is important to consider each user group separately for this analysis.</p>

<p>For example, for an online service that allows for the control, operation and monitoring of a water treatment facility, each group of users (e.g., technicians who control and operate the facility, auditors and monitoring officials, system administrators, etc.) is considered separately based on the transactions available to that user group through the online service. In other words, the impact analysis tries to determine if a bad actor obtained unauthorized access to the online service as a member of a user group and performed some nefarious actions and the level of impact (i.e., Low, Moderate or High) on various impacted entities (e.g., citizens who drink the water, the organization that owns the facility, auditors, monitoring officials, etc.) for each of the impact categories being considered.</p>

<p>The impact analysis <strong>SHALL</strong> be performed for each user group that has access to the online service.  For each impact category, the impact level is estimated for each impacted entity as a result of a compromise of the online service caused by failures in the identity management functions.</p>

<p><strong>The output of this impact analysis is a set of impact levels for each user group that</strong> <strong>SHALL</strong> <strong>be documented in a suitable format for further analysis in accordance with the next subsection below.</strong></p>
<h3 id="combLevel" data-section="3">
  
  
    Determine Combined Impact Level for Each User Group <a href="#combLevel" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>The impact assessment level results for each user group generated from the previous step are combined to establish a single impact level for that user group. This single impact level represents the risks to impacted entities that result from a compromise of identity proofing, authentication, and/or federation functions for that user group.</p>

<p>Organizations can apply a variety of methods for this combinatorial analysis to determine the effective impact level for each user group. Some options include:</p>

<ul>
  <li>Using a high-water mark approach across the various impact categories and impacted entities to derive the effective impact level</li>
  <li>Assigning different weights to different impact categories and/or impacted entities and taking an average to derive the effective impact level</li>
  <li>Some other combinatorial logic that aligns with the organization’s mission and priorities</li>
</ul>

<p>Organizations <strong>SHALL</strong> document the approach they use to combine their impact assessment into an overall impact score for each of their defined user groups and <strong>SHALL</strong> apply it consistently across all its online services. At the conclusion of the combinatorial analysis, organizations <strong>SHALL</strong> document the impact for each user group.</p>

<p><strong>The outcome of this step is an effective impact level for each user group due to a compromise of the identity management system functions (i.e., identity proofing, authentication, federation).</strong></p>
<h2 id="select-initial-assurance-levels-and-baseline-controls" data-section="3">
  
  
    Select Initial Assurance Levels and Baseline Controls <a href="#select-initial-assurance-levels-and-baseline-controls" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The initial impact analysis of the last step yields an effective impact level (i.e., Low, Moderate, or High) that serves as a primary input to the process of selecting the initial assurance levels for identity proofing, authentication, and federation for each user group.</p>

<p>The purpose of the initial assurance level is to identify baseline digital identity controls (including process and technology elements) for each identity management function, from the requirements and guidelines in the companion volumes <a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a>, <a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a>, and <a href="/800-63-4/sp800-63c/introduction/#introduction" latex-href="#ref-SP800-63C">[SP800-63C]</a>.</p>

<p>The initial set of digital identity controls and processes selected will be assessed and tailored in Step 4 based on potential risks generated by the identity management system.</p>
<h3 id="assurance-levels" data-section="3">
  
  
    Assurance Levels <a href="#assurance-levels" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Depending on the functionality and deployed architecture of the online service, it may require the support of one or more of the identity management functions (i.e., identity proofing, authentication, and federation). The strength of these functions is described in terms of assurance levels. The RP <strong>SHALL</strong> identify the types of assurance levels that apply to their online service from the following:</p>

<ul>
  <li><strong>IAL</strong>: The robustness of the identity proofing process to determine the identity of an individual. The IAL is selected to mitigate risks that result from potential identity proofing failures.</li>
  <li><strong>AAL</strong>: The robustness of the authentication process itself, and the binding between an authenticator and a specific individual’s identifier. The AAL is selected to mitigate risks that result from potential authentication failures.</li>
  <li><strong>FAL</strong>: The robustness of the federation process used to communicate authentication and attribute information to an RP from an IdP. The FAL is selected to mitigate risks that result from potential federation failures.</li>
</ul>
<h3 id="assurance-level-descriptions" data-section="3">
  
  
    Assurance Level Descriptions <a href="#assurance-level-descriptions" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>A summary of each of the xALs is provided below. While high-level descriptions of the assurance levels are provided in this subsection, readers of this guidance are encouraged to refer to companion volumes <a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a>, <a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a>, and <a href="/800-63-4/sp800-63c/introduction/#introduction" latex-href="#ref-SP800-63C">[SP800-63C]</a> for normative guidelines and requirements for each assurance level.</p>
<h4 id="identity-assurance-level" data-section="3">
  
  
    Identity Assurance Level <a href="#identity-assurance-level" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<ul>
  <li>
    <p><strong>IAL1</strong>:
Supports the real-world existence of the claimed identity. Core attributes are obtained from identity evidence or asserted by the applicant. All core attributes are validated against authoritative or credible sources and steps are taken to link the attributes to the person undergoing the identity proofing process.</p>
  </li>
  <li>
    <p><strong>IAL2</strong>:
IAL2 adds rigor by requiring the collection of additional evidence and a more rigorous process for validating the evidence and verifying the identity.</p>
  </li>
  <li>
    <p><strong>IAL3</strong>:
 IAL3 adds the requirement for a trained CSP representative (i.e., proofing agent) to interact directly with the applicant as part of an on-site attended identity proofing session as well as the collection of at least one biometric.</p>
  </li>
</ul>

<p latex-ignore="true"><a href="/800-63-4/sp800-63/dirm/#table-1" name="table-1">Table 1. IAL Summary</a></p>

<table latex-table="1" latex-caption="IAL Summary" latex-columns="p@0.15\textwidth,p@0.75\textwidth">
  <thead>
    <tr>
      <th>IAL</th>
      <th style="text-align: center">Control Objectives</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>IAL1</td>
      <td style="text-align: center">Limit highly scalable attacks; provide protection against synthetic identity. Provide protections against attacks using compromised PII.</td>
    </tr>
    <tr>
      <td>IAL2</td>
      <td style="text-align: center">Limit scaled and targeted attacks. Provide protections against basic evidence falsification and evidence theft. Provide protections against basic social engineering.</td>
    </tr>
    <tr>
      <td>IAL3</td>
      <td style="text-align: center">Limit sophisticated attacks. Provide protections against advanced evidence falsification, theft, and repudiation. Provide protection against advanced social engineering attacks.</td>
    </tr>
  </tbody>
</table>
<h4 id="authentication-assurance-level" data-section="3">
  
  
    Authentication Assurance Level <a href="#authentication-assurance-level" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<ul>
  <li>
    <p><strong>AAL1</strong>:
AAL1 provides a basic level of confidence that the claimant controls an authenticator bound to the subscriber account being authenticated. AAL1 requires only single-factor authentication using a wide range of available authentication technologies. However, it is recommended that online services assessed at AAL1 offer multi-factor authentication options. Successful authentication requires that the claimant prove possession and control of the authenticator.</p>
  </li>
  <li>
    <p><strong>AAL2</strong>:
AAL2 provides high confidence that the claimant controls one or more authenticators bound to the subscriber account being authenticated. Proof of possession and control of two distinct authentication factors is required. A phishing-resistant authentication option must be offered for online services assessed at AAL2.</p>
  </li>
  <li>
    <p><strong>AAL3</strong>:
AAL3 provides very high confidence that the claimant controls one or more authenticators bound to the subscriber account being authenticated. Authentication at AAL3 is based on the proof of possession of a key through the use of a public-key cryptographic protocol. AAL3 authentication requires a hardware-based authenticator with a non-exportable private key and a phishing-resistant authenticator; the same device may fulfill both requirements. In order to authenticate at AAL3, claimants are required to prove possession and control of two distinct authentication factors.</p>
  </li>
</ul>

<p latex-ignore="true"><a href="/800-63-4/sp800-63/dirm/#table-2" name="table-2">Table 2. AAL Summary</a></p>

<table latex-table="2" latex-caption="AAL Summary" latex-columns="p@0.15\textwidth,p@0.75\textwidth">
  <thead>
    <tr>
      <th>AAL</th>
      <th style="text-align: center">Control Objectives</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>AAL1</td>
      <td style="text-align: center">Provide minimal protections against attacks. Deter password focused attacks.</td>
    </tr>
    <tr>
      <td>AAL2</td>
      <td style="text-align: center">Support multifactor authentication. Offer phishing-resistant options.</td>
    </tr>
    <tr>
      <td>AAL3</td>
      <td style="text-align: center">Provide phishing resistance and verifier compromise protections.</td>
    </tr>
  </tbody>
</table>
<h4 id="federation-assurance-level" data-section="3">
  
  
    Federation Assurance Level <a href="#federation-assurance-level" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<ul>
  <li>
    <p><strong>FAL1</strong>:
FAL1 allows a subscriber to authenticate to the RP using an assertion from an IdP in a federation protocol. FAL1 provides assurance that the assertion came from a specific IdP and was intended for a specific RP.</p>
  </li>
  <li>
    <p><strong>FAL2</strong>:
FAL2 additionally requires that the trust agreement between the IdP and RP be established prior to the federation transaction, and that the RP have robust protections against injection of assertions from attackers.</p>
  </li>
  <li>
    <p><strong>FAL3</strong>:
FAL3 additionally requires the subscriber to authenticate directly to the RP with a bound authenticator and present the assertion from the IdP. Additionally, the IdP and RP establish their identities and cryptographic key material with each other through a highly trusted process that is often manual.</p>
  </li>
</ul>

<p latex-ignore="true"><a href="/800-63-4/sp800-63/dirm/#table-3" name="table-3">Table 3. AAL Summary</a></p>

<table latex-table="3" latex-caption="FAL Summary" latex-columns="p@0.15\textwidth,p@0.75\textwidth">
  <thead>
    <tr>
      <th>FAL</th>
      <th>Control Objectives</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>FAL1</td>
      <td>Provide protections against forged assertions.</td>
    </tr>
    <tr>
      <td>FAL2</td>
      <td>Provide protections against forged assertions and injection attacks.</td>
    </tr>
    <tr>
      <td>FAL3</td>
      <td>Provide protection against IdP compromise.</td>
    </tr>
  </tbody>
</table>
<h3 id="initial-assurance-level-selection" data-section="3">
  
  
    Initial Assurance Level Selection <a href="#initial-assurance-level-selection" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>The overall impact level for each user group is used as the basis for the selection of the initial assurance level and related technical and process controls for the digital identity functions for the organization’s online service under assessment. These initial assurance levels and control selections are primarily based on the impacts arising from failures within the digital identity functions that allow an unauthorized entity to gain access to the online service. The initial assurance levels and controls will be further assessed and tailored, as appropriate, in the next step of the DIRM process.</p>

<p>Organizations <strong>SHALL</strong> develop and document a process and governance model for selecting initial assurance levels and controls based on the potential impact of failures in the digital identity approach. This section provides guidance on the major elements to include in that process.</p>

<p>While online service providers must assess and determine the xALs that are appropriate for protecting their applications, the selection of these assurance levels does not mean that the online service provider must implement the controls independently. Based on the identity model that the online service provider chooses to implement, some or all of the assurance levels may be implemented by an external entity such as a third-party CSP or IdP.</p>
<h4 id="IAL_CYOA" data-section="3">
  
  
    Selecting Initial IAL <a href="#IAL_CYOA" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>Before selecting an initial assurance level, RPs must determine if identity proofing is needed for the users of their online services. Identity proofing is not required if the online service does not require any personal information to execute digital transactions. If personal information is needed, the RP needs to determine if validated attributes are required or if self-asserted attributes are acceptable. The system may also be able to operate without identity proofing if the potential harms from accepting self-asserted attributes are insignificant. In such cases, the identity proofing processes described in <a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a> are not applicable to the system.</p>

<div latex-literal="true" class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>\clearpage
</code></pre></div></div>

<p>If the online service does require identity proofing, an initial IAL is selected through a simple mapping process, as follows:</p>

<ul>
  <li>Low impact: IAL1</li>
  <li>Moderate impact: IAL2</li>
  <li>High impact: IAL3</li>
</ul>

<p>The organization <strong>SHALL</strong> document whether identity proofing is required for their application and, if it is, <strong>SHALL</strong> select an initial IAL for each user group based on the effective impact level determination from <a href="/800-63-4/sp800-63/dirm/#combLevel">Sec. 3.2.4</a>.</p>

<p>The IAL reflects the level of assurance that an applicant holds the claimed real-life identity. The initial selection assumes that higher potential impacts of failures in the identity proofing process should be mitigated by higher assurance processes.</p>
<h4 id="AAL_CYOA" data-section="3">
  
  
    Selecting Initial AAL <a href="#AAL_CYOA" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>Not all online services require authentication. Online services that offer access to public information and do not utilize subscriber accounts do not necessarily need to implement authentication mechanisms. However, authentication is needed for online services that do offer access to personal information, protected information, or subscriber accounts. In addition to the impact assessments mandated by these guidelines, when making decisions regarding the application of authentication assurance levels and authentication mechanisms, it is important that organizations consider legal, regulatory, or policy requirements that govern online services. For example,  [EO13681] states “that all organizations making personal data accessible to citizens through digital applications require the use of multiple factors of authentication,” which requires a minimum selection of AAL2 for applications meeting those criteria.</p>

<p>If the online service requires an authenticator to be implemented, an initial AAL is selected through a simple mapping process, as follows:</p>

<ul>
  <li>Low impact: AAL1</li>
  <li>Moderate impact: AAL2</li>
  <li>High impact: AAL3</li>
</ul>

<p>The organization <strong>SHALL</strong> document whether authentication is needed for their online service and, if it is, <strong>SHALL</strong> select an initial AAL for each user group based on the effective impact level determination from <a href="/800-63-4/sp800-63/dirm/#combLevel">Sec. 3.2.4</a>.</p>

<p>The AAL reflects the level of assurance that the claimant is the same individual to whom the credential or authenticator was issued. The initial selection assumes that higher potential impacts of failures in the authentication process should be mitigated by higher assurance processes.</p>
<h4 id="FAL_CYOA" data-section="3">
  
  
    Selecting Initial FAL <a href="#FAL_CYOA" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>Identity federation brings many benefits including a convenient user experience that avoids redundant, costly, and often time-consuming identity processes. The benefits of federation through a general-purpose IdP model or a subscriber-controlled wallet model are covered in <a href="/800-63-4/sp800-63c/Wallets/#wallet" latex-href="#ref-SP800-63C">Sec. 5 of [SP800-63C]</a>. However, not all online services will be able to make use of federation, whether for risk-based reasons or due to legal or regulatory requirements. Consistent with <a href="/800-63-4/sp800-63/references/#ref-M-19-17">[M-19-17]</a>, federal agencies that operate online services <strong>SHOULD</strong> implement federation as an option for user access.</p>

<p>If the online service implements identity federation, an initial FAL is selected through a simple mapping process, as follows:</p>

<ul>
  <li>Low impact: FAL1</li>
  <li>Moderate impact: FAL2</li>
  <li>High impact: FAL3</li>
</ul>

<p>The organization <strong>SHALL</strong> document whether federation will be used for their online service and, if it is, <strong>SHALL</strong> select an initial FAL for each user group based on the effective impact level determination from <a href="/800-63-4/sp800-63/dirm/#combLevel">Sec. 3.2.4</a>.</p>

<p>The FAL reflects the level of assurance in identity assertions that convey the results of authentication processes and relevant identity information to RP online services. The preliminary selection assumes that higher potential impacts of failures in federated identity architectures should be mitigated by higher assurance processes.</p>
<h3 id="baseControls" data-section="3">
  
  
    Identify Baseline Controls <a href="#baseControls" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>The selection of the initial assurance levels for each of the applicable identity functions (i.e., IAL, AAL, and FAL) serves as the basis for the selection of the baseline digital identity controls from the guidelines in companion volumes <a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a>, <a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a>, and <a href="/800-63-4/sp800-63c/introduction/#introduction" latex-href="#ref-SP800-63C">[SP800-63C]</a>. As described in <a href="/800-63-4/sp800-63/dirm/#tailor">Sec. 3.4</a>, the baseline controls include technology and process controls that will be assessed against additional potential impacts.</p>

<p>The output of this step <strong>SHALL</strong> include the relevant xALs and controls for each user group, as follows:</p>

<ul>
  <li>Initial IAL and related technology and process controls from <a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a></li>
  <li>Initial AAL and related technology and process controls from <a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a></li>
  <li>Initial FAL and related technology and process controls from <a href="/800-63-4/sp800-63c/introduction/#introduction" latex-href="#ref-SP800-63C">[SP800-63C]</a></li>
</ul>
<h2 id="tailor" data-section="3">
  
  
    Tailor and Document Assurance Levels <a href="#tailor" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The second dimension of risk addressed by the Digital Identity Risk Management process focuses on risks from the identity management system. These risks inform the tailoring process and seeks to identify the risks and unintended consequences that result from the initial selection of xALs and the related technical and process controls in <a href="/800-63-4/sp800-63/dirm/#baseControls">Sec. 3.3.4</a>.</p>

<p>Tailoring provides a process to modify an initially assessed assurance level and implement compensating or supplemental controls based on ongoing detailed risk assessments. It provides a pathway for flexibility and enables organizations to achieve risk management objectives that align with their specific context, users, and threat environment. This process focuses on assessing for unintended risks and equity, privacy, and usability impacts, and specific environmental threats. It does not prioritize any specific risk area or outcomes for agencies. Making decisions that balance different types of risks to meet organizational outcomes remains the responsibility of organizations.  Organizations <strong>SHOULD</strong> employ tailoring with the objective of aligning of digital identity controls to their specific context, users, and threat environment.</p>

<p>Within the tailoring step, organizations <strong>SHALL</strong> focus on impacts to mission delivery due to the implementation of identity management controls that result in disproportionate impact on marginalized or historically underserved populations. Organizations <strong>SHALL</strong> consider not only the possibility of certain intended subjects failing to access the online service, but also the burdens, frustrations, and frictions experienced as a result of the identity management controls.</p>

<p>As a part of the tailoring process, organizations <strong>SHALL</strong> review the impact assessment documentation and practice statements<sup id="fnref:Practice" role="doc-noteref"><a href="#fn:Practice" class="footnote">1</a></sup> from CSPs and IdPs that they use or intend to use. However, organizations <strong>SHALL</strong> also conduct their own analysis to ensure that the organization’s specific mission and the communities being served by the online service are given due consideration for tailoring purposes. As a result the organization may require their chosen CSP to strengthen or provide optionality in the implementation of certain controls to address risks and unintended impacts to the organization’s mission and the communities served.</p>

<p>To promote interoperability and consistency across organizations, third-party CSPs <strong>SHOULD</strong> implement their (assessed or tailored) xALs consistent with the normative guidance in this document. However, these guidelines provide flexibility to allow organizations to tailor the initial xALs and related controls to meet specific mission needs, address unique risk appetites, and provide secure and accessible online services. In doing so, CSPs <strong>MAY</strong> offer and organizations <strong>MAY</strong> utilize tailored sets of controls that differ from the normative statements in this guidance.</p>

<div latex-literal="true" class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>\clearpage
</code></pre></div></div>

<p>Therefore, organizations <strong>SHALL</strong> establish and document an xAL tailoring process. At a minimum this process:</p>

<ul>
  <li><strong>SHALL</strong> follow a documented governance approach to allow for decision-making.</li>
  <li><strong>SHALL</strong> document all decisions in the tailoring process, including the assessed xALs, modified xALs, and supplemental and compensating controls in the Digital Identity Acceptance Statement (see <a href="/800-63-4/sp800-63/dirm/#IDacceptStmt">Sec. 3.4.4</a>).</li>
  <li><strong>SHALL</strong> justify and document all risk-based decisions or modifications to the initially assessed xALs in the Digital Identity Acceptance Statement (see <a href="/800-63-4/sp800-63/dirm/#IDacceptStmt">Sec. 3.4.4</a>).</li>
  <li><strong>SHOULD</strong> establish a cross-functional capability to support subject matter analysis of xAL selection impacts in the tailoring process (e.g., subject matter experts who can speak about risks and considerations related to privacy, usability, fraud and impersonation impacts, equity, and other germane areas).</li>
  <li><strong>SHOULD</strong> be a continuous process that incorporates real-world operational data to evaluate the impacts of selected xAL controls.</li>
</ul>

<p>The tailoring process promotes a structured means of balancing risks and impacts in the furtherance of protecting online services, systems, and data in a manner that enables mission success while supporting equity, privacy, and usability for individuals.</p>
<h3 id="assess-privacy-equity-usability-and-threat-resistance" data-section="3">
  
  
    Assess Privacy, Equity, Usability and Threat Resistance <a href="#assess-privacy-equity-usability-and-threat-resistance" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>When selecting and tailoring assurance levels for specific online services, it is critical that insights and inputs to the process extend beyond the initial impact assessment in <a href="/800-63-4/sp800-63/dirm/#intlAssess">Sec. 3.2</a>. When transitioning from the initial assurance level selection in <a href="/800-63-4/sp800-63/dirm/#baseControls">Sec. 3.3.4</a> to the final xAL selection and implementation, organizations <strong>SHALL</strong> conduct detailed assessments of the controls defined for the initially selected xALs to identify potential impacts in the operational environment.</p>

<p>At a minimum, organizations <strong>SHALL</strong> assess the impacts and potential unintended consequences related to the following areas:</p>

<ul>
  <li><strong>Privacy</strong> – Identify unintended consequences to the privacy of individuals that will be subject to the controls at an assessed xAL and of individuals affected by organizational or third-party practices related to the establishment, management, or federation of a digital identity. Privacy assessments <strong>SHOULD</strong> leverage existing Privacy Threshold Assessments (PTAs) and Privacy Impact Assessments (PIAs) as inputs to the privacy assessment process. However, as the goal of the privacy assessment is to identify privacy risks that arise from the initial assurance level selection, additional assessments and evaluations that are specific to the baseline controls for the assurance levels may be required for the underlying information system.</li>
  <li><strong>Equity</strong> – Determine whether implementation of the initial assurance levels may create, maintain, or exacerbate inequities across communities. Equity assessments <strong>SHALL</strong> evaluate impacts on the communities being served by considering factors such as: proficiency with and access to technology, the availability of end devices with required technical capabilities (e.g., cameras), shared computing or device scenarios, housing status, access to internet, internet speed, family income bracket, credit score, disability status, sex, skin tone, age, native language, English fluency, and education. The intent of this assessment is to mitigate potential impacts on marginalized and historically underserved groups and limit disproportionate impacts from the requirements of the identity management functions.</li>
  <li><strong>Usability</strong> – Determine whether implementation of the initial assurance levels will result in challenges to the end-user experience. Usability assessments <strong>SHALL</strong> consider usability impacts that result from the identity management controls to ensure that they do not cause undue burdens, frustrations, or frictions for the communities served and that there are pathways to provide accessibility to users of all capabilities.</li>
  <li><strong>Threat Resistance</strong> – Determine whether the defined assurance level and related controls will address specific threats to the online service based on the operational environment, its threat actors, and known tactics, techniques, and procedures (TTPs). Threat assessments <strong>SHALL</strong> consider specific and known threats, threat actors, and TTPs within the implementation environment for the identity management functions. For example, certain benefits programs may be more subject to familial threats or collusion. Supplemental controls <strong>MAY</strong> need to be implemented to address specific threats within communities served by the online service. Conversely, agencies <strong>MAY</strong> tailor their assessed xAL down or modify their baseline controls if their threat assessment indicates that a reduced threat posture is appropriate based on their environment.</li>
</ul>

<p>Organizations <strong>SHOULD</strong> leverage consultation and feedback to ensure that the tailoring process addresses the constraints of the entities and communities served.  Organizations <strong>MAY</strong> establish mechanisms through which civil society organizations that work with marginalized groups can provide input on the impacts felt or likely to be felt.</p>

<p>Additionally, organizations <strong>SHOULD</strong> conduct additional business-specific assessments as appropriate to fully represent mission- and domain-specific considerations not captured here. These assessments <strong>SHALL</strong> be extended to any compensating or supplemental controls as defined in <a href="/800-63-4/sp800-63/dirm/#IDCompCntls">Sec. 3.4.2</a> and <a href="/800-63-4/sp800-63/dirm/#IDSupCntrls">Sec. 3.4.3</a>.</p>

<p><strong>The outcome of this step is a set of risk assessments for privacy, equity, usability, threat resistance and other dimensions that informs the tailoring of the initial assurance levels and the selection of compensating and supplemental controls.</strong></p>
<h3 id="IDCompCntls" data-section="3">
  
  
    Identify Compensating Controls <a href="#IDCompCntls" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>A compensating control is a management, operational, or technical control employed by an organization in lieu of a normative control in the defined xALs. They are intended to address the same risks as the baseline control is intended to address to the greatest degree practicable.</p>

<p>Organizations <strong>MAY</strong> choose to implement a compensating control when they are unable to implement a baseline control or when a risk assessment indicates that a compensating control sufficiently mitigates risk in alignment with organizational risk tolerance. This control <strong>MAY</strong> be a modification to the normative statements as defined in these guidelines, but <strong>MAY</strong> also be applied elsewhere in an application, digital transaction, or service lifecycle. For example:</p>

<ul>
  <li>A federal agency could choose to use a federal background investigation and checks, as referenced by <em>Personal Identity Verification</em> <a href="/800-63-4/sp800-63/references/#ref-FIPS201">[FIPS201]</a>, to compensate for the identity evidence validation with authoritative sources requirement under these guidelines.</li>
  <li>An organization could choose to implement stricter auditing and transactional review processes on a payment application where verification processes using weaker forms of identity evidence were accepted due to the lack of required evidence in the end-user population.</li>
</ul>

<p>Where compensating controls are implemented, organizations <strong>SHALL</strong> document the compensating control, the rationale for the deviation, comparability of the chosen alternative, and resulting residual risk (if any). CSPs and IDPs who implement compensating controls <strong>SHALL</strong> communicate this information to all potential RPs prior to integration to allow the RP to assess and determine the acceptability of the compensating controls for their use cases.</p>

<p>The process of tailoring allows agencies and service providers to make risk-based decisions regarding how they implement their xALs and related controls. It also provides a mechanism for documenting and communicating decisions through the Digital Identity Acceptance Statement described in
<a href="/800-63-4/sp800-63/dirm/#IDacceptStmt">Sec. 3.4.4</a>.</p>
<h3 id="IDSupCntrls" data-section="3">
  
  
    Identify Supplemental Controls <a href="#IDSupCntrls" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Supplemental controls are those that may be added to further strengthen the baseline controls specified for the organization’s selected assurance levels. Organizations <strong>SHOULD</strong> identify and implement supplemental controls to address specific threats in the operational environment that may not be addressed by the baseline controls. For example:</p>

<ul>
  <li>To complete the proofing process, an organization could choose to verify an end user against additional pieces of identity evidence, beyond what is required by the assurance level, due to a high prevalence of fraudulent attempts.</li>
  <li>An organization could restrict users to only phishing-resistant authentication at AAL2.</li>
  <li>An organization could choose to implement risk-scoring analytics, coupled with re-proofing mechanisms, to confirm a user’s identity when their access attempts exhibit certain risk factors.</li>
</ul>

<p>Any supplemental controls <strong>SHALL</strong> be assessed for impacts based on the same factors used to tailor the organization’s assurance level and <strong>SHALL</strong> be documented.</p>
<h3 id="IDacceptStmt" data-section="3">
  
  
    Digital Identity Acceptance Statement (DIAS) <a href="#IDacceptStmt" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Organizations <strong>SHALL</strong> develop a Digital Identity Acceptance Statement (DIAS) to document the results of the Digital Identity Risk Management process for each online service managed by the organization. A CSP/IdP <strong>SHALL</strong> make their DIAS and practice statements available to RPs. RPs who intend to use a particular CSP/IdP <strong>SHALL</strong> review the latter’s DIAS and practice statements and incorporate relevant information into the organization’s DIAS for each online service.</p>

<p>The DIAS <strong>SHALL</strong> include, at a minimum:</p>

<ul>
  <li>Initial impact assessment results,</li>
  <li>Initially assessed xALs,</li>
  <li>Tailored xAL and rationale, if the tailored xAL differs from the initially assessed xAL,</li>
  <li>All compensating controls with their comparability or residual risk, and</li>
  <li>All supplemental controls.</li>
</ul>

<p>Federal agencies <strong>SHOULD</strong> include this information in the information system authorization package described in <a href="/800-63-4/sp800-63/references/#ref-NIST-RMF">[NISTRMF]</a>.</p>
<h2 id="sec5.5" data-section="3">
  
  
    Continuously Evaluate and Improve <a href="#sec5.5" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Threat actors adapt; user capabilities, expectations, and needs shift; seasonal surges occur; and missions evolve. As such, risk assessments and identity solutions must be continuously improved. In addition to keeping pace with the threat and technology environment, continuous improvement is a critical tool for illustrating programmatic gaps that — if unaddressed — may hinder the implementation of identity management systems in a manner that balances risk management objectives. For instance, an organization may determine that a portion of the target population intended to be served by the online service does not have access to affordable high-speed internet services needed to support remote identity proofing. The organization could address this gap with a program that implements local proofing capabilities within the community or by offering appointments with proofing agents who will meet the individual at an address that is more accessible and convenient, such as their local community center, closest post office, an affiliated business partner facility, or the individual’s home.</p>

<p>To address the shifting environment in which they operate and more rapidly address service capability gaps, organizations <strong>SHALL</strong> implement a continuous evaluation and improvement program that leverages input from end users who have interacted with the identity management system as well as performance metrics for the online service. This program <strong>SHALL</strong> be documented, including the metrics that are collected, the sources of data required to enable performance evaluation, and the processes in place for taking timely actions based on the continuous improvement process. This program and its effectiveness <strong>SHOULD</strong> be assessed on a defined basis to ensure that outcomes are being achieved and that programs are addressing issues in a timely manner.</p>

<p>Additionally, organizations <strong>SHALL</strong> monitor the evolving threat landscape to stay informed of the latest threats and fraud tactics. Organizations <strong>SHALL</strong> regularly assess the effectiveness of current security measures and fraud detection capabilities against the latest threats and fraud tactics.</p>
<h3 id="evaluation-inputs" data-section="3">
  
  
    Evaluation Inputs <a href="#evaluation-inputs" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>To fully understand the performance of their identity system, organizations will need to identify critical inputs to their evaluation process. At a minimum these <strong>SHALL</strong> include:</p>

<ul>
  <li>Integrated CSP, IdP, and authenticator functions as well as validation, verification, and fraud management systems as appropriate.</li>
  <li>Customer feedback mechanisms such as complaint processes, help-desk statistics, and other user feedback (e.g., surveys, interviews, or focus groups)</li>
  <li>Threat analysis, threat reporting, and threat intelligence feeds as available to the organization.</li>
  <li>Fraud trends, fraud investigation results, and fraud metrics as available to the organization.</li>
  <li>The results of ongoing equity assessments, privacy assessments, and usability assessments.</li>
</ul>

<p>Organizations <strong>SHALL</strong> document their metrics, reporting requirements, and data inputs for any CSP, IdP, or other integrated identity services to ensure that expectations are appropriately communicated to partners and vendors.</p>
<h3 id="performance-metrics" data-section="3">
  
  
    Performance Metrics <a href="#performance-metrics" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>The exact metrics available to organizations will vary based on the technologies, architectures, and deployment patterns they follow. Additionally, what is available and what is useful may vary over time. Therefore, these guidelines do not attempt to define a comprehensive set of metrics for all scenarios. <a href="/800-63-4/sp800-63/dirm/#table-4">Table 4</a> provides a set of recommended metrics that organizations <strong>SHOULD</strong> capture as part of their continuous evaluation program. However, organizations are not constrained by this table and <strong>SHOULD</strong> implement metrics that are not defined here based on their specific systems, technology, and program needs. In <a href="/800-63-4/sp800-63/dirm/#table-4">Table 4</a>, all references to unique users include both legitimate users and imposters.</p>

<p latex-ignore="true"><a href="/800-63-4/sp800-63/dirm/#table-4" name="table-4">Table 4. Performance Metrics</a></p>

<table latex-table="4" latex-caption="Performance Metrics" latex-longtable="true" latex-columns="p@0.25\textwidth,p@0.50\textwidth,p@0.28\textwidth">
  <thead>
    <tr>
      <th>Title</th>
      <th>Description</th>
      <th>Type</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Pass Rate (Overall)</td>
      <td>Percentage of unique users who successfully proof.</td>
      <td>Proofing</td>
    </tr>
    <tr>
      <td>Pass Rate (Per Proofing Type)</td>
      <td>Percentage of unique users who successfully proof for each offered type (i.e., Remote Unattended, Remote Attended, Onsite Attended, Onsite Unattended).</td>
      <td>Proofing</td>
    </tr>
    <tr>
      <td>Fail Rate (Overall)</td>
      <td>Percentage of unique users who start the identity proofing process but are unable to successfully complete all the steps.</td>
      <td>Proofing</td>
    </tr>
    <tr>
      <td>Estimated Adjusted Fail Rate</td>
      <td>Percentage adjusted to account for digital transactions that are terminated based on suspected fraud.</td>
      <td>Proofing</td>
    </tr>
    <tr>
      <td>Fail Rate (Per Proofing Type)</td>
      <td>Percentage of unique users who do not complete proofing due to a process failure for each offered type (i.e., Remote Unattended, Remote Attended, Onsite Attended, Onsite Unattended)</td>
      <td>Proofing</td>
    </tr>
    <tr>
      <td>Abandonment Rate (Overall)</td>
      <td>Percentage of unique users who start the identity proofing process, but do not complete it without failing a process.</td>
      <td>Proofing</td>
    </tr>
    <tr>
      <td>Abandonment Rate (Per Proofing Type)</td>
      <td>Percentage of unique users who start a specific type of identity proofing process, but do not complete it without failing a process.</td>
      <td>Proofing</td>
    </tr>
    <tr>
      <td>Failure Rates (Per Proofing Process Step)</td>
      <td>Percentage of unique users who are unsuccessful at completing each identity proofing step in a CSP process.</td>
      <td>Proofing</td>
    </tr>
    <tr>
      <td>Completion (Times Per Proofing Type)</td>
      <td>Average time that it takes a user to complete each defined proofing type offered as part of an identity service.</td>
      <td>Proofing</td>
    </tr>
    <tr>
      <td>Authenticator Type Usage</td>
      <td>Percentage of subscribers who have an active authenticator by each type available.</td>
      <td>Authentication</td>
    </tr>
    <tr>
      <td>Authentication Failures</td>
      <td>Percentage of authentication events that fail (not to include attempts that are successful after re-entry of an authenticator output).</td>
      <td>Authentication</td>
    </tr>
    <tr>
      <td>Account Recovery Attempts</td>
      <td>The number of account or authenticator recovery processes initiated by subscribers</td>
      <td>Authentication</td>
    </tr>
    <tr>
      <td>Confirmed Fraud</td>
      <td>Percentage of digital transactions that are confirmed to be fraudulent through investigation or self-reporting.</td>
      <td>Fraud</td>
    </tr>
    <tr>
      <td>Suspected Fraud</td>
      <td>Percentage of digital transactions that are suspected of being fraudulent.</td>
      <td>Fraud</td>
    </tr>
    <tr>
      <td>Reported Fraud</td>
      <td>Percentage of digital transactions reported to be fraudulent by users.</td>
      <td>Fraud</td>
    </tr>
    <tr>
      <td>Fraud (Per Proofing Type</td>
      <td>Number of digital transactions that are suspected, confirmed, and reported by each available type of proofing.</td>
      <td>Fraud</td>
    </tr>
    <tr>
      <td>Fraud (Per Authentication Type)</td>
      <td>Number of digital transactions suspected, confirmed, and reported by each available type of authentication</td>
      <td>Fraud</td>
    </tr>
    <tr>
      <td>Help Desk Calls</td>
      <td>Number of calls received by the CSP or identity service.</td>
      <td>Customer Support</td>
    </tr>
    <tr>
      <td>Help Desk Calls (Per Type)</td>
      <td>Number of calls received related to each offered service (e.g., proofing failures, authenticator resets, complaints)</td>
      <td>Customer Support</td>
    </tr>
    <tr>
      <td>Help Desk Resolution Times</td>
      <td>Average length of time it takes to resolve a complaint or help desk ticket.</td>
      <td>Customer Support</td>
    </tr>
    <tr>
      <td>Customer Satisfaction Surveys</td>
      <td>The results of customer feedback surveys conducted by CSPs, RP, or both.</td>
      <td>User Experience</td>
    </tr>
    <tr>
      <td>Redress requests</td>
      <td>The number of redress requests received related to the identity management system.</td>
      <td>User Experience</td>
    </tr>
    <tr>
      <td>Redress resolution times</td>
      <td>The average time it takes to resolve redress requests related to the identity management system.</td>
      <td>User Experience</td>
    </tr>
  </tbody>
</table>

<p>The data used to generate continuous evaluation metrics may not always reside with the identity program or the organizational entity responsible for identity management systems. The intent of these metrics is not to establish redundant processes but to integrate with existing data sources whenever possible to collect information that is critical to identity program evaluation. For example, customer service representative (CSR) teams may already have substantial information on customer requests, complaints, or concerns. Identity management systems would be expected to coordinate with these teams to acquire the information needed to discern identity management system-related complaints or issues.</p>
<h3 id="measurement-in-support-of-equity-assessments-and-outcomes" data-section="3">
  
  
    Measurement in Support of Equity Assessments and Outcomes <a href="#measurement-in-support-of-equity-assessments-and-outcomes" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>A primary purpose of continuous improvement is to improve equity and accessibility outcomes for different user populations. As a result, the metrics collected by organizations <strong>SHOULD</strong> be further evaluated to provide insights into the performance of their identity management systems for their supported communities and demographics. Where possible, these efforts <strong>SHOULD</strong> avoid the collection of additional personal information and instead use informed analysis of proxy data to help provide indicators of potential disparities. This can include comparing and filtering the metrics to identify deviations in performance across different user populations based on other available data such as zip code, geographic region, age, or sex.</p>

<p>Organizations are encouraged to consult the OMB Report <em>A Vision for Equitable Data:  Recommendations from the Equitable Data Working Group</em> <a href="/800-63-4/sp800-63/references/#ref-EO13985-vision">[EO13985-vision]</a> for guidance on incorporating performance metrics into equity assessments across demographic groups and generating disaggregated statistical estimates to assess equitable performance outcomes.</p>
<h2 id="redress" data-section="3">
  
  
    Redress <a href="#redress" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>An important part of designing services that support a wide range of populations is the inclusion of processes to adjudicate issues and provide redress<sup id="fnref:redress" role="doc-noteref"><a href="#fn:redress" class="footnote">2</a></sup> as warranted. Service failures, disputes, and other issues tend to arise as part of normal operations, and their impact can vary broadly, from minor inconveniences to major disruptions or damage. Barriers to access, as well as cybersecurity incidents and data breaches, have real-world consequences for affected individuals. Furthermore, the same issue experienced by one person or community as an inconvenience can have a disproportionately damaging impacts on other individuals and communities, particularly those that are currently experiencing other harms or barriers. Left unchecked, these issues can result in harms that exacerbate existing inequities and allow systemic cycles of exclusion to continue.</p>

<p>To enable equitable access to critical services while deterring identity-related fraud and cybersecurity threats, it is essential for organizations to plan for potential issues and to design redress approaches that aim to be fair, transparent, easy for legitimate claimants to navigate, and resistant to exploitation attempts.</p>

<p>Understanding when and how harms might be occurring is a critical first step for organizations to take informed action. Continuous evaluation and improvement programs can play a key role in identifying instances and patterns of potential harm. Moreover, there may be business processes in place outside of those established to support identity management that can be leveraged as part of a comprehensive approach to issue adjudication and redress. Beyond these activities, additional practices can be implemented to ensure that users of identity management systems are able to voice their concerns and have a path to redress. Requirements for these practices include:</p>

<ul>
  <li>RPs and CSPs <strong>SHALL</strong> enable people to convey grievances and seek redress through an issue handling process that is documented, accessible, trackable, and usable by all people, and whose instructions are easy to find on a public-facing website.</li>
  <li>RPs and CSPs <strong>SHALL</strong> institute a governance model, including documented roles and responsibilities, for implementing this issue handling process.</li>
  <li>The issue handling process <strong>SHALL</strong> be implemented as a dedicated function that includes:
    <ul>
      <li>Procedures for the impartial review of evidence pertinent to issues;</li>
      <li>Procedures for requesting and collecting additional evidence that informs the issues; and</li>
      <li>Procedures to expeditiously resolve issues and determine corrective action.</li>
    </ul>
  </li>
  <li>RPs and CSPs <strong>SHALL</strong> make human support personnel available to intervene and override issue adjudication outputs generated by algorithmic support mechanisms, such as chatbots.</li>
  <li>RPs and CSPs <strong>SHALL</strong> educate support personnel on issue handling procedures for the digital identity management system, the avenues for redress, and the alternatives available to gain access to services.</li>
  <li>RPs and CSPs <strong>SHALL</strong> implement a process for  personnel and technologies that provides support functions to report major barriers that end users face and commonly expressed grievances. This process <strong>SHALL</strong> enable tracing (e.g., who/what is reported) and tracking (e.g. progress/state of action taken).</li>
  <li>RPs and CSPs <strong>SHALL</strong> incorporate findings derived from the issue handling process into continuous evaluation and improvement activities.</li>
</ul>

<p>Organizations are encouraged to consider these and other emerging redress practices. Prior to adopting any new redress practice, including supporting technology, organizations <strong>SHOULD</strong> test the practice with target populations to avoid the introduction of unintended consequences, particularly those that may counteract or contradict the goals associated with redress.</p>
<h2 id="cybersecurity-fraud-and-identity-program-integrity" data-section="3">
  
  
    Cybersecurity, Fraud, and Identity Program Integrity <a href="#cybersecurity-fraud-and-identity-program-integrity" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Identity solutions should not operate in a vacuum. Close coordination of identity functions with teams that are responsible for cybersecurity, privacy, threat intelligence, fraud detection, and program integrity can enable a more complete protection of business capabilities, while constantly improving identity solution capabilities. For example, payment fraud data collected by program integrity teams could provide indicators of compromised subscriber accounts and potential weaknesses in identity proofing implementations. Similarly, threat intelligence teams may learn of new TTPs that Could impact identity proofing, authentication, and federation processes. Organizations <strong>SHALL</strong> establish consistent mechanisms for the exchange of information between critical internal security and fraud stakeholders. Organizations <strong>SHOULD</strong> do the same for external stakeholders and identity services that are part of the protection plan for their online services.</p>

<p>When supporting identity service providers (e.g., CSPs) are external to an organization, the exchange of data related to security, fraud, and other RP functions may be complicated by regulation or policy. However, establishing the necessary mechanisms and guidelines to enable effective information-sharing <strong>SHOULD</strong> be considered in contractual and legal mechanisms. All data collected, transmitted, or shared <strong>SHALL</strong> be minimized and subject to a detailed privacy and legal assessment by the generating entity.</p>

<p>This section is meant to address coordination and integration with various organizational functional teams to achieve better outcomes for the identity functions. Ideally, such coordination is performed throughout the risk management process and operations lifecycle. Companion volumes <a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a>, <a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a>, and <a href="/800-63-4/sp800-63c/introduction/#introduction" latex-href="#ref-SP800-63C">[SP800-63C]</a> provide specific fraud mitigation requirements related to each of the identity functions.</p>
<h2 id="artificial-intelligence-ai-and-machine-learning-ml-in-identity-systems" data-section="3">
  
  
    Artificial Intelligence (AI) and Machine Learning (ML) in Identity Systems <a href="#artificial-intelligence-ai-and-machine-learning-ml-in-identity-systems" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Identity solutions have used and will continue to use AI and ML for multiple purposes, such as improving the performance of biometric matching systems, documenting authentication, detecting fraud, and even assisting users (e.g., chatbots). The potential applications of AI/ML are extensive. They also introduce distinct risks and potential issues, including disparate outcomes, biased outputs, and the exacerbation of existing inequities and access issues.</p>

<p>The following requirements apply to all uses of AI and ML regardless of how they are used in identity systems:</p>

<ul>
  <li>All uses of AI and ML <strong>SHALL</strong> be documented and communicated to organizations that rely on these systems. The use of integrated technologies that leverage AI and ML by CSPs, IdPs, or verifiers <strong>SHALL</strong> be disclosed to all RPs that make access decisions based on information from these systems.</li>
  <li>All organizations that use AI and ML <strong>SHALL</strong> provide information to any entities that use their technology on the methods and techniques used for training their models, a description of the data sets used in training, information on the frequency of model updates, and the results of all testing completed on their algorithms.</li>
  <li>All organizations that use AI and ML systems or rely on services that use these systems <strong>SHALL</strong> implement <em>NIST AI Risk Management Framework</em> (<a href="/800-63-4/sp800-63/references/#ref-NISTAIRMF">[NISTAIRMF]</a>) to evaluate the risks that may be introduced by the use of AI and ML.
    <ol>
      <li>All organizations that use AI and ML <strong>SHALL</strong> consult <a href="/800-63-4/sp800-63/references/#ref-SP1270">[SP1270]</a>, <em>Towards a Standard for Managing Bias in Artificial Intelligence</em>.</li>
    </ol>
  </li>
</ul>

<p>NIST continues to advance efforts to promote safe and trustworthy AI implementations through a number of venues. In particular, the U.S. AI Safety Institute, housed at NIST <a href="/800-63-4/sp800-63/references/#ref-US-AI-Safety-Inst">[US-AI-Safety-Inst]</a>, is creating a portfolio of safety-focused resources, guidance, and tools that can improve how organizations assess, deploy, and manage their AI systems. Organizations are encouraged to follow the U.S. AI Safety Institute’s efforts and make use of their resources.</p>
<div class="footnotes" role="doc-endnotes">
  <ol>
    <li id="fn:Practice" role="doc-endnote">
      <p>Further information on practice statements and their contents can be found in Section 3.1 of SP800-63A. <a href="#fnref:Practice" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:redress" role="doc-endnote">
      <p>Redress generally refers to a remedy that is made after harm occurs. <a href="#fnref:redress" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
  </ol>
</div>

<h1 id="references">
  
  
    References <a href="#references" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<p><em>This section is informative.</em></p>

<p><a href="/800-63-4/sp800-63/references/#ref-A-130" name="ref-A-130">[A-130]</a> Office of Management and Budget (2016) Managing Information as a Strategic Resource. (The White House, Washington, DC), OMB Circular A-130, July 28, 2016. Available at <a href="https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf">https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-EO13985" name="ref-EO13985">[EO13985]</a> Biden J (2021) Advancing Racial Equity and Support for Underserved Communities Through the Federal Government. (The White House, Washington, DC), Executive Order 13985, January 25, 2021. <a href="https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government">https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-EO13985-vision" name="ref-EO13985-vision">[EO13985-vision]</a> Office of Management and Budget (2022) A Vision for Equitable Data: Recommendations from the Equitable Data Working Group. (The White House, Washington, DC), OMB Report Pursuant to Executive Order 13985, April 22, 2022. <a href="https://www.whitehouse.gov/wp-content/uploads/2022/04/eo13985-vision-for-equitable-data.pdf">https://www.whitehouse.gov/wp-content/uploads/2022/04/eo13985-vision-for-equitable-data.pdf</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-EO14012" name="ref-EO14012">[EO14012]</a> Biden J (2021) Restoring Faith in Our Legal Immigration Systems and Strengthening Integration and Inclusion Efforts for New Americans. (The White House, Washington, DC), Executive Order 14012, February 02, 2021. <a href="https://www.whitehouse.gov/briefing-room/presidential-actions/2021/02/02/executive-order-restoring-faith-in-our-legal-immigration-systems-and-strengthening-integration-and-inclusion-efforts-for-new-americans/">https://www.whitehouse.gov/briefing-room/presidential-actions/2021/02/02/executive-order-restoring-faith-in-our-legal-immigration-systems-and-strengthening-integration-and-inclusion-efforts-for-new-americans/</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-EO14058" name="ref-EO14058">[EO14058]</a> Biden J (2021) Transforming Federal Customer Experience and Service Delivery to Rebuild Trust in Government. (The White House, Washington, DC), Executive Order 14058, December 13, 2021. <a href="https://www.federalregister.gov/documents/2021/12/16/2021-27380/transforming-federal-customer-experience-and-service-delivery-to-rebuild-trust-in-government">https://www.federalregister.gov/documents/2021/12/16/2021-27380/transforming-federal-customer-experience-and-service-delivery-to-rebuild-trust-in-government</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-EO14091" name="ref-EO14091">[EO14091]</a> Biden J (2023) Further Advancing Racial Equity and Support for Underserved Communities Through the Federal Government. (The White House, Washington, DC), Executive Order 14091, February 16, 2023. <a href="https://www.whitehouse.gov/briefing-room/presidential-actions/2023/02/16/executive-order-on-further-advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government/">https://www.whitehouse.gov/briefing-room/presidential-actions/2023/02/16/executive-order-on-further-advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government/</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-FIPS199" name="ref-FIPS199">[FIPS199]</a> National Institute of Standards and Technology (2004) Standards for Security Categorization of Federal Information and Information Systems. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 199. <a href="https://doi.org/10.6028/NIST.FIPS.199">https://doi.org/10.6028/NIST.FIPS.199</a></p>

<div latex-literal="true" class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>\clearpage
</code></pre></div></div>

<p><a href="/800-63-4/sp800-63/references/#ref-FIPS201" name="ref-FIPS201">[FIPS201]</a> National Institute of Standards and Technology (2022) Personal Identity Verification (PIV) of Federal Employees and Contractors. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 201-3. <a href="https://doi.org/10.6028/NIST.FIPS.201-3">https://doi.org/10.6028/NIST.FIPS.201-3</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-FISMA" name="ref-FISMA">[FISMA]</a> Federal Information Security Modernization Act of 2014, Pub. L. 113-283, 128 Stat. 3073. <a href="https://www.govinfo.gov/app/details/PLAW-113publ283">https://www.govinfo.gov/app/details/PLAW-113publ283</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-ISOIEC9241" name="ref-ISOIEC9241">[ISO/IEC9241-11]</a> International Standards Organization (2018) <em>ISO/IEC 9241-11 Ergonomics of human-system interaction – Part 11: Usability: Definitions and concepts</em> (ISO, Geneva, Switzerland). Available at <a href="https://www.iso.org/standard/63500.html">https://www.iso.org/standard/63500.html</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-M-03-22" name="ref-M-03-22">[M-03-22]</a> Office of Management and Budget (2003) OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002. (The White House, Washington, DC), OMB Memorandum M-03-22, September 26, 2003. Available at <a href="https://georgewbush-whitehouse.archives.gov/omb/memoranda/m03-22.html">https://georgewbush-whitehouse.archives.gov/omb/memoranda/m03-22.html</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-M-19-17" name="ref-M-19-17">[M-19-17]</a> Office of Management and Budget (2019) Enabling Mission Delivery through Improved Identity, Credential, and Access Management. (The White House, Washington, DC), OMB Memorandum M-19-17, May 21, 2019. Available at <a href="https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf">https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-NISTAIRMF" name="ref-NISTAIRMF">[NISTAIRMF]</a> Tabassi E (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). (National Institute of Standards and Technology (U.S.), Gaithersburg, MD), NIST AI 100-1. <a href="https://doi.org/10.6028/NIST.AI.100-1">https://doi.org/10.6028/NIST.AI.100-1</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-NISTIR8062" name="ref-NISTIR8062">[NISTIR8062]</a> Brooks SW, Garcia ME, Lefkovitz NB, Lightman S, Nadeau EM (2017) An Introduction to Privacy Engineering and Risk Management in Federal Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8062. <a href="https://doi.org/10.6028/NIST.IR.8062">https://doi.org/10.6028/NIST.IR.8062</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-NIST-RMF" name="ref-NIST-RMF">[NISTRMF]</a> Joint Task Force (2018) Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-37, Rev. 2. <a href="https://doi.org/10.6028/NIST.SP.800-37r2">https://doi.org/10.6028/NIST.SP.800-37r2</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-NIST-PF" name="ref-NIST-PF">[NISTPF]</a> National Institute of Standards and Technology (2020) NIST Privacy Framework: A Tool for Improving Privacy Through Enterprise Risk Management, Version 1.0. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Cybersecurity White Paper (CSWP) NIST CSWP 10. <a href="https://doi.org/10.6028/NIST.CSWP.10">https://doi.org/10.6028/NIST.CSWP.10</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-PrivacyAct" name="ref-PrivacyAct">[PrivacyAct]</a> Privacy Act of 1974, Pub. L. 93-579, 5 U.S.C. § 552a, 88 Stat. 1896 (1974). <a href="https://www.govinfo.gov/content/pkg/USCODE-2018-title5/pdf/USCODE-2018-title5-partI-chap5-subchapII-sec552a.pdf">https://www.govinfo.gov/content/pkg/USCODE-2018-title5/pdf/USCODE-2018-title5-partI-chap5-subchapII-sec552a.pdf</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-RFC5246" name="ref-RFC5246">[RFC5246]</a> Rescorla E, Dierks T (2008) The Transport Layer Security (TLS) Protocol Version 1.2. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 5246. <a href="https://doi.org/10.17487/RFC5246">https://doi.org/10.17487/RFC5246</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-RFC5280" name="ref-RFC5280">[RFC5280]</a> Cooper D, Santesson S, Farrell S, Boeyen S, Housley R, Polk W (2008) Internet X.509 Public Key Infrastructure Certification and Certificate Revocation List (CRL) Profile. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 5280. <a href="https://doi.org/10.17487/RFC5280">https://doi.org/10.17487/RFC5280</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-rfc9325" name="ref-rfc9325">[RFC9325]</a> Sheffer Y, Saint-Andre P, Fossati T (2022) Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 9325. <a href="https://doi.org/10.17487/RFC9325">https://doi.org/10.17487/RFC9325</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-Section508" name="ref-Section508">[Section508]</a> Section 508 of the Rehabilitation Act of 1973 (2011), 29 U.S.C. § 794(d). <a href="https://www.govinfo.gov/content/pkg/USCODE-2011-title29/html/USCODE-2011-title29-chap16-subchapV-sec794d.htm">https://www.govinfo.gov/content/pkg/USCODE-2011-title29/html/USCODE-2011-title29-chap16-subchapV-sec794d.htm</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-SP800-30" name="ref-SP800-30">[SP800-30]</a> Blank R, Gallagher P (2012) Guide for Conducting Risk Assessments. (National Institute of Standards and Technology, Gaithersburg, MD) NIST Special Publication (SP) 800-30 Revision 1. <a href="https://doi.org/10.6028/NIST.SP.800-30r1">https://doi.org/10.6028/NIST.SP.800-30r1</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-SP800-52" name="ref-SP800-52">[SP800-52]</a> McKay K, Cooper D (2019) Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. (National Institute of Standards and Technology), NIST Special Publication (SP) 800-52 Rev. 2. <a href="https://doi.org/10.6028/NIST.SP.800-52r2">https://doi.org/10.6028/NIST.SP.800-52r2</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-SP800-53" name="ref-SP800-53">[SP800-53]</a> Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53 Rev. 5, Includes updates as of December 10, 2020. <a href="https://doi.org/10.6028/NIST.SP.800-53r5">https://doi.org/10.6028/NIST.SP.800-53r5</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-SP800-57P1" name="ref-SP800-57P1">[SP800-57Part1]</a> Barker EB (2020) Recommendation for Key Management: Part 1 – General. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-57 Part 1, Rev. 5. <a href="https://doi.org/10.6028/NIST.SP.800-57pt1r5">https://doi.org/10.6028/NIST.SP.800-57pt1r5</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-SP800-63A" name="ref-SP800-63A">[SP800-63A]</a> Temoshok D, Abruzzi C, Choong YY, Fenton JL, Galluzzo R, LaSalle C, Lefkovitz N, Regenscheid A (2024) Digital Identity Guidelines: Identity Proofing and Enrollment. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-63A-4 2pd. <a href="https://doi.org/10.6028/NIST.SP.800-63a-4.2pd">https://doi.org/10.6028/NIST.SP.800-63a-4.2pd</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-SP800-63B" name="ref-SP800-63B">[SP800-63B]</a> Temoshok D, Fenton JL, Choong YY, Lefkovitz N, Regenscheid A, Galluzzo R, Richer JP (2024) Digital Identity Guidelines: Authentication and Authenticator Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-63B-4 ipd. <a href="https://doi.org/10.6028/NIST.SP.800-63b-4.2pd">https://doi.org/10.6028/NIST.SP.800-63b-4.2pd</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-SP800-63C" name="ref-SP800-63C">[SP800-63C]</a> Temoshok D, Richer JP, Choong YY, Fenton JL, Lefkovitz N, Regenscheid A, Galluzzo R (2024) Digital Identity Guidelines: Federation and Assertions. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-63C-4 2pd. <a href="https://doi.org/10.6028/NIST.SP.800-63c-4.2pd">https://doi.org/10.6028/NIST.SP.800-63c-4.2pd</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-SP800-122" name="ref-SP800-122">[SP800-122]</a> McCallister E, Grance T, Scarfone KA (2010) Guide to Protecting the Confidentiality of Personally Identifiable Information (PII). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-122. <a href="https://doi.org/10.6028/NIST.SP.800-122">https://doi.org/10.6028/NIST.SP.800-122</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-SP1270" name="ref-SP1270">[SP1270]</a> Schwartz R, Vassilev A, Greene K, Perine L, Burt A, Hall P (2022) Towards a standard for identifying and managing bias in artificial intelligence. (National Institute of Standards and Technology (U.S.), Gaithersburg, MD), NIST SP 1270. <a href="https://doi.org/10.6028/NIST.SP.1270">https://doi.org/10.6028/NIST.SP.1270</a></p>

<p><a href="/800-63-4/sp800-63/references/#ref-US-AI-Safety-Inst" name="ref-US-AI-Safety-Inst">[US-AI-Safety-Inst]</a> U.S. Artificial Intelligence Safety Institute (2023) NIST. Available at <a href="https://www.nist.gov/aisi">https://www.nist.gov/aisi</a></p>

<h1 id="abbr" data-section="A">
  
  
    List of Symbols, Abbreviations, and Acronyms <a href="#abbr" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<dl>
  <dt>1:1 Comparison</dt>
  <dd>One-to-One Comparison</dd>
  <dt>ABAC</dt>
  <dd>Attribute-Based Access Control</dd>
  <dt>AAL</dt>
  <dd>Authentication Assurance Level</dd>
  <dt>CAPTCHA</dt>
  <dd>Completely Automated Public Turing test to tell Computers and Humans Apart</dd>
  <dt>CSP</dt>
  <dd>Credential Service Provider</dd>
  <dt>CSRF</dt>
  <dd>Cross-Site Request Forgery</dd>
  <dt>XSS</dt>
  <dd>Cross-Site Scripting</dd>
  <dt>DNS</dt>
  <dd>Domain Name System</dd>
  <dt>FACT Act</dt>
  <dd>Fair and Accurate Credit Transaction Act of 2003</dd>
  <dt>FAL</dt>
  <dd>Federation Assurance Level</dd>
  <dt>FEDRAMP</dt>
  <dd>Federal Risk and Authorization Management Program</dd>
  <dt>FMR</dt>
  <dd>False Match Rate</dd>
  <dt>FNMR</dt>
  <dd>False Non-Match Rate</dd>
  <dt>IAL</dt>
  <dd>Identity Assurance Level</dd>
  <dt>IdP</dt>
  <dd>Identity Provider</dd>
  <dt>JOSE</dt>
  <dd>JSON Object Signing and Encryption</dd>
  <dt>JWT</dt>
  <dd>JSON Web Token</dd>
  <dt>KBA</dt>
  <dd>Knowledge-Based Authentication</dd>
  <dt>KBV</dt>
  <dd>Knowledge-Based Verification</dd>
  <dt>KDC</dt>
  <dd>Key Distribution Center</dd>
  <dt>MAC</dt>
  <dd>Message Authentication Code</dd>
  <dt>MFA</dt>
  <dd>Multi-Factor Authentication</dd>
  <dt>NARA</dt>
  <dd>National Archives and Records Administration</dd>
  <dt>OTP</dt>
  <dd>One-Time Password</dd>
  <dt>PAD</dt>
  <dd>Presentation Attack Detection</dd>
  <dt>PIA</dt>
  <dd>Privacy Impact Assessment</dd>
  <dt>PII</dt>
  <dd>Personally Identifiable Information</dd>
  <dt>PIN</dt>
  <dd>Personal Identification Number</dd>
  <dt>PKI</dt>
  <dd>Public Key Infrastructure</dd>
  <dt>PSTN</dt>
  <dd>Public Switched Telephone Network</dd>
  <dt>RMF</dt>
  <dd>Risk Management Framework</dd>
  <dt>RP</dt>
  <dd>Relying Party</dd>
  <dt>SA&amp;A</dt>
  <dd>Security Authorization &amp; Accreditation</dd>
  <dt>SAML</dt>
  <dd>Security Assertion Markup Language</dd>
  <dt>SAOP</dt>
  <dd>Senior Agency Official for Privacy</dd>
  <dt>SSL</dt>
  <dd>Secure Sockets Layer</dd>
  <dt>SSO</dt>
  <dd>Single Sign-On</dd>
  <dt>SMS</dt>
  <dd>Short Message Service</dd>
  <dt>SORN</dt>
  <dd>System of Records Notice</dd>
  <dt>TEE</dt>
  <dd>Trusted Execution Environment</dd>
  <dt>TLS</dt>
  <dd>Transport Layer Security</dd>
  <dt>TPM</dt>
  <dd>Trusted Platform Module</dd>
  <dt>TTP</dt>
  <dd>Tactics, Techniques, and Procedures</dd>
  <dt>VOIP</dt>
  <dd>Voice-Over-IP</dd>
  <dt>XSS</dt>
  <dd>Cross-Site Scripting</dd>
</dl>

<h1 id="def" data-section="B">
  
  
    Glossary <a href="#def" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<p><em>This section is informative.</em></p>

<p>A wide variety of terms are used in the realm of digital identity. While many definitions are consistent with earlier versions of SP 800-63, some have changed in this revision. Many of these terms lack a single, consistent definition, warranting careful attention to how the terms are defined here.</p>

<dl>
  <dt>account linking</dt>
  <dd>The association of multiple <em>federated identifiers</em> with a single <em>RP subscriber account</em>, or the management of those associations.</dd>
  <dt>account recovery</dt>
  <dd>The ability to regain ownership of a <em>subscriber account</em> and its associated information and privileges.</dd>
  <dt>account resolution</dt>
  <dd>The association of an <em>RP subscriber account</em> with information already held by the <em>RP</em> prior to the <em>federation transaction</em> and outside of a <em>trust agreement</em>.</dd>
  <dt>activation</dt>
  <dd>The process of inputting an <em>activation factor</em> into a <em>multi-factor authenticator</em> to enable its use for <em>authentication</em>.</dd>
  <dt>activation factor</dt>
  <dd>An additional <em>authentication factor</em> that is used to enable successful <em>authentication</em> with a <em>multi-factor authenticator</em>.</dd>
  <dt>activation secret</dt>
  <dd>A <em>password</em> that is used locally as an <em>activation factor</em> for a <em>multi-factor authenticator</em>.</dd>
  <dt>allowlist</dt>
  <dd>A documented list of specific elements that are allowed, per policy decision. In <em>federation</em> contexts, this is most commonly used to refer to the list of <em>RPs</em> allowed to connect to an <em>IdP</em> without subscriber intervention. This concept has historically been known as a <em>whitelist</em>.</dd>
  <dt>applicant</dt>
  <dd>A <em>subject</em> undergoing the processes of <em>identity proofing</em> and <em>enrollment</em>.</dd>
</dl>

<div latex-literal="true" class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>\clearpage
</code></pre></div></div>

<dl>
  <dt>applicant reference</dt>
  <dd>A representative of the <em>applicant</em> who can vouch for the identity of the applicant, specific <em>attributes</em> related to the applicant, or conditions relative to the context of the individual (e.g., emergency status, homelessness).</dd>
  <dt>approved cryptography</dt>
  <dd>An encryption algorithm, <em>hash function</em>, random bit generator, or similar technique that is <em>Federal Information Processing Standard</em> (FIPS)-approved or NIST-recommended. Approved algorithms and techniques are either specified or adopted in a FIPS or NIST recommendation.</dd>
  <dt>assertion</dt>
  <dd>A statement from an <em>IdP</em> to an <em>RP</em> that contains information about an authentication event for a subscriber. Assertions can also contain identity <em>attributes</em> for the subscriber.</dd>
  <dt>assertion reference</dt>
  <dd>A data object, created in conjunction with an <em>assertion</em>, that is used by the <em>RP</em> to retrieve an assertion over an <em>authenticated</em> protected channel.</dd>
  <dt>assertion presentation</dt>
  <dd>The method by which an <em>assertion</em> is transmitted to the <em>RP</em>.</dd>
  <dt>asymmetric keys</dt>
  <dd>Two related keys, comprised of a <em>public key</em> and a <em>private key</em>, that are used to perform complementary operations such as encryption and decryption or signature <em>verification</em> and generation.</dd>
  <dt>attestation</dt>
  <dd>Information conveyed to the <em>CSP</em>, generally at the time that an <em>authenticator</em> is bound, describing the characteristics of a connected authenticator or the <em>endpoint</em> involved in an authentication operation.</dd>
  <dt>attribute</dt>
  <dd>A quality or characteristic ascribed to someone or something. An identity attribute is an attribute about the identity of a subscriber.</dd>
  <dt>attribute bundle</dt>
  <dd>A package  of <em>attribute values</em> and <em>derived attribute values</em> from a <em>CSP</em>. The package has necessary cryptographic protection to allow <em>validation</em> of the bundle independent from interaction with the CSP or <em>IdP</em>. Attribute bundles are often used with subscriber-controlled wallets.</dd>
  <dt>attribute provider</dt>
  <dd>The provider of an <em>identity API</em> that provides access to a subscriber’s attributes without necessarily asserting that the subscriber is present to the <em>RP</em>.</dd>
  <dt>attribute validation</dt>
  <dd>The process or act of confirming that a set of attributes are accurate and associated with a real-life identity. See <em>validation</em>.</dd>
  <dt>attribute value</dt>
  <dd>A complete statement that asserts an identity attribute of a subscriber, independent of format. For example, for the <em>attribute</em> “birthday,” a value could be “12/1/1980” or “December 1, 1980.”</dd>
  <dt>audience restriction</dt>
  <dd>The restriction of a message to a specific target audience to prevent a receiver from unknowingly <em>processing</em> a message intended for another recipient. In <em>federation protocols</em>, <em>assertions</em> are audience <em>restricted</em> to specific <em>RPs</em> to prevent an RP from accepting an assertion generated for a different RP.</dd>
  <dt>authenticate</dt>
  <dd>See <em>authentication</em>.</dd>
  <dt>authenticated protected channel</dt>
  <dd>An encrypted communication channel that uses <em>approved cryptography</em> where the connection initiator (client) has authenticated the recipient (server). Authenticated protected channels are encrypted to provide confidentiality and protection against active intermediaries and are frequently used in the user <em>authentication</em> process. <em>Transport Layer Security</em> (TLS) and Datagram Transport Layer Security (DTLS) <a href="/800-63-4/sp800-63/references/#ref-rfc9325">[RFC9325]</a> are examples of authenticated protected channels in which the certificate presented by the recipient is verified by the initiator. Unless otherwise specified, authenticated protected channels do not require the server to authenticate the client. Authentication of the server is often accomplished through a certificate chain that leads to a trusted root rather than individually with each server.</dd>
  <dt>authenticated session</dt>
  <dd>See <em>protected session</em>.</dd>
  <dt>authentication</dt>
  <dd>The process by which a <em>claimant</em> proves possession and control of one or more <em>authenticators</em> bound to a <em>subscriber account</em> to demonstrate that they are the subscriber associated with that account.</dd>
  <dt>Authentication Assurance Level (AAL)</dt>
  <dd>A category that describes the strength of the authentication process.</dd>
  <dt>authentication factor</dt>
  <dd>The three types of authentication factors are <em>something you know</em>, <em>something you have</em>, and <em>something you are</em>. Every <em>authenticator</em> has one or more authentication factors.</dd>
  <dt>authentication intent</dt>
  <dd>The process of confirming the <em>claimant’s</em> intent to <em>authenticate</em> or reauthenticate by requiring user intervention in the authentication flow. Some <em>authenticators</em> (e.g., OTPs) establish authentication intent as part of their operation. Others require a specific step, such as pressing a button, to establish intent. Authentication intent is a countermeasure against use by malware at the <em>endpoint</em> as a proxy for authenticating an attacker without the subscriber’s knowledge.</dd>
  <dt>authentication protocol</dt>
  <dd>A defined sequence of messages between a <em>claimant</em> and a <em>verifier</em> that demonstrates that the claimant has possession and control of one or more valid <em>authenticators</em> to establish their identity, and, optionally, demonstrates that the claimant is communicating with the intended verifier.</dd>
  <dt>authentication secret</dt>
  <dd>A generic term for any secret value that an attacker could use to impersonate the subscriber in an <em>authentication protocol</em>.

    <p>These are further divided into <em>short-term authentication secrets</em>, which are only useful to an attacker for a limited period of time, and <em>long-term authentication secrets</em>, which allow an attacker to impersonate the subscriber until they are manually reset. The <em>authenticator</em> secret is the canonical example of a long-term authentication secret, while the <em>authenticator output</em> — if it is different from the <em>authenticator secret</em> — is usually a short-term authentication secret.</p>
  </dd>
  <dt>authenticator</dt>
  <dd>Something that the subscriber possesses and controls (e.g., a <em>cryptographic module</em> or <em>password</em>) and that is used to <em>authenticate</em> a <em>claimant’s</em> identity. See <em>authenticator type</em> and <em>multi-factor authenticator</em>.</dd>
  <dt>authenticator binding</dt>
  <dd>The establishment of an association between a specific <em>authenticator</em> and a <em>subscriber account</em> that allows the <em>authenticator</em> to be used to <em>authenticate</em> for that subscriber account, possibly in conjunction with other authenticators.</dd>
  <dt>authenticator output</dt>
  <dd>The output value generated by an <em>authenticator</em>. The ability to generate valid authenticator outputs on demand proves that the <em>claimant</em> possesses and controls the authenticator. Protocol messages sent to the <em>verifier</em> depend on the authenticator output, but they may or may not explicitly contain it.</dd>
  <dt>authenticator secret</dt>
  <dd>The secret value contained within an <em>authenticator</em>.</dd>
  <dt>authenticator type</dt>
  <dd>A category of <em>authenticators</em> with common characteristics, such as the types of <em>authentication factors</em> they provide and the mechanisms by which they operate.</dd>
  <dt>authenticity</dt>
  <dd>The property that data originated from its purported source.</dd>
  <dt>authoritative source</dt>
  <dd>An entity that has access to or verified copies of accurate information from an <em>issuing source</em> such that a <em>CSP</em> has high confidence that the source can confirm the validity of the identity attributes or evidence supplied by an <em>applicant</em> during <em>identity proofing</em>. 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 identity proofing <em>validation</em> phase.</dd>
  <dt>authorize</dt>
  <dd>A decision to grant access, typically automated by evaluating a <em>subject</em>’s <em>attributes</em>.</dd>
  <dt>authorized party</dt>
  <dd>In <em>federation</em>, the organization, person, or entity that is responsible for making decisions regarding the release of information within the <em>federation transaction</em>, most notably subscriber <em>attributes</em>. This is often the subscriber (when runtime decisions are used) or the party operating the <em>IdP</em> (when <em>allowlists</em> are used).</dd>
  <dt>back-channel communication</dt>
  <dd>Communication between two systems that relies on a direct connection without using redirects through an intermediary such as a browser.</dd>
  <dt>bearer assertion</dt>
  <dd>An <em>assertion</em> that can be presented on its own as proof of the identity of the presenter.</dd>
</dl>

<div latex-literal="true" class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>\clearpage
</code></pre></div></div>

<dl>
  <dt>biometric reference</dt>
  <dd>One or more stored <em>biometric samples</em>, templates, or models attributed to an individual and used as the object of biometric comparison in a database, such as a facial image stored digitally on a passport, fingerprint minutiae template on a National ID card or Gaussian Mixture Model for speaker recognition.</dd>
  <dt>biometric sample</dt>
  <dd>An analog or digital representation of biometric characteristics prior to biometric feature extraction, such as a record that contains a fingerprint image.</dd>
  <dt>biometrics</dt>
  <dd>Automated recognition of individuals based on their biological or behavioral characteristics. Biological characteristics include but are not limited to fingerprints, palm prints, facial features, iris and retina patterns, voiceprints, and vein patterns. Behavioral characteristics include but are not limited to keystrokes, angle of holding a smart phone, screen pressure, typing speed, mouse or mobile phone movements, and gyroscope position.</dd>
  <dt>blocklist</dt>
  <dd>A documented list of specific elements that are blocked, per policy decision. This concept has historically been known as a <em>blacklist</em>.</dd>
  <dt>challenge-response protocol</dt>
  <dd>An <em>authentication protocol</em> in which the <em>verifier</em> sends the <em>claimant</em> a challenge (e.g., a random value or <em>nonce</em>) that the claimant combines with a secret (e.g., by hashing the challenge and a <em>shared secret</em> together or by applying a <em>private-key</em> operation to the challenge) to generate a response that is sent to the verifier. The verifier can independently verify the response generated by the claimant (e.g., by re-computing the hash of the challenge and the shared secret and comparing to the response or performing a public-key operation on the response) and establish that the claimant possesses and controls the secret.</dd>
  <dt>claimant</dt>
  <dd>A <em>subject</em> whose identity is to be verified using one or more <em>authentication protocols</em>.</dd>
  <dt>claimed address</dt>
  <dd>The physical location asserted by a <em>subject</em> where they can be reached. It includes the individual’s residential street address and may also include their mailing address.</dd>
  <dt>claimed identity</dt>
  <dd>An <em>applicant’s</em> declaration of unvalidated and unverified personal <em>attributes</em>.</dd>
  <dt>compensating controls</dt>
  <dd>Alternative <em>controls</em> to the normative controls for the assessed and selected xALs of an organization based on that organization’s mission, risk tolerance, business processes, and <em>risk assessments</em> and considerations for the privacy, <em>usability</em>, and <em>equity</em> of the populations served by the <em>online service</em>.</dd>
  <dt>controls</dt>
  <dd>Policies, procedures, guidelines, practices, or organizational structures that manage security, privacy, and other risks.
See <em>supplemental controls</em> and <em>compensating controls</em></dd>
  <dt>core attributes</dt>
  <dd>The set of identity <em>attributes</em> that the <em>CSP</em> has determined and documented to be required for <em>identity proofing</em>.</dd>
  <dt>credential</dt>
  <dd>An object or data structure that authoritatively binds an identity — via an <em>identifier</em> — and (optionally) additional <em>attributes</em>, to at least one <em>authenticator</em> possessed and controlled by a subscriber.

    <p>A credential is issued, stored, and maintained by the <em>CSP</em>. Copies of information from the credential can be possessed by the subscriber, typically in the form of one or more digital certificates that are often contained in an authenticator along with their associated <em>private keys</em>.</p>
  </dd>
  <dt>credential service provider (CSP)</dt>
  <dd>A trusted entity whose functions include <em>identity proofing</em> <em>applicants</em> to the identity service and registering <em>authenticators</em> to <em>subscriber accounts</em>. A CSP may be an independent third party.</dd>
  <dt>credible source</dt>
  <dd>An entity that can provide or validate the accuracy of <em>identity evidence</em> and <em>attribute</em> information. A credible source has access to attribute information that was validated through an <em>identity proofing</em> process or that can be traced to an <em>authoritative source</em>, or it maintains identity attribute information obtained from multiple sources that is checked for data correlation for accuracy, consistency, and currency.</dd>
  <dt>cross-site request forgery (CSRF)</dt>
  <dd>An attack in which a subscriber who is currently <em>authenticated</em> to an <em>RP</em> and connected through a secure session browses an attacker’s website, causing the subscriber to unknowingly invoke unwanted actions at the RP.

    <p>For example, if a bank website is vulnerable to a CSRF attack, it may be possible for a subscriber to unintentionally <em>authorize</em> a large money transfer by clicking on a malicious link in an email while a connection to the bank is open in another browser window.</p>
  </dd>
  <dt>cross-site scripting (XSS)</dt>
  <dd>A vulnerability that allows attackers to inject malicious code into an otherwise benign website. These scripts acquire the permissions of scripts generated by the target website to compromise the confidentiality and integrity of data transfers between the website and clients. Websites are vulnerable if they display user-supplied data from requests or forms without sanitizing the data so that it is not executable.</dd>
  <dt>cryptographic authenticator</dt>
  <dd>An <em>authenticator</em> that proves possession of an <em>authentication secret</em> through direct communication with a <em>verifier</em> through a cryptographic <em>authentication protocol</em>.</dd>
  <dt>cryptographic key</dt>
  <dd>A value used to control cryptographic operations, such as decryption, encryption, signature generation, or signature <em>verification</em>. For the purposes of these guidelines, key requirements shall meet the minimum requirements stated in Table 2 of <a href="/800-63-4/sp800-63/references/#ref-SP800-57P1">[SP800-57Part1]</a>. See <em>asymmetric keys</em> or <em>symmetric keys</em>.</dd>
  <dt>cryptographic module</dt>
  <dd>A set of hardware, software, or firmware that implements approved security functions including cryptographic algorithms and key generation.</dd>
  <dt>data integrity</dt>
  <dd>The property that data has not been altered by an unauthorized entity.</dd>
  <dt>derived attribute value</dt>
  <dd>A statement that asserts a limited identity <em>attribute</em> of a subscriber without containing the attribute value from which it is derived, independent of format. For example, instead of requesting the attribute “birthday,” a derived value could be “older than 18”. Instead of requesting the attribute for “physical address,” a derived value could be “currently residing in this district.” Previous versions of these guidelines referred to this construct as an “attribute reference.”</dd>
  <dt>digital authentication</dt>
  <dd>The process of establishing confidence in user identities that are digitally presented to a system. In previous editions of SP 800-63, this was referred to as electronic authentication.</dd>
  <dt>digital identity</dt>
  <dd>An <em>attribute</em> or set of attributes that uniquely describes a <em>subject</em> within a given context.</dd>
  <dt>Digital Identity Acceptance Statement (DIAS)</dt>
  <dd>Documents the results of the <em>digital identity</em> <em>risk management</em> process. This includes the impact assessment, initial assurance level selection, and <em>tailoring</em> process.</dd>
  <dt>digital signature</dt>
  <dd>An <em>asymmetric key</em> operation in which the <em>private key</em> is used to digitally sign data and the <em>public key</em> is used to verify the signature. Digital signatures provide <em>authenticity</em> protection, integrity protection, and <em>non-repudiation</em> support but not confidentiality or <em>replay attack</em> protection.</dd>
  <dt>digital transaction</dt>
  <dd>A discrete digital event between a user and a system that supports a business or programmatic purpose.</dd>
  <dt>disassociability</dt>
  <dd>Enabling the <em>processing</em> of PII or events without association to individuals or devices beyond the operational requirements of the system. <a href="/800-63-4/sp800-63/references/#ref-NISTIR8062">[NISTIR8062]</a></dd>
  <dt>electronic authentication (e-authentication)</dt>
  <dd>See <em>digital authentication</em>.</dd>
  <dt>endpoint</dt>
  <dd>Any device that is used to access a <em>digital identity</em> on a <em>network</em>, such as laptops, desktops, mobile phones, tablets, servers, Internet of Things devices, and virtual environments.</dd>
  <dt>enrollment</dt>
  <dd>The process through which a <em>CSP</em>/<em>IdP</em> provides a successfully identity-proofed <em>applicant</em> with a <em>subscriber account</em> and binds <em>authenticators</em> to grant persistent access.</dd>
  <dt>entropy</dt>
  <dd>The amount of uncertainty that an attacker faces to determine the value of a secret. Entropy is usually stated in bits. A value with <em>n</em> bits of entropy has the same degree of uncertainty as a uniformly distributed <em>n</em>-bit random value.</dd>
  <dt>equity</dt>
  <dd>The consistent and systematic fair, just, and impartial treatment of all individuals, including individuals who belong to underserved communities that have been denied such treatment, such as Black, Latino, and Indigenous and Native American persons, Asian Americans and Pacific Islanders, and other persons of color; members of religious minorities; lesbian, gay, bisexual, transgender, and queer (LGBTQ+) persons; persons with disabilities; persons who live in rural areas; and persons otherwise adversely affected by persistent poverty or inequality. <a href="/800-63-4/sp800-63/references/#ref-EO13985">[EO13985]</a></dd>
  <dt>factor</dt>
  <dd>See <em>authentication factor</em></dd>
  <dt>Federal Information Processing Standard (FIPS)</dt>
  <dd>Under the Information Technology Management Reform Act (Public Law 104-106), the Secretary of Commerce approves the standards and guidelines that the National Institute of Standards and Technology (NIST) develops for federal computer systems. NIST issues these standards and guidelines as Federal Information Processing Standards (FIPS) for government-wide use. 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.

    <p>FIPS documents are available online on the FIPS home page: <a href="https://www.nist.gov/itl/fips.cfm">https://www.nist.gov/itl/fips.cfm</a></p>
  </dd>
  <dt>federated identifier</dt>
  <dd>The combination of a <em>subject identifier</em> within an <em>assertion</em> and an <em>identifier</em> for the <em>IdP</em> that issued that assertion. When combined, these pieces of information uniquely identify the <em>subscriber</em> in the context of a <em>federation transaction</em>.</dd>
  <dt>federation</dt>
  <dd>A process that allows for the conveyance of identity and authentication information across a set of <em>networked</em> systems.</dd>
  <dt>Federation Assurance Level (FAL)</dt>
  <dd>A category that describes the process used in a <em>federation transaction</em> to communicate authentication events and subscriber <em>attributes</em> to an <em>RP</em>.</dd>
  <dt>federation protocol</dt>
  <dd>A technical protocol that is used in a <em>federation transaction</em> between <em>networked</em> systems.</dd>
  <dt>federation proxy</dt>
  <dd>A component that acts as a logical <em>RP</em> to a set of <em>IdPs</em> and a logical IdP to a set of RPs, bridging the two systems with a single component. These are sometimes referred to as “brokers.”</dd>
  <dt>federation transaction</dt>
  <dd>A specific instance of <em>processing</em> an authentication using a <em>federation</em> process for a specific <em>subscriber</em> by conveying an <em>assertion</em> from an <em>IdP</em> to an <em>RP</em>.</dd>
  <dt>front-channel communication</dt>
  <dd>Communication between two systems that relies on passing messages through an intermediary, such as using redirects through the subscriber’s browser.</dd>
  <dt>hash function</dt>
  <dd>A function that maps a bit string of arbitrary length to a fixed-length bit string. Approved hash functions satisfy the following properties:

    <ol>
      <li>
        <p>One-way — It is computationally infeasible to find any input that maps to any pre-specified output.</p>
      </li>
      <li>
        <p>Collision-resistant — It is computationally infeasible to find any two distinct inputs that map to the same output.</p>
      </li>
    </ol>
  </dd>
  <dt>identifier</dt>
  <dd>A data object that is associated with a single, unique entity (e.g., individual, device, or <em>session</em>) within a given context and is never assigned to any other entity within that context.</dd>
  <dt>identity</dt>
  <dd>See <em>digital identity</em></dd>
  <dt>identity API</dt>
  <dd>A protected API accessed by an <em>RP</em> to access the <em>attributes</em> of a specific subscriber.</dd>
  <dt>Identity Assurance Level (IAL)</dt>
  <dd>A category that conveys the degree of confidence that the <em>subject</em>’s <em>claimed identity</em> is their real identity.</dd>
  <dt>identity evidence</dt>
  <dd>Information or documentation that supports the real-world existence of the <em>claimed identity</em>. Identity evidence may be physical (e.g., a driver’s license) or digital (e.g., a mobile driver’s license or digital <em>assertion</em>). Evidence must support both <em>validation</em> (i.e., confirming <em>authenticity</em> and accuracy) and <em>verification</em> (i.e., confirming that the <em>applicant</em> is the true owner of the evidence).</dd>
  <dt>identity proofing</dt>
  <dd>The processes used to collect, validate, and verify information about a <em>subject</em> to establish assurance in the subject’s <em>claimed identity</em>.</dd>
  <dt>identity provider (IdP)</dt>
  <dd>The party in a <em>federation transaction</em> that creates an <em>assertion</em> for the subscriber and transmits the assertion to the <em>RP</em>.</dd>
  <dt>identity resolution</dt>
  <dd>The process of collecting information about an <em>applicant</em> to uniquely distinguish an individual within the context of the population that the <em>CSP</em> serves.</dd>
  <dt>identity verification</dt>
  <dd>See <em>verification</em></dd>
  <dt>injection attack</dt>
  <dd>An attack in which an attacker supplies untrusted input to a program. In the context of federation, the attacker presents an untrusted <em>assertion</em> or <em>assertion reference</em> to the <em>RP</em> in order to create an <em>authenticated</em> <em>session</em> with the RP.</dd>
  <dt>issuing source</dt>
  <dd>An authority responsible for the generation of data, digital evidence (i.e., <em>assertions</em>), or physical documents that can be used as <em>identity evidence</em>.</dd>
  <dt>knowledge-based verification (KBV)</dt>
  <dd>A process of validating knowledge of personal or private information associated with an individual for the purpose of verifying the <em>claimed identity</em> of an <em>applicant</em>. KBV does not include collecting personal <em>attributes</em> for the purposes of <em>identity resolution</em>.</dd>
  <dt>legal person</dt>
  <dd>An individual, organization, or company with legal rights.</dd>
  <dt>login</dt>
  <dd>Establishment of an <em>authenticated</em> <em>session</em> between a person and a system. Also known as <em>“sign in”</em>, <em>“log on”</em>, and <em>“sign on.”</em></dd>
  <dt>manageability</dt>
  <dd>Providing the capability for the granular administration of <em>personally identifiable information</em>, including alteration, deletion, and selective disclosure. <a href="/800-63-4/sp800-63/references/#ref-NISTIR8062">[NISTIR8062]</a></dd>
  <dt>memorized secret</dt>
  <dd>See <em>password</em>.</dd>
  <dt>message authentication code (MAC)</dt>
  <dd>A cryptographic checksum on data that uses a <em>symmetric key</em> to detect both accidental and intentional modifications of the data. MACs provide <em>authenticity</em> and integrity protection, but not <em>non-repudiation</em> protection.</dd>
  <dt>mobile code</dt>
  <dd>Executable code that is normally transferred from its source to another computer system for execution. This transfer is often through the <em>network</em> (e.g., JavaScript embedded in a web page) but may transfer through physical media as well.</dd>
  <dt>multi-factor authentication (MFA)</dt>
  <dd>An authentication system that requires more than one distinct type of <em>authentication factor</em> for successful authentication. MFA can be performed using a <em>multi-factor authenticator</em> or by combining <em>single-factor</em> authenticators that provide different types of factors.</dd>
  <dt>multi-factor authenticator</dt>
  <dd>An <em>authenticator</em> that provides more than one distinct <em>authentication factor</em>, such as a cryptographic authentication device with an integrated biometric sensor that is required to activate the device.</dd>
  <dt>natural person</dt>
  <dd>A real-life human being, not synthetic or artificial.</dd>
  <dt>network</dt>
  <dd>An open communications medium, typically the Internet, used to transport messages between the <em>claimant</em> and other parties. Unless otherwise stated, no assumptions are made about the network’s security; it is assumed to be open and subject to active (e.g., impersonation, <em>session</em> hijacking) and passive (e.g., eavesdropping) attacks at any point between the parties (e.g., claimant, <em>verifier</em>, <em>CSP</em>, <em>RP</em>).</dd>
  <dt>nonce</dt>
  <dd>A value used in security protocols that is never repeated with the same key. For example, nonces used as challenges in <em>challenge-response authentication protocols</em> must not be repeated until authentication keys are changed. Otherwise, there is a possibility of a <em>replay attack</em>. Using a nonce as a challenge is a different requirement than a random challenge, because a nonce is not necessarily unpredictable.</dd>
  <dt>non-repudiation</dt>
  <dd>The capability to protect against an individual falsely denying having performed a particular transaction.</dd>
  <dt>offline attack</dt>
  <dd>An attack in which the attacker obtains some data (typically by eavesdropping on an authentication transaction or by penetrating a system and stealing security files) that the attacker is able to analyze in a system of their own choosing.</dd>
  <dt>one-to-one (1:1) comparison</dt>
  <dd>The process in which a <em>biometric sample</em> from an individual is compared to a <em>biometric reference</em> to produce a comparison score.</dd>
  <dt>online attack</dt>
  <dd>An attack against an <em>authentication protocol</em> in which the attacker either assumes the role of a <em>claimant</em> with a genuine <em>verifier</em> or actively alters the authentication channel.</dd>
  <dt>online guessing attack</dt>
  <dd>An attack in which an attacker performs repeated logon trials by guessing possible values of the <em>authenticator</em> output.</dd>
  <dt>online service</dt>
  <dd>A service that is accessed remotely via a <em>network</em>, typically the internet.</dd>
  <dt>pairwise pseudonymous identifier</dt>
  <dd>A <em>pseudonymous identifier</em> generated by an IdP for use at a specific <em>RP</em>.</dd>
  <dt>passphrase</dt>
  <dd>A <em>password</em> that consists of a sequence of words or other text that a <em>claimant</em> uses to <em>authenticate</em> their identity. A passphrase is similar to a password in usage but is generally longer for added security.</dd>
  <dt>password</dt>
  <dd>A type of <em>authenticator</em> consisting of a character string that is intended to be memorized or memorable by the subscriber to permit the <em>claimant</em> to demonstrate <em>something they know</em> as part of an authentication process. Passwords are referred to as <em>memorized secrets</em> in the initial release of SP 800-63B.</dd>
  <dt>personal identification number (PIN)</dt>
  <dd>A <em>password</em> that typically consists of only decimal digits.</dd>
  <dt>personal information</dt>
  <dd>See <em>personally identifiable information</em>.</dd>
  <dt>personally identifiable information (PII)</dt>
  <dd>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. <a href="/800-63-4/sp800-63/references/#ref-A-130">[A-130]</a></dd>
  <dt>personally identifiable information processing</dt>
  <dd>An operation or set of operations performed upon <em>personally identifiable information</em> that can include the collection, retention, logging, generation, transformation, use, disclosure, transfer, or disposal of personally identifiable information.</dd>
  <dt>pharming</dt>
  <dd>An attack in which an attacker corrupts an infrastructure service such as DNS (e.g., Domain Name System [DNS]) and causes the subscriber to be misdirected to a forged <em>verifier</em>/<em>RP</em>, which could cause the subscriber to reveal sensitive information, download harmful software, or contribute to a fraudulent act.</dd>
  <dt>phishing</dt>
  <dd>An attack in which the subscriber is lured (usually through an email) to interact with a counterfeit <em>verifier</em>/<em>RP</em> and tricked into revealing information that can be used to masquerade as that subscriber to the real verifier/RP.</dd>
  <dt>phishing resistance</dt>
  <dd>The ability of the <em>authentication protocol</em> to prevent the disclosure of <em>authentication secrets</em> and valid <em>authenticator</em> outputs to an impostor <em>verifier</em> without reliance on the vigilance of the <em>claimant</em>.</dd>
  <dt>physical authenticator</dt>
  <dd>An <em>authenticator</em> that the <em>claimant</em> proves possession of as part of an authentication process.</dd>
  <dt>possession and control of an authenticator</dt>
  <dd>The ability to activate and use the <em>authenticator</em> in an <em>authentication protocol</em>.</dd>
  <dt>practice statement</dt>
  <dd>A formal statement of the practices followed by the parties to an authentication process (e.g., <em>CSP</em> or <em>verifier</em>). It usually describes the parties’ policies and practices and can become legally binding.</dd>
  <dt>predictability</dt>
  <dd>Enabling reliable assumptions by individuals, owners, and operators about PII and its <em>processing</em> by an information system. <a href="/800-63-4/sp800-63/references/#ref-NISTIR8062">[NISTIR8062]</a></dd>
  <dt>private key</dt>
  <dd>In <em>asymmetric key</em> cryptography, the private key (i.e., a secret key) is a mathematical key used to create <em>digital signatures</em> and, depending on the algorithm, decrypt messages or files that are encrypted with the corresponding <em>public key</em>. In <em>symmetric key</em> cryptography, the same private key is used for both encryption and decryption.</dd>
  <dt>processing</dt>
  <dd>Operation or set of operations performed upon PII that can include, but is not limited to, the collection, retention, logging, generation, transformation, use, disclosure, transfer, and disposal of PII. <a href="/800-63-4/sp800-63/references/#ref-NISTIR8062">[NISTIR8062]</a></dd>
  <dt>presentation attack</dt>
  <dd>Presentation to the biometric data capture subsystem with the goal of interfering with the operation of the biometric system.</dd>
  <dt>presentation attack detection (PAD)</dt>
  <dd>Automated determination of a <em>presentation attack</em>. A subset of presentation attack determination methods, referred to as <em>liveness detection</em>, involves the measurement and analysis of anatomical characteristics or voluntary or involuntary reactions, to determine if a <em>biometric sample</em> is being captured from a living <em>subject</em> that is present at the point of capture.</dd>
  <dt>process assistant</dt>
  <dd>An individual who provides support for the proofing process but does not support decision-making or risk-based evaluation (e.g., translation, transcription, or accessibility support).</dd>
  <dt>proofing agent</dt>
  <dd>An agent of the <em>CSP</em> who is trained to attend <em>identity proofing</em> <em>sessions</em> and can make limited risk-based decisions – such as physically inspecting <em>identity evidence</em> and making physical comparisons of the <em>applicant</em> to identity evidence.</dd>
  <dt>Privacy Impact Assessment (PIA)</dt>
  <dd>A method of analyzing how <em>personally identifiable information</em> (PII) is collected, used, shared, and maintained. PIAs are used to identify and mitigate privacy risks throughout the development lifecycle of a program or system. They also help ensure that handling information conforms to legal, regulatory, and policy requirements regarding privacy.</dd>
  <dt>protected session</dt>
  <dd>A <em>session</em> in which messages between two participants are encrypted and integrity is protected using a set of <em>shared secrets</em> called “session keys.”

    <p>A protected session is said to be <em>authenticated</em> if — during the session — one participant proves possession of one or more <em>authenticators</em> in addition to the session keys, and if the other party can verify the identity associated with the authenticators. If both participants are authenticated, the protected session is said to be <em>mutually authenticated</em>.</p>
  </dd>
  <dt>Provisioning API</dt>
  <dd>A protected API that allows an <em>RP</em> to access identity <em>attributes</em> for multiple subscribers for the purposes of provisioning and managing RP <em>subscriber accounts</em>.</dd>
  <dt>pseudonym</dt>
  <dd>A name other than a legal name.</dd>
  <dt>pseudonymity</dt>
  <dd>The use of a <em>pseudonym</em> to identify a <em>subject</em>.</dd>
  <dt>pseudonymous identifier</dt>
  <dd>A meaningless but unique <em>identifier</em> that does not allow the <em>RP</em> to infer anything regarding the subscriber but that does permit the RP to associate multiple interactions with a single subscriber.</dd>
  <dt>public key</dt>
  <dd>The public part of an <em>asymmetric key</em> pair that is used to verify signatures or encrypt data.</dd>
  <dt>public key certificate</dt>
  <dd>A digital document issued and digitally signed by the <em>private key</em> of a certificate authority that binds an <em>identifier</em> to a subscriber’s <em>public key</em>. The certificate indicates that the subscriber identified in the certificate has sole control of and access to the private key. See also <a href="/800-63-4/sp800-63/references/#ref-RFC5280">[RFC5280]</a>.</dd>
  <dt>public key infrastructure (PKI)</dt>
  <dd>A set of policies, processes, server platforms, software, and workstations used to administer certificates and public-_private key_ pairs, including the ability to issue, maintain, and revoke <em>public key certificates</em>.</dd>
  <dt>reauthentication</dt>
  <dd>The process of confirming the subscriber’s continued presence and intent to be <em>authenticated</em> during an extended usage <em>session</em>.</dd>
  <dt>registration</dt>
  <dd>See <em>enrollment</em>.</dd>
  <dt>relying party (RP)</dt>
  <dd>An entity that relies upon a <em>verifier</em>’s <em>assertion</em> of a subscriber’s identity, typically to process a transaction or grant access to information or a system.</dd>
  <dt>remote</dt>
  <dd>A process or transaction that is conducted through connected devices over a <em>network</em>, rather than in person.</dd>
  <dt>replay attack</dt>
  <dd>An attack in which the attacker is able to replay previously captured messages (between a legitimate <em>claimant</em> and a <em>verifier</em>) to masquerade as that claimant to the verifier or vice versa.</dd>
  <dt>replay resistance</dt>
  <dd>The property of an authentication process to resist <em>replay attacks</em>, typically by the use of an <em>authenticator</em> output that is valid only for a specific authentication.</dd>
  <dt>resolution</dt>
  <dd>See <em>identity resolution</em>.</dd>
  <dt>restricted</dt>
  <dd>An <em>authenticator</em> type, class, or instantiation that has additional risk of false acceptance associated with its use and is therefore subject to additional requirements.</dd>
  <dt>risk assessment</dt>
  <dd>The process of identifying, estimating, and prioritizing risks to organizational operations (i.e., mission, functions, image, or reputation), organizational assets, individuals, and other organizations that result from the operation of a system. A risk assessment is part of <em>risk management</em>, incorporates threat and vulnerability analyses, and considers mitigations provided by security <em>controls</em> that are planned or in-place. It is synonymous with “risk analysis.”</dd>
  <dt>risk management</dt>
  <dd>The program and supporting processes that manage information security risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, and other organizations and includes (i) establishing the context for risk-related activities, (ii) assessing risk, (iii) responding to risk once determined, and (iv) monitoring risk over time.</dd>
  <dt>RP subscriber account</dt>
  <dd>An account established and managed by the <em>RP</em> in a federated system based on the RP’s view of the <em>subscriber account</em> from the <em>IdP</em>. An RP subscriber account is associated with one or more <em>federated identifiers</em> and allows the subscriber to access the account through a <em>federation transaction</em> with the IdP.</dd>
  <dt>salt</dt>
  <dd>A non-secret value used in a cryptographic process, usually to ensure that the results of computations for one instance cannot be reused by an attacker.</dd>
  <dt>Secure Sockets Layer (SSL)</dt>
  <dd>See <em>Transport Layer Security (TLS)</em>.</dd>
  <dt>security domain</dt>
  <dd>A set of systems under a common administrative and access control.</dd>
  <dt>Senior Agency Official for Privacy (SAOP)</dt>
  <dd>Person responsible for ensuring that an agency complies with privacy requirements and manages privacy risks. The SAOP is also responsible for ensuring that the agency considers the privacy impacts of all agency actions and policies that involve PII.</dd>
  <dt>session</dt>
  <dd>A persistent interaction between a subscriber and an <em>endpoint</em>, either an <em>RP</em> or a <em>CSP</em>. A session begins with an authentication event and ends with a session termination event. A session is bound by the use of a session secret that the subscriber’s software (e.g., a browser, application, or OS) can present to the RP to prove association of the session with the authentication event.</dd>
  <dt>session hijack attack</dt>
  <dd>An attack in which the attacker is able to insert themselves between a <em>claimant</em> and a <em>verifier</em> subsequent to a successful authentication exchange between the latter two parties. The attacker is able to pose as a subscriber to the verifier or vice versa to control <em>session</em> data exchange. Sessions between the claimant and the <em>RP</em> can be similarly compromised.</dd>
  <dt>shared secret</dt>
  <dd>A secret used in authentication that is known to the subscriber and the verifier.</dd>
  <dt>side-channel attack</dt>
  <dd>An attack enabled by the leakage of information from a physical cryptosystem. Characteristics that could be exploited in a side-channel attack include timing, power consumption, and electromagnetic and acoustic emissions.</dd>
  <dt>single-factor</dt>
  <dd>A characteristic of an authentication system or an <em>authenticator</em> that requires only one <em>authentication factor</em> (i.e., something you know, something you have, or something you are) for successful authentication.</dd>
  <dt>single sign-on (SSO)</dt>
  <dd>An authentication process by which one account and its <em>authenticators</em> are used to access multiple applications in a seamless manner, generally implemented with a <em>federation protocol</em>.</dd>
  <dt>social engineering</dt>
  <dd>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.</dd>
  <dt>subject</dt>
  <dd>A person, organization, device, hardware, <em>network</em>, software, or service. In these guidelines, a subject is a <em>natural person</em>.</dd>
  <dt>subscriber</dt>
  <dd>An individual enrolled in the <em>CSP</em> identity service.</dd>
  <dt>subscriber account</dt>
  <dd>An account established by the <em>CSP</em> containing information and <em>authenticators</em> registered for each subscriber enrolled in the CSP identity service.</dd>
  <dt>supplemental controls</dt>
  <dd><em>Controls</em> that may be added, in addition to those specified in the organization’s tailored assurance level, in order to address specific threats or attacks.</dd>
  <dt>symmetric key</dt>
  <dd>A <em>cryptographic key</em> used to perform both the cryptographic operation and its inverse. (e.g., to encrypt and decrypt or create a <em>message authentication code</em> and to verify the code).</dd>
  <dt>sync fabric</dt>
  <dd>Any on-premises, cloud-based, or hybrid service used to store, transmit, or manage authentication keys generated by syncable <em>authenticators</em> that are not local to the user’s device.</dd>
  <dt>syncable authenticators</dt>
  <dd>Software or hardware cryptographic <em>authenticators</em> that allow authentication keys to be cloned and exported to other storage to sync those keys to other authenticators (i.e., devices).</dd>
  <dt>synthetic identity fraud</dt>
  <dd>The use of a combination of <em>personally identifiable information</em> (PII) to fabricate a person or entity in order to commit a dishonest act for personal or financial gain.</dd>
  <dt>system of record (SOR)</dt>
  <dd>An SOR is a collection of records that contain information about individuals and are under the control of an agency. The records can be retrieved by the individual’s name or by an identifying number, symbol, or other <em>identifier</em>.</dd>
  <dt>System of Record Notice (SORN)</dt>
  <dd>A notice that federal agencies publish in the Federal Register to describe their systems of records.</dd>
  <dt>tailoring</dt>
  <dd>The process by which xALs and specified <em>controls</em> are modified by: considerations for the impacts on privacy, <em>usability</em>, and <em>equity</em> on the user population, identifying and designating common controls, applying scoping considerations on the applicability and implementation of specified controls, selecting any <em>compensating controls</em>, assigning specific values to organization-defined security control parameters, supplementing xAL controls with additional controls or control enhancements, and providing additional specification information for control implementation.</dd>
  <dt>token</dt>
  <dd>See <em>authenticator</em>.</dd>
  <dt>transaction</dt>
  <dd>See <em>digital transaction</em></dd>
  <dt>Transport Layer Security (TLS)</dt>
  <dd>An authentication and security protocol widely implemented in browsers and web servers. TLS is defined by <a href="/800-63-4/sp800-63/references/#ref-RFC5246">[RFC5246]</a>. TLS is similar to the older SSL protocol, and TLS 1.0 is effectively SSL version 3.1. SP 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations <a href="/800-63-4/sp800-63/references/#ref-SP800-52">[SP800-52]</a>, specifies how TLS is to be used in government applications.</dd>
  <dt>trust agreement</dt>
  <dd>A set of conditions under which a <em>CSP</em>, <em>IdP</em>, and <em>RP</em> are allowed to participate in a <em>federation transaction</em> for the purposes of establishing an authentication <em>session</em> between the subscriber and the RP.</dd>
  <dt>trust anchor</dt>
  <dd>A public or <em>symmetric key</em> that is trusted because it is built directly 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 <em>public key</em> certificate). A trust anchor may have name or policy constraints that limit its scope.</dd>
  <dt>trusted referee</dt>
  <dd>An agent of the <em>CSP</em> who is trained to make risk-based decisions regarding an <em>applicant’s</em> <em>identity proofing</em> case when that applicant is unable to meet the expected requirements of a defined IAL proofing process.</dd>
  <dt>usability</dt>
  <dd>The 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. <a href="/800-63-4/sp800-63/references/#ref-ISOIEC9241">[ISO/IEC9241-11]</a></dd>
  <dt>validation</dt>
  <dd>The process or act of checking and confirming that the evidence and <em>attributes</em> supplied by an <em>applicant</em> are authentic, accurate and associated with a real-life identity. Specifically, evidence validation is the process or act of checking that the presented evidence is authentic, current, and issued from an acceptable source. See also <em>attribute validation</em>.</dd>
  <dt>verification</dt>
  <dd>The process or act of confirming that the <em>applicant</em> undergoing <em>identity proofing</em> holds the claimed real-life identity represented by the validated identity <em>attributes</em> and associated evidence. Synonymous with “identity verification.”</dd>
  <dt>verifier</dt>
  <dd>An entity that verifies the <em>claimant’s</em> identity by verifying the claimant’s possession and control of one or more <em>authenticators</em> using an <em>authentication protocol</em>. To do this, the verifier needs to confirm the binding of the authenticators with the <em>subscriber account</em> and check that the subscriber account is active.</dd>
  <dt>verifier impersonation</dt>
  <dd>See <em>phishing</em>.</dd>
  <dt>zeroize</dt>
  <dd>Overwrite a memory location with data that consists entirely of bits with the value zero so that the data is destroyed and unrecoverable. This is often contrasted with deletion methods that merely destroy references to data within a file system rather than the data itself.</dd>
  <dt>zero-knowledge password protocol</dt>
  <dd>A password-based <em>authentication protocol</em> that allows a <em>claimant</em> to <em>authenticate</em> to a <em>verifier</em> without revealing the <em>password</em> to the verifier. Examples of such protocols are EKE, SPEKE and SRP.</dd>
</dl>

<h1 id="changelog" data-section="C">
  
  
    Change Log <a href="#changelog" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<h2 id="sp-800-63-1" data-section="C">
  
  
    SP 800-63-1 <a href="#sp-800-63-1" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>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 (minimum) technical requirements were specified for the CSP, protocols used to transport authentication information, and assertions if implemented within the digital identity model.</p>
<h2 id="sp-800-63-2" data-section="C">
  
  
    SP 800-63-2 <a href="#sp-800-63-2" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>NIST SP 800-63-2 was a limited update of SP 800-63-1 and substantive changes were made only in Sec. 5, <em>Registration and Issuance Processes</em>. 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 send postal mail to an address of record to issue credentials for level 3 remote registration. Other changes to Sec. 5 were minor explanations and clarifications.</p>
<h2 id="sp-800-63-3" data-section="C">
  
  
    SP 800-63-3 <a href="#sp-800-63-3" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>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 authentication strength and confidence in an individual’s claimed identity (e.g., in strong pseudonymous authentication). A risk assessment methodology and its application to IAL, AAL, and FAL has been included in this guideline. It also moves the whole of digital identity guidance covered under SP 800-63 from a single document describing authentication to a suite of four documents (to separately address the individual components mentioned above) of which SP 800-63-3 is the top-level document.</p>

<p>Other areas updated in 800-63-3 include:</p>

<ul>
  <li>Renamed to <em>Digital Identity Guidelines</em> to properly represent the scope includes identity proofing and federation, and to support expanding the scope to include device identity, or machine-to-machine authentication in future revisions.</li>
  <li>Changed terminology, including the use of <em>authenticator</em> in place of <em>token</em> to avoid conflicting use of the word <em>token</em> in assertion technologies.</li>
  <li>Updated authentication and assertion requirements to reflect advances in both security technology and threats.</li>
  <li>Added requirements on the storage of long-term secrets by verifiers.</li>
  <li>Restructured identity proofing model.</li>
  <li>Updated requirements regarding remote identity proofing.</li>
  <li>Clarified the use of independent channels and devices as “something you have”.</li>
  <li>Removed pre-registered knowledge tokens (authenticators), with the recognition that they are special cases of (often very weak) passwords.</li>
  <li>Added requirements regarding account recovery in the event of loss or theft of an authenticator.</li>
  <li>Removed email as a valid channel for out-of-band authenticators.</li>
  <li>Expanded discussion of reauthentication and session management.</li>
  <li>Expanded discussion of identity federation; restructuring of assertions in the context of federation.</li>
</ul>
<h2 id="sp-800-63-4" data-section="C">
  
  
    SP 800-63-4 <a href="#sp-800-63-4" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>NIST SP 800-63-4 has substantial updates and re-organization from SP 800-63-3. Updates to 800-63-4 include:</p>

<ul>
  <li>Expanded security and privacy considerations and added equity and usability considerations.</li>
  <li>Updated digital identity models and added a user-controlled wallet federation model that addresses the increased attention and adoption of digital wallets and attribute bundles.</li>
  <li>Expanded digital identity risk management process to include definition of the protected online services, user groups, and impacted entities.</li>
  <li>A more descriptive introduction to establish the context of the DIRM process, the two dimensions of risk it addresses, and the intended outcomes. This context-setting step includes defining and understanding the online service that the organization is offering and intending to protect with identity systems.</li>
  <li>Expanded digital identity risk management process to include definition of the protected online services, user groups, and impacted entities.</li>
  <li>Updated digital identity risk management process for additional assessments for tailoring initial baseline control selections.</li>
  <li>Added performance metrics for the continuous evaluation of digital identity systems.</li>
  <li>Added a new subsection on redress processes and requirements.</li>
  <li>Added a new Artificial Intelligence subsection to address the use of Artificial Intelligence in digital identity services.</li>
</ul>


  </div>
</div>
<footer role="contentInfo" class="site-footer">
  <div class="section-container">
    <div class="section-content">
    </div>
  </div>
</footer>

<script type="text/javascript">
    function loadSearch() {
        var sjs = SimpleJekyllSearch({
          searchInput: document.getElementById('search-input'),
          resultsContainer: document.getElementById('results-container'),
          json: '/800-63-4/search.json'
        });
    }
    $(function() {
      
      // Convert all links to on-page within document in collapsed view
      $('.container a[href^="/800-63-4/sp800-63/"], .container a[href^="../"]').filter('a[href*="#"]').each(function(i, el) {
          var $el = $(el);
          var newPath = $el.attr('href').replace(/(.*)(\#.+)/, "$2");
          //console.log('1: ' + $el.attr('href') + ' :: ' + newPath);
          $el.attr('href', newPath);
      });
      // Convert all cross-document links when in collapsed view
      $('.container a[href^="/800-63-4/"]').not('a[href*="sp800-63/"]').each(function(i, el) {
          var $el = $(el);
          var newPath = $el.attr('href').replace(new RegExp('(/800-63-4)/([^/]+)(/.*)?/(#.*)?'), '$1/$2.html$4');
          //console.log('2: ' + $el.attr('href') + ' :: ' + newPath);
          $el.attr('href', newPath);
      });
      
      // highlight normative language by adding classes
      $('strong').filter(':contains("SHALL"), :contains("SHALL NOT"), :contains("SHOULD"), :contains("SHOULD NOT"), :contains("MAY"), :contains("NEED NOT"), :contains("CAN"), :contains("CANNOT"), :contains("CAPITALS")').each(function(i, el) {
        var $el;
        $el = $(el);
        $el.addClass('normative');
      });
      // highlight the target
      $('a:target').parent().addClass('target');
      $(':target').addClass('target');
      $(window).on('hashchange', function(e) {
        $('.target').removeClass('target');
        $('a:target').parent().addClass('target');
        $(':target').addClass('target');
      });
    });
</script>


</body>
</html>