sp800-63a.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-63a.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-63A</title>
    <meta property="og:title" content="NIST Special Publication 800-63A"/>
    

    <meta name="description" content="NIST Special Publication 800-63A">
    <meta property="og:description" content="NIST Special Publication 800-63A"/>
    
</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="">
          
              <a href="/800-63-4/sp800-63.html">SP 800-63</a>
          
          
        </li>
      
        
        <li class="active">
          
              <a href="/800-63-4/sp800-63a.html">SP 800-63A</a>
          
          
            <ul class="subnav">
            
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#abstract">Abstract</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#reviewers">Reviewers</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#preface">Preface</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#introduction"><span class="section">1</span>Introduction</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#ipv-section"><span class="section">2</span>Proofing</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#ial-general"><span class="section">3</span>General IAL</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#ial-section"><span class="section">4</span>IAL</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#accounts"><span class="section">5</span>Accounts</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#security"><span class="section">6</span>Security</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#privacy-section-header"><span class="section">7</span>Privacy</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#usability"><span class="section">8</span>Usability</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#equity"><span class="section">9</span>Equity</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#references">References</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#EvidenceExamples"><span class="section">A</span>Evidence</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#abbr"><span class="section">B</span>Abbreviations</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#def-and-acr"><span class="section">C</span>Glossary</a></li>
                
              
                    <li class=""><a href="/800-63-4/sp800-63a.html#changelog"><span class="section">D</span>Change Log</a></li>
                
              
            </ul>
          
          
        </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-63a/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>This guideline focuses on the enrollment and verification of an identity for use in digital authentication. Central to this is a process known as identity proofing in which an applicant provides evidence to a credential service provider (CSP) reliably identifying themselves, thereby allowing the CSP to assert that identification at a useful identity assurance level. This document defines technical requirements for each of three identity assurance levels. 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-63A.</p>
<h1 id="keywords">
  
  
    Keywords <a href="#keywords" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<p>authentication; credential service provider; electronic authentication; digital authentication; electronic credentials; digital credentials; identity proofing; federation.</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>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>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>The purpose of this document, and associated companion volumes <a href="/800-63-4/sp800-63/introduction/#introduction" latex-href="#ref-SP800-63">[SP800-63]</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>, is to provide guidance to organizations for the processes and technologies for the management of digital identities at designated levels of assurance.</p>

<p>This document provides requirements for the identity proofing of individuals at each Identity Assurance Level (IAL) for the purposes of enrolling them into an identity service or providing them access to online resources.  It applies to the identity proofing of individuals over a network or in person.</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>One of the challenges of providing online services is being able to associate a set of activities with a single, known individual. While there are situations where this is not necessary, there are other situations where it is important to reliably establish an association with a real-life subject. Examples of this include accessing government services and executing financial transactions. There are also situations where association with a real-life subject is required by regulations (e.g., the financial industry’s ‘Customer Identification Program’ requirements) or to establish accountability for high-risk actions (e.g., changing the release rate of water from a dam).</p>

<p>This guidance defines identity proofing as the process of establishing, to some degree of assurance, a relationship between a subject accessing online services and a real-life person. This document provides guidance for Federal Agencies, third-party Credential Service Providers (CSP), and other organizations that provide or use identity proofing services.</p>
<h2 id="expected-outcomes-of-identity-proofing" data-section="1">
  
  
    Expected Outcomes of Identity Proofing <a href="#expected-outcomes-of-identity-proofing" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The expected outcomes of identity proofing include:</p>

<ul>
  <li><strong>Identity resolution</strong>: Determine that the claimed identity corresponds to a single, unique individual within the context of the population of users served by the CSP or online service.</li>
  <li><strong>Evidence validation</strong>: Confirm that supplied evidence is genuine, authentic, and valid.</li>
  <li><strong>Attribute validation</strong>: Confirm the accuracy of the core attributes. Core attributes are the minimum set required for identity proofing.</li>
  <li><strong>Identity verification</strong>: Confirm that the claimant is the genuine owner of the presented evidence and attributes.</li>
  <li><strong>Identity enrollment</strong>: Enroll the identity proofed applicant in the CSP’s identity service as a subscriber.</li>
  <li><strong>Fraud mitigation</strong>: Detect, respond to, and prevent access to benefits, services, data, or assets using a fraudulent identity.</li>
</ul>

<p>Identity proofing services are expected to incorporate privacy-enhancing principles, such as data minimization, as well as employ good usability practices, to minimize the burden on applicants while still accomplishing the expected outcomes.</p>
<h2 id="identity-assurance-levels" data-section="1">
  
  
    Identity Assurance Levels <a href="#identity-assurance-levels" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Assurance (confidence) in a subscriber’s identity is established using the processes associated with the defined Identity Assurance Levels (IAL). Each successive IAL builds on the requirements of lower IALs in order to achieve increased assurance.</p>

<p><strong>No identity proofing</strong>: There is no requirement to link the applicant to a specific, real-life person. Any attributes provided in conjunction with the subject’s activities are self-asserted or are treated as self-asserted. Evidence is not validated and attributes are neither validated nor verified.</p>

<p><strong>IAL1</strong>: The identity proofing process supports the real-world existence of the claimed identity and provides some assurance that the applicant is associated with that identity. Core attributes are obtained from identity evidence or self-asserted by the applicant.  All core attributes (see <a href="/800-63-4/sp800-63a/proofing/#CoreAttributes">Sec. 2.2</a>) are validated against authoritative or credible sources and steps are taken to link the attributes to the person undergoing the identity proofing process. Identity proofing is performed using remote or onsite processes, with or without the attendance of a CSP representative (proofing agent or trusted referee). Upon the successful completion of identity proofing, the applicant is enrolled into a subscriber account and any authenticators, including subscriber-provided authenticators, can then be bound to the account. IAL1 is designed to limit highly scalable attacks, provide protection against synthetic identities, and provide protections against attacks using compromised PII.</p>

<p><strong>IAL2</strong>: IAL2 adds additional rigor to the identity proofing process by requiring the collection of additional evidence and a more rigorous process for validating the evidence and verifying the identity. In addition to those threats addressed by IAL1, IAL2 is designed to limit scaled and targeted attacks, provide protections against basic evidence falsification and evidence theft, and provide protections against basic social engineering tactics.</p>

<p><strong>IAL3</strong>: IAL3 adds the requirement for a trained CSP representative (proofing agent) to interact directly with the applicant, as part of an on-site attended identity proofing session, and the collection of at least one biometric. The successful on-site identity proofing session concludes with the enrollment of the applicant into a subscriber account and the delivery of one or more authenticators associated (bound) to that account. IAL3 is designed to limit more sophisticated attacks, provide protections against advanced evidence falsification, theft, and repudiation, and provide protection against more advanced social engineering tactics.</p>

<div latex-literal="true" class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>\clearpage
</code></pre></div></div>
<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 permissible within the limits of the publication.</li>
      <li>The terms “<strong>CAN</strong>” and “<strong>CANNOT</strong>” indicate a possibility and capability—whether material, physical, or causal—or, in the negative, the absence of that possibility or capability.</li>
    </ul>
  </li>
</ul>
<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 requirements for identity proofing. This section is <em>normative</em>.</li>
  <li>Section 3 describes general requirements for IALs. This section is <em>normative</em>.</li>
  <li>Section 4 describes requirements for specific IALs. This section is <em>normative</em>.</li>
  <li>Section 5 describes subscriber accounts. This section is <em>normative</em>.</li>
  <li>Section 6 provides security considerations. This section is <em>informative</em>.</li>
  <li>Section 7 provides privacy considerations. This section is <em>informative</em>.</li>
  <li>Section 8 provides usability considerations. This section is <em>informative</em>.</li>
  <li>Section 9 provides equity considerations. This section is <em>informative</em>.</li>
  <li>References contains a list of publications referred to from this document. This section is <em>informative</em>.</li>
  <li>Appendix A provides a non-exhaustive list of types of identity evidence, grouped by strength. This appendix is <em>informative</em>.</li>
  <li>Appendix B contains a selected list of abbreviations used in this document. This appendix is <em>informative</em>.</li>
  <li>Appendix C contains a glossary of selected terms used in this document. This appendix is <em>informative</em>.</li>
  <li>Appendix D contains a summarized list of changes in this document’s history. This appendix is <em>informative</em>.</li>
</ul>

<h1 id="ipv-section" data-section="2">
  
  
    Identity Proofing Overview <a href="#ipv-section" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

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

<p>This section provides an overview of the identity proofing and enrollment process, as well as requirements to support the resolution, validation, and verification of the identity claimed by an applicant. It also provides guidelines on additional aspects of the identity proofing process.  These requirements are intended to ensure that the claimed identity exists in the real world and that the applicant is the individual associated with that identity.</p>

<p>Additionally, these guidelines provide for multiple methods by which resolution, validation, and verification can be accomplished, as well as providing the multiple types of identity evidence that support the identity proofing process. CSPs and organizations <strong>SHALL</strong> provide options when implementing their identity proofing services and processes to promote access for applicants with different means, capabilities, and technology access. These options <strong>SHOULD</strong> include accepting multiple types and combinations of identity evidence; supporting multiple data validation sources; enabling multiple methods for verifying identity; providing multiple channels for engagement (e.g., onsite, remote); and offering assistance mechanisms for applicants (e.g., applicant references).</p>

<p>CSPs <strong>SHALL</strong> evaluate the risks associated with each identity proofing option offered (e.g., identity proofing types, validation sources, assistance mechanisms) and implement mitigating fraud controls, as appropriate. At a minimum, CSPs <strong>SHALL</strong> design each option such that, in aggregate, the options provide comparable assurance.</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>The objective of identity proofing is to ensure that, to a stated level of certainty, the applicant involved in the identity proofing process is who they claim to be. This document presents a three-step process for CSPs to identity proof applicants at designated assurance levels. The first step, identity resolution, consists of collecting appropriate identity evidence and attribute information to determine that the applicant is a unique identity in the population served by the CSP and is a real-life person. The second step, identity validation, validates the genuineness, accuracy, and validity of the evidence and attribute information collected in the first step. The third step, identity verification, confirms that the applicant presenting the identity evidence is the same individual to whom the validated evidence was issued and with whom the validated attributes are associated. In most cases, upon successfully identity proofing an applicant to the designated IAL, the CSP establishes a unique subscriber account for the applicant (now a subscriber in the identity service), which allows one or more authenticators to be bound to the proven identity in the account.</p>

<p>Identity proofing can be part of an organization’s business processes that support the determination of suitability or entitlement to a benefit or service. While these guidelines provide guidance for appropriate levels of identity assurance, suitability and eligibility determinations for benefits or services are distinct business process decisions from these identity proofing processes and are outside the scope of these guidelines.</p>
<h3 id="process-flow" data-section="2">
  
  
    Process Flow <a href="#process-flow" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

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

<p><a href="/800-63-4/sp800-63a/proofing/#fig-1">Figure 1</a> provides an illustrative example of the three-step identity proofing process.</p>

<p latex-ignore="true"><a href="/800-63-4/sp800-63a/proofing/#fig-1" name="fig-1">Fig. 1. Identity Proofing Process</a></p>

<p><img src="/800-63-4/sp800-63a/images/ProofingProcess.png" alt="Illustration of steps in identity proofing and enrollment" title="Identity Proofing Process" latex-src="ProofingProcess.pdf" latex-fig="1" latex-place="h" /></p>

<p>The following steps present a common workflow example for IAL2 remote identity proofing, which is intended to illustrate the workflow steps for this example. These steps are not intended to represent a normative processing workflow model.</p>

<ol>
  <li>
    <p><strong>Resolution</strong></p>

    <ul>
      <li>The CSP captures one or more pieces of identity evidence, such as a driver’s license, mobile driver’s license, or passport.</li>
      <li>The CSP collects any additional attributes, as needed, from the applicant to supplement those contained on the presented identity evidence.</li>
    </ul>
  </li>
  <li>
    <p><strong>Validation</strong></p>

    <ul>
      <li>The CSP confirms the presented evidence is authentic, accurate, and valid (e.g., not revoked).</li>
      <li>The CSP validates the attributes obtained in step 1 by checking them against authoritative or credible validation sources.</li>
    </ul>
  </li>
  <li>
    <p><strong>Verification</strong></p>

    <ul>
      <li>The CSP employs one of the IAL2 Verifcation Pathways to confirm the applicant is the genuine owner of the presented identity evidence.</li>
    </ul>

    <p><strong>Enrollment</strong></p>

    <p>Upon the successful completion of the three identity proofing steps, a notification of proofing is sent to a validated address, and the applicant can be enrolled into a subscriber account with the CSP, as described in Section 5. A subscriber account includes at least one validated address (e.g., phone number, mailing address) that can be used to communicate with the subscriber about their account. Additionally, one or more authenticators are bound to the proven identity in the subscriber account.</p>
  </li>
</ol>
<h3 id="ProofingRoles" data-section="2">
  
  
    Identity Proofing Roles <a href="#ProofingRoles" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>To support the delivery of identity proofing that meets the various needs of applicants and risk scenarios, different individuals would be expected to play different roles within the proofing process. To support the consistent implementation of these guidelines, the following identity proofing roles are defined:</p>

<ol>
  <li><strong>Proofing Agent</strong> - An agent of the CSP who is trained to attend identity proofing sessions, either onsite or remotely, and make limited, risk-based decisions – such as visually inspecting identity evidence and making a determination that the evidence has not been altered.</li>
  <li><strong>Trusted Referee</strong> - An agent of the CSP who is trained to make risk-based decisions regarding an applicant’s identity proofing case when that applicant is unable to meet expected requirements of a defined IAL proofing process. Unlike a Proofing Agent (although a trusted referee may also fulfill this role), the level of training is expected to be more substantial to include training to detect deception and signs of social engineering, in addition to the ability to support validation and verification through physical inspection of the evidence and visual comparison of the applicant to a reference facial image. Requirements for trusted referees are contained in <a href="/800-63-4/sp800-63a/ial-general/#TRs">Sec. 3.1.13.1</a>.
    <blockquote>
      <p><strong>Note:</strong> Trusted referees differ from proofing agents in that trusted referees receive additional training and resources to support exception handling scenarios, including when applicants do not possess the required identity evidence or the attributes on the evidence do not all match the claimed identity (e.g., due to a recent name or address change).</p>
    </blockquote>
  </li>
  <li><strong>Applicant Reference</strong> - A representative of the applicant who can vouch for the identity of the applicant, specific attributes related to the applicant, or conditions relative to the context of the individual (e.g., emergency status, homelessness). This individual does not act on behalf of the applicant in the identity proofing process but is a resource that can be called on to support claims of identity. Requirements for applicant references are contained in <a href="/800-63-4/sp800-63a/ial-general/#ARs">Sec. 3.1.13.3</a>.</li>
  <li><strong>Process Assistants</strong> - 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). Process assistants may be provided by the CSP or the applicant.</li>
</ol>

<p>CSPs <strong>SHALL</strong> identify which of above roles are applicable to their identity service and <strong>SHALL</strong> provide training and support resources consistent with the requirements and expectations provided in <a href="/800-63-4/sp800-63a/ial-general/#ial-general">Sec. 3</a>.</p>
<h3 id="ProofingTypes" data-section="2">
  
  
    Identity Proofing Types <a href="#ProofingTypes" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>The ability to provide resolution, validation, and verification as part of an identity proofing process is delivered through a combination of technologies, communication channels, and identity proofing roles to support the diverse users, communities, and relying parties CSPs serve. The types of proofing can be categorized based on two specific factors – whether they are attended and where they take place.</p>

<ol>
  <li><strong>Remote Unattended Identity Proofing</strong> – Identity proofing conducted where the resolution, validation, and verification processes are completely automated and interaction with a proofing agent is not required.  The location and devices used in the proofing process are not controlled by the CSP.</li>
  <li><strong>Remote Attended Identity Proofing</strong> – Identity proofing conducted where the applicant completes resolution, validation, and verification steps through a secure video session with a proofing agent. The location and devices used in the proofing process are not controlled by the CSP.</li>
  <li><strong>Onsite Unattended Identity Proofing</strong> -  Identity proofing conducted where an individual interacts with a controlled workstation or kiosk, but interaction with a proofing agent is not required. The process is fully automated, but at a physical location and on devices approved by the CSP.</li>
  <li><strong>Onsite Attended Identity Proofing</strong> - Identity proofing conducted in a physical setting where the applicant completes the entire identity proofing process - to include resolution, validation, and verification – in the presence of a proofing agent. The proofing agent may be co-located with the user or interact with the user via a kiosk or device. The physical location and devices are all approved by the CSP.</li>
</ol>

<p>Requirements at each assurance level are structured to allow CSPs to implement different combinations of proofing types to meet the requirements of different assurance levels (as appropriate). CSPs that offer IAL1 &amp; IAL2 services <strong>SHALL</strong> provide a Remote Unattended identity proofing process and <strong>SHALL</strong> offer at-least one attended identity proofing process option. CSPs that offer IAL1 &amp; IAL2 services <strong>SHOULD</strong> support identity proofing processes that allow for the applicant to transition between proofing types in the event an applicant is unsuccessful with one type (e.g., allow an applicant who fails remote unattended to transition to remote attended).</p>
<h2 id="CoreAttributes" data-section="2">
  
  
    Core Attributes <a href="#CoreAttributes" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The identity proofing process involves the presentation and validation of the minimum attributes necessary to accomplish identity proofing - this includes what is needed to complete resolution, validation, and verification. While the necessary core attributes for a given use case will change based on the nature of the community being served, the following attributes <strong>SHOULD</strong> be collected by CSPs to support the proofing process:</p>

<ul>
  <li><strong>First Name</strong>: The applicant’s given name.</li>
  <li><strong>Middle Name or Initial</strong>: The applicant’s middle name or initial if available.</li>
  <li><strong>Last Name</strong>: The applicant’s last name or family name as appropriate.</li>
  <li><strong>Government Identifier</strong>: A unique identifier which is associated with the applicant in government records (e.g., SSN, TIN, Driver’s License #).</li>
  <li><strong>Physical Address</strong>: A physical address to which the applicant can receive communications related to the proofing process; or a <strong>Digital Address</strong>: A digital address (e.g., phone or email) to which the applicant can receive communications related to the proofing process.</li>
</ul>

<p>Additional attributes may be added to these as required by the CSP and RP. The CSP and RP <strong>SHALL</strong> document all core attributes in trust agreements and practice statements. Following a privacy risk assessment, a CSP <strong>MAY</strong> request additional attributes that are not required to complete identity proofing, but that may support other RP business processes. See <a href="/800-63-4/sp800-63a/ial-general/#PrivacyReqs">Sec. 3.1.3</a> for details on privacy requirements for requesting additional attributes.</p>
<h2 id="resolve" data-section="2">
  
  
    Identity Resolution <a href="#resolve" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The goal of identity resolution is to use the smallest possible set of attributes to uniquely and accurately distinguish an individual within a given population or context. This step involves comparing an applicant’s collected attributes to those stored in records for users served by the CSP. While identity resolution is the starting point in the overall identity proofing process, to include the initial detection of potential fraud, it in no way represents a complete and successful identity proofing process.</p>
<h2 id="evidence-collection" data-section="2">
  
  
    Identity Validation and Identity Evidence Collection <a href="#evidence-collection" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The goal of identity validation is to collect the most appropriate identity evidence from the applicant and determine that it is genuine (not altered or forged), accurate (the pertinent data is correct, current, and related to the applicant), and valid.</p>

<blockquote>
  <p><strong>Note:</strong> This document uses the term “valid” rather than expired in recognition that evidence can remain a useful means to prove identity, even if it is expired or was issued outside a determined timeframe.</p>
</blockquote>

<p>Identity evidence collection supports the identity validation process and consists of two steps: 1) the presentation of identity evidence by the identity proofing applicant to the CSP and 2) the determination by the CSP that the presented evidence meets the applicable strength requirements.</p>
<h3 id="evidence-strength" data-section="2">
  
  
    Evidence Strength Requirements <a href="#evidence-strength" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>This section defines the requirements for identity evidence at each strength. The strength of a piece of identity evidence is determined by:</p>

<ol>
  <li>The issuing rigor,</li>
  <li>The ability to provide confidence in validation, including accuracy and authenticity checks, and</li>
  <li>The ability to provide confidence in the verification of the applicant presenting the evidence.</li>
</ol>

<p><a href="/800-63-4/sp800-63a/evidence/#EvidenceExamples">Appendix A</a> of this document provides a non-exhaustive list of possible evidence types, grouped by strength.</p>
<h4 id="fair-evidence-requirements" data-section="2">
  
  
    Fair Evidence Requirements <a href="#fair-evidence-requirements" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>To be considered FAIR, identity evidence <strong>SHALL</strong> meet <em>all</em> the following requirements:</p>

<ol>
  <li>The issuing source of the evidence confirmed the claimed identity through a process designed to enable it to form a belief that it knows the real-life identity of the person. For example, evidence issued by financial institutions that have customer identity verification obligations under the Customer Identification Program (CIP) Rule implementing Section 326 of the USA PATRIOT Act of 2001, or that have obligations to establish an Identity Theft Prevention Program under the Red Flags Rule and Guidelines, implemented under Sec. 114 of the Fair and Accurate Credit Transaction Act of 2003 (FACT Act).</li>
</ol>

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

<ol>
  <li>It is likely that the evidence-issuing process would result in the delivery of the evidence to the person to whom it relates, such as delivery to a postal address.</li>
  <li>The evidence contains the name of the claimed identity.</li>
  <li>The evidence contains at least one reference number, a facial portrait, or sufficient attributes to uniquely identify the person to whom it relates.</li>
  <li>The evidence contains physical (e.g., security printing, optically variable features, holograms) or digital security features that make it difficult to reproduce.</li>
  <li>The information on the evidence is able to be validated by an authoritative or credible source.</li>
  <li>The evidence is able to be verified through an approved method, as provided in <a href="/800-63-4/sp800-63a/proofing/#validation-methods">Sec. 2.4.2.2</a>.</li>
</ol>
<h4 id="strong-evidence-requirements" data-section="2">
  
  
    Strong Evidence Requirements <a href="#strong-evidence-requirements" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>In order to be considered STRONG, identity evidence <strong>SHALL</strong> meet <em>all</em> the following requirements:</p>

<ol>
  <li>The issuing source of the evidence confirmed the claimed identity by following written procedures designed to enable it to have high confidence that it knows the real-life identity of the subject. Additionally, these procedures are subject to recurring oversight by regulatory or publicly accountable institutions, such as states, the federal government, and some regulated industries.  Such procedures would include, but not be limited to, identity proofing at IAL2 or above.</li>
  <li>It is likely that the evidence-issuing process would result in the delivery of the evidence to the person to whom it relates, such as delivery to a postal address.</li>
  <li>The evidence contains the name of the claimed identity.</li>
  <li>The evidence contains a reference number or other attributes that uniquely identify the person to whom it relates.</li>
  <li>The evidence contains a facial portrait or other biometric characteristic of the person to whom it relates.</li>
  <li>The evidence includes physical security features or digital security features that make it difficult to copy or reproduce.</li>
  <li>The information on the evidence is able to be validated by an authoritative or credible source.</li>
  <li>The evidence is able to be validated through an approved method, as provided in <a href="/800-63-4/sp800-63a/proofing/#validation-methods">Sec. 2.4.2.2</a>.</li>
</ol>
<h4 id="superior-evidence-requirements" data-section="2">
  
  
    Superior Evidence Requirements <a href="#superior-evidence-requirements" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>In order to be considered SUPERIOR, identity evidence <strong>SHALL</strong> meet <em>all</em> the following requirements:</p>

<ol>
  <li>The issuing source of the evidence confirmed the claimed identity by following written procedures designed to enable it to have high confidence that the source knows the real-life identity of the subject. Additionally, these procedures are subject to recurring oversight by regulatory or publicly accountable institutions, such as states and the federal government, and some regulated industries.  Such procedures would include, but not be limited to, identity proofing at IAL2 or above.</li>
  <li>The identity evidence contains attributes and data objects that are cryptographically protected and can be validated through verification of a digital signature applied by the issuing source.</li>
  <li>The issuing source had the subject participate in an attended enrollment and identity proofing process that confirmed their physical existence.</li>
  <li>It is likely that the evidence-issuing process would result in the delivery of the evidence to the person to whom it relates, such as delivery to a postal address.</li>
  <li>The evidence contains the name of the claimed identity.</li>
  <li>The evidence contains at least one reference number that uniquely identifies the person to whom it relates.</li>
  <li>The evidence contains a facial portrait or other biometric characteristic of the person to whom it relates.</li>
  <li>If the evidence is physical, then evidence includes security features that make it difficult to copy or reproduce.</li>
  <li>The evidence is able to be verified through an approved method, as provided in <a href="/800-63-4/sp800-63a/proofing/#validation-methods">Sec. 2.4.2.2</a>.</li>
</ol>
<h3 id="identity-evidence-and-attribute-validation" data-section="2">
  
  
    Identity Evidence and Attribute Validation <a href="#identity-evidence-and-attribute-validation" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Identity evidence validation involves examining the presented evidence to confirm it is authentic (not forged or altered), accurate (the information on the evidence is correct), and valid (unexpired or within the CSP’s defined timeframe for issuance or expiration). Attribute validation involves confirming the accuracy of the core attributes, whether obtained from presented evidence or self-asserted. The following subsections provide the acceptable methods for evidence and attribute validation.</p>
<h4 id="validation" data-section="2">
  
  
    Evidence Validation <a href="#validation" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>The CSP <strong>SHALL</strong> validate the authenticity, accuracy, and validity of presented evidence by confirming:</p>

<ul>
  <li>The evidence is in the correct format and includes complete information for the identity evidence type;</li>
  <li>The evidence is not counterfeit and that it has not been tampered with;</li>
  <li>Any security features; and</li>
  <li>The information on the evidence is accurate.</li>
</ul>
<h4 id="validation-methods" data-section="2">
  
  
    Evidence Validation Methods <a href="#validation-methods" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>Acceptable methods for validating presented evidence include:</p>

<ul>
  <li>Visual and tactile inspection by trained personnel for onsite identity proofing;</li>
  <li>Visual inspection by trained personnel for remote identity proofing;</li>
  <li>Automated document validation processes using appropriate technologies; and</li>
  <li>Cryptographic verification of the source and integrity of digital evidence, or attribute data objects.</li>
</ul>
<h4 id="attribute-validation" data-section="2">
  
  
    Attribute Validation <a href="#attribute-validation" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>The CSP <strong>SHALL</strong> validate all core attributes, as described in <a href="/800-63-4/sp800-63a/proofing/#CoreAttributes">Sec. 2.2</a>, whether obtained from identity evidence or self-asserted by the applicant, with an authoritative or credible source, as in <a href="/800-63-4/sp800-63a/proofing/#ValidSources">Sec. 2.4.2.4</a>.</p>
<h4 id="ValidSources" data-section="2">
  
  
    Validation Sources <a href="#ValidSources" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>The CSP <strong>SHALL</strong> use authoritative or credible sources that meet the following criteria.</p>

<p>An authoritative source is the issuing source of identity evidence or attributes, or has direct access to the information maintained by issuing sources, such as state DMVs for driver’s license data and the Social Security Administration for Social Security Cards and Social Security Numbers. An authoritative source may also be one that provides or enables direct access to issuing sources of evidence or attributes, such as the American Association of Motor Vehicle Administrators’ Driver’s License Data Verification (DLDV) Service.</p>

<p>A credible source is an entity that can provide or validate the accuracy of identity evidence and attribute information. In addition to being subject to regulatory oversight (such as the Fair Credit Reporting Act (FCRA)), a credible source has access to attribute information that can be traced to an authoritative source, or maintains identity attribute information obtained from multiple sources that is correlated for accuracy, consistency, and currency. Examples of credible sources are credit bureaus that are subject to the FCRA.</p>
<h2 id="identity-verification" data-section="2">
  
  
    Identity Verification <a href="#identity-verification" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The goal of identity verification is to establish, to a specified level of confidence, the linkage between the claimed validated identity and the real-life applicant engaged in the identity proofing process. In other words, verification provides assurance that the applicant presenting the evidence is the rightful owner of that evidence.</p>
<h3 id="verification" data-section="2">
  
  
    Identity Verification Methods <a href="#verification" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>The CSP <strong>SHALL</strong> verify the linkage of the claimed identity to the applicant engaged in the identity proofing process through one or more of the following methods. <a href="/800-63-4/sp800-63a/ial/#ial-section">Section 4</a> provides acceptable verification methods at each IAL.</p>

<ul>
  <li><strong>Confirmation Code Veriﬁcation.</strong> The individual is able to demonstrate control of a piece of identity evidence through the return of a confirmation code, consistent with the requirements speciﬁed in <a href="3_ialgen#ConfirmCodes">Sec. 3.1.8</a>.</li>
  <li><strong>Authentication and Federation Protocols.</strong> The individual is able to demonstrate control of a digital account (e.g., online bank account) or signed digital assertion (e.g., veriﬁable credentials) through the use of authentication or federation protocols. This may be done in person, through presentation of the credential to a device or reader, but can also be done during remote identity prooﬁng sessions.</li>
  <li><strong>Micro Transaction.</strong> An individual is able to demonstrate control of a piece of evidence by returning a value based on a micro transaction made between the CSP and the issuing source of the evidence (e.g., bank account).</li>
  <li><strong>Onsite-In-person (Attended) visual facial image comparison.</strong> The proofing agent and applicant interact for the identity prooﬁng event. The proofing agent performs a visual comparison of the facial portrait presented on identity evidence to the face of the applicant engaged in the identity prooﬁng event.</li>
  <li><strong>Remote (Attended or Unattended) visual facial image comparison.</strong> The proofing agent performs a visual comparison of the facial portrait presented on identity evidence, or stored by the issuing source, to the facial image of the applicant engaged in the identity prooﬁng event. The proofing agent may interact directly with the applicant during some or all of the identity prooﬁng event (attended) or may conduct the comparison at a later time (unattended) using a captured video or photograph and the uploaded copy of the evidence. If the comparison is performed at a later time, steps are taken to ensure the captured video or photograph was taken from the live applicant present during the identity prooﬁng event.</li>
  <li><strong>Automated (Unattended) biometric comparison.</strong> Automated biometric comparison, such as facial recognition or other fully automated algorithm-driven biometric comparison, <strong>MAY</strong> be performed for onsite or remote identity proofing events. The facial image or other biometric characteristic (e.g., fingerprints, palm prints, iris and retina patterns, voiceprints, or vein patterns) on the identity evidence, or stored in authoritative records, is compared to the facial image in a photograph of the live applicant or other biometric live sample collected from the applicant during the identity proofing event.</li>
</ul>

<p>Knowledge-based verification (KBV) or knowledge-based authentication <strong>SHALL NOT</strong> be used for identity verification.</p>

<h1 id="ial-general" data-section="3">
  
  
    Identity Proofing Requirements <a href="#ial-general" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

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

<p>This section provides requirements for CSPs that operate identity proofing and enrollment services, including requirements for identity proofing at each of the IALs. This section also includes additional requirements for federal agencies regardless of whether they operate their own identity service or use an external CSP.</p>

<p>Sections <a href="/800-63-4/sp800-63a/ial/#IAL1">4.1</a>, <a href="/800-63-4/sp800-63a/ial/#IAL2">4.2</a>, and <a href="/800-63-4/sp800-63a/ial/#IAL3">4.3</a> provide the requirements and guidelines for identity proofing at a specific IAL. <a href="/800-63-4/sp800-63a/ial/#summary">Section 4.4</a> includes a summarized list of these requirements by IAL in <a href="/800-63-4/sp800-63a/ial-general/#table-1">Table 1</a>.</p>
<h2 id="genProofReqs" data-section="3">
  
  
    General Requirements <a href="#genProofReqs" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The requirements in this section apply to all CSPs performing identity proofing at any IAL.</p>
<h3 id="DocRecReqs" data-section="3">
  
  
    Identity Service Documentation and Records <a href="#DocRecReqs" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>The CSP <strong>SHALL</strong> conduct its operations according to a practice statement that details all identity proofing processes as they are implemented to achieve the defined IAL. The practice statement <strong>SHALL</strong> include, at a minimum:</p>

<ol>
  <li>A complete service description including the particular steps the CSP follows to identity proof applicants at each offered assurance level;</li>
  <li>The CSP’s policy for providing notice to applicants about the types of identity proofing processes available, the evidence and attribute collection requirements for the specified IAL, the purpose of PII collection (per <a href="/800-63-4/sp800-63a/ial-general/#AddlPrivacy">Sec. 3.1.3.2</a>), and for the collection, use, and retention of biometrics (see <a href="/800-63-4/sp800-63a/ial-general/#ProofBios">Sec. 3.1.11</a>);</li>
  <li>The CSP’s policy for ensuring the identity proofing process is concluded in a timely manner, once the applicant has met all of the requirements;</li>
  <li>Types of identity evidence the CSP accepts to meet the evidence strength requirements;</li>
  <li>The CSP’s policy and process for validating and verifying identity evidence, including training and qualification requirements for personnel who have validation and verification responsibilities, as well as specific technologies the CSP employs for evidence validation and verification;</li>
  <li>Alternative processes for the CSP to complete identity proofing for an individual applicant who does not possess the required identity evidence to complete the identity proofing process<sup id="fnref:alternatives" role="doc-noteref"><a href="#fn:alternatives" class="footnote">1</a></sup>;</li>
  <li>The attributes that the CSP considers to be core attributes, and the authoritative and credible sources it uses for validating those attributes. Core attributes include the minimum set of attributes that the CSP needs to perform identity resolution as well as any additional attributes that the CSP collects and validates for the purposes of identity proofing, fraud mitigation, complying with laws or legal process, or conveying to relying parties (RPs) through attribute assertions;</li>
  <li>The CSP’s policy and process for addressing identity proofing errors;</li>
  <li>The CSP’s policy and process for identifying and remediating suspected or confirmed fraudulent accounts, including communicating with RPs and affected individuals;</li>
  <li>The CSP’s policy for managing and communicating service changes (e.g., changes in data sources, integrated vendors, or biometric algorithms) to RPs;</li>
  <li>The CSP’s policy for any conditions that would require re-verification of the user (e.g., account recovery, account abandonment, regulatory “recertification” requirements);</li>
  <li>The CSP’s policy for conducting privacy risk assessments, including the timing of its periodic reviews and specific conditions that will trigger an updated privacy risk assessment (see <a href="/800-63-4/sp800-63a/ial-general/#PrivRiskAssess">Sec. 3.1.3.1</a>);</li>
  <li>The CSP’s policy for conducting assessments to determine potential equity impacts, including the timing of its periodic reviews and any specific conditions that will trigger an out-of-cycle review (see <a href="/800-63-4/sp800-63a/ial-general/#EquityReqs">Sec. 3.1.4</a>); and,</li>
  <li>The CSP’s policy for the collection, purpose, retention, protection, and deletion of all personal and sensitive data, including the treatment of all personal information if the CSP ceases operation or merges or transfers operations to another CSP.</li>
</ol>

<blockquote>
  <p><strong>Note:</strong> 800-63C references the use of trust agreements to define requirements between an IdP, CSP, and RP in a federated relationship. CSP practice statements <strong>MAY</strong> be included directly in these agreements.</p>
</blockquote>
<h3 id="FraudMgmt" data-section="3">
  
  
    Fraud Management <a href="#FraudMgmt" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>A critical aspect of the identity proofing process is to mitigate fraudulent attempts to gain access to benefits, services, data, or assets protected by identity management systems. Resolution, Validation, and Verification processes in many instances can mitigate many attacks. However, with the constantly changing threat environment, the layering of additional checks and controls can provide increased confidence in proofed identities and additional protections against attacks intended to defeat other controls. The ability to identify, detect, and resolve instances of potential fraud is a critical functionality for CSPs and RPs alike.</p>
<h4 id="csp-fraud-management" data-section="3">
  
  
    CSP Fraud Management <a href="#csp-fraud-management" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<ol>
  <li>CSPs <strong>SHALL</strong> establish and maintain a fraud management program that provides fraud identification, detection, investigation, reporting, and resolution capabilities. The specific capabilities and details of this program <strong>SHALL</strong> be documented within their CSP practice statement.</li>
  <li>CSPs <strong>SHALL</strong> conduct a Privacy Risk Assessment of all fraud checks and fraud mitigation technologies prior to implementation.</li>
  <li>The CSP <strong>SHALL</strong> establish a self-reporting mechanism and investigation capability for subjects who believe they have been the victim of fraud or an attempt to compromise their involvement in the identity proofing processes.</li>
  <li>The CSP <strong>SHALL</strong> take measures to prevent unsuccessful applicants from inferring the accuracy of any self-asserted information with that confirmed by authoritative or credible sources.
 NOTE: This is often called “data washing” and can be prevented through a number of methods, depending on the interfaces deployed by a CSP. As such, these guidelines do not dictate specific mechanisms to prevent this practice.</li>
  <li>CSPs <strong>SHALL</strong> implement the following fraud check for all identity proofing processes:
    <ul>
      <li><strong>Date of Death Check</strong> – Confirm with a credible, authoritative, or issuing source that the applicant is not deceased. Such checks can aid in preventing synthetic identity fraud, the use of stolen identity information, and exploitation by a close associate or relative.</li>
    </ul>
  </li>
  <li>CSPs <strong>SHOULD</strong> implement - but are not limited to - the following fraud checks for their identity proofing processes based on their available identity proofing types, selected technologies, evidence, and user base:
    <ul>
      <li><strong>SIM Swap Detection</strong> – Confirm that the phone number used in an identity proofing process has not been recently ported to a new user or device. Such checks can provide an indication that a phone or device was compromised by a targeted attack.</li>
      <li><strong>Device or Account Tenure Check</strong> – Evaluate the length of time a phone or other account has existed without substantial modifications or changes. Such checks can provide additional confidence in the reliability of a device or piece of evidence used in the identity proofing process.</li>
      <li><strong>Transaction Analytics</strong> – Evaluate anticipated transaction characteristics – such as IP Addresses, geolocations, and transaction velocities – to identify anomalous behaviors or activities that can indicate a higher risk or a potentially fraudulent event. Such checks can provide protections against scaled and automated attacks, as well as give indications of specific attack patterns being executed on identity systems.</li>
      <li><strong>Fraud Indicator Check</strong> – Evaluate records, such as reported, confirmed, or historical fraud events to determine if there is an elevated risk related to a specific applicant, applicant’s data, or device. Such checks can give an indication of identity theft or compromise. Where such information is collected, aggregated, or exchanged across commercial platforms and made available for use to RPs and other CSPs, users <strong>SHALL</strong> be made aware of this practice. This also applies to all websites that report user activity to Federal RPs.</li>
    </ul>
  </li>
  <li>CSPs <strong>MAY</strong> employ knowledge-based verification (KBV) as part of its fraud management program.</li>
  <li>CSPs <strong>SHOULD</strong> consider the recency of fraud-related data when factoring it into fraud prevention capabilities and decisions.</li>
  <li>For attended proofing processes, CSPs <strong>SHALL</strong> train proofing agents to detect indicators of fraud and <strong>SHALL</strong> provide proofing agents and trusted referees with tools to flag suspected fraudulent events for further treatment and investigation.</li>
  <li>CSPs <strong>SHALL</strong> continuously monitor the performance of their fraud checks and fraud mitigation technologies to identify and remediate issues related to disparate performance across their platforms or between the demographic groups served by their identity service.</li>
  <li>CSPs <strong>SHALL</strong> establish a technical or process-based mechanism to communicate suspected and confirmed fraudulent events to RPs.</li>
  <li>CSPs <strong>SHOULD</strong> implement shared signaling, as described in NIST SP 800-63C-4, to communicate fraud events in real time to RPs.</li>
  <li>CSPs <strong>MAY</strong> implement fraud mitigation measures as compensating controls. When this is done, these <strong>SHALL</strong> be documented as deviations from the normative guidance of these guidelines and <strong>SHALL</strong> be conveyed to all RPs through a Digital Identity Acceptance Statement prior to integration.</li>
</ol>
<h4 id="rp-fraud-management" data-section="3">
  
  
    RP Fraud Management <a href="#rp-fraud-management" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<ol>
  <li>RPs <strong>SHALL</strong> establish a point of contact with whom CSPs interact and communicate fraud data.</li>
  <li>Pursuant to a privacy risk assessment, the RP <strong>MAY</strong> also request additional attributes beyond what a CSP provides as its core attributes to combat fraud or to support other business processes.</li>
  <li>Pursuant to applicable laws and regulations, RPs <strong>SHOULD</strong> establish a mechanism to communicate the outcomes of fraud reports and investigations, including both positive and negative results, to CSPs and other partners in order to allow them to improve their own fraud identification, mitigation, and reporting capabilities.</li>
  <li>RPs <strong>SHOULD</strong> establish a fraud management program consistent with their mission, regulatory environment, systems, applications, data, and resources.</li>
  <li>RPs <strong>SHALL</strong> conduct a privacy risk assessment of any CSP fraud checks and mitigation technologies to identify potential privacy risks or unintended harms. Federal agency RPs <strong>SHALL</strong> implement this consistent with the requirements contained in <a href="/800-63-4/sp800-63a/ial-general/#Feds">Sec. 3.1.7</a>.</li>
  <li>RPs <strong>SHALL</strong> include any requirements for fraud checks and fraud mitigation technologies in trust agreements with their CSPs.</li>
  <li>RPs <strong>SHALL</strong> conduct periodic reviews of their CSP’s fraud management program, fraud checks, and fraud technologies to adjust thresholds, review investigations into fraud events, and make determinations about the effectiveness and efficacy of fraud controls.</li>
  <li>RPs <strong>SHALL</strong> review all fraud mitigation measures that have been deployed as compensating or supplemental controls by CSPs for alignment to their internal risk tolerance and acceptance. The RP <strong>SHALL</strong> record the CSPs compensating controls in their own Digital Identity Acceptance Statement prior to integration.</li>
</ol>
<h4 id="treatment-of-fraud-check-failures" data-section="3">
  
  
    Treatment of Fraud Check Failures <a href="#treatment-of-fraud-check-failures" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>The effectiveness of fraud checks and mitigation technologies will vary based on numerous contributing factors including the data sources used, the technologies used, and – perhaps most importantly – the applicant population. It is therefore critical to have well-structured and documented processes for how to handle failures arising from the fraud management measures. The following requirements apply to handling these failures:</p>

<ol>
  <li>CSPs <strong>SHALL</strong> establish and document thresholds and actions related to each of the fraud checks they implement and provide these thresholds to RPs.</li>
  <li>CSPs <strong>SHALL</strong> establish procedures for redress to allow applicants to resolve issues associated with fraud checks and mitigation technologies. See (see <a href="/800-63-4/sp800-63/dirm/#redress" latex-href="#ref-SP800-63">Sec. 3.6 of [SP800-63]</a>) for a more information about redress.</li>
  <li>The CSP <strong>SHALL</strong> offer trusted referee services to those who fail fraud checks in unattended remote processes. Trusted referees <strong>SHALL</strong> be provided with a summary of the results of the fraud failures to inform their risk-based decisioning processes.</li>
</ol>

<div latex-literal="true" class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>\clearpage
</code></pre></div></div>
<h3 id="PrivacyReqs" data-section="3">
  
  
    General Privacy Requirements <a href="#PrivacyReqs" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>The following privacy requirements apply to all CSPs providing identity services at any IAL.</p>
<h4 id="PrivRiskAssess" data-section="3">
  
  
    Privacy Risk Assessment <a href="#PrivRiskAssess" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<ol>
  <li>The CSP <strong>SHALL</strong> conduct and document a privacy risk assessment for the processes used for identity proofing and enrollment.<sup id="fnref:privacyframework" role="doc-noteref"><a href="#fn:privacyframework" class="footnote">2</a></sup>  At a minimum, the privacy risk assessment <strong>SHALL</strong> assess the risks associated with:
    <ol class="letter-list">
      <li>Any processing of PII - including identity attributes, biometrics, images, video, scans, or copies of identity evidence - for the purposes of identity proofing, enrollment, or fraud management;</li>
      <li>Any additional steps that the CSP takes to verify the identity of an applicant beyond the mandatory requirements specified herein;</li>
      <li>Any processing of PII for purposes outside the scope of identity proofing and enrollment, except to comply with law or legal processes;</li>
      <li>The retention schedule for identity records and PII;</li>
      <li>Any non-PII that, when aggregated or processed by an algorithm ( e.g., artificial intelligence or machine learning tools), could be used to identify a person; and,</li>
      <li>Any PII that is processed by a third-party service on behalf of the CSP.</li>
    </ol>
  </li>
  <li>Based on the results of its privacy risk assessment, the CSP <strong>SHALL</strong> document the measures it takes to maintain the disassociability, predictability, manageability, confidentiality, integrity, and availability of the PII it processes. <sup id="fnref:NISTIR8062" role="doc-noteref"><a href="#fn:NISTIR8062" class="footnote">3</a></sup> In determining such measures, the CSP <strong>SHOULD</strong> apply relevant guidance and standards, such as the <em>NIST Privacy Framework</em> <a href="/800-63-4/sp800-63a/references/#ref-NIST-Privacy">[NIST-Privacy]</a> and NIST Special Publication <a href="/800-63-4/sp800-63a/references/#ref-SP800-53">[SP800-53]</a>.</li>
  <li>The CSP <strong>SHALL</strong> re-assess privacy risks and update its privacy risk assessment any time it makes changes to its identity service that affect the processing of PII.</li>
  <li>The CSP <strong>SHALL</strong> review its privacy risk assessment periodically, as documented in its practice statement, to ensure that it accurately reflects the current risks associated with the processing of PII.</li>
  <li>The CSP <strong>SHALL</strong> make a summary of its privacy risk assessment available to any organizations that use its services. The summary <strong>SHALL</strong> be in sufficient detail to enable such organizations to do a due diligence investigation.</li>
  <li>The CSP <strong>SHALL</strong> perform a privacy risk assessment for the processing of any personal information maintained in the subscriber account <a href="/800-63-4/sp800-63a/accounts/#accounts">Sec. 5</a>.</li>
</ol>
<h4 id="AddlPrivacy" data-section="3">
  
  
    Additional Privacy Protective Measures <a href="#AddlPrivacy" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<ol>
  <li>The processing of PII <strong>SHALL</strong> be limited to the minimum necessary to validate the existence of the claimed identity, associate the claimed identity with the applicant, mitigate fraud, and provide RPs with attributes that they may use to make authorization decisions.</li>
  <li>The CSP <strong>SHALL</strong> provide privacy training to all personnel and any third-party service providers who have access to sensitive information associated with the CSP’s identity service.</li>
  <li>The CSP <strong>MAY</strong> collect the Social Security Number (SSN) as an attribute when necessary for identity resolution, in accordance with the privacy requirements in <a href="/800-63-4/sp800-63a/ial-general/#PrivacyReqs">Sec. 3.1.3</a>. If SSNs are collected, CSPs <strong>SHOULD</strong> implement privacy protective techniques (e.g., transmitting and accepting derived attribute values rather than full attribute values) to limit the proliferation and retention of SSN data. Knowledge of an SSN is not sufficient to act as evidence of identity nor is it considered an acceptable method of verifying possession of the Social Security Card when used as evidence. If the SSN is collected on behalf of a federal, state, or local government agency, the CSP <strong>SHALL</strong> provide notice to the applicant for the collection in accordance with applicable laws.</li>
  <li>At the time of collection, the CSP <strong>SHALL</strong> provide explicit notice to the applicant regarding the purpose for collecting the PII and attributes necessary for identity proofing, enrollment, and fraud mitigation, including whether such PII and attributes are voluntary or mandatory to complete the identity proofing process, the specific attributes and other sensitive data that the CSP intends to store in the applicant’s subsequent subscriber account, the consequences for not providing the attributes, and the details of any records retention requirement if one is in place.</li>
</ol>
<h3 id="EquityReqs" data-section="3">
  
  
    General Equity Requirements <a href="#EquityReqs" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>In support of the goal of improved equity, and as part of its overall risk assessment process, CSPs assess the elements of their identity services to identify processes and technologies that may result in inequitable access, treatment, or outcomes for members of one group as compared to others. Where risks to equity are identified, CSPs proactively employ mitigations that will reduce or eliminate these discrepancies between demographic groups. <a href="/800-63-4/sp800-63a/equity/#equity">Sec. 9</a> of this document provides a non-exhaustive list of identity proofing processes and technologies that may be subject to inequitable access or outcomes, as well as possible mitigations.</p>

<p>Executive order <a href="/800-63-4/sp800-63a/references/#ref-EO13985">[EO13985]</a>, <em>Advancing Racial Equity and Support for Underserved Communities Through the Federal Government</em>, requires each federal agency to assess whether, and to what extent, its programs and policies perpetuate systemic barriers to opportunities and benefits for people of color and other underserved groups. Additionally, executive order <a href="/800-63-4/sp800-63a/references/#ref-EO13988">[EO13988]</a>, <em>Preventing and Combating Discrimination on the Basis of Gender Identity or Sexual Orientation</em>, sets policy that all persons are be treated with respect, regardless of gender identity or sexual orientation, and requires agencies to enforce this prohibition on sex discrimination.</p>

<p>CSPs <strong>SHOULD</strong> review the methods of assessment, data collection, and redress outlined in OMB Report, <em>A Vision for Equitable Data: Recommendations from the Equitable Data Working Group</em> <a href="/800-63-4/sp800-63a/references/#ref-EO13985-vision">[EO13985-vision]</a> for the development of its equity assessment policy and practices.</p>

<p>The following requirements apply to all CSPs providing identity services at any IAL:</p>

<ol>
  <li>The CSP <strong>SHALL</strong> assess the elements of its identity proofing process(es) to identify processes or technologies that can result in inequitable access, treatment, or outcomes for members of one group as compared to others.</li>
  <li>Based on the results of its assessment, the CSP <strong>SHALL</strong> document the measures it takes to mitigate the possibility of inequitable access, treatment, or outcomes.</li>
  <li>The CSP <strong>SHALL</strong> re-assess the risks to equitable access, treatment, or outcomes periodically and any time the CSP makes changes to its identity service that affect the processes or technologies.</li>
  <li>The CSP <strong>SHALL NOT</strong> make applicant participation in these risk assessments mandatory.</li>
  <li>The CSP <strong>SHALL</strong> make the results of its equity assessment, including any associated mitigations, publicly available.</li>
</ol>
<h3 id="SecurityReqs" data-section="3">
  
  
    General Security Requirements <a href="#SecurityReqs" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>Each online transaction within the identity proofing process, including transactions that involve third parties, <strong>SHALL</strong> occur over an authenticated protected channel.</li>
  <li>The CSP <strong>SHALL</strong> implement a means to prevent automated attacks on the identity proofing process. Acceptable means include, but are not limited to: bot detection, mitigation, and management solutions; behavioral analytics<sup id="fnref:behavioral" role="doc-noteref"><a href="#fn:behavioral" class="footnote">4</a></sup>; web application firewall settings; and network traffic analysis.</li>
  <li>All PII collected as part of the identity proofing process <strong>SHALL</strong> be protected to maintain the confidentiality and integrity of the information, including the encryption of data at rest and the exchange of information using authenticated protected channels.</li>
  <li>The CSP <strong>SHALL</strong> assess the risks associated with operating its identity service, according to the NIST <em>Risk Management Framework</em> <a href="/800-63-4/sp800-63a/references/#ref-NIST-RMF">[NIST-RMF]</a> or equivalent risk management guidelines. At a minimum, the CSP <strong>SHALL</strong> apply appropriate controls consistent with <a href="/800-63-4/sp800-63a/references/#ref-SP800-53">[SP800-53]</a> moderate baseline, regardless of IAL.</li>
  <li>The CSP <strong>SHOULD</strong> assess risks associated with its use of third-party services and apply appropriate controls, as provided in the <a href="/800-63-4/sp800-63a/references/#ref-SP800-161">[SP800-161]</a> <em>Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations</em>.</li>
</ol>
<h3 id="redress" data-section="3">
  
  
    Redress Requirements <a href="#redress" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>The CSP <strong>SHALL</strong> provide mechanisms for the redress of applicant complaints and for problems arising from the identity proofing process, including but not limited to: proofing failures, delays, and difficulties.</li>
  <li>These mechanisms <strong>SHALL</strong> be easy for applicants to find and use.</li>
  <li>The CSP <strong>SHALL</strong> assess the mechanisms for their efficacy in achieving a resolution of complaints or problems.</li>
</ol>

<p>See <a href="/800-63-4/sp800-63/dirm/#redress" latex-href="#ref-SP800-63">Sec. 3.6 of [SP800-63]</a> for more information about redress.</p>
<h3 id="Feds" data-section="3">
  
  
    Additional Requirements for Federal Agencies <a href="#Feds" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>The following requirements apply to federal agencies, regardless of whether they operate their own identity service or use an external CSP as part of their identity service:</p>

<ol>
  <li>The agency <strong>SHALL</strong> consult with their Senior Agency Official for Privacy (SAOP) to conduct an analysis determining whether the collection of PII, including biometrics, to conduct identity proofing triggers Privacy Act requirements.</li>
  <li>The agency <strong>SHALL</strong> consult with their SAOP to conduct an analysis determining whether the collection of PII, including biometrics, to conduct identity proofing triggers E-Government Act of 2002 <a href="/800-63-4/sp800-63a/references/#ref-E-Gov">[E-Gov]</a> requirements.</li>
  <li>The agency <strong>SHALL</strong> publish a System of Records Notice (SORN) to cover such collection, as applicable.<sup id="fnref:SORN" role="doc-noteref"><a href="#fn:SORN" class="footnote">5</a></sup></li>
  <li>The agency <strong>SHALL</strong> publish a Privacy Impact Assessment (PIA) to cover such collection, as applicable.</li>
  <li>The agency <strong>SHALL</strong> consult with the senior official, office, or governance body responsible for diversity, equity, inclusion, and accessibility (DEIA) for their agency to determine how the identity proofing service can meet the needs of all served populations.</li>
  <li>The agency <strong>SHOULD</strong> consult with public affairs and communications professionals within their organization to determine if a communications or public awareness strategy should be developed to accompany the roll-out of any new process, or an update to an existing process, including requirements associated with identity proofing. This may include materials detailing information about how to use the technology associated with the service, a Frequently Asked Questions (FAQs) page, prerequisites to participate in the identity proofing process (such as required evidence), webinars or other live or pre-recorded information sessions, or other media to support adoption of the identity service and provide applicants with a mechanism to communicate questions, issues, and feedback.</li>
  <li>If the agency uses a third-party CSP, the agency SHALL conduct its own privacy risk assessment as part of its PIA process, using the CSP’s privacy risk assessment as input to the agency’s assessment.</li>
  <li>If the agency uses a third-party CSP, the agency <strong>SHALL</strong> incorporate the CSP’s assessment of equity risks into its own assessment of equity risks.</li>
</ol>
<h3 id="ConfirmCodes" data-section="3">
  
  
    Requirements for Confirmation Codes <a href="#ConfirmCodes" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>This section includes requirements for CSPs that support the use of confirmation codes.</p>

<p>Confirmation codes are used to confirm that an applicant has access to a postal address, email address, or phone number, for the purposes of future communications. They are also used as an identity verification option at IALs 1 and 2, as described in <a href="/800-63-4/sp800-63a/proofing/#verification">Sec. 2.5.1</a>.</p>

<p>Confirmation codes used for these purposes <strong>SHALL</strong> include at least 6 decimal digits (or equivalent) from an approved random bit generator (see <a href="/800-63-4/sp800-63b/authenticators/#randomness" latex-href="#ref-SP800-63B">Sec. 3.2.12 of [SP800-63B]</a>). The confirmation code may be presented as numeric or alphanumeric (e.g., Base64) for manual entry; a secure (e.g., https) link containing a representation of the confirmation code; or a machine-readable optical label, such as a QR code, containing the confirmation code.</p>

<p>Confirmation codes <strong>SHALL</strong> be valid for at most:</p>

<ul>
  <li>21 days, when sent to a validated postal address within the contiguous United States;</li>
  <li>30 days, when sent to a validated postal address outside the contiguous United States;</li>
  <li>10 minutes, when sent to a validated telephone number (SMS or voice); or</li>
  <li>24 hours, when sent to a validated email address.</li>
</ul>

<p>Upon its use, the CSP <strong>SHALL</strong> invalidate the confirmation code.</p>
<h3 id="ContinueCodes" data-section="3">
  
  
    Requirements for Continuation Codes <a href="#ContinueCodes" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>This section includes requirements for CSPs that support the use of continuation codes.</p>

<p>Continuation codes are used to re-establish an applicant’s linkage to an incomplete identity proofing or enrollment process. CSPs <strong>MAY</strong> use continuation codes when an applicant is unable to complete all the steps necessary to be successfully identity proofed and enrolled into the CSP’s identity service in a single session, or when switching between different identity proofing types (such as from remote unattended to remote attended). Continuation codes are intended to be maintained offline (e.g., printed or written down) and stored in a secure location by the applicant for use in re-establishing linkage to a previous, incomplete session.</p>

<p>In order to facilitate the authentication of the applicant to a subsequent session, the CSP <strong>SHALL</strong> first bind an authenticator to a record or account established for the applicant prior to the cessation of the initial session. Continuation codes <strong>SHALL</strong> include at least 64 bits from an approved random bit generator (see <a href="/800-63-4/sp800-63b/authenticators/#randomness" latex-href="#ref-SP800-63B">Sec. 3.2.12 of [SP800-63B]</a>). The continuation code <strong>MAY</strong> be presented as numeric or alphanumeric (e.g., Base64) for manual entry, or as a machine-readable optical label, such as a QR code containing the continuation code.</p>

<p>Verification of continuation codes <strong>SHALL</strong> be subject to throttling requirements, as provided in <a href="/800-63-4/sp800-63b/authenticators/#throttle" latex-href="#ref-SP800-63B">Sec. 3.2.2 of [SP800-63B]</a>. Continuation codes <strong>SHALL</strong> be stored in hashed form, using a FIPS-approved or NIST recommended one-way function. Upon its use, the CSP <strong>SHALL</strong> invalidate the continuation code.</p>
<h3 id="ProofingNotifs" data-section="3">
  
  
    Requirements for Notifications of Identity Proofing <a href="#ProofingNotifs" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Notifications of proofing are sent to the applicant’s validated address notifying them that they have been successfully identity proofed and provide information about the identity proofing event and subsequent enrollment, including how the recipient can repudiate they were the subject of the identity proofing.</p>

<p>The following requirements apply to CSPs and RPs that send notifications of proofing at any IAL.</p>

<p>Notifications of proofing:</p>

<ol>
  <li><strong>SHALL</strong> be sent to a validated postal address, email address, or phone number.</li>
  <li><strong>SHALL</strong> include details about the identity proofing event, including the name of the identity service and the date the identity proofing was completed.</li>
  <li><strong>SHALL</strong> provide clear instructions, including contact information, on actions for the recipient to take in the case that they repudiate the identity proofing event.</li>
  <li><strong>SHALL</strong> provide additional information, such as how the organization or CSP protects the security and privacy of the information it collects and any responsibilities that the recipient has as a subscriber of the identity service.</li>
  <li><strong>SHOULD</strong> provide instructions on how to access their subscriber account or information about how the subscriber can update the information contained in that account.</li>
</ol>

<p>In the event a subscriber repudiates having been identity proofed by the identity service, the CSP or RP <strong>SHALL</strong> respond in accordance to its fraud management program (<a href="/800-63-4/sp800-63a/ial-general/#FraudMgmt">Sec. 3.1.2</a>).</p>
<h3 id="ProofBios" data-section="3">
  
  
    Requirements for the Use of Biometrics <a href="#ProofBios" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Biometrics is the automated recognition of individuals based on their biological and behavioral characteristics such as, but not limited to, fingerprints, voice patterns, or facial features (biological characteristics), and keystroke patterns, angle of holding a smart phone, screen pressure, typing speed, mouse movements, or gait (behavioral characteristics).  As used in these guidelines, biometric data refers to any analog or digital representation of biological and behavioral characteristics at any stage of their capture, storage, or processing. This includes live biometric samples from applicants (e.g., facial images, fingerprint), as well as biometric references obtained from evidence (e.g., facial image on a driver’s license, fingerprint minutiae template on identification cards). As applied to the identity proofing process, CSPs can use biometrics to verify that an individual is the rightful subject of identity evidence, to bind an individual to a new piece of identity evidence or credential, or for the purposes of fraud detection.</p>

<p>The following requirements apply to CSPs that employ biometrics as part of their identity proofing process:</p>

<ol>
  <li>CSPs <strong>SHALL</strong> provide clear, publicly available information about all uses of biometrics, what biometric data is collected, how it is stored, how it is protected, and information on how to remove biometric information consistent with applicable laws and regulations.</li>
  <li>CSPs <strong>SHALL</strong> collect an explicit biometric consent from all applicants before collecting biometric information.</li>
  <li>CSPs <strong>SHALL</strong> store a record of subscriber’s consent for biometric use and associate it with subscriber’s account.</li>
  <li>CSPs <strong>SHALL</strong> have a documented, and publicly available, deletion process and default retention period for all biometric information.</li>
  <li>CSPs <strong>SHALL</strong> support the deletion of all of a subscriber’s biometric information upon the subscriber’s request at any time, except where otherwise restricted by regulation, law, or statute.</li>
  <li>CSPs <strong>SHALL</strong> have their biometric algorithms periodically tested by independent entities (e.g., accredited laboratories or research institutions) for their performance characteristics, including performance across demographic groups. At a minimum, the CSP <strong>SHALL</strong> have an algorithm retested after it has been updated.</li>
  <li>CSPs <strong>SHALL</strong> assess the performance and demographic impacts of employed biometric technologies in conditions that are substantially similar to the operational environment and user base of the system. The user base is defined by both the demographic characteristics of the expected users as well as the devices they are expected to use. When such assessments include real-world users, participation by users <strong>SHALL</strong> be voluntary.</li>
  <li>CSPs <strong>SHALL</strong> meet the following minimum performance thresholds for biometric usage in verification scenarios:
    <ul>
      <li>False match rate: 1:10,000 or better; and</li>
      <li>False non-match rate: 1:100 or better</li>
    </ul>
  </li>
  <li>CSPs <strong>MAY</strong> use 1:N matching in support of resolution or fraud detection, pursuant to a privacy risk assessment. In 1:N scenarios, CSPs <strong>SHALL</strong> meet a minimum performance threshold for false positive identifications of 1:1,000. This applies to, and <strong>SHALL</strong> be tested for, each demographic group. Tests demonstrating this requirement <strong>SHALL</strong> employ a gallery no smaller than 90% of the current or intended operational size (N).</li>
  <li>CSPs that make use of 1:N biometric matching for either resolution or fraud prevention purposes <strong>SHALL NOT</strong> decline a user’s enrollment without a manual review by a trained proofing agent or trusted referee to confirm the automated matching results and confirm the results are not a false positive identification (for example, twins submitting for different accounts with the same CSP).</li>
  <li>CSPs <strong>SHALL</strong> employ biometric technologies that provide similar performance characteristics for applicants of different demographic groups (age, race, sex, etc.). If significant performance differences across demographic groups are discovered, CSPs <strong>SHALL</strong> act expeditiously to provide redress options to affected individuals and to close performance gaps.</li>
  <li>All biometric performance tests <strong>SHALL</strong> be conformant to ISO/IEC 19795-1:2021 and ISO/IEC 19795-10:2024, including demographics testing.</li>
  <li>CSPs <strong>SHALL</strong> make performance and operational test results publicly available.</li>
</ol>

<p>The following requirements apply to CSPs who collect biometric characteristics from applicants:</p>

<ol>
  <li>CSP <strong>SHALL</strong> collect biometrics in such a way that provides reasonable assurance that the biometric is collected from the applicant, and not another subject.</li>
  <li>When collecting and comparing biometrics remotely, the CSP <strong>SHALL</strong> implement presentation attack detection (PAD) capabilities, which meet IAPAR performance metric &lt;0.15, to confirm the genuine presence of a live human being and to mitigate spoofing and impersonation attempts.</li>
  <li>When collecting biometrics onsite, the CSP <strong>SHALL</strong> have the operator view the biometric source (e.g., fingers, face) for the presence of non-natural materials and perform such inspections as part of the proofing process. All biometric presentation attack detection tests <strong>SHALL</strong> be conformant to ISO/IEC 30107-3:2023</li>
</ol>
<h3 id="requirements-for-evidence-validation-processes-authenticity-checks" data-section="3">
  
  
    Requirements for Evidence Validation Processes (Authenticity Checks) <a href="#requirements-for-evidence-validation-processes-authenticity-checks" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Evidence validation can be conducted by remote optical capture and inspection (often called document authentication or doc auth) or conducted by visual inspection of a trained proofing agent or trusted referee. CSPs may employ either or both processes for evaluating the authenticity of identity evidence.</p>

<p>The following requirements apply to CSPs that employ optical capture and inspection for the purposes of determining document authenticity:</p>

<ol>
  <li>Automated evidence validation technology <strong>SHALL</strong> meet the following performance measures:
    <ul>
      <li>Document false acceptance rate (DFAR) of .10 or less. <sup id="fnref:Note_DFAR" role="doc-noteref"><a href="#fn:Note_DFAR" class="footnote">6</a></sup></li>
      <li>Document false rejection rate (DFRR) of .10 or less. <sup id="fnref:Note_DFRR" role="doc-noteref"><a href="#fn:Note_DFRR" class="footnote">7</a></sup></li>
    </ul>
  </li>
  <li>If a Machine Readable Zone (MRZ) or barcode is present on the evidence, the optical capture and inspection <strong>SHALL</strong> compare the MRZ data to the printed data on the evidence for consistency.</li>
  <li>CSPs <strong>SHALL</strong> implement live capture of documents during the validation process. CSPs <strong>SHOULD</strong> deploy technology controls to prevent the injection of document images, for example using document presence checks (also called document liveness) or inspecting device characteristics to determine the presence of a virtual camera or device emulator.</li>
  <li>CSPs <strong>SHALL</strong> assess the performance of employed optical capture and inspection technologies in conditions that are substantially similar to the operational environment and user base of the system. These tests <strong>SHALL</strong> account for all available identity evidence types that the CSPs allow to be validated using optical capture and inspection technology. Where subscribers’ documents, PII, or images are used as part of the testing, it <strong>SHALL</strong> be on a voluntary basis and with subscriber notification and consent.</li>
  <li>CSPs <strong>SHOULD</strong> have their evidence validation technology periodically tested by independent entities (e.g., accredited laboratories or research institutions) for their performance characteristics.</li>
  <li>CSPs <strong>SHALL</strong> make the results of their testing available publicly.</li>
</ol>

<blockquote>
  <p><strong>Note:</strong> These requirements apply to technologies that capture and validate images of physical identity evidence. They do not apply to validation techniques that rely on PKI or other cryptographic technologies that are embedded in the evidence themselves.</p>
</blockquote>

<p>The following requirements apply to CSPs that employ visual inspection of evidence by trained proofing agents or trusted referees for the purposes of determining document authenticity:</p>

<ol>
  <li>Proofing agents and trusted referees <strong>SHALL</strong> be trained and provided resources to visually inspect all forms of evidence supported by the CSP. This training <strong>SHALL</strong> include:
    <ul>
      <li>Authentic layouts and topography of evidence types</li>
      <li>Physical security features (e.g., raised letters, holographic features, microprinting)</li>
      <li>Techniques for assessing features (e.g., tools to be used, where tactile inspection is needed, manipulation to view specific features)</li>
      <li>Common indications of tampering (e.g., damage to the lamination, image modification)</li>
    </ul>
  </li>
  <li>When the setting allows for it (e.g., onsite attended proofing events), proofing agents and trusted referees <strong>SHALL</strong> be provided with specialized tools and equipment to support the visual inspection of evidence (e.g., magnifiers, ultraviolet lights, barcode readers).</li>
  <li>Proofing agents and trusted referees who conduct visual inspection via remote means <strong>SHALL</strong> be provided with devices and internet connections that support sufficiently high-quality imagery to be able to effectively inspect presented evidence. In these instances, the visual validation <strong>SHOULD</strong> be supported by automated document validation technologies that provide additional confidence in the authenticity of the evidence (e.g., submitting and validating evidence in advance of an attended remote session)</li>
  <li>Proofing agents and trusted referees <strong>SHALL</strong> be reviewed regarding their ability to visually inspect evidence on an ongoing basis, and be assessed and certified with at least annual evaluations.</li>
</ol>

<blockquote>
  <p><strong>Note:</strong> Due to the potential number and permutations of identity evidence, these guidelines do not attempt to provide a comprehensive list of security features. CSPs need to provide evidence validation training specific to the types of identity evidence they accept.</p>
</blockquote>
<h3 id="TRs-ARs" data-section="3">
  
  
    Exception and Error Handling <a href="#TRs-ARs" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Throughout the identity proofing process there are many points where errors or failures may occur. Such exceptions to a standard identity proofing workflow include: process failures, such as when a user does not possess the required evidence; technical failures, such as when an integrated service is not available; and failures due to user error, such as when an applicant is unable to capture a clear image of their identity evidence when using remote validation tools.</p>

<p>In order to increase the accessibility, usability, and equity of their identity proofing services, CSPs <strong>SHALL</strong> document their operational processes for dealing with errors and handling exceptions. These documented processes <strong>SHALL</strong> include providing trusted referees to support those applicants who are otherwise unable to meet the requirements of IALs 1 and 2. Additionally, CSPs <strong>SHOULD</strong> support the use of applicant references who can vouch for an applicant’s attributes, conditions, or identity.</p>
<h4 id="TRs" data-section="3">
  
  
    Trusted Referees Requirements <a href="#TRs" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>To increase accessibility and promote equal access to online government services, CSPs provide trusted referees. Trusted referees are used to facilitate the identity proofing and enrollment of individuals who are otherwise unable to meet the requirements for identity proofing to a specific IAL. A non-exhaustive list of examples of such individuals and demographic groups includes: individuals who do not possess and cannot obtain the required identity evidence; persons with disabilities; older individuals; persons experiencing homelessness; individuals with little or no access to online services or computing devices; persons without a bank account or with limited credit history; victims of identity theft; individuals displaced or affected by natural disasters; and children under 18. The following requirements apply to the use of trusted referees:</p>

<ol>
  <li>The CSP <strong>SHALL</strong> provide notification to the public of the availability of trusted referee services and how such services are obtained.</li>
  <li>The CSP <strong>SHALL</strong> establish written policies and procedures for the use of trusted referees as part of its practice statement, as specified in <a href="/800-63-4/sp800-63a/ial-general/#DocRecReqs">Sec. 3.1.1</a>.</li>
  <li>The CSP <strong>SHALL</strong> train and certify its trusted referees to make risk-based decisions that allow applicants to be successfully identity proofed based on their unique circumstances. At a minimum such training <strong>SHALL</strong> include:
    <ol>
      <li>Document identification and validation, such as common templates, security features, layouts, and topography.</li>
      <li>Indicators of fraudulent documents, such as damage, tampering, modification, and material types</li>
      <li>Facial and image comparisons to conduct verification of applicants against presented documents</li>
      <li>Indicators of social engineering - such as distress, confusion, or coercion - exhibited by an applicant</li>
      <li>Annual recertification of the trusted referee’s capabilities</li>
    </ol>
  </li>
  <li>The CSP <strong>SHALL</strong> establish a record of any identity proofing session that involves a trusted referee, to include: what evidence was presented; which processes were completed (e.g., validation or verification); and, the reason(s) why a trusted referee was used (e.g., automated process failure, applicant request, established exception policy).</li>
  <li>The CSP <strong>MAY</strong> offer trusted referee services for either onsite-attended or remote-attended sessions. These sessions <strong>SHALL</strong> be consistent with the requirements of these proofing types based on the IAL of the proofing event.</li>
</ol>
<h4 id="trusted-referee-uses" data-section="3">
  
  
    Trusted Referee Uses <a href="#trusted-referee-uses" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>Trusted referees offer a critical path for those who are unable to complete identity proofing by other means. However, given the number of possible failures that may occur within the proofing process, it is essential for CSPs to define the uses for which a trusted referee can be applied within their own service offerings. The following requirements apply to defining the integration of trusted referees into the identity proofing process:</p>

<ol>
  <li>CSPs <strong>SHALL</strong> document which types of exceptions and failures are eligible for the use of a trusted referee.</li>
  <li>CSPs <strong>SHALL</strong> offer trusted referee services for failures of automated verification processes (e.g., biometric comparisons).</li>
  <li>CSPs <strong>SHOULD</strong> offer trusted referee services for failures in completing automated validation processes, such as in cases of mismatched core attributes or the absence of the applicant in a record source.
    <ol>
      <li>CSPs <strong>SHALL</strong> provide a policy for additional evidence types that may be used to corroborate core attributes or changes in core attributes.</li>
      <li>Trusted referees <strong>SHALL</strong> review additional evidence types for authenticity to the greatest degree allowed by the evidence.</li>
      <li>If no authoritative or credible records are available to support validation, the trusted referee <strong>MAY</strong> compare the attributes on additional pieces of evidence with the strongest piece of evidence available to corroborate the consistency of core attributes.</li>
      <li>If there is a partial mismatch of core attributes to authoritative records, the trusted referee <strong>SHALL</strong> review evidence that supports the legitimacy of the asserted attribute value (e.g., recent move or change of name).</li>
    </ol>
  </li>
</ol>
<h4 id="ARs" data-section="3">
  
  
    Applicant Reference Requirements <a href="#ARs" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>Applicant references are individuals who participate in the identity proofing of an applicant in order to vouch for the applicant’s identity, attributes, or circumstances related to the applicant’s ability to complete identity proofing. Applicant representatives are not agents of the CSP, but instead are representatives of the applicant who have sufficient knowledge to aide in the completion of identity proofing when other forms of evidence, validation, and verification are not available.</p>

<p>The following requirements apply to the use of applicant references at IAL1 or IAL2:</p>

<ol>
  <li>The CSP <strong>SHALL</strong> provide notification to the public of the allowability of applicant references and any requirements for the relationship between the reference and an applicant.</li>
  <li>The CSP <strong>SHALL</strong> establish written policies and procedures for the use of applicant references as part of its practice statement, as specified in <a href="/800-63-4/sp800-63a/ial-general/#DocRecReqs">Sec. 3.1.1</a>.</li>
  <li>The CSP <strong>SHALL</strong> identity proof an applicant reference to the same or higher IAL intended for the applicant. The CSP <strong>SHALL</strong> include the information collected, recorded, and retained for identity proofing the applicant references in its privacy risk assessment for identity proofing applicants, as required in section <a href="/800-63-4/sp800-63a/ial-general/#PrivacyReqs">Sec. 3.1.3</a>.</li>
  <li>The CSP <strong>SHALL</strong> record the use of an applicant reference in the subscriber account as well as maintain a record of the applicant reference and their relationship to the applicant.</li>
  <li>The RP <strong>SHALL</strong> conduct a risk assessment to determine the applicability, business requirements, and potential risks associated with excluding or including applicant references for proofing events.</li>
</ol>
<h4 id="uses-of-applicant-references" data-section="3">
  
  
    Uses of Applicant References <a href="#uses-of-applicant-references" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>Applicant references may take several different actions to support an applicant in the identity proofing process. CSPs and RPs <strong>SHALL</strong> establish all acceptable uses for applicant references in their Trust Agreements. These <strong>MAY</strong> include the following:</p>

<ol>
  <li>The applicant reference <strong>MAY</strong> vouch for one or more claimed core attributes relative to the applicant as part of evidence and attribute validation process.</li>
  <li>The applicant reference <strong>MAY</strong> vouch for a specific condition or status of an applicant relative to the identity proofing process (e.g., homelessness, disaster scenarios)
    <blockquote>
      <p><strong>Note:</strong> This information is intended to support risk determinations relative to the identity proofing event. Use of applicant reference statements relative to eligibility for status or benefits is outside the scope of these guidelines.</p>
    </blockquote>
  </li>
  <li>The applicant reference <strong>MAY</strong> vouch for the identity of the applicant in the absence of sufficient identity evidence.</li>
</ol>

<p>In all instances, the CSP <strong>SHALL</strong> establish a record of the role the applicant reference played in the process and document these actions sufficient to support any applicable legal and regulatory requirements. This <strong>MAY</strong> include:</p>

<ol>
  <li>Capturing and recording the statements and assertions made by the applicant reference;</li>
  <li>Capturing an electronic, digital signature, or physical signature of the applicant reference; or,</li>
  <li>Capturing consent and acknowledgement relative to the legal and liability impacts of the applicant reference’s statements.</li>
</ol>

<p>CSPs <strong>SHALL</strong> make available to the applicant reference clear and understandable information relative to the legal and liability impacts that may result from their participation as an applicant reference.</p>
<h4 id="establishing-applicant-reference-relationships" data-section="3">
  
  
    Establishing Applicant Reference Relationships <a href="#establishing-applicant-reference-relationships" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>In many cases, there will be business, legal, or fraud prevention reasons to confirm the relationship between the applicant and an applicant reference. Where such steps are deemed necessary by a risk assessment, the following requirements <strong>SHALL</strong> apply:</p>

<ol>
  <li>The CSP and RP <strong>SHALL</strong> establish requirements for applicant reference relationship confirmation processes and document this in any Trust Agreements.</li>
  <li>The CSP <strong>SHALL</strong> make a list of acceptable evidence of relationship available to the applicant reference prior to initiating the relationship confirmation process</li>
  <li>The CSP <strong>SHALL</strong> request evidence of the applicant’s relationship (e.g., notarized power of attorney, a professional certification)</li>
  <li>Upon successfully identity proofing an applicant, the CSP <strong>SHALL</strong> record the evidence used to confirm the applicant reference’s relationship to the applicant in the subscriber account.</li>
</ol>
<h4 id="Minors" data-section="3">
  
  
    Requirements for Interacting with Minors <a href="#Minors" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>The following requirements apply to all CSPs providing identity proofing services to minors at any IAL.</p>

<ol>
  <li>The CSP <strong>SHALL</strong> establish written policy and procedures as part of its practice statement for identity proofing minors who may not be able to meet the evidence requirements for a given IAL.</li>
  <li>When interacting with persons under the age of 13, the CSP <strong>SHALL</strong> ensure compliance with the Children’s Online Privacy Protection Act of 1998 <a href="/800-63-4/sp800-63a/references/#ref-COPPA">[COPPA]</a>, or other laws and regulations dealing with the protection of minors, as applicable.</li>
  <li>CSPs <strong>SHALL</strong> support the use of applicant references when interacting with individuals under the age of 18.</li>
</ol>
<h2 id="upgradeIAL" data-section="3">
  
  
    Elevating Subscriber IALs <a href="#upgradeIAL" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>CSPs <strong>SHOULD</strong> allow subscribers to elevate identity assurance levels related to their subscriber accounts to support higher assurance transactions with RPs. For CSPs supporting these functions the following apply:</p>

<ol>
  <li>CSPs <strong>SHALL</strong> document their approved approaches for elevating assurance levels in their practice statements.</li>
  <li>CSPs <strong>SHALL</strong> require subscribers to authenticate at the highest AAL available on their account prior to initiating the upgrade process.</li>
  <li>CSPs <strong>SHALL</strong> collect, validate, and verify additional evidence, as mandated to achieve the higher IAL.</li>
  <li>CSPs <strong>SHOULD</strong> avoid collecting, validating, and verifying previously processed evidence, though they <strong>MAY</strong> do so based on the age of the account, indicators of fraud, or if evidence has become invalidated since the original proofing event.</li>
</ol>

<div class="footnotes" role="doc-endnotes">
  <ol>
    <li id="fn:alternatives" role="doc-endnote">
      <p>Options include using a trusted referee, with or without an applicant representative. <a href="#fnref:alternatives" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:privacyframework" role="doc-endnote">
      <p>For more information about privacy risk assessments, refer to the NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management at <a href="https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf">https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf</a>. <a href="#fnref:privacyframework" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:NISTIR8062" role="doc-endnote">
      <p><a href="references.md#ref-NISTIR8062">[NISTIR8062]</a> provides an overview of predictability and manageability including examples of how these objectives can be met. <a href="#fnref:NISTIR8062" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:behavioral" role="doc-endnote">
      <p>Behavioral analytics in this context are used to determine if an interaction is indicative of an automated attack and not an effort to identify or authenticate a specific user based on a captured reference template for that user. <a href="#fnref:behavioral" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:SORN" role="doc-endnote">
      <p>For more information about SORNs, see OPM’s <em>System of Records Notice (SORN) Guide</em> (https://www.opm.gov/information-management/privacy-policy/privacy-references/sornguide.pdf). <a href="#fnref:SORN" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:Note_DFAR" role="doc-endnote">
      <p>For the purposes of this document, the DFAR is the proportion of processed, fraudulent documents that the document validation system determined to be valid divided by the number of processed fraudulent documents. DFAR is defined as the number of fraudulent documents processed that were deemed valid by a document validation system divided by the number of processed fraudulent documents. <a href="#fnref:Note_DFAR" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:Note_DFRR" role="doc-endnote">
      <p>For the purposes of this document, DFRR is the proportion of processed, genuine documents which the document validation system determined to be invalid. DFRR is defined as the number of genuine documents processed that were deemed invalid by a document validation system divided by the number of processed genuine documents. <a href="#fnref:Note_DFRR" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
  </ol>
</div>

<h1 id="ial-section" data-section="4">
  
  
    Identity Assurance Level Requirements <a href="#ial-section" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<p><em>This section is normative.</em></p>
<h2 id="IAL1" data-section="4">
  
  
    Identity Assurance Level 1 Requirements <a href="#IAL1" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Identity proofing processes at IAL1 allow for a range of acceptable techniques in order to detect the fraudulent claims to identities by malicious actors, while facilitating user adoption, minimizing the rejection of legitimate users, and reducing application departures. The use of biometric matching, such as the automated comparison of a facial portrait to supplied evidence, at IAL1 is optional, providing pathways to proofing and enrollment where such collection may not be viable.</p>
<h3 id="proofing-types" data-section="4">
  
  
    Proofing Types <a href="#proofing-types" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>IAL1 Identity Proofing <strong>MAY</strong> be delivered through any proofing type, as described in <a href="/800-63-4/sp800-63a/proofing/#ProofingTypes">Sec. 2.1.3</a>.</li>
  <li>CSPs <strong>SHALL</strong> offer Unattended Remote identity proofing as an option.</li>
  <li>CSPs <strong>SHALL</strong> offer at least one method of Attended (Remote or Onsite) identity proofing as an option.</li>
  <li>CSPs MAY combine proofing types and their stated requirements to create hybrid processes. For example, a CSP might leverage remote unattended identity proofing validation processes in advance of a remote attended session where verification will take place. Where such steps are combined, CSPs SHALL document their processes in alignment of requirements of each proofing type that is applied.</li>
</ol>
<h3 id="ial1-evidence-collection" data-section="4">
  
  
    Evidence Collection <a href="#ial1-evidence-collection" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>For each identity proofing type, the CSP <strong>SHALL</strong> collect the following:</p>

<ol>
  <li>One piece of FAIR evidence or better (i.e., STRONG, SUPERIOR) evidence</li>
</ol>

<p>For onsite attended identity proofing at IAL1, organizations <strong>SHOULD</strong> prioritize the use of evidence (FAIR or STRONG) that contains a facial portrait, which can be used for verification purposes. While forms of evidence that do not contain a facial portrait <strong>MAY</strong> be used for such sessions, the associated verification requirements (e.g., returning a confirmation code) may result in additional burden on applicants.</p>
<h3 id="ial1-attribute-collection" data-section="4">
  
  
    Attribute Collection <a href="#ial1-attribute-collection" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>The CSP <strong>SHALL</strong> collect all Core Attributes. Validated evidence is the preferred source of identity attributes. If the presented identity evidence does not provide all the attributes that the CSP considers core attributes, it <strong>MAY</strong> collect attributes that are self-asserted by the applicant.</p>
<h3 id="ial1-evidence-validation" data-section="4">
  
  
    Evidence Validation <a href="#ial1-evidence-validation" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Each piece of evidence presented <strong>SHALL</strong> be validated using one of the following techniques:</p>

<ol>
  <li>Confirming the authenticity of digital evidence through interrogation of digital security features (e.g., signatures on assertions or data).</li>
  <li>Confirming the authenticity of physical evidence using automated scanning technology able to detect physical security features.</li>
  <li>Confirming the integrity of physical security features of presented evidence through visual inspection by a proofing agent using real-time or asynchronous processes (e.g., offline manual review).</li>
  <li>Confirming the integrity of physical security features through physical and tactile inspection of security features by a proofing agent at an onsite location.</li>
</ol>
<h3 id="ial1-attribute-validation" data-section="4">
  
  
    Attribute Validation <a href="#ial1-attribute-validation" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>The CSP <strong>SHALL</strong> validate all core attributes and the government identifier against an authoritative or credible source to determine accuracy.</li>
  <li>CSPs <strong>SHOULD</strong> correlate the data on evidence, self-asserted, and as presented by credible and authoritative sources for consistency.</li>
  <li>CSPs <strong>SHOULD</strong> validate the reference numbers of presented identity evidence if available.</li>
</ol>
<h3 id="ial1-verification" data-section="4">
  
  
    Verification Requirements <a href="#ial1-verification" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>The CSP <strong>SHALL</strong> verify the applicant’s ownership of one piece of evidence using one of the following processes:</p>

<ol>
  <li>Confirming the applicant’s ability to return a confirmation code delivered to a validated address associated with the evidence;</li>
  <li>Confirming the applicant’s ability to return a micro-transaction value delivered to a validated financial or similar account;</li>
  <li>Confirming the applicant’s ability to successfully complete an authentication and federation protocol equivalent to AAL2/FAL2, or higher, to access an account related to the identity evidence;</li>
  <li>Comparing the applicant’s facial image to a facial portrait on evidence via an automated comparison.</li>
  <li>Visually comparing the applicant’s facial image to a facial portrait on evidence, or in records associated with the evidence, during either an onsite attended session (in-person with a proofing agent), a remote attended session (live video with a proofing agent), or an asynchronous process (i.e., visual comparison made by a proofing agent at a different time).</li>
  <li>Comparing a stored biometric on identity evidence, or in authoritative records related to the evidence, to a sample provided by the applicant.</li>
</ol>
<h3 id="remote-attended-requirements" data-section="4">
  
  
    Remote Attended Requirements <a href="#remote-attended-requirements" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>All video sessions <strong>SHALL</strong> take place using a service that allows for the exchange of information over an authenticated protected channel.</li>
  <li>During the video session, the applicant <strong>SHALL</strong> remain in view of the proofing agent during each step of the proofing process.</li>
  <li>The video quality <strong>SHALL</strong> be sufficient to support the necessary steps in the validation and verification processes, such as inspecting evidence and making visual comparisons of the user to the evidence.</li>
  <li>The proofing agent <strong>SHALL</strong> be trained to identify signs of manipulation, coercion, or social engineering occurring during the recorded session.</li>
  <li>CSPs <strong>MAY</strong> record and maintain video sessions for fraud prevention and prosecution purposes pursuant to a privacy risk assessment, as defined in <a href="3_ialgen#PrivRiskAssess">Sec. 3.1.3.1</a>. If the CSP records session, the following further requirements apply:
    <ol>
      <li>The CSP <strong>SHALL</strong> notify the applicant of the recording prior to initiating a recorded session.</li>
      <li>The CSP <strong>SHALL</strong> gain consent from the applicant to prior to initiating a recorded session.</li>
      <li>The CSP <strong>SHALL</strong> publish their retention schedule and deletion processes for all video records.</li>
    </ol>
  </li>
  <li>The CSP <strong>SHOULD</strong> introduce challenges and response features into their video sessions that are randomized or periodically changed to deter deep fakes and pre-recorded materials from being used to defeat the proofing process. These MAY be shifting questions, changes to the orders of sessions, or physical cues that would be hard for attackers to predict.</li>
  <li>The CSP <strong>SHALL</strong> provide proofing agents with a method or mechanism to flag events for potential fraud.</li>
</ol>
<h3 id="onsite-attended-requirements" data-section="4">
  
  
    Onsite Attended Requirements <a href="#onsite-attended-requirements" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>The CSP <strong>SHALL</strong> provide a physical setting in which onsite identity proofing sessions are conducted.</li>
  <li>The CSP <strong>SHALL</strong> ensure all information systems and technology leveraged by proofing agents and trusted referees are protected consistent with FISMA Moderate or comparable levels of controls.</li>
  <li>CSP proofing agents <strong>SHALL</strong> be trained to identify signs of manipulation, coercion, or social engineering occurring during the onsite session.</li>
  <li>CSPs <strong>MAY</strong> record and maintain video sessions for fraud prevention and prosecution purposes pursuant to a privacy risk assessment, as defined in <a href="3_ialgen#PrivRiskAssess">Sec. 3.1.3.1</a>. If the CSP records session, the following further requirements apply:
    <ol>
      <li>The CSP <strong>SHALL</strong> notify the applicant of the recording prior to initiating a recorded session.</li>
      <li>The CSP <strong>SHALL</strong> gain consent from the applicant prior to initiating a recorded session.</li>
      <li>The CSP <strong>SHALL</strong> publish their retention schedule and deletion processes for all video records.</li>
    </ol>
  </li>
  <li>The CSP <strong>SHALL</strong> provide proofing agents with a method or mechanism to safely flag events for potential fraud.</li>
</ol>
<h3 id="onsite-unattended-requirements-devices--kiosks" data-section="4">
  
  
    Onsite Unattended Requirements (Devices &amp; Kiosks) <a href="#onsite-unattended-requirements-devices--kiosks" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>All devices <strong>SHALL</strong> be safeguarded from tampering through either observation by CSP representatives or through physical and digital tamper prevention features.</li>
  <li>All devices <strong>SHALL</strong> be protected by appropriate baseline security features comparable to FISMA Moderate controls – including Malware Protection, Admin Specific Access Controls, and Software Update processes.</li>
  <li>All devices <strong>SHALL</strong> be inspected periodically by trained technicians to deter tampering, modification, or damage.</li>
</ol>
<h3 id="initial-authenticator-binding" data-section="4">
  
  
    Initial Authenticator Binding <a href="#initial-authenticator-binding" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Upon the successful completion of the identity proofing process, a unique subscriber account is established and maintained for the applicant (now subscriber) in the CSP’s identity system. One or more authenticators can be associated (bound) to the subscriber’s account, either at the time of identity proofing or at a later time. See <a href="/800-63-4/sp800-63a/accounts/#accounts">Sec. 5</a> for more information about subscriber accounts.</p>

<ol>
  <li>The CSP <strong>SHALL</strong> provide the ability for the applicant to bind an authenticator using one of the following methods:
    <ol>
      <li>The remote enrollment of a subscriber-provided authenticator, consistent with the requirements for the authenticator type as defined in <a href="/800-63-4/sp800-63b/events/#bind-subscriber-authenticator" latex-href="#ref-SP800-63B">Sec. 4.1.3 of [SP800-63B]</a>.</li>
      <li>Distribution of a physical authenticator to a validated address of record.</li>
      <li>Distribution or onsite enrollment of an authenticator.</li>
    </ol>
  </li>
  <li>Where authenticators are bound outside of a single protected session with the user, the CSP <strong>SHALL</strong> confirm the presence of the intended subscriber through one of the following methods:
    <ol>
      <li>Return of an confirmation code, or</li>
      <li>Comparison against a biometric collected at the time of proofing.</li>
    </ol>
  </li>
</ol>
<h3 id="notification-of-proofing" data-section="4">
  
  
    Notification of Proofing <a href="#notification-of-proofing" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Upon the successful completion of identity proofing at IAL1, the CSP <strong>SHALL</strong> send a notification of proofing to a validated address for the applicant, as specified in <a href="/800-63-4/sp800-63a/ial-general/#ProofingNotifs">Sec. 3.1.10</a>.</p>
<h2 id="IAL2" data-section="4">
  
  
    Identity Assurance Level 2 Requirements <a href="#IAL2" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>IAL2 identity proofing includes additional evidence, validation, and verification requirements in order to provide increased mitigation against impersonation attacks and other identity proofing errors relative to IAL1. IAL2 can be achieved through a number of different types of proofing (e.g., remote unattended, remote attended, etc.) and identity verification at IAL2 can be accomplished with or without the use of biometrics. To provide clear options to achieving IAL2, this section presents three different pathways to achieving alignment with IAL2 outcomes and requirements: IAL2 Verification - Non-Biometric Pathway; IAL2 Verification - Biometric Pathway; and IAL2 Verification - Digital Evidence Pathway. These different options do not imply different security or assurance outcomes; instead they present requirements in a manner that allows for clear selection of non-biometric methods that can be used to achieve IAL2.</p>
<h3 id="proofing-types-1" data-section="4">
  
  
    Proofing Types <a href="#proofing-types-1" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>Identity proofing at IAL2 <strong>MAY</strong> be delivered through any proofing type, as described in <a href="/800-63-4/sp800-63a/proofing/#ProofingTypes">Sec. 2.1.3</a>.</li>
  <li>CSPs <strong>SHALL</strong> offer Unattended Remote identity proofing as an option.</li>
  <li>CSPs <strong>SHALL</strong> offer at least one method of Attended (Remote or Onsite) identity proofing as an option.</li>
  <li>CSPs <strong>MAY</strong> combine elements of different proofing types to create hybrid processes. For example, a CSP might leverage remote unattended identity proofing validation processes in advance of a remote attended session where verification will take place. If a CSP employs a hybrid process, it <strong>SHALL</strong> document how the process satisfies the requirements associated with the associated proofing types.</li>
</ol>
<h3 id="ial2-evidence-collection" data-section="4">
  
  
    Evidence Collection <a href="#ial2-evidence-collection" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>For all types of proofing the CSP <strong>SHALL</strong> collect:</p>

<ol>
  <li>One piece of FAIR Evidence and one piece of STRONG; or</li>
  <li>One piece of SUPERIOR.</li>
</ol>
<h3 id="ial2-attribute-collection" data-section="4">
  
  
    Attribute Collection <a href="#ial2-attribute-collection" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Same as IAL1</p>
<h3 id="ial2-evidence-validation" data-section="4">
  
  
    Evidence Validation <a href="#ial2-evidence-validation" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>Each piece of FAIR or STRONG evidence presented <strong>SHALL</strong> be validated using one of the following techniques.
    <ol>
      <li>Confirming the authenticity of digital evidence through interrogation of digital security features (e.g., signatures on assertions or data).</li>
      <li>Confirming the authenticity of physical evidence using automated scanning technology able to detect physical security features.</li>
      <li>Confirming the integrity of physical security features of presented evidence through visual inspection by a proofing agent using real-time or asynchronous processes (e.g., offline manual review).</li>
      <li>Confirming the integrity of physical security features through physical and tactile inspection of security features by a proofing agent at an onsite location.</li>
    </ol>
  </li>
  <li>Each Piece of SUPERIOR evidence <strong>SHALL</strong> be validated through cryptographic verification of the evidence contents and the issuing source, including digital signature verification and the validation of any trust chain back to a trust anchor. SUPERIOR evidence unable to be validated using cryptographic verification <strong>SHALL</strong> be considered STRONG evidence and validated consistent with the requirements above.</li>
</ol>
<h3 id="ial2-attribute-validation" data-section="4">
  
  
    Attribute Validation <a href="#ial2-attribute-validation" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>The CSP <strong>SHALL</strong> validate all core attributes by either:
    <ol>
      <li>Comparing the government identifier and core attributes against an authoritative or credible source to determine accuracy; or</li>
      <li>Validating the accuracy of digitally signed attributes contained on SUPERIOR evidence through the public key of the issuing source.</li>
    </ol>
  </li>
  <li>CSPs <strong>SHOULD</strong> correlate the attributes collected from evidence, self-assertion, and as presented by credible and authoritative sources for consistency.</li>
  <li>CSPs <strong>SHOULD</strong> validate the reference numbers of presented identity evidence if available.</li>
</ol>
<h3 id="ial2-verification" data-section="4">
  
  
    Verification Requirements <a href="#ial2-verification" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Verification pathways <strong>SHOULD</strong> be implemented consistent with relevant policy and be responsive to the use cases, populations, and threat environment of the online service being protected. CSPs <strong>SHOULD</strong> deploy more than one pathway to IAL2 verification and <strong>MAY</strong> combine pathways in order to achieve desired outcomes.</p>
<h4 id="ial2-verification---non-biometric-pathway" data-section="4">
  
  
    IAL2 Verification - Non-Biometric Pathway <a href="#ial2-verification---non-biometric-pathway" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>The IAL2 Non-Biometric Pathway provides verification methods that do not use automated comparison of biometric samples provided by the applicant. Non-biometric processes will often still include biometric data being collected and verified - for example, through a visual comparison performed by a proofing agent and images contained on identity evidence - but comparisons are not done through automated means. Additional verification methods that may not require the use of automated biometric comparison are also included in the IAL2 Verification - Digital Evidence Pathway requirements specified in <a href="/800-63-4/sp800-63a/ial/#dig-evidence-pathway">Sec. 4.2.6.2</a>.</p>

<ol>
  <li>The CSP <strong>SHALL</strong> verify the applicant’s ownership of all presented identity evidence.</li>
  <li>Approved non-biometric methods for verifying FAIR evidence at IAL2 include:
    <ol>
      <li>Confirming the applicant’s ability to return a confirmation code delivered to a validated address associated with the evidence (e.g., postal address, email address, phone number)</li>
      <li>Visually comparing the applicant’s facial image to a facial portrait on evidence, or in records associated with the evidence, during either an onsite attended session (in-person with a proofing agent), a remote attended session (live video with a proofing agent), or an asynchronous process (i.e., visual comparison made by a proofing agent at a different time)</li>
    </ol>
  </li>
  <li>Approved non-biometric methods for verifying STRONG and SUPERIOR evidence at IAL2 include:
    <ol>
      <li>Confirming the applicant’s ability to return a confirmation code delivered to a physical address (i.e., postal address) that was obtained from the evidence and was validated with an authoritative source</li>
      <li>Visually comparing the applicant’s facial image to a facial portrait on evidence, or in records associated with the evidence, during either an onsite attended session (in-person with a proofing agent), a remote attended session (live video with a proofing agent), or an asynchronous process (i.e., visual comparison made by a proofing agent at a different time)</li>
    </ol>
  </li>
</ol>

<div latex-literal="true" class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>\clearpage
</code></pre></div></div>
<h4 id="dig-evidence-pathway" data-section="4">
  
  
    IAL2 Verification - Digital Evidence Pathway <a href="#dig-evidence-pathway" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>The IAL2 Digital Evidence Pathway provides a means of allowing individuals to make use of digital forms of evidence, such as digital credentials (sometimes referred to as <em>digital identity documents</em>) or digital accounts as part of the verification process. This pathway achieves verification by confirming the individual’s ability to access evidence through digital means.</p>

<ol>
  <li>The CSP <strong>SHALL</strong> verify the applicant’s ownership of all pieces of presented identity evidence.</li>
  <li>Approved digital evidence verification methods for FAIR evidence at IAL2 include:
    <ol>
      <li>Confirming the applicant’s ability to return a micro-transaction value delivered to a validated account (e.g., a checking account)</li>
      <li>Confirming the applicant’s ability to return a confirmation code delivered to a validated digital address associated with the digital evidence (e.g., MNO/Phone account)</li>
      <li>Confirming the applicant’s ability to successfully complete an authentication and federation protocol equivalent to AAL2/FAL2 to access an account related to the identity evidence</li>
    </ol>
  </li>
  <li>Approved digital evidence verification methods for STRONG evidence at IAL2 include:
    <ol>
      <li>Confirming the applicant’s ability to successfully complete an authentication and federation protocol equivalent to AAL2/FAL2, or higher, to access an account related to the identity evidence</li>
    </ol>
  </li>
  <li>Approved digital evidence verification methods for SUPERIOR evidence at IAL2 include:
    <ol>
      <li>Confirming the applicant’s ability to successfully complete an authentication and federation protocol equivalent to AAL3/FAL2, or higher, to access an account related to the identity evidence</li>
    </ol>
  </li>
</ol>
<h4 id="ial2-verification---biometric-pathway" data-section="4">
  
  
    IAL2 Verification - Biometric Pathway <a href="#ial2-verification---biometric-pathway" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h4>

<p>The IAL2 Biometric Pathway provides verification methods that support automated comparison of biometric samples provided by the applicant.</p>

<ol>
  <li>The CSP <strong>SHALL</strong> verify the applicant’s ownership of all pieces of presented identity evidence.</li>
  <li>Approved biometric methods for verifying FAIR evidence at IAL2 include:
    <ol>
      <li>Comparing the applicant’s facial image to a facial portrait on evidence via an automated comparison</li>
    </ol>
  </li>
  <li>Approved methods for verifying STRONG and SUPERIOR evidence for use in the IAL2 Biometric Pathway include:
    <ol>
      <li>Comparing the applicant’s facial image to a facial portrait on evidence via an automated comparison</li>
      <li>Comparing, via automated means, a non-facial portrait biometric stored on identity evidence, or in-records associated with the evidence, to a live sample provided by the applicant</li>
    </ol>
  </li>
</ol>
<h3 id="remote-attended-requirements-1" data-section="4">
  
  
    Remote Attended Requirements <a href="#remote-attended-requirements-1" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Same as IAL1.</p>
<h3 id="onsite-attended-requirements-1" data-section="4">
  
  
    Onsite Attended Requirements <a href="#onsite-attended-requirements-1" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Same as IAL1.</p>
<h3 id="onsite-unattended-requirements-devices--kiosks-1" data-section="4">
  
  
    Onsite Unattended Requirements (Devices &amp; Kiosks) <a href="#onsite-unattended-requirements-devices--kiosks-1" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Same as IAL1.</p>
<h3 id="notification-of-proofing-1" data-section="4">
  
  
    Notification of Proofing <a href="#notification-of-proofing-1" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Same as IAL1.</p>
<h3 id="initial-authenticator-binding-1" data-section="4">
  
  
    Initial Authenticator Binding <a href="#initial-authenticator-binding-1" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Same as IAL 1.</p>
<h2 id="IAL3" data-section="4">
  
  
    Identity Assurance Level 3 <a href="#IAL3" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>IAL3 adds additional rigor to the steps required at IAL2 and is subject to additional and specific processes (including the use of biometric information comparison, collection, and retention) to further protect the identity and RP from impersonation and other forms of identity fraud. In addition, identity proofing at IAL3 must be attended by a CSP proofing agent, as described in <a href="/800-63-4/sp800-63a/proofing/#ProofingRoles">Sec. 2.1.2</a>.</p>
<h3 id="proofing-types-2" data-section="4">
  
  
    Proofing Types <a href="#proofing-types-2" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>IAL 3 Identity Proofing <strong>SHALL</strong> only be delivered as Onsite Attended. The Proofing Agent <strong>MAY</strong> be collocated or attend the proofing session remotely via a CSP controlled kiosk or device.</p>
<h3 id="ial3-evidence-collection" data-section="4">
  
  
    Evidence Collection <a href="#ial3-evidence-collection" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>For all types of IAL 3 identity proofing the CSP <strong>SHALL</strong> collect either:
    <ol>
      <li>One piece of STRONG and one piece of FAIR (or better), or</li>
      <li>One piece of SUPERIOR</li>
    </ol>
  </li>
</ol>
<h3 id="ial3-attribute-collection" data-section="4">
  
  
    Attribute Requirements <a href="#ial3-attribute-collection" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>The CSP <strong>SHALL</strong> collect all core attributes. Validated evidence is the preferred source of identity attributes. If the presented identity evidence does not provide all the attributes that the CSP considers core attributes, it <strong>MAY</strong> collect attributes that are self-asserted by the applicant.</li>
  <li>The CSP <strong>SHALL</strong> collect and retain a biometric sample from the applicant during the identity proofing process to support account recovery, non-repudiation, and establish a high level of confidence that the same participant is present in the proofing and issuance processes (if done separately). CSPs <strong>MAY</strong> choose to periodically re-enroll user biometrics based on the modalities they use and the likelihood that subscriber accounts will persist long enough to warrant such a refresh.</li>
</ol>
<h3 id="ial3-evidence-validation" data-section="4">
  
  
    Evidence Validation <a href="#ial3-evidence-validation" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>Each piece of FAIR or STRONG evidence presented <strong>SHALL</strong> be validated using one of the following techniques.
    <ol>
      <li>Confirming the authenticity of digital evidence through interrogation of digital security features (e.g., signatures on assertions or data).</li>
      <li>Confirming the authenticity of physical evidence using automated scanning technology able to detect physical security features.</li>
      <li>Confirming the integrity of physical security features of presented evidence through physical inspection by a proofing agent using real-time or asynchronous processes (e.g., offline manual review).</li>
      <li>Confirming the integrity of physical security features through physical and tactile inspection of security features by a proofing agent at an onsite location.</li>
    </ol>
  </li>
  <li>Each Piece of SUPERIOR evidence <strong>SHALL</strong> be validated through cryptographic verification of the evidence contents and the issuing source, including digital signature verification and the validation of any trust chain back to a trust anchor.</li>
</ol>
<h3 id="ial3-attribute-validation" data-section="4">
  
  
    Attribute Validation <a href="#ial3-attribute-validation" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>The CSP <strong>SHALL</strong> validate all core attributes by either:
    <ol>
      <li>Comparing the core attributes against an authoritative or credible source to determine accuracy; or</li>
      <li>Validating the accuracy of digitally signed attributes contained on SUPERIOR evidence through the public key of the issuing source.</li>
    </ol>
  </li>
  <li>CSPs <strong>SHOULD</strong> correlate the attributes collected from evidence, self-assertion, and as presented by credible and authoritative sources for consistency.</li>
  <li>CSPs <strong>SHOULD</strong> validate the reference numbers of presented identity evidence if available.</li>
</ol>
<h3 id="ial3-verification" data-section="4">
  
  
    Verification Requirements <a href="#ial3-verification" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>The CSP <strong>SHALL</strong> verify the applicants ownership of the strongest piece of evidence (STRONG or SUPERIOR) by one of the following methods:
    <ol>
      <li>Confirming the applicant’s ability to successfully authenticate to a physical device or application (for example a mobile driver’s license) and comparing a digitally protected and transmitted facial portrait to the applicant.</li>
      <li>Comparing the applicant’s facial image to the facial portrait on evidence via an automated comparison.</li>
      <li>Visually comparing the applicant’s facial image to the facial portrait on evidence, either during an onsite attended session or a remote attended session (live video).</li>
      <li>Comparing a stored biometric on identity evidence, or in authoritative records associated with the evidence, to a sample provided by the applicant.</li>
    </ol>
  </li>
</ol>
<h3 id="onsite-attended-requirements-locally-attended" data-section="4">
  
  
    Onsite Attended Requirements (Locally Attended) <a href="#onsite-attended-requirements-locally-attended" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>The CSP <strong>SHALL</strong> provide a secure, physical setting in which onsite identity proofing sessions are conducted.</li>
  <li>The CSP <strong>SHALL</strong> provide sensors and capture devices for the collection of biometrics from the applicant.</li>
  <li>The CSP <strong>SHALL</strong> have the proofing agent view the source of the collected biometric for the presence of any non-natural materials.</li>
  <li>The CSP <strong>SHALL</strong> have the proofing agent collect the biometric samples in such a way that ensures the sample was collected from the applicant and no other source.</li>
  <li>The CSP <strong>SHALL</strong> ensure all information systems and technology leveraged by proofing agents and trusted referees are protected consistent with FISMA Moderate or comparable levels of controls to include physical controls for the proofing facility.</li>
  <li>CSP proofing agents <strong>SHALL</strong> be trained to identify signs of manipulation, coercion, or social engineering occurring during the onsite session.</li>
  <li>CSPs <strong>MAY</strong> record and maintain video sessions for fraud prevention and prosecution purposes pursuant to a privacy risk assessment, as defined in <a href="/800-63-4/sp800-63a/ial-general/#PrivRiskAssess">Sec. 3.1.3.1</a>. If the CSP records session, the following further requirements apply:
    <ol>
      <li>The CSP <strong>SHALL</strong> notify the applicant of the recording prior to initiating a recorded session.</li>
      <li>The CSP <strong>SHALL</strong> gain consent from the applicant to prior to initiating a recorded session.</li>
      <li>The CSP <strong>SHALL</strong> publish their retention schedule and deletion processes for all video records.</li>
    </ol>
  </li>
  <li>The CSP <strong>SHALL</strong> provide proofing agents with a method or mechanism to safely flag events for potential fraud.</li>
</ol>
<h3 id="onsite-attended-requirements-remotely-attended---formerly-supervised-remote-identity-proofing" data-section="4">
  
  
    Onsite Attended Requirements (Remotely Attended - Formerly Supervised Remote Identity Proofing) <a href="#onsite-attended-requirements-remotely-attended---formerly-supervised-remote-identity-proofing" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>The CSP <strong>MAY</strong> offer a remote means of interacting with a proofing agent whereby the agent and the applicant do not have to be at the same facility. In this scenario, the following requirements apply:
    <ol>
      <li>The CSP <strong>SHALL</strong> monitor the entire identity proofing session through a high-resolution video transmission with the applicant.</li>
      <li>The CSP <strong>SHALL</strong> have a live proofing agent participate remotely with the applicant for the evidence collection, evidence validation, and verification steps of the identity proofing process. Data entry of attributes for resolution and enrollment <strong>MAY</strong> be done without the presence of a live proofing agent.</li>
      <li>The CSP <strong>SHALL</strong> require all actions taken by the applicant during the evidence collection, evidence validation, and verification steps to be clearly visible to the remote proofing agent.</li>
      <li>The CSP <strong>SHALL</strong> require that all digital validation and verification of evidence (e.g., via chip or wireless technologies) be performed by integrated scanners and sensors (e.g., embedded fingerprint reader).</li>
      <li>All devices used to support interaction between the proofing agent and the applicant<strong>SHALL</strong> be safeguarded from tampering through observation by CSP representatives or monitoring devices (e.g., cameras) and through physical and digital tamper prevention features.</li>
      <li>All devices used to support interaction between the proofing agent and the applicant <strong>SHALL</strong> be protected by appropriate baseline security features comparable to FISMA Moderate controls, including malware protection, admin-specific access controls, and software update processes.</li>
      <li>All devices used to support interaction between the proofing agent and the applicant <strong>SHALL</strong> be inspected periodically by trained technicians to deter tampering, modification, or damage.</li>
    </ol>
  </li>
</ol>
<h3 id="notification-of-proofing-2" data-section="4">
  
  
    Notification of Proofing <a href="#notification-of-proofing-2" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>Same as IAL1.</p>
<h3 id="initial-authenticator-binding-2" data-section="4">
  
  
    Initial Authenticator Binding <a href="#initial-authenticator-binding-2" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<ol>
  <li>The CSP <strong>SHALL</strong> distribute or enroll the applicant’s initial authenticator during an onsite attended interaction with a proofing agent.</li>
  <li>If the CSP distributes or enrolls the initial authenticator outside of a single, protected session with the user, the CSP <strong>SHALL</strong> compare a biometric sample collected from the applicant to the one collected at the time of proofing, prior to issuance of the authenticator.</li>
  <li>The CSP <strong>MAY</strong> request that the applicant bring the identity evidence used during the proofing process to the issuance event to further strengthen the process of binding the authenticators to the applicant.</li>
</ol>

<div latex-literal="true" class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>\clearpage
</code></pre></div></div>
<h2 id="summary" data-section="4">
  
  
    Summary of Requirements <a href="#summary" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p><a href="/800-63-4/sp800-63a/ial/#table-1">Table 1</a> summarizes the requirements for each of the identity assurance levels:</p>

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

<p></p>

<table latex-table="1" latex-caption="IAL Requirements Summary" latex-columns="p@0.15\textwidth,p@0.25\textwidth,p@0.25\textwidth,p@0.25\textwidth">
  <thead>
    <tr>
      <th style="text-align: left">Process</th>
      <th style="text-align: left">IAL1</th>
      <th style="text-align: left">IAL2</th>
      <th style="text-align: left">IAL3</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: left">Proofing Types</td>
      <td style="text-align: left">Remote Unattended <br /> Remote Attended <br /> Onsite Unattended <br /> Onsite Attended</td>
      <td style="text-align: left">Same as IAL1</td>
      <td style="text-align: left">Onsite Attended</td>
    </tr>
    <tr>
      <td style="text-align: left">Evidence Collection</td>
      <td style="text-align: left"><em>Unattended:</em> <br /> –1 FAIR or <br /> –1 STRONG <br /> <em>Attended:</em> <br /> –1 FAIR w/ image or <br /> –1 STRONG</td>
      <td style="text-align: left"><em>For all proofing types:</em> <br /> –1 FAIR and 1 STRONG or <br /> –1 SUPERIOR</td>
      <td style="text-align: left">–1 STRONG + 1 FAIR or <br /> –1 SUPERIOR</td>
    </tr>
    <tr>
      <td style="text-align: left">Attribute Collection</td>
      <td style="text-align: left">All Core Attributes</td>
      <td style="text-align: left">All Core Attributes</td>
      <td style="text-align: left">All Core Attributes + Biometric Sample</td>
    </tr>
    <tr>
      <td style="text-align: left">Evidence Validation</td>
      <td style="text-align: left"><em>Physical Evidence:</em> <br /> –automated doc auth. <br /> –visual inspection <br /> <em>Digital Evidence:</em> <br /> –interrogation of digital security features</td>
      <td style="text-align: left"><em>Physical Evidence:</em><br /> –automated doc. auth. <br /> –visual inspection <br /> –physical/tactile inspection <br /> <em>Digital Evidence:</em>  <br /> –interrogation of digital security features <br /> <em>SUPERIOR Evidence:</em>  <br /> –Dig. sig. verification</td>
      <td style="text-align: left"><em>Physical Evidence:</em> <br /> –automated doc. auth. <br /> –physical inspection <br /> –physical/tactile inspection <br /> <em>Digital Evidence:</em> <br /> –interrogation of digital security features <br /> <em>SUPERIOR Evidence:</em><br /> –Dig. sig. verification</td>
    </tr>
    <tr>
      <td style="text-align: left">Attribute Validation</td>
      <td style="text-align: left">Confirmation of core attributes against authoritative or credible sources.</td>
      <td style="text-align: left">Confirmation of core attributes against authoritative or credible sources. <br /> Confirmation of digitally signed attributes through signature verification.</td>
      <td style="text-align: left"><br /> Confirmation of core attributes against authoritative or credible sources. <br /> Confirmation of digitally signed attributes through digital signature verification.</td>
    </tr>
    <tr>
      <td style="text-align: left">Verification</td>
      <td style="text-align: left">Verify applicant’s ownership of either the FAIR evidence or the STRONG evidence per 4.1.6</td>
      <td style="text-align: left">Verify applicant’s ownership of all presented evidence using methods provided in 4.2.6</td>
      <td style="text-align: left">Verify applicant’s ownership of all presented evidence using methods provided in 4.3.6</td>
    </tr>
  </tbody>
</table>

<p></p>

<h1 id="accounts" data-section="5">
  
  
    Subscriber Accounts <a href="#accounts" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

<p><em>This section is normative.</em></p>
<h2 id="subscriber-accounts" data-section="5">
  
  
    Subscriber Accounts <a href="#subscriber-accounts" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The CSP <strong>SHALL</strong> establish and maintain a unique subscriber account for each active subscriber in the CSP identity system from the time of enrollment to the time of account closure. The CSP establishes a subscriber account to record each subscriber as a unique identity within its identity service and to maintain a record of all authenticators associated with that account.</p>

<p>The CSP <strong>SHALL</strong> assign a unique identifier to each subscriber account. The identifier <strong>SHOULD</strong> be randomly generated by the CSP system and of sufficient length and entropy to ensure uniqueness within its user population and to support federation with RPs, where applicable. The identifier <strong>MAY</strong> be used as a subject identifier in the generation of assertions, consistent with <a href="/800-63-4/sp800-63a/references/#ref-SP800-63C" latex-href="#ref-SP800-63C">[SP800-63C]</a>.</p>

<p>At a minimum, the CSP <strong>SHALL</strong> include the following information in each subscriber account:</p>

<ul>
  <li>The unique identifier associated with the subscriber account</li>
  <li>Any subject identifiers established for the subscriber, including any RP specific subject identifiers</li>
  <li>A record of the identity proofing steps completed for the subscriber, including:
    <ul>
      <li>The type and issuer of identity evidence</li>
      <li>The type of proofing (Remote Unattended, Remote Attended, Onsite Attended, Onsite Unattended)</li>
      <li>The validation and verification methods used</li>
      <li>The use of a trusted referee or other exception handling process</li>
      <li>The use of an applicant reference, including a unique identifier for the applicant reference</li>
    </ul>
  </li>
  <li>Maximum IAL successfully achieved for the identity proofing of the subscriber</li>
  <li>Records of any applicant consent agreements related to the collection and processing of information about the applicant, including biometrics, throughout the subscriber account lifecycle</li>
  <li>All authenticators currently bound to the subscriber account, whether registered at enrollment or subsequent to enrollment</li>
  <li>Attributes that were validated during the identity proofing process or in subsequent transactions to support RP access</li>
</ul>
<h2 id="subscriber-account-access" data-section="5">
  
  
    Subscriber Account Access <a href="#subscriber-account-access" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The CSP <strong>SHALL</strong> provide the capability for subscribers to authenticate and access information in their subscriber account.</p>

<p>For subscriber accounts that contain PII, this capability <strong>SHALL</strong> be accomplished through AAL2 or AAL3 authentication processes using authenticators registered to the subscriber account.</p>
<h2 id="subscriber-account-maintenance-and-updates" data-section="5">
  
  
    Subscriber Account Maintenance and Updates <a href="#subscriber-account-maintenance-and-updates" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The CSP <strong>SHALL</strong> provide the capability for a subscriber to request the CSP to update information contained in their subscriber account. The CSP <strong>MAY</strong> provide a mechanism for subscribers to update any non-core attributes directly.</p>

<p>The CSP <strong>SHALL</strong> validate any changes to core attribute information maintained in the subscriber account.</p>

<p>The CSP <strong>SHALL</strong> provide notice to the subscriber of any updates made to information in the subscriber account.</p>

<p>The CSP <strong>SHALL</strong> provide the capability for the subscriber to report any unauthorized access or potential compromise to information in their subscriber account.</p>
<h2 id="subscriber-account-suspension-or-termination" data-section="5">
  
  
    Subscriber Account Suspension or Termination <a href="#subscriber-account-suspension-or-termination" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The CSP <strong>SHALL</strong> promptly suspend or terminate the subscriber account when one of the following occurs:</p>

<ul>
  <li>The subscriber elects to terminate their subscriber account with the CSP.</li>
  <li>The CSP determines that the subscriber account has been compromised.</li>
  <li>The CSP determines that the subscriber has violated the policies or rules for participation in the CSP identity service.</li>
  <li>The CSP determines that the subscriber account is inactive in accordance with the policies or rules established by the CSP.</li>
  <li>The CSP receives notification of a subscriber’s death from an authoritative source.</li>
  <li>The CSP receives a legal instrument from a court to terminate a subscriber’s account.</li>
  <li>The CSP ceases identity system and services operations.</li>
</ul>

<p>The CSP <strong>SHALL</strong> provide notification to the subscriber that their subscriber account has been suspended or terminated. Such notices <strong>SHALL</strong> include information about why the account was suspended or terminated, reactivation or renewal options, and any options for redress if the subscriber thinks the account was suspended or terminated in error.</p>

<p>The CSP <strong>SHALL</strong> delete any personal or sensitive information from the subscriber account records following account termination in accordance with the record retention and disposal requirements, as documented in its practices statement <a href="/800-63-4/sp800-63a/ial-general/#DocRecReqs">Sec. 3.1.1</a>.</p>

<h1 id="security" data-section="6">
  
  
    Threats and Security Considerations <a href="#security" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

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

<p>Effective protection of identity proofing processes requires the layering of security controls and processes throughout a transaction with a given applicant. To achieve this, it is necessary to understand where and how threats can arise and compromise enrollments. There are three general categories of threats to the identity proofing process:</p>

<ul>
  <li>
    <p><strong>Impersonation</strong>: where an attacker attempts to pose as another, legitimate, individual (e.g., identity theft)</p>
  </li>
  <li>
    <p><strong>False or Fraudulent Representation</strong>: where an attacker may create a false identity or false claims about an identity (e.g., synthetic identity fraud)</p>
  </li>
  <li>
    <p><strong>Infrastructure</strong>: where attackers may seek to compromise confidentiality, availability, and integrity of the infrastructure, data, software, or people supporting the CSP’s identity proofing process (e.g., distributed denial of service, insider threats)</p>
  </li>
</ul>

<p>This section focuses on impersonation and false or fraudulent representation threats, as infrastructure threats are addressed by traditional computer security controls (e.g., intrusion protection, record keeping, independent audits) and are outside the scope of this document. For more information on security controls, see <a href="/800-63-4/sp800-63a/references/#ref-SP800-53">[SP800-53]</a>, <em>Recommended Security and Privacy Controls for Federal Information Systems and Organizations</em>.</p>

<p latex-ignore="true"><a href="/800-63-4/sp800-63a/security/#table-2" name="table-2">Table 2. Identity Proofing and Enrollment Threats</a></p>

<table latex-table="2" latex-caption="Identity Proofing and Enrollment Threats" latex-columns="p@0.25\textwidth,p@0.35\textwidth,p@0.25\textwidth">
  <thead>
    <tr>
      <th>Attack/Threat</th>
      <th>Description</th>
      <th>Example</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Automated Enrollment Attempts</td>
      <td>Attackers leverage scripts and automated processes to rapidly generate large volumes of enrollments</td>
      <td>Bots leverage stolen data to submit benefits claims.</td>
    </tr>
    <tr>
      <td>Evidence Falsification</td>
      <td>Attacker creates or modifies evidence in order to claim an identity</td>
      <td>A fake driver’s license is used as evidence.</td>
    </tr>
    <tr>
      <td>Synthetic Identity fraud</td>
      <td>Attacker fabricates evidence of identity that is not associated with a real person</td>
      <td>Opening a credit card in a fake name to create a credit file.</td>
    </tr>
    <tr>
      <td>Fraudulent Use of Identity (Identity Theft)</td>
      <td>Attacker fraudulently uses another individual’s identity or identity evidence</td>
      <td>An individual uses a stolen passport.</td>
    </tr>
    <tr>
      <td>Social Engineering</td>
      <td>Attacker convinces a legitimate applicant to provide identity evidence or complete the identity proofing process under false pretenses</td>
      <td>An individual submits their identity evidence to an attacker posing as a potential employer.</td>
    </tr>
    <tr>
      <td>False Claims</td>
      <td>Attacker associates false attributes or information with a legitimate identity</td>
      <td>An individual falsely claims residence in a state in order to obtain a benefit that is available only to state residents.</td>
    </tr>
    <tr>
      <td>Video or Image Injection Attack</td>
      <td>Attacker creates a fake video feed of an individual associated with a real person</td>
      <td>A deepfake video is used to impersonate an individual portrayed on a stolen driver’s license.</td>
    </tr>
  </tbody>
</table>
<h2 id="threat-mitigation-strategies" data-section="6">
  
  
    Threat Mitigation Strategies <a href="#threat-mitigation-strategies" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Threats to the enrollment and identity proofing process are summarized in <a href="/800-63-4/sp800-63a/security/#table-2">Table 2</a>. Related mechanisms that assist in mitigating the threats identified above are summarized in <a href="/800-63-4/sp800-63a/security/#table-3">Table 3</a>. These mitigations should not be considered comprehensive but a summary of mitigations detailed more thoroughly at each Identity Assurance Level and applied based on the risk assessment processes detailed in <a href="/800-63-4/sp800-63/dirm/#sec5" latex-href="#ref-SP800-63">Sec. 3 of [SP800-63]</a>.</p>

<p latex-ignore="true"><a href="/800-63-4/sp800-63a/security/#table-3" name="table-3">Table 3. Identity Proofing and Enrollment Threat Mitigation Strategies</a></p>

<p></p>

<table latex-table="3" latex-caption="Identity Proofing and Enrollment Threat Mitigation Strategies" latex-columns="p@0.15\textwidth,p@0.55\textwidth,p@0.20\textwidth">
  <thead>
    <tr>
      <th>Threat/Attack</th>
      <th>Mitigation Strategies</th>
      <th>Normative Reference(s)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Automated Enrollment Attempts</td>
      <td>Web Application Firewall (WAF) controls and bot detection technology. Out-of-band engagement (e.g., confirmation codes). Biometric verification and liveness detection mechanisms. Traffic and network analysis capabilities to identify indications or malicious traffic.</td>
      <td>3.1.5, 3.1.8, 3.1.11</td>
    </tr>
    <tr>
      <td>Evidence Falsification</td>
      <td>Validation of core attributes with authoritative or credible sources. Validation of physical or digital security features of the presented evidence.</td>
      <td>4.1.4 &amp; 4.1.5 (IAL1), 4.2.4 &amp; 4.2.5 (IAL2), 4.3.4 &amp; 4.3.5 (IAL3)</td>
    </tr>
    <tr>
      <td>Synthetic Identity Fraud</td>
      <td>Collection of identity evidence. Validation of core attributes with authoritative or credible sources. Biometric comparison of the applicant to validated identity evidence or biometric data. Checks against vital statistics repositories (e.g., Death Master File).</td>
      <td>3.1.2.1, 4.1.2, 4.1.5, &amp; 4.1.6 (IAL1), 4.2.2, 4.2.5, &amp; 4.2.6 (IAL2), 4.3.2, 4.3.5, &amp; 4.3.6 (IAL3)</td>
    </tr>
    <tr>
      <td>Fraudulent Use of Identity (Identity Theft)</td>
      <td>Biometric comparison of the applicant to validated identity evidence or biometric data. Presentation attack detection measures to confirm the genuine presence of applicant. Out-of-band engagement (e.g., confirmation codes) and notice of proofing. Checks against vital statistics repositories (e.g., Death Master File). Fraud, transaction, and behavioral analysis capabilities to identify indicators of potentially malicious account establishment.</td>
      <td>3.1.2.1, 3.1.8, 3.1.10, 3.1.11, 4.1.6 (IAL1), 4.2.6 (IAL2), 4.3.6 (IAL3)</td>
    </tr>
    <tr>
      <td>Social Engineering</td>
      <td>Training of trusted referees to identify indications of coercion or distress. Out-of-band engagement and notice of proofing to validated address. Provide information and communication to end users on common threats and schemes. Offer onsite in-person attended identity proofing option.</td>
      <td>2.1.3, 3.1.8, 3.1.110, 3.1.13.1, 8.4</td>
    </tr>
    <tr>
      <td>False Claims</td>
      <td>Geographic restrictions on traffic. Validation of core attributes with authoritative or credible sources.</td>
      <td>3.1.2.1, 4.1.5 (IAL1), 4.2.5 (IAL2), 4.3.5 (IAL3)</td>
    </tr>
    <tr>
      <td>Video or Image Injection Attack</td>
      <td>Use of a combination of active and passive PAD. Use of authenticated protected channels for communications between devices and servers running matching. Authentication of biometric sensors where feasible. Monitoring and analysis of incoming video and image files to detect signs of injection.</td>
      <td>3.1.8</td>
    </tr>
  </tbody>
</table>

<p></p>
<h2 id="collaboration-with-adjacent-programs" data-section="6">
  
  
    Collaboration with Adjacent Programs <a href="#collaboration-with-adjacent-programs" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Identity proofing services typically serve as the front door for critical business or service functions. Accordingly, these services should not operate in a vacuum. A close coordination of identity proofing and CSP functions with cybersecurity teams, threat intelligence teams, and program integrity teams can enable a more complete protection of business capabilities while constantly improving identity proofing 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 receive indications of new tactics, techniques, and procedures that may impact identity proofing processes. CSPs and RPs should seek to establish consistent mechanisms for the exchange of information between critical security and fraud stakeholders. Where the CSP is external, this may be complicated, but should be addressed through contractual and legal mechanisms, to include technical and interoperability considerations. All data collected, transmitted, or shared should be minimized and subject to a detailed privacy and legal assessment.</p>

<h1 id="privacy-section-header" data-section="7">
  
  
    Privacy Considerations <a href="#privacy-section-header" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

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

<p>These privacy considerations provide additional information in implementing the requirements set forth in <a href="/800-63-4/sp800-63a/ial-general/#PrivacyReqs">Sec. 3.1.3</a> and are intended to guide CSPs and RPs in designing identity systems that prioritize protecting their users’ privacy.</p>
<h2 id="collection-and-data-minimization" data-section="7">
  
  
    Collection and Data Minimization <a href="#collection-and-data-minimization" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>These guidelines permit the collection and processing of only the PII necessary to validate the claimed identity, associate the claimed identity to the applicant, mitigate fraud, and to provide RPs with attributes they may use to make authorization decisions. Collecting unnecessary PII can create confusion regarding why information that is not being used for the identity proofing service is being collected. This leads to invasiveness or overreach concerns, which can lead to a loss of applicant trust. Further, PII retention can become vulnerable to unauthorized access or use. Data minimization reduces the amount of PII vulnerable to unauthorized access or use, and encourages trust in the identity proofing process.</p>
<h3 id="social-security-numbers" data-section="7">
  
  
    Social Security Numbers <a href="#social-security-numbers" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h3>

<p>These guidelines permit the CSP collection of the SSN as an attribute for use in identity resolution. However, over-reliance on the SSN can contribute to misuse and place the applicant at risk of harm, such as through identity theft. Nonetheless, the SSN may facilitate identity resolution for CSPs, in particular federal agencies that use the SSN to correlate an applicant to agency records. This document recognizes the role of the SSN as an attribute and makes appropriate allowance for its use. Knowledge of the SSN is not sufficient to serve as identity evidence.</p>

<p>Where possible, CSPs and agencies should consider mechanisms to limit the proliferation and exposure of SSNs during the identity proofing process. This is particularly pertinent where the SSN is communicated to third party providers during attribute validation processes. To the extent possible, privacy protective techniques and technologies should be applied to reduce the risk of an individual’s SSN being exposed, stored, or maintained by third party systems. Examples of this could be the use of attribute claims (e.g., yes/no responses from a validator) to confirm the validity of a SSN without requiring it to be unnecessarily transmitted by the third party. As with all attributes in the identity proofing process, the value and risk of each attribute being processed is subject to a privacy risk assessment and federal agencies may address further in its associated PIA and SORN documentation. The SSN should only be collected where it is necessary to support identity resolution associated with the applications assurance and risk levels.</p>
<h2 id="consent" data-section="7">
  
  
    Notice and Consent <a href="#consent" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The guidelines require the CSP to provide explicit notice to the applicant at the time of collection regarding the purpose for collecting and maintaining a record of the attributes necessary for identity proofing, including whether such attributes are voluntary or mandatory in order to complete the identity proofing transactions, and the consequences for not providing the attributes.</p>

<p>An effective notice will take into account user experience design standards and research, and an assessment of privacy risks that may arise from the collection. Various factors should be considered, including incorrectly inferring that applicants understand why attributes are collected, that collected information may be combined with other data sources, etc. An effective notice is never only a pointer leading to a complex, legalistic privacy policy or general terms and conditions that applicants are unlikely to read or understand.</p>

<p>In addition, RPs should provide additional guidance to applicants for available choices for the selection of CSPs, identity document requirements, related privacy notices, and alternative means of accessing services.</p>
<h2 id="use-limitation" data-section="7">
  
  
    Use Limitation <a href="#use-limitation" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The guidelines require CSPs to use measures to maintain the objectives of predictability (enabling reliable assumptions by individuals, owners, and operators about PII and its processing by an information system) and manageability (providing the capability for the granular administration of PII, including alteration, deletion, and selective disclosure) commensurate with privacy risks that can arise from the processing of attributes for purposes other than identity proofing, authentication, authorization, or attribute assertion, related fraud mitigation, or to comply with law or legal process. A framework for managing these risks and supporting privacy risk management principles can be found in <a href="/800-63-4/sp800-63a/references/#ref-NISTIR8062">[NISTIR8062]</a>.</p>

<p>CSPs may have various business purposes for processing attributes, including providing non-identity services to subscribers. However, processing attributes for other purposes than those disclosed to a subject can create additional privacy risks. CSPs can determine appropriate measures commensurate with the privacy risk arising from the additional processing. For example, absent applicable law, regulation, or policy, it may not be necessary to obtain consent when processing attributes to provide non-identity services requested by subscribers, although notices may help the subscribers maintain reliable assumptions about the processing (predictability). Other processing of attributes may carry different privacy risks which may call for obtaining consent or allowing subscribers more control over the use or disclosure of specific attributes (manageability). Subscriber consent needs to be meaningful; therefore, when CSPs do use consent measures, they cannot make acceptance by the subscriber of additional uses a condition of providing the identity service.</p>

<p>Federal agencies should consult their SAOP if there are questions about whether the proposed processing falls outside the scope of the permitted processing or the appropriate privacy risk mitigation measures.</p>
<h2 id="privacy-redress" data-section="7">
  
  
    Redress <a href="#privacy-redress" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The guidelines require the CSP to provide effective mechanisms for redressing applicant complaints or problems arising from the identity proofing, and make the mechanisms easy for applicants to find and access.</p>

<p>The Privacy Act requires federal CSPs that maintain a system of records to follow procedures to enable applicants to access and, if incorrect, amend their records. Any Privacy Act Statement should include a reference to the applicable SORN(s) (see <a href="/800-63-4/sp800-63a/ial-general/#PrivacyReqs">Sec. 3.1.3</a>), which provide the applicant with instructions on how to make a request for access or correction. Non-federal CSPs should have comparable procedures, including contact information for any third parties if they are the source of the information.</p>

<p>In the event an applicant is unable to establish their identity and complete the online enrollment process, CSPs should make the availability of alternative methods for completing the process clear to applicants (e.g., in person at a customer service center).</p>

<blockquote>
  <p>Note: If the identity proofing process is not successful, CSPs should inform the applicant of the procedures to address the issue but should not inform the applicant of the specifics of why the registration failed (e.g., do not inform the applicant, “Your SSN did not match the one that we have on record for you”), as doing so could allow fraudulent applicants to gain more knowledge about the accuracy of the PII.</p>
</blockquote>
<h2 id="privacy-risk-assessment" data-section="7">
  
  
    Privacy Risk Assessment <a href="#privacy-risk-assessment" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The guidelines require the CSP to conduct a privacy risk assessment. In conducting a privacy risk assessment, CSPs should consider:</p>

<ol>
  <li>The likelihood that an action it takes (e.g., additional verification steps or records retention) could create a problem for the applicant, such as invasiveness or unauthorized access to the information; and</li>
  <li>The impact on the applicant should a problem occur. CSPs should be able to justify any response they take to identified privacy risks, including accepting the risk, mitigating the risk, and sharing the risk. Applicant consent is considered to be a form of sharing the risk and, therefore, should only be used when an applicant could reasonably be expected to have the capacity to assess and accept this shared risk.</li>
</ol>
<h2 id="agency-specific-privacy-compliance" data-section="7">
  
  
    Agency-Specific Privacy Compliance <a href="#agency-specific-privacy-compliance" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The guidelines cover specific compliance obligations for federal CSPs. It is critical to involve an agency’s SAOP in the earliest stages of identity service development to assess and mitigate privacy risks and advise the agency on compliance requirements, such as whether or not the PII collection to conduct identity proofing triggers the Privacy Act of 1974 <a href="/800-63-4/sp800-63a/references/#ref-PrivacyAct">[PrivacyAct]</a> or the E-Government Act of 2002 <a href="/800-63-4/sp800-63a/references/#ref-E-Gov">[E-Gov]</a> requirement to conduct a Privacy Impact Assessment. For example, with respect to identity proofing, it is likely that the Privacy Act requirements will be triggered and require coverage by either a new or existing Privacy Act system of records notice (SORN) due to the collection and maintenance of PII or other attributes necessary to conduct identity proofing.</p>

<p>The SAOP can similarly assist the agency in determining whether a PIA is required. These considerations should not be read as a requirement to develop a Privacy Act SORN or PIA for identity proofing alone; in many cases it will make the most sense to draft a PIA and SORN that encompasses the entire digital identity lifecycle or includes the identity proofing process as part of a larger, programmatic PIA that discusses the program or benefit to which the agency is establishing online access.</p>

<p>Due to the many components of the digital identity lifecycle, it is important for the SAOP to have an awareness and understanding of each individual component. For example, other privacy artifacts may be applicable to an agency offering or using proofing services such as Data Use Agreements, Computer Matching Agreements, etc. The SAOP can assist the agency in determining what additional requirements apply. Moreover, a thorough understanding of the individual components of digital authentication will enable the SAOP to thoroughly assess and mitigate privacy risks either through compliance processes or by other means.</p>

<h1 id="usability" data-section="8">
  
  
    Usability Considerations <a href="#usability" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

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

<p>In order to align with the standard terminology of user-centered design and usability, the term “user” is used throughout this section to refer to the human party. In most cases, the user in question will be the subject (in the role of applicant, claimant, or subscriber) as described elsewhere in these guidelines.</p>

<p>This section is intended to raise implementers’ awareness of the usability considerations associated with identity proofing and enrollment (for usability considerations for typical authenticator usage and intermittent events, see <a href="/800-63-4/sp800-63b/usability/#sec10" latex-href="#ref-SP800-63B">Sec. 8 of [SP800-63B]</a>.</p>

<p><a href="/800-63-4/sp800-63a/references/#ref-ISOIEC9241">[ISO/IEC9241-11]</a> defines usability as the “extent to which a system, product, or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” This definition focuses on users, goals, and context of use as the necessary elements for achieving effectiveness, efficiency, and satisfaction. A holistic approach considering these key elements is necessary to achieve usability.</p>

<p>The overarching goal of usability for identity proofing and enrollment is to promote a smooth, positive enrollment process for users by minimizing user burden (e.g., time and frustration) and enrollment friction (e.g., the number of steps to complete and the amount of information to track). To achieve this goal, organizations have to first familiarize themselves with their users.</p>

<p>The identity proofing and enrollment process sets the stage for a user’s interactions with a given CSP and the online services that the user will access; as negative first impressions can influence user perception of subsequent interactions, organizations need to promote a positive user experience throughout the process.</p>

<p>Usability cannot be achieved in a piecemeal manner. Performing a usability evaluation on the enrollment and identity proofing process is critical. It is important to conduct a usability evaluation with representative users, realistic goals and tasks, and appropriate contexts of use. The enrollment and identity proofing process should be designed and implemented so that it is easy for users to do the right thing, hard for them to do the wrong thing, and easy for them to recover when the wrong thing happens. <a href="/800-63-4/sp800-63a/references/#ref-ISOIEC9241">[ISO/IEC9241-11]</a>, <a href="/800-63-4/sp800-63a/references/#ref-ISO16982">[ISO16982]</a>, and <a href="/800-63-4/sp800-63a/references/#ref-ISO25060">[ISO25060]</a> provide guidance on how to evaluate the overall usability of an identity service and additional considerations for increasing usability.</p>

<p>From the user’s perspective, the three main steps of identity proofing and enrollment are pre-enrollment preparation, the enrollment and proofing session, and post-enrollment actions. These steps may occur in a single session or there could be significant time elapsed between each one (e.g., days or weeks).</p>

<p>General and step-specific usability considerations are described in sub-sections below.</p>

<p>Guidelines and considerations are described from the users’ perspective.</p>

<p>Section 508 of the Rehabilitation Act of 1973 <a href="/800-63-4/sp800-63a/references/#ref-Section508">[Section508]</a> was enacted to eliminate barriers in information technology and require federal agencies to make electronic and information technology accessible to people with disabilities. While these guidelines do not directly assert requirements from Section 508, identity service providers are expected to comply with Section 508 provisions. Beyond compliance with Section 508, Federal Agencies and their service providers are generally expected to design services and systems with the experiences of people with disabilities in mind to ensure that accessibility is prioritized throughout identity system lifecycles.</p>
<h2 id="general-user-considerations-during-identity-proofing-and-enrollment" data-section="8">
  
  
    General User Considerations During Identity Proofing and Enrollment <a href="#general-user-considerations-during-identity-proofing-and-enrollment" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>This sub-section provides usability considerations that are applicable across all steps of the enrollment process. Usability considerations specific to each step are detailed in <a href="/800-63-4/sp800-63a/usability/##usability-pre">Sec. 8.2</a>, <a href="/800-63-4/sp800-63a/usability/#usability-proofing">Sec. 8.3</a>, and <a href="/800-63-4/sp800-63a/usability/#usability-post">Sec. 8.4</a>.</p>

<ul>
  <li>
    <p>To avoid user frustration, streamline the process required for enrollment to make each step as clear and easy as possible.</p>
  </li>
  <li>
    <p>Clearly communicate how and where to acquire technical assistance. For example, provide helpful information such as a link to an online self-service portal, chat sessions, and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to answer their own enrollment preparation questions without outside intervention.</p>
  </li>
  <li>
    <p>Clearly explain what personal data is being collected and whether collecting the data is optional or not. Additionally, provide information indicating with whom the data will be shared, where it will be stored, and how it will be protected.</p>
  </li>
  <li>Ensure that all information presented is usable.
    <ul>
      <li>Follow good information design practice for all user-facing materials (e.g., data collection notices and fillable forms).</li>
      <li>Write materials in plain language and avoid technical jargon. If appropriate, tailor that language to the literacy level of the intended population. Use active voice and conversational style; logically sequence main points; use the same word consistently rather than synonyms to avoid confusion; and use bullets, numbers, and formatting where appropriate to aid readability.</li>
      <li>Consider text legibility, such as font style, size, color, and contrast with the surrounding background. The highest contrast is black on white. Text legibility is important because users have different levels of visual acuity. Illegible text will contribute to user comprehension errors or user entry errors (e.g., when completing fillable forms). Use sans serif font styles for electronic materials and serif fonts for paper materials. When possible, avoid fonts that do not clearly distinguish between easily confusable characters (such as the letter “O” and the number “0”). This is especially important for confirmation codes. Use a minimum font size of 12 points, as long as the text fits the display.</li>
    </ul>
  </li>
  <li>Perform a usability evaluation for each step with representative users. Establish realistic goals and tasks, and appropriate contexts of use for the usability evaluation.</li>
</ul>
<h2 id="usability-pre" data-section="8">
  
  
    Pre-Enrollment Preparation <a href="#usability-pre" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>This section describes an effective approach to facilitate sufficient pre-enrollment preparation so users can avoid challenging, frustrating enrollment sessions. Ensuring that users are as prepared as possible for their enrollment sessions is critical to the overall success and usability of the identity proofing and enrollment process.</p>

<p>Such preparation is only possible if users receive the necessary information (e.g., the required documentation) in a usable format in an appropriate timeframe. This includes making users aware of exactly what identity evidence will be required. Users do not need to know anything about IALs or whether the identity evidence required is scored as “fair,” “strong,” or “superior,” whereas organizations need to know what IAL is required for access to a particular system.</p>

<p>To ensure users are equipped to make informed decisions about whether to proceed with the enrollment process, and what will be needed for their session, provide users:</p>

<ul>
  <li>Information about the entire process, such as what to expect in each step.
    <ul>
      <li>Clear explanations of the expected timeframes to allow users to plan accordingly.</li>
    </ul>
  </li>
  <li>
    <p>Explanation of the need for — and benefits of — identity proofing to allow users to understand the value proposition.</p>
  </li>
  <li>
    <p>Identity evidence requirements for the intended IAL and a list of acceptable evidence documents, with information about how they will be validated.</p>
  </li>
  <li>
    <p>If there is an enrollment fee and, if so, the amount and acceptable forms of payment. Offering a variety of acceptable forms of payment allows users to choose their preferred payment operation.</p>
  </li>
  <li>Information on whether the user’s enrollment session will be in-person or in-person over remote channels, and whether a user can choose. Only provide information relevant to the allowable session option(s).
    <ul>
      <li>Information on the location(s), whether a user can choose their preferred location, and necessary logistical information for in-person or in-person over remote channels session. Note that users may be reluctant to bring identity evidence to certain public places (a supermarket versus a bank), as it increases exposure to loss or theft.</li>
      <li>Information on the technical requirements (e.g., requirements for internet access) for remote sessions.</li>
      <li>An option to set an appointment for in-person or in-person over remote channels identity proofing sessions to minimize wait times. If walk-ins are allowed, make it clear to users that their wait times may be greater without an appointment.
        <ul>
          <li>Provide clear instructions for setting up an enrollment session appointment, reminders, and how to reschedule existing appointments.</li>
          <li>Offer appointment reminders and allow users to specify their preferred appointment reminder method(s) (e.g., postal mail, voicemail, email, text message). Users need information such as the date, time, and location, and a description of the required identity evidence.</li>
        </ul>
      </li>
    </ul>
  </li>
  <li>Information on the allowed and required identity evidence and attributes, whether each piece is voluntary or mandatory, and the consequences for not providing the complete set of identity evidence. Users need to know the specific combinations of identity evidence, including requirements specific to a piece of identity evidence (e.g., a raised seal on a birth certificate). This is especially important due to potential difficulties procuring the necessary identity evidence.
    <ul>
      <li>Where possible, implement tools to make it easier to obtain the necessary identity evidence.</li>
      <li>Inform users of any special requirements for minors or people with unique needs. For example, provide users with the information on whether applicant reference and/or trusted referee processes are available and the information necessary to use those processes (see <a href="/800-63-4/sp800-63a/ial-general/#TRs-ARs">Sec. 3.1.13</a>).</li>
      <li>If forms are required:
        <ul>
          <li>Provide fillable forms before and at the enrollment session. Do not require users to have access to a printer.</li>
          <li>Minimize the amount of information that users must enter on a form, as users are easily frustrated and more error-prone with longer forms. Where possible, pre-populate forms.</li>
        </ul>
      </li>
    </ul>
  </li>
</ul>
<h2 id="usability-proofing" data-section="8">
  
  
    Identity Proofing and Enrollment <a href="#usability-proofing" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Usability considerations specific to identity proofing and enrollment include:</p>

<ul>
  <li>At the start of the identity proofing session, remind users of the procedure. Do not expect them to remember the procedures described during the pre-enrollment preparation step. If the enrollment session does not immediately follow pre-enrollment preparation, it is especially important to clearly remind users of the typical timeframe to complete the proofing and enrollment phase.</li>
  <li>Depending on the identity proofing method (e.g., Remote or Onsite Unattended), provide a separate video window that provides a step-by-step tutorial of the identity proofing process. When these types of tutorials or examples are provided, service providers should provide a range of support options to cover a broad set of users. Alternatives to a video window include verbal or written instructions.</li>
  <li>Provide options for the user to reschedule the time or type of their identity proofing appointment, if needed.</li>
  <li>Provide a checklist with the allowed and required identity evidence to ensure that users have the requisite identity evidence to proceed with the enrollment session, including enrollment codes, if applicable. If users do not have the complete set of identity evidence, they must be informed regarding whether they can complete a partial identity proofing session or use exception processing through a trusted referee or, as appropriate, applicant references for identity proofing exception processing. This also would apply to international users where the types of identity evidence and access to data, services, and validation sources may not be easily or readily available to achieve IAL identity proofing requirements. Trusted referees and applicant references are intended to provide capabilities for alternative identity proofing workflows and risk-based decisions for such types of users needing exception processing.</li>
  <li>Notify users regarding what information will be destroyed, what, if any, information will be retained for future follow-up sessions, and what identity evidence they will need to bring to complete a future session. Ideally, users can choose whether they would like to complete a partial identity proofing session.</li>
  <li>Set user expectations regarding the outcome of the enrollment session, as prior identity verification experiences may drive their expectations (e.g., receiving a driver’s license in person, receiving a passport in the mail).</li>
  <li>
    <p>Clearly indicate if 1) users will receive an authenticator immediately at the end of a successful enrollment session; 2) if they will have to schedule a follow-up appointment to pick up an authenticator in person; or 3) or if users will receive the authenticator in the mail and, if so, when they can expect to receive it.</p>
  </li>
  <li>
    <p>During the enrollment session, there are several requirements to provide users with explicit notice at the time of identity proofing, such as what data will be collected and processed by the CSP. (See <a href="/800-63-4/sp800-63a/ial-general/#genProofReqs">Sec. 3.1</a> and <a href="/800-63-4/sp800-63a/privacy/#privacy-section-header">Sec. 7</a> for detailed requirements on notices). CSPs should be aware that seeking consent from users for the use of their attributes for purposes other than identity proofing, authentication, authorization, or attribute assertions, may make them uncomfortable. If users do not perceive how they benefit by the additional collection or uses, they may be unwilling or hesitant to provide consent or continue the process. It is recommended, then, that CSPs provide users with a thorough explanation of how they might benefit from the additional processing of their personal information, and steps the CSP takes to mitigate the risks associated with such processing. Additionally, CSPs should provide users with the ability to opt out of the additional processing.</p>
  </li>
  <li>If a confirmation code is issued:
    <ul>
      <li>Notify users in advance that they will receive a confirmation code, when to expect it, the length of time for which the code is valid, and how it will arrive (e.g., physical mail, SMS, landline telephone, or email).</li>
      <li>When a confirmation code is delivered to a user, remind the users which service they are enrolling in and include instructions on how to use the code and the length of time for which the code is valid. This is especially important given the short validity timeframes specified in <a href="/800-63-4/sp800-63a/ial-general/#ConfirmCodes">Sec. 3.1.8</a>.</li>
      <li>If issuing a machine-readable optical label, such as a QR Code (see <a href="/800-63-4/sp800-63a/ial-general/#ConfirmCodes">Sec. 3.1.8</a>), provide users with information on how to obtain QR code scanning capabilities (e.g., acceptable QR code applications).</li>
      <li>Inform users that they will be required to repeat the enrollment process if enrollment codes expire or are lost before use.</li>
      <li>Provide users with alternative options, as not all users are able to access and use technology equitably. For example, users may not have the technology needed for this approach to be feasible.</li>
    </ul>
  </li>
  <li>At the end of the enrollment session:
    <ul>
      <li>If enrollment is successful, send subscribers a notification of proofing confirming successful identity proofing and enrollment (see <a href="/800-63-4/sp800-63a/ial-general/#ConfirmCodes">Sec. 3.1.8</a>) and directions on next steps they need to take (e.g., when and where to pick up their authenticator, when it will arrive in the mail).</li>
      <li>If enrollment is partially complete (due to users not having the complete set of identity evidence, users choosing to stop the process, or session timeouts), communicate to users:
        <ul>
          <li>what information will be destroyed;</li>
          <li>what, if any, information will be retained for future follow-up sessions;</li>
          <li>how long the information will be retained; and</li>
          <li>what identity evidence they will need to bring to a future session.</li>
        </ul>
      </li>
      <li>If enrollment is not successful, provide users with clear instructions for alternative identity proofing and enrollment options, for example, in-person proofing for users who cannot complete remote proofing.</li>
    </ul>
  </li>
  <li>
    <p>If users receive the authenticator during the enrollment session, provide users with instructions on the use and maintenance of the authenticator. For example, information could include instructions for use (especially if there are different requirements for first-time use or initialization), information on authenticator expiration, how to protect the authenticator, and what to do if the authenticator is lost or stolen.</p>
  </li>
  <li>For both in-person and remote identity proofing, additional usability considerations apply:
    <ul>
      <li>At the start of the enrollment session, operators or attendants need to explain their role to users (e.g., whether operators or attendants will walk users through the enrollment session or observe silently and only interact as needed).</li>
      <li>At the start of the enrollment session, inform users that they must not depart during the session, and that their actions must be visible throughout the session.</li>
      <li>When biometrics are collected during the enrollment session, provide users with clear instructions on how to complete the collection process. The instructions are best given just prior to the process. Verbal instructions with guidance from a live operator are the most effective (e.g., instructing users where the biometric sensor is, when to start, how to interact with the sensor, and when the biometric collection is completed).</li>
    </ul>
  </li>
  <li>Since remote identity proofing is conducted online, follow general web usability principles. For example:
    <ul>
      <li>Design the user interface to walk users through the enrollment process.</li>
      <li>Reduce users’ memory load.</li>
      <li>Make the interface consistent.</li>
      <li>Clearly label sequential steps.</li>
      <li>Make the starting point clear.</li>
      <li>Design to support multiple platforms and device sizes.</li>
      <li>Make the navigation consistent, easy to find, and easy to follow.</li>
    </ul>
  </li>
</ul>
<h2 id="usability-post" data-section="8">
  
  
    Post-Enrollment <a href="#usability-post" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Post-enrollment refers to the step immediately following enrollment but prior to the first use of an authenticator (for usability considerations for typical authenticator usage and intermittent events, see <a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a>, Sec. 10. As described above, users have already been informed at the end of their enrollment session regarding the expected delivery (or pick-up) mechanism by which they will receive their authenticator.</p>

<p>Usability considerations for post-enrollment include:</p>

<ul>
  <li>
    <p>Minimize the amount of time that users wait for their authenticator to arrive. Shorter wait times will allow users to access information systems and services more quickly.</p>
  </li>
  <li>
    <p>Inform users whether they need to go to a physical location to pick up their authenticators. The previously identified usability considerations for appointments and reminders still apply.</p>
  </li>
  <li>
    <p>Along with the authenticator, give users information relevant to the use and maintenance of the authenticator; this may include instructions for use, especially if there are different requirements for first-time use or initialization, information on authenticator expiration, and what to do if the authenticator is lost or stolen.</p>
  </li>
  <li>
    <p>Provide information to users about how to protect themselves from common threats to their identity accounts and associated authenticators, such as social engineering and phishing attacks.</p>
  </li>
</ul>

<h1 id="equity" data-section="9">
  
  
    Equity Considerations <a href="#equity" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

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

<p>This section is intended to provide guidance to CSPs and RPs for assessing the risks associated with inequitable access, treatment, or outcomes for individuals using its identity services, as required in <a href="/800-63-4/sp800-63a/ial-general/#EquityReqs">Sec. 3.1.4</a>. It provides a non-exhaustive list of potential areas in the identity proofing process that may be subject to inequities, as well as possible mitigations that can be applied. CSPs and RPs can use this section as a starting point for considering where the risks for inequitable access, treatment, or outcomes exist within its identity service. It is not intended that the below guidance be considered a definitive, all-inclusive list of associated equity risks to identity services.</p>

<p>In assessing equity risks, CSPs and RPs start by considering the overall user population served by its online service. Additionally, CSPs and RPs further identify groups of users within the population whose shared characteristic(s) can cause them to be subject to inequitable access, treatment, or outcomes when using that service. CSPs and RPs are encouraged to assess the effectiveness of any mitigations by evaluating their impacts on the affected user group(s). The usability considerations provided in <a href="/800-63-4/sp800-63a/usability/#usability">Sec. 8</a> should also be considered when applying equity risk mitigations to help improve the overall usability and equity for all persons using an identity service.</p>

<p>Pursuant to Executive Order 13985 <a href="/800-63-4/sp800-63a/references/#ref-EO13985">[EO13985]</a>, <em>Advancing Racial Equity and Support for Underserved Communities Through the Federal Government</em>, OMB published its <em>Study to Identify Methods to Assess Equity: Report to the President</em> <a href="/800-63-4/sp800-63a/references/#ref-OMB-Equity">[OMB-Equity]</a> which identified “the best methods, consistent with applicable law, to assist agencies in assessing equity with respect to race, ethnicity, religion, income, geography, gender identity, sexual orientation, and disability.” CSPs and RPs are encouraged to consult this study when determining which approaches and methods they will use to assess the equity of their identity services.</p>

<p>It is intended that remote identity proofing can broaden usability and accessibility for enrollment into online identity services. The following subsections present considerations for some identity proofing processes that may create risks of inequitable treatment for some groups and individuals and present the use of trusted referees to help to mitigate such risks associated with remote identity proofing. However, it is important that the use of trusted referees do not create additional risks of exclusion among groups who may lack internet access or who do not have easy access to smartphones or computing devices. Providing in-person options for trusted referees can help ensure that those impacted by the digital divide are still able to access services offered by the CSP or RP.</p>

<p>Additionally, CSPs and RPs should assess whether implementing these considerations could introduce delays to the identity proofing process and employ appropriate methods, such as online scheduling tools or additional staffing for peak demand times, to mitigate these delays.</p>

<p>It is also intended that the considerations and mitigations provided in this section will be proactively employed and result in a more equitable identity proofing experience for the population served by the identity service. CSPs are expected to continuously monitor the performance of their service and to make remedial updates, as appropriate. This includes policies and processes for redressing user reports of inequitable access, treatment, or outcomes of the service.</p>
<h2 id="EquityResolve" data-section="9">
  
  
    Identity Resolution and Equity <a href="#EquityResolve" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Identity resolution involves collecting the minimum set of attributes to be able to distinguish the claimed identity as a single, unique individual within the population served by the identity service. Attributes are obtained from the presented identity evidence, applicant self-assertion, and/or back-end attribute providers.</p>

<p>This section provides a set of possible problems and mitigations with the inequitable access, treatment, or outcomes associated with the identity resolution process:</p>

<p><strong>Description: The identity service design requires an applicant to enter their name using a Western name format (e.g., first name, last name, optional middle name).</strong></p>

<p>Possible mitigations include:</p>

<ol>
  <li>Analyzing possible name configurations and determining how all names can be accurately accommodated using the name fields</li>
  <li>Providing easy-to-find and use guidance to users on how to enter all names using the name fields</li>
  <li>Accepting reasonable name variations (for example, to allow for differences in name order, multiple surnames, etc.)</li>
  <li>Providing the option for applicants to switch to an attended (onsite or remote) workflow option</li>
</ol>

<p><strong>Description: The identity service cannot accommodate applicants whose name, gender, or other attributes have changed and are not consistently reflected on the presented identity evidence or match what is in the attribute verifier’s records.</strong></p>

<p>Possible mitigations include:</p>

<ol>
  <li>Providing trusted referees (<a href="/800-63-4/sp800-63a/ial-general/#TRs">Sec. 3.1.13.1</a>) who can make risk-based decisions based on the specific applicant circumstances</li>
  <li>Allowing for the use of applicant references (<a href="/800-63-4/sp800-63a/ial-general/#ARs">Sec. 3.1.13.3</a>) who can vouch for the differences in attributes</li>
  <li>Providing an easily accessible list of acceptable evidence in support of the updated attribute, such as a marriage certificate</li>
  <li>Accepting reasonable name variations (for example, to allow for differences in name order, multiple surnames, hyphenation, or recent name changes)</li>
</ol>
<h2 id="EquityValidation" data-section="9">
  
  
    Identity Validation and Equity <a href="#EquityValidation" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Identity evidence and core attribute validation involves confirming the genuineness, currency, and accuracy of the presented identity evidence and the accuracy of any additional attributes. These outcomes are accomplished by comparison of the evidence and attributes against data held by authoritative or credible sources. When considered together with the identity resolution phase, the result of successful validation phase is the confirmation, to some level of confidence, that the claimed identity exists in the real world.</p>

<p>This section provides a set of possible problems and mitigations with the inequitable access, treatment, or outcomes associated with the evidence and attribute validation process:</p>

<p><strong>Description: Certain user groups do not possess the necessary minimum evidence to meet the requirements of a given IAL.</strong></p>

<p>Possible mitigations include:</p>

<ol>
  <li>Providing trusted referees (<a href="/800-63-4/sp800-63a/ial-general/#TRs">Sec. 3.1.13.1</a>) who can make risk-based decisions based on the specific applicant circumstances</li>
  <li>Allowing for the use of applicant references (<a href="/800-63-4/sp800-63a/ial-general/#ARs">Sec. 3.1.13.3</a>), such as the parent of a minor child, who can vouch for the applicant</li>
  <li>Ensuring that the selected IAL is not higher than necessary to be commensurate with the risk of the digital service offering</li>
  <li>RPs offering a limited set of functionality or options for users identity proofed at lower IALs</li>
</ol>

<p><strong>Description: Records held by authoritative and credible sources are insufficient to support the validation of core attributes or presented evidence for applicants belonging to certain user groups, such as those who self-exclude themselves from programs and services due to fears of surveillance or other concerns that might result in a record of their association.</strong></p>

<p>Possible mitigations include:</p>

<ol>
  <li>Providing trusted referees (<a href="/800-63-4/sp800-63a/ial-general/#TRs">Sec. 3.1.13.1</a>) who can make risk-based decisions based on the specific applicant circumstances</li>
  <li>Allowing the use of applicant references (<a href="/800-63-4/sp800-63a/ial-general/#ARs">Sec. 3.1.13.3</a>) who can vouch for the difference in attributes</li>
  <li>Employing multiple authoritative or credible sources</li>
</ol>

<p><strong>Description: Records held by authoritative and credible sources may include inaccurate or false information about persons who are the victims of identity fraud.</strong></p>

<p>Possible mitigations include:</p>

<ol>
  <li>Providing trusted referees (<a href="/800-63-4/sp800-63a/ial-general/#TRs">Sec. 3.1.13.1</a>) who can make risk-based decisions based on the specific applicant circumstances</li>
  <li>Allowing the use of applicant references (<a href="/800-63-4/sp800-63a/ial-general/#ARs">Sec. 3.1.13.3</a>) who can vouch for the difference in attributes</li>
  <li>Employing multiple authoritative or credible sources</li>
</ol>
<h2 id="EquityVerification" data-section="9">
  
  
    Identity Verification and Equity <a href="#EquityVerification" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>Identity verification involves proving the binding between the applicant undergoing the identity proofing process and the validated, real-world identity established through the identity resolution and validation steps. It most often involves collecting a picture (facial image capture) of the applicant taken during the identity proofing event and comparing it to a photograph contained on a presented and validated piece of identity evidence.</p>

<p>This section provides a set of possible problems and mitigations with the inequitable treatment or outcomes associated with the identity verification phase:</p>

<p><strong>Description: Facial image capture technologies lack the ability to capture certain skin tones or facial features of sufficient quality to perform a comparison.</strong></p>

<p>Possible mitigations include:</p>

<ol>
  <li>Employing robust image capture technologies, with high performing algorithms, which have been demonstrated to accommodate different skin tones, facial features, and lighting situations</li>
  <li>Conducting operational testing of image capture technologies to determine if they function equitably across ethnicity, race, sex assigned at birth, and other demographic factors and upgrading, as needed, to correct for inequities</li>
  <li>Providing guidance to the applicant about how to improve the lighting or conditions for image capture</li>
  <li>Providing risk-based alternative processes, such as Trusted Referees (<a href="/800-63-4/sp800-63a/ial-general/#TRs">Sec. 3.1.13.1</a>), that compensate for residual bias and technological limitations</li>
  <li>Providing the option for applicants to use CSP-controlled kiosks, which employ state-of-the-art facial and biometric capture technologies</li>
  <li>Providing the option for applicants to switch to an attended workflow option</li>
</ol>

<p><strong>Description: For biometric comparison involving facial images, facial coverings worn for religious purposes may impede the ability to capture a facial image of an applicant. For biometric comparison involving other biometric characteristics, demographic factors may impede the ability to capture a usable biometric sample, such as age affecting the capability to collect a usable fingerprint.</strong></p>

<p>Possible mitigations include:</p>

<ol>
  <li>Providing trusted referees (<a href="/800-63-4/sp800-63a/ial-general/#TRs">Sec. 3.1.13.1</a>) who can make risk-based decisions based on the specific applicant circumstances.</li>
  <li>Providing alternative ways to accomplish identity verification, such as an in-person proofing.</li>
  <li>Offering alternative biometric collection and comparison capabilities.</li>
</ol>

<p><strong>Description: When using 1:1 facial image comparison technologies, biased facial comparison algorithms may result in false non-matches.</strong></p>

<p>Possible mitigations include:</p>

<ol>
  <li>Using algorithms that are independently tested for consistent performance across demographic groups and image types</li>
  <li>Supporting alternative processes to compensate for residual bias and technological limitations</li>
  <li>Conducting ongoing quality monitoring and operational testing to identify performance variances across demographic groups and implementing corrective actions as needed (e.g., updated algorithms, machine learning, etc.)</li>
</ol>

<p><strong>Description: When employing visual facial image comparison performed by agents of the CSP (proofing agents or trusted referees), human biases and inconsistencies in making facial comparisons may result in false non-matches.</strong></p>

<p>Possible mitigations include:</p>

<ol>
  <li>Defining policy and procedures aimed at reducing/eliminating the inequitable treatment of applicants by CSP agents</li>
  <li>Rigorously training and certifying CSP agents</li>
  <li>Conducting ongoing quality monitoring and taking corrective actions when biases, inequitable treatments, or outcomes are identified</li>
</ol>
<h2 id="EquityUser" data-section="9">
  
  
    User Experience and Equity <a href="#EquityUser" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p>The Usability Considerations section of this document (<a href="/800-63-4/sp800-63a/usability/#usability">Sec. 8</a>) provides CSPs with guidance on how to provide applicants with a smooth, positive identity proofing experience. In addition to the specific considerations provided in <a href="/800-63-4/sp800-63a/usability/#usability">Sec. 8</a>, this section provides CSPs with additional considerations when considering the equity of their user experience.</p>

<p><strong>Description: Lack of access to the needed technology (e.g. connected mobile device or computer), or difficulties in using the required technologies, unduly burdens some user groups.</strong></p>

<p>Possible mitigations include:</p>

<ol>
  <li>Allowing the use of process assistants who assist applicants, who are otherwise able to meet the identity proofing requirements, in the use of the required technologies and activities</li>
  <li>Allowing the use of publicly-available devices (e.g., computers or tablets) and providing online help resources for completing the identity proofing process on a non-applicant-owned computer or device</li>
  <li>Providing in-person proofing options</li>
  <li>Employing technologies, such as auto capture, that simplify the uploading of identity evidence and facial images</li>
</ol>

<p><strong>Description: The remote or in-person identity proofing process presents challenges for persons with disabilities.</strong></p>

<p>Possible mitigations for remote identity proofing include:</p>

<ol>
  <li>Providing trusted referees (<a href="/800-63-4/sp800-63a/ial-general/#TRs">Sec. 3.1.13.1</a>) who are trained to communicate and assist people with a variety of needs or disabilities (e.g., fluent in sign language)</li>
  <li>Allowing for the use of applicant references (<a href="/800-63-4/sp800-63a/ial-general/#ARs">Sec. 3.1.13.3</a>)</li>
  <li>Supporting the use of accessibility and other technologies, such as audible instructions, screen readers and voice recognition technologies</li>
  <li>Allowing the use of process assistants to assist applicants, who are otherwise able to meet the identity proofing requirements, in the use of the required technologies and activities</li>
</ol>

<p>Possible mitigations for in-person identity proofing include:</p>

<ol>
  <li>Providing trained operators who are trained to communicate and assist people with a variety of needs or disabilities (e.g., fluent in sign language)</li>
  <li>Choosing equipment and workstations that can be adjusted to different heights and angles</li>
  <li>Selecting locations that are convenient and comply with ADA accessibility guidelines</li>
</ol>

<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-63a/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-63a/references/#ref-COPPA" name="ref-COPPA">[COPPA]</a> Children’s Online Privacy Protection Act of 1998, Pub. L. 105-277 Title XIII, 112 Stat. 2681-728. Available at <a href="https://www.govinfo.gov/app/details/PLAW-105publ277">https://www.govinfo.gov/app/details/PLAW-105publ277</a></p>

<p><a href="/800-63-4/sp800-63a/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-63a/references/#ref-EO13988" name="ref-EO13988">[EO13988]</a> Biden J (2021) Preventing and Combating Discrimination on the Basis of Gender Identity or Sexual Orientation. (The White House, Washington, DC), Executive Order 13988, January 20, 2021. <a href="https://www.federalregister.gov/documents/2021/01/25/2021-01761/preventing-and-combating-discrimination-on-the-basis-of-gender-identity-or-sexual-orientation">https://www.federalregister.gov/documents/2021/01/25/2021-01761/preventing-and-combating-discrimination-on-the-basis-of-gender-identity-or-sexual-orientation</a></p>

<p><a href="/800-63-4/sp800-63a/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-63a/references/#ref-E-Gov" name="ref-E-Gov">[E-Gov]</a> E-Government Act of 2002, Pub. L. 107-347, 116 Stat. 2899. <a href="https://www.govinfo.gov/app/details/PLAW-107publ347">https://www.govinfo.gov/app/details/PLAW-107publ347</a></p>

<p><a href="/800-63-4/sp800-63a/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-63a/references/#ref-ISO16982" name="ref-ISO16982">[ISO16982]</a> International Standards Organization (2002) <em>ISO/TR 16982:2002 Ergonomics of human-system interaction Usability methods supporting human-centred design</em> (ISO, Geneva, Switzerland). Available at <a href="https://www.iso.org/standard/31176.html">https://www.iso.org/standard/31176.html</a></p>

<p><a href="/800-63-4/sp800-63a/references/#ref-ISO25060" name="ref-ISO25060">[ISO25060]</a> International Standards Organization (2023) <em>ISO/TR 25060:2023 Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) General framework for Common Industry Format (CIF) for usability-related information</em> (ISO, Geneva, Switzerland). Available at <a href="https://www.iso.org/standard/83763.html">https://www.iso.org/standard/83763.html</a></p>

<p><a href="/800-63-4/sp800-63a/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-63a/references/#ref-NIST-Privacy" name="ref-NIST-Privacy">[NIST-Privacy]</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) 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-63a/references/#ref-NIST-RMF" name="ref-NIST-RMF">[NIST-RMF]</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-63a/references/#ref-OMB-Equity" name="ref-OMB-Equity">[OMB-Equity]</a> Office of Management and Budget (July 20th, 2021). Study to Identify Methods to Assess Equity: Report to the President. <a href="https://www.whitehouse.gov/wp-content/uploads/2021/08/OMB-Report-on-E013985-Implementation_508-Compliant-Secure-v1.1.pdf">https://www.whitehouse.gov/wp-content/uploads/2021/08/OMB-Report-on-E013985-Implementation_508-Compliant-Secure-v1.1.pdf</a></p>

<p><a href="/800-63-4/sp800-63a/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-2020-title5/pdf/USCODE-2020-title5-partI-chap5-subchapII-sec552a.pdf">https://www.govinfo.gov/content/pkg/USCODE-2020-title5/pdf/USCODE-2020-title5-partI-chap5-subchapII-sec552a.pdf</a></p>

<p><a href="/800-63-4/sp800-63a/references/#ref-Section508" name="ref-Section508">[Section508]</a> General Services Administration (2022) <em>IT Accessibility Laws and Policies</em>. Available at <a href="https://www.section508.gov/manage/laws-and-policies/">https://www.section508.gov/manage/laws-and-policies/</a></p>

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

<p><a href="/800-63-4/sp800-63a/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-63a/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-63a/references/#ref-SP800-161" name="ref-SP800-161">[SP800-161]</a> Boyen H, Smith A, Bartol N, Winkler K, Holbrook A (2022) Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD) NIST Special Publication (SP) 800-161r1. <a href="https://doi.org/10.6028/NIST.SP.800-161r1">https://doi.org/10.6028/NIST.SP.800-161r1</a></p>

<h1 id="EvidenceExamples" data-section="A">
  
  
    Identity Evidence Examples by Strength <a href="#EvidenceExamples" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h1>

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

<p>This appendix provides a non-exhaustive list of types of identity evidence, grouped by strength.</p>
<h2 id="fair-evidence-examples" data-section="A">
  
  
    Fair Evidence Examples <a href="#fair-evidence-examples" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p latex-ignore="true"><a href="/800-63-4/sp800-63a/evidence/#table-A1" name="table-A1">Table 4. Fair Evidence Examples</a></p>

<table latex-table="4" latex-caption="Fair Evidence Examples" latex-longtable="true" latex-columns="p@0.20\textwidth,p@0.20\textwidth,p@0.20\textwidth,p@0.30\textwidth">
  <thead>
    <tr>
      <th>Evidence</th>
      <th>Proofing</th>
      <th>Validation</th>
      <th>Verification</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Financial Account</td>
      <td>KYC/CIP requirements</td>
      <td>Confirm signature on assertion is from intended origin.</td>
      <td>*Demonstrated possession via an AAL2 authentication event and FAL 2 federated assertion. *User input of a micro deposit event of sufficient entropy.</td>
    </tr>
    <tr>
      <td>Phone Account</td>
      <td>Established and documented account opening practices.</td>
      <td>*Confirm presence of user account with MNO. *Confirm signature on assertion is from intended origin.</td>
      <td>*Demonstrated possession through enrollment code. *Demonstrated possession via and AAL2 authentication event and FAL2 federated assertion.</td>
    </tr>
    <tr>
      <td>Student ID Card</td>
      <td>Student registration and enrollment practices.</td>
      <td>*Confirm signature on assertion is from intended origin; or  *Confirm physical security features and evaluate for tampering.</td>
      <td>*Demonstrated possession via and AAL2 authentication event and FAL2 federated assertion. *Physical comparison to image on the ID. *Biometric Comparison to image on the ID.</td>
    </tr>
    <tr>
      <td>Corporate ID Card</td>
      <td>Onboarding and background screening practices.</td>
      <td>*Confirm signature on assertion is from intended origin; or *Confirm physical security features and evaluate for tampering.</td>
      <td>*Demonstrated possession via and AAL2 authentication event and FAL2 federated assertion. *Physical comparison to image on the ID. *Biometric Comparison to image on the ID.</td>
    </tr>
    <tr>
      <td>Veteran Health ID card</td>
      <td>VA identity verification, issuance and eligibility process</td>
      <td>*Confirm signature on assertion is from intended origin; or *Confirm physical security features and evaluate for tampering</td>
      <td>*Demonstrated possession via and AAL2 authentication event and FAL2 federated assertion. *Physical comparison to image on the ID. *Biometric Comparison to image on the ID.</td>
    </tr>
    <tr>
      <td>Credit or Debit Card</td>
      <td>KYC/CIP Account Opening Practices.</td>
      <td>*Confirm physical security features, physical signature.</td>
      <td>*Demonstrated ability to authenticate to the card using a PIN or other activation factor (if available). *Physical inspection of the card. Must be presented with other evidence containing a photo.</td>
    </tr>
    <tr>
      <td>Snap Card</td>
      <td>State defined eligibility and enrollment requirements.</td>
      <td>Confirm physical security features, physical signature</td>
      <td>*Visual inspection of the card. Must be presented with other evidence containing a photo (if there is no image on the card).</td>
    </tr>
    <tr>
      <td>Social Security Card</td>
      <td>SSN application process.</td>
      <td>*Confirm physical security features, inspect for tampering.</td>
      <td>*Visual inspection of the card. Must be presented with other evidence containing a photo.</td>
    </tr>
  </tbody>
</table>

<div latex-literal="true" class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>\clearpage
</code></pre></div></div>
<h2 id="strong-evidence-examples" data-section="A">
  
  
    Strong Evidence Examples <a href="#strong-evidence-examples" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p latex-ignore="true"><a href="/800-63-4/sp800-63a/evidence/#table-A2" name="table-A2">Table 5. Strong Evidence Examples</a></p>

<table latex-table="5" latex-caption="Strong Evidence Examples" latex-longtable="true" latex-columns="p@0.20\textwidth,p@0.20\textwidth,p@0.20\textwidth,p@0.30\textwidth">
  <thead>
    <tr>
      <th>Evidence</th>
      <th>Proofing</th>
      <th>Validation</th>
      <th>Verification</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Driver’s License or State ID</td>
      <td>State issuance processes, REAL ID Act</td>
      <td>Confirm physical security features through inspection.</td>
      <td>*Physical comparison of image on ID. *Biometric Comparison of the image on the ID. *Biometric comparison to issuing source records.</td>
    </tr>
    <tr>
      <td>Permanent Resident Card (issued prior to May 11, 2010)</td>
      <td>DHS issuance and eligibility process</td>
      <td>*Confirm physical security features through inspection.</td>
      <td>*Physical comparison of image on ID. *Biometric Comparison of the image on the ID. *Biometric comparison to issuing source records.</td>
    </tr>
    <tr>
      <td>U.S. Uniformed Services Privilege and Identification Card</td>
      <td>DoD issuance and eligibility processes</td>
      <td>*Confirm physical security features through inspection.</td>
      <td>*Visual comparison of image on ID. *Biometric Comparison of the image on the ID. *Biometric comparison to issuing source records.</td>
    </tr>
    <tr>
      <td>Native American Tribal Photo Identification Card</td>
      <td>Local issuance and eligibility processes</td>
      <td>*Confirm physical security features through inspection.</td>
      <td>*Visual comparison of image on ID. *Biometric Comparison of the image on the ID. *Biometric comparison to issuing source records.</td>
    </tr>
    <tr>
      <td>Veteran Health ID Card (VHIC)</td>
      <td>VA identity verification, issuance and eligibility process</td>
      <td>*Confirm physical security features and evaluate for tampering</td>
      <td>*Visual comparison to image on the ID. *Biometric Comparison to image on the ID.</td>
    </tr>
  </tbody>
</table>

<div latex-literal="true" class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>\clearpage
</code></pre></div></div>
<h2 id="superior-evidence-examples" data-section="A">
  
  
    Superior Evidence Examples <a href="#superior-evidence-examples" class="header-link"><i class="fa fa-link"></i></a>
  
  
</h2>

<p latex-ignore="true"><a href="/800-63-4/sp800-63a/evidence/#table-A3" name="table-A3">Table 6. Superior Evidence Examples</a></p>

<table latex-table="6" latex-caption="Superior Evidence Examples" latex-longtable="true" latex-columns="p@0.20\textwidth,p@0.20\textwidth,p@0.20\textwidth,p@0.30\textwidth">
  <thead>
    <tr>
      <th>Evidence</th>
      <th>Proofing</th>
      <th>Validation</th>
      <th>Verification</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Personal Identity Verification (PIV) Card</td>
      <td>FIPS 201-3 identity verification and issuance processes</td>
      <td>Validation of stored PKI Certificate, CRL check if available</td>
      <td>*Authentication consistent with multi-factor cryptographic authenticators per NIST SP 800-63B. *Biometric comparison to image stored on ID or biometric stored on ID. *Visual comparison of image on ID.</td>
    </tr>
    <tr>
      <td>Personal Identity Verification-Interoperable (PIV-I) Card</td>
      <td>FIPS 201-3 identity verification and issuance processes</td>
      <td>Validation of stored PKI Certificate, CRL check if available</td>
      <td>*Authentication consistent with multi-factor cryptographic authenticators per NIST SP 800-63B. *Biometric comparison to image stored on ID or biometric stored on ID. *Visual comparison of image on ID.</td>
    </tr>
    <tr>
      <td>Common Access Card (CAC)</td>
      <td>DoD identity verification and issuance process</td>
      <td>Validation of stored PKI Certificate, CRL check if available</td>
      <td>*Authentication consistent with multi-factor cryptographic authenticators per NIST SP 800-63B. *Biometric comparison to image stored on ID or biometric stored on ID. *Visual comparison of image on ID.</td>
    </tr>
    <tr>
      <td>US Passport</td>
      <td>State Department passport issuance process</td>
      <td>Validation of stored PKI certificate, CRL check if available.</td>
      <td>*Visual comparison of image on ID on stored in ID. *Biometric comparison to image on ID or stored in ID. *Biometric comparison to issuing source records.</td>
    </tr>
    <tr>
      <td>International e-Passports Passports</td>
      <td>ICAO compliant and/or State Department approved</td>
      <td>Validation of stored PKI certificate, CRL check if available.</td>
      <td>*Visual comparison of image on ID on stored in ID. *Biometric comparison to image on ID or stored in ID. *Biometric comparison to issuing source records.</td>
    </tr>
    <tr>
      <td>Mobile Driver’s License (MDL)</td>
      <td>State Issuance processes, AAMVA guidance, and Real ID Act</td>
      <td>Validation of Mobile Security Object, revocation check if available</td>
      <td>*Authentication consistent with multi-factor cryptographic authenticators per NIST SP 800-63B.</td>
    </tr>
    <tr>
      <td>Digital Permanent Resident Card (Verifiable Credential)</td>
      <td>DHS issuance and eligibility process</td>
      <td>Validation of stored verifiable credential, revocation check if available</td>
      <td>*Authentication consistent with multi-factor cryptographic authenticators per NIST SP 800-63B.</td>
    </tr>
    <tr>
      <td>European Digital Identity Wallet (EUDI Wallet) Personal Identification (PID) Element</td>
      <td>EC defined identity verification and issuance process; qualified issuer certified</td>
      <td>Validation of stored verifiable credential or Mobile Security Object, revocation check if available</td>
      <td>*Authentication consistent with multi-factor cryptographic authenticators per NIST SP 800-63B.</td>
    </tr>
  </tbody>
</table>

<h1 id="abbr" data-section="B">
  
  
    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>AAL</dt>
  <dd>Authentication Assurance Level</dd>
  <dt>CSP</dt>
  <dd>Credential Service Provider</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>KBA</dt>
  <dd>Knowledge-Based Authentication</dd>
  <dt>KBV</dt>
  <dd>Knowledge-Based Verification</dd>
  <dt>MFA</dt>
  <dd>Multi-Factor Authentication</dd>
  <dt>NARA</dt>
  <dd>National Archives and Records Administration</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>PKI</dt>
  <dd>Public Key Infrastructure</dd>
  <dt>RMF</dt>
  <dd>Risk Management Framework</dd>
  <dt>RP</dt>
  <dd>Relying Party</dd>
  <dt>SMS</dt>
  <dd>Short Message Service</dd>
  <dt>SORN</dt>
  <dd>System of Records Notice</dd>
</dl>

<h1 id="def-and-acr" data-section="C">
  
  
    Glossary <a href="#def-and-acr" 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>applicant</dt>
  <dd>A <em>subject</em> undergoing the processes of <em>identity proofing</em> and <em>enrollment</em>.</dd>
  <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>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 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>authenticate</dt>
  <dd>See <em>authentication</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>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>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>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>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>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 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>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 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>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-63a/references/#ref-NISTIR8062">[NISTIR8062]</a></dd>
  <dt>electronic authentication (e-authentication)</dt>
  <dd>See <em>digital authentication</em>.</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-63a/references/#ref-EO13985">[EO13985]</a></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>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>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 session) 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 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> in order 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>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-63a/references/#ref-NISTIR8062">[NISTIR8062]</a></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>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 service</dt>
  <dd>A service that is accessed remotely via a <em>network</em>, typically the internet.</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-63a/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>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-63a/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-63a/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>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-63a/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>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>resolution</dt>
  <dd>See <em>identity resolution</em>.</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>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>
</dl>

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

<dl>
  <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>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>transaction</dt>
  <dd>See <em>digital transaction</em></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>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-63a/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</dd>
</dl>

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

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

<p>This appendix provides a high-level overview of the changes to SP 800-63A since its initial release.</p>

<ul>
  <li>Reorganizes the sections to introduce general identity proofing requirements before providing specific requirements</li>
  <li>Separates global requirements from IAL-specific requirements to facilitate the design of identity services, regardless of assurance level</li>
  <li>Provides requirements for lower-risk applications, through an updated IAL1</li>
  <li>Introduces fraud mitigation guidance and requirements</li>
  <li>Adds requirements for CSP-specific privacy and equity risk assessments and considerations for integrating the results into agency assessment processes</li>
  <li>Introduces the concept of core attributes</li>
  <li>Decouples the collection of identity attributes from the collection of identity evidence</li>
  <li>Adjusts evidence collection requirements for IALs 1 and 2</li>
  <li>Expands acceptable evidence and attribute validation sources to include credible sources</li>
  <li>Provides non-biometric options for identity verification at IALs 1 and 2</li>
  <li>Adds new guidance and requirements for subscriber accounts</li>
  <li>Adds new guidance and requirements for the consideration of equity risks associated with identity proofing processes</li>
  <li>Introduces exception handling concepts and requirements, including requirements for the use of trusted referees and applicant references</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-63a/"], .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-63a/"]').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>