View this document as: a single page | multiple pages.

Wed, 22 Feb 2023 09:09:01 +0000

ABSTRACT

These guidelines provide technical requirements for federal agencies implementing digital identity services and are not intended to constrain the development or use of standards outside of this purpose. The guidelines cover identity proofing and authentication of users (such as employees, contractors, or private individuals) interacting with government information systems over networks. They define technical requirements in each of the areas of identity proofing, registration, authenticators, management processes, authentication protocols, federation, and related assertions. This publication will supersede NIST Special Publication 800-63-3.

Keywords

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

Note to Reviewers

過去数年間のオンライン サービスの急速な普及により，信頼性が高く，公平で，安全で，プライバシーが保護されたデジタル ID ソリューションの必要性が高まっています．

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.

NIST SP 800-63 のリビジョン4，デジタルアイデンティティガイドラインは，最後の主要なリビジョンが 2017 年に発行されて以来，出現した変化するデジタルランドスケープに対応することを意図している — オンラインリスクの現実世界への影響を含む．このガイドラインは，身元確認(identity proofing)，認証(authentication)，フェデレーション(federation)のデジタルアイデンティティ管理保証レベルを満たすためのプロセスと技術的な要件を示している．これには，セキュリティとプライバシーの要件，およびデジタルアイデンティティソリューションとテクノロジの公平性と使いやすさを促進するための考慮事項が含まれる．

Revision 4 of NIST Special Publication 800-63, Digital Identity Guidelines, 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.

2020年6月のドラフト前のコメント募集にて提供されたフィードバックを考慮して，およびガイドラインの実際の実装，市場の革新，現在の脅威環境について実施された調査に加えて，このドラフトは次のことを目指している．

Taking into account feedback provided in response to our June 2020 Pre-Draft Call for Comments, as well as research conducted into real-world implementations of the guidelines, market innovation, and the current threat environment, this draft seeks to:

  1. 更なる公平性: このドラフトは，以前の改訂のリスク管理の内容を拡張することを目指しており，組織への影響に加えて，個人やコミュニティへの影響を説明することを機関に明確に義務付けている．また，リスク管理プロセス内およびデジタルアイデンティティシステムの実装時に，ミッションの提供に対するリスクを高める．これには，資格のあるすべての人にサービスを提供するという課題が含まれる．さらに，ガイダンスは現在，人口統計全体にわたる，潜在的な影響の継続的な評価を義務付けており，生体認証のパフォーマンス要件，および顔認識を利用するものなどの生体認証ベースの技術の責任ある使用のための追加のパラメーターを提供している．
  1. Advance Equity: This draft seeks to expand upon the risk management content of previous revisions and specifically mandates that agencies account for impacts to individuals and communities in addition to impacts to the organization. It also elevates risks to mission delivery – including challenges to providing services to all people who are eligible for and entitled to them – within the risk management process and when implementing digital identity systems. Additionally, the guidance now mandates continuous evaluation of potential impacts across demographics, provides biometric performance requirements, and additional parameters for the responsible use of biometric-based technologies, such as those that utilize face recognition.
  1. 消費者の選択性と選択肢の強調: 顔認識技術を利用するものや利用しないものを含む，追加のスケーラブルで公平で便利な身元確認オプションを促進および調査するために，このドラフトは，さまざまな手段，動機，および背景を持つ個人にサービスを安全に提供するための新しいメカニズムを提供するための身元確認の代替手段として許容可能なリストを拡大する．この改訂では，多様な消費者のニーズに対応し，アカウントを安全に復元するために，デジタルアイデンティティサービスが複数の認証オプションをサポートする必要性も強調している．
  1. Emphasize Optionality and Choice for Consumers: In the interest of promoting and investigating additional scalable, equitable, and convenient identify verification options, including those that do and do not leverage face recognition technologies, this draft expands the list of acceptable identity proofing alternatives to provide new mechanisms to securely deliver services to individuals with differing means, motivations, and backgrounds. The revision also emphasizes the need for digital identity services to support multiple authenticator options to address diverse consumer needs and secure account recovery.
  1. 詐欺と高度な脅威の抑止: このドラフトは，新しい攻撃に対応するためにリスクと脅威のモデルを更新し，フィッシング耐性のある認証のための新しいオプションを提供し，登録プロセスに対する自動化された攻撃を防止するための要件を導入することにより，第3版の詐欺防止対策を強化する．また，モバイル運転免許証(mDL)や verifiable credentials などの新しいテクノロジーへの扉も開く．
  1. Deter Fraud and Advanced Threats: This draft enhances fraud prevention measures from the third revision by updating risk and threat models to account for new attacks, providing new options for phishing resistant authentication, and introducing requirements to prevent automated attacks against enrollment processes. It also opens the door to new technology such as mobile driver’s licenses and verifiable credentials.
  1. 実装で学んだ教訓への対処: このドラフトでは，実装の経験から，ガイドラインを効果的に運用するために追加の明確さや詳細が必要であることが示された領域に対処している．これには，フェデレーションの保証レベルの見直し，Trusted Referee に関する詳細の提供，属性の検証ソースに関するガイドラインの明確化，アドレス確認要件の改善が含まれる．
  1. Address Implementation Lessons Learned: This draft addresses areas where implementation experience has indicated that additional clarity or detail was required to effectively operationalize the guidelines. This includes re-working the federation assurance levels, providing greater detail on Trusted Referees, clarifying guidelines on identity attribute validation sources, and improving address confirmation requirements.

NIST は，次のトピックに関するコメントと推奨事項に特に関心がある．

NIST is specifically interested in comments on and recommendations for the following topics:

身元確認と登録 (Identity Proofing and Enrollment)

  • NIST sees a need for inclusion of an unattended, fully remote Identity Assurance Level (IAL) 2 identity proofing workflow that provides security and convenience, but does not require face recognition. Accordingly, NIST seeks input on the following questions:
    • What technologies or methods can be applied to develop a remote, unattended IAL2 identity proofing process that demonstrably mitigates the same risks as the current IAL2 process?
    • Are these technologies supported by existing or emerging technical standards?
    • Do these technologies have established metrics and testing methodologies to allow for assessment of performance and understanding of impacts across user populations (e.g., bias in artificial intelligence)?
  • What methods exist for integrating digital evidence (e.g., Mobile Driver’s Licenses, Verifiable Credentials) into identity proofing at various identity assurance levels?
  • What are the impacts, benefits, and risks of specifying a set of requirements for CSPs to establish and maintain fraud detection, response, and notification capabilities?
    • Are there existing fraud checks (e.g., date of death) or fraud prevention techniques (e.g., device fingerprinting) that should be incorporated as baseline normative requirements? If so, at what assurance levels could these be applied?
    • How might emerging methods such as fraud analytics and risk scoring be further researched, standardized, measured, and integrated into the guidance in the future?
    • What accompanying privacy and equity considerations should be addressed alongside these methods?
  • Are current testing programs for liveness detection and presentation attack detection sufficient for evaluating the performance of implementations and technologies?
  • What impacts would the proposed biometric performance requirements for identity proofing have on real-world implementations of biometric technologies?

リスク管理 (Risk Management)

  • What additional guidance or direction can be provided to integrate digital identity risk with enterprise risk management?
  • How might equity, privacy, and usability impacts be integrated into the assurance level selection process and digital identity risk management model?
  • How might risk analytics and fraud mitigation techniques be integrated into the selection of different identity assurance levels? How can we qualify or quantify their ability to mitigate overall identity risk?

認証とライフサイクル管理 (Authentication and Lifecycle Management)

  • Are emerging authentication models and techniques – such as FIDO passkey, Verifiable Credentials, and mobile driver’s licenses – sufficiently addressed and accommodated, as appropriate, by the guidelines? What are the potential associated security, privacy, and usability benefits and risks?
  • Are the controls for phishing resistance as defined in the guidelines for AAL2 and AAL3 authentication clear and sufficient?
  • How are session management thresholds and reauthentication requirements implemented by agencies and organizations? Should NIST provide thresholds or leave session lengths to agencies based on applications, users, and mission needs?
  • What impacts would the proposed biometric performance requirements for this volume have on real-world implementations of biometric technologies?

フェデレーションとアサーション (Federation and Assertions)

  • What additional privacy considerations (e.g., revocation of consent, limitations of use) may be required to account for the use of identity and provisioning APIs that had not previously been discussed in the guidelines?
  • Is the updated text and introduction of “bound authenticators” sufficiently clear to allow for practical implementations of federation assurance level (FAL) 3 transactions? What complications or challenges are anticipated based on the updated guidance?

全体 (General)

  • Is there an element of this guidance that you think is missing or could be expanded?
  • Is any language in the guidance confusing or hard to understand? Should we add definitions or additional context to any language?
  • Does the guidance sufficiently address privacy?
  • Does the guidance sufficiently address equity?
    • What equity assessment methods, impact evaluation models, or metrics could we reference to better support organizations in preventing or detecting disparate impacts that could arise as a result of identity verification technologies or processes?
  • What specific implementation guidance, reference architectures, metrics, or other supporting resources may enable more rapid adoption and implementation of this and future iterations of the Digital Identity Guidelines?
  • What applied research and measurement efforts would provide the greatest impact on the identity market and advancement of these guidelines?

レビュアーは，NIST SP 800-63-4 の 4 つのドラフトボリュームすべてのテキストにコメントし，変更を提案することをお勧めする．コメントの締め切りは 2023年3月24日の午後11時59分(東部時間)である．コメント送信先は dig-comments@nist.gov．NIST はすべてのコメントを確認し，NIST Identity and Access Management websiteで確認できるようにする．コメントは、 NIST Computer Security Resource Center website で提供されているコメントテンプレートを使用することをお勧めする.

Reviewers are encouraged to comment and suggest changes to the text of all four draft volumes of of the NIST SP 800-63-4 suite. NIST requests that all comments be submitted by 11:59pm Eastern Time on March 24, 2023. Please submit your comments to dig-comments@nist.gov. NIST will review all comments and make them available at the NIST Identity and Access Management website. Commenters are encouraged to use the comment template provided on the NIST Computer Security Resource Center website.

Purpose

This section is informative.

This publication and its companion volumes, [SP800-63A], [SP800-63B], and [SP800-63C], provide technical guidelines to organizations for the implementation of digital identity services.

はじめに (Introduction)

This section is informative.

仮想世界と物理世界の境界線が曖昧になり，デジタルおよびインターネット対応の技術が急増して接続し続けるにつれて，開発者と消費者は，関連する機会とリスクを含んで，この変化するハイブリッドエコシステムを理解することが不可欠である．このエコシステム全体での約束(engagement)は，多くの場合，個人の能力とデジタルアイデンティティ(オンライントランザクションに従事している個人の固有の表現) を確立する意思によって決定される．

As the line between the virtual world and physical world blurs, and as digital and internet-enabled technologies continue to proliferate and connect, it is imperative that developers and consumers alike understand this changing hybrid ecosystem - including its associated opportunities and risks. Engagement across this ecosystem is often determined by an individual’s ability and willingness to establish a digital identity - the unique representation of a person engaged in an online transaction.

デジタルアイデンティティは，デジタルサービスの文脈においてはは常に一意であるものの，すべての文脈において常に個人を一意に識別するわけではない．さらに，デジタルアイデンティティは，デジタルサービスの文脈において固有の特定の意味を表す場合があるが，デジタルアイデンティティの背後にある個人の実際のアイデンティティは不明な場合がある．本刊行物の目的上，「人」は自然人のみを指す (つまり，すべての法人ではない)．

A digital identity is always unique in the context of a digital service but does not always uniquely identify a person in all contexts. Further, while a digital identity may relay unique and specific meaning within the context of a digital service, the real-life identity of the individual behind the digital identity may not be known. For the purpose of this publication, a “person” refers to natural persons only (i.e., not all legal persons.)

デジタルアイデンティティの確立は，デジタルアイデンティティの所有者と，デジタルトランザクションの相手側の人，組織，またはシステムとの間の信頼を示すことを目的としている．ただし，このプロセスには問題が生じる可能性がある．物理的な世界での関係や取引と同様に，間違い，誤解，なりすまし，および他人のデジタルアイデンティティを不正に主張するその他の攻撃の機会が複数存在する．さらに，幅広い個人のニーズ，制約，能力，および好みを考慮して，デジタルサービスは公平性と柔軟性を念頭に置いて設計し，広範かつ永続的な参加を保証する必要がある．

Establishing a digital identity is intended to demonstrate trust between the holder of the digital identity and the person, organization, or system on the other side of the digital transaction. However, this process can present challenges. As in relationships and transactions in the physical world, there are multiple opportunities for mistakes, miscommunication, impersonation, and other attacks that fraudulently claim another person’s digital identity. Additionally, given the broad range of individual needs, constraints, capacities, and preferences, digital services must be designed with equity and flexibility in mind to ensure broad and enduring participation.

デジタルアイデンティティに関連するリスクは，企業への潜在的な影響を超えているため，企業の意思決定に組み込む必要がある． 本刊行物は，個人，コミュニティ，およびその他の組織に対するリスクをより確実かつ明確に説明するよう努めている．具体的には，このガイダンスを使用する際に，組織は，組織のサイバーセキュリティの目的を優先するデジタルアイデンティティに関連する決定が，他の目的にどのように影響するか，またはそれに対応する必要があるかを検討する必要がある．(プログラムやサービスと対話する個人の経験を中心とする，プライバシー，公平性，使いやすさ，およびミッションとビジネスパフォーマンスのその他の指標に関連するものなど)．人間中心で継続的に情報に基づいた方法でミッションを遂行することにより，組織はサービスを提供するさまざまな人々との信頼関係を徐々に構築し，顧客満足度を向上させ，問題をより迅速に特定し，効果的で文化的に適切な是正オプションを個人に提供する機会を得ることができる．

Risks associated with digital identity stretch beyond the potential impacts to enterprises and should be incorporated into enterprise decision-making. This publication endeavors to more robustly and explicitly account for risks to individuals, communities, and other organizations. Specifically, while using this guidance, organizations should consider how decisions related to digital identity that prioritize organizational cybersecurity objectives might affect or need to accommodate other objectives, such as those related to privacy, equity, usability, and other indicators of mission and business performance that center the experiences of the individuals interacting with programs and services. By taking a human-centered and continuously informed approach to mission delivery, organizations have an opportunity to incrementally build trust with the variety of populations they serve, improve customer satisfaction, identify issues more quickly, and provide individuals with effective and culturally appropriate redress options.

本ガイドラインは，デジタルアイデンティティ管理をサポートするプロセス，ポリシー，データ，人，テクノロジーなど，デジタルアイデンティティシステムに関連するリスクを評価および管理するための，連邦政府のプログラムやその他の組織向けのモデルを示している． このモデルは，身元確認(identity proofing)，当人認証(authentication)，フェデレーションという一連のプロセスによってサポートされている．身元確認プロセスは，主体が特定の物理的な人物であることを確立する．当人認証プロセスは，デジタルアイデンティティを主張するために使用される 1つまたは複数のオーセンティケーターの有効性を判断し，主体がデジタルサービスにアクセスしようとしているという信頼を確立する．つまり，主体は，(1) 認証に使用されるテクノロジを管理しており，(2) 以前にサービスにアクセスしたのと同じ主体であるということを確認する．最後に，フェデレーションプロセスにより，システム間での認証をサポートするためにアイデンティティ情報を共有することができる．

These guidelines lay out a model for federal programs and other organizations to assess and manage risks associated with digital identity systems, including the processes, policies, data, people, and technologies that support digital identity management. The model is supported by a series of processes: identity proofing, authentication, and federation. The identity proofing process establishes that a subject is a specific physical person. The digital authentication process determines the validity of one or more authenticators used to claim a digital identity and establishes confidence that a subject attempting to access a digital service: (1) is in control of the technologies being used for authentication, and (2) is the same subject that previously accessed the service. Finally, the federation process allows for identity information to be shared in support of authentication across systems.

SP 800-63 の初版がリリースされて以来，アイデンティティサービスの構成，モデル，および可用性は大幅に変化しており，さまざまなユーザーコミュニティに安全でプライベートで公平なサービスを展開する際の考慮事項と課題も変化している．本改訂では，これらの課題に対処すると同時に，エンティティが全体的なデジタルアイデンティティモデルの下で提供できる機能に基づいて要件を明確にすることにより，開発されたアイデンティティサービスの新しいモデルとアーキテクチャを促進する．

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

さらに，本刊行物は，クレデンシャルサービスプロバイダー (CSP)，検証者，および　Relying Party (RP) 向けの指示を提供し，組織がデジタルアイデンティティサービスを実装するために従うべき管理プロセスを説明しており，NIST Risk Management Framework [NISTRMF]とその構成特殊刊行物(Special Publications) を補足する．本刊行物は，公平性とユーザビリティの考慮事項をデジタルアイデンティティリスク管理プロセスに組み込む方法を概説することで NIST RMF を拡張し，企業の運用と資産だけでなく，個人や他の組織，より広義には社会に及ぼす影響を考慮することの重要性を強調している．さらに，デジタル認証は，個人情報への不正アクセスのリスクを軽減することでプライバシー保護をサポートするが，身元確認(identity proofing)，当人認証(authentication)，承認(authorization)，フェデレーションには個人情報の処理が含まれることが多いため，これらの機能はプライバシーリスクも生み出す可能性がありる．したがって，これらのガイドラインには，関連する潜在的なプライバシー リスクを軽減するのに役立つプライバシー要件と考慮事項が含まれている．

Additionally, this publication provides instruction for credential service providers (CSPs), verifiers, and relying parties (RPs) and it describes the risk management processes that organizations should follow for implementing digital identity services and that supplement the NIST Risk Management Framework [NISTRMF] and its component special publications. The publication expands upon the NIST RMF by outlining how equity and usability considerations should be incorporated into digital identity risk management processes and it highlights the importance of considering impacts, not only on the enterprise operations and assets, but also on individuals, other organizations, and, more broadly, society. Further, while digital authentication supports privacy protection by mitigating risks of unauthorized access to individuals’ information, given that identity proofing, authentication, authorization, and federation often involve the processing of individuals’ information, these functions can also create privacy risks. These guidelines, therefore, include privacy requirements and considerations to help mitigate potential associated privacy risks.

最後に，本刊行物は，ネットワークを介してデジタルシステムにアクセスするために主体のデジタルアイデンティティを確立，維持，および認証するための技術的要件と推奨事項を組織に提供するが，障壁と悪影響に対処し，公平性を促進し，任務の目的を首尾よく遂行するために，情報技術チームの範囲外の追加のサポートオプションを提供する必要のある場合がある．

Finally, while this publication provides organizations with technical requirements and recommendations for establishing, maintaining, and authenticating the digital identity of subjects in order to access digital systems over a network, additional support options outside the purview of information technology teams may need to be provided to address barriers and adverse impacts, foster equity, and successfully deliver on mission objectives.

Scope & Applicability

すべてのデジタルサービスが身元確認(identity proofing)や当人認証(authentication)を必要とするわけではない．ただし，本ガイドラインは，対象者 (市民，ビジネス パートナー，政府機関など) に関係なく，ある程度のデジタルアイデンティティが必要なすべてのオンライントランザクションに適用される．

Not all digital services require identity proofing or authentication; however, this guidance applies to all online transactions for which some level of digital identity is required, regardless of the constituency (e.g., citizens, business partners, and government entities).

本ガイドラインは主に，公益にアクセスする市民やコラボレーションスペースにアクセスする民間部門のパートナーなど，外部ユーザーと対話する組織サービスに焦点を当てている．ただし，従業員や請負業者がアクセスする連邦システムにも適用される． *Personal Identity Verification (PIV) of Federal Employees and Contractors 標準 [FIPS201] およびそれに対応する一連の特別刊行物(Special Publication)および組織固有の指示は，これらのガイドラインを連邦企業向けに拡張したものであり，Personal Identity Verification (PIV) カードを発行および管理するための追加の技術的制御とプロセスを提供し，派生した PIV クレデンシャルとして追加のオーセンティケーターをバインドし，PIV システムでフェデレーションアーキテクチャとプロトコルを使用する．

These guidelines primarily focus on organizational services that interact with external users, such as citizens accessing public benefits or private sector partners accessing collaboration spaces. However, it also applies to federal systems accessed by employees and contractors. The Personal Identity Verification (PIV) of Federal Employees and Contractors standard [FIPS201] and its corresponding set of special publications and organization-specific instructions, extend these guidelines for the federal enterprise, providing additional technical controls and processes for issuing and managing Personal Identity Verification (PIV) cards, binding additional authenticators as derived PIV credentials, and using federation architectures and protocols with PIV systems.

このガイダンスでカバーされていないトランザクションには，44 U.S.C. § 3542(b)(2) で定義されている国家安全保障システムに関連するトランザクションが含まれる．さまざまなデジタルアイデンティティ保証レベルを必要とするデジタルプロセスを使用する民間部門の組織および州，地方，部族政府は，必要に応じてこれらの標準の使用を検討することができる．

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

さらに，これらの技術ガイドラインは，物理アクセス (建物など) の主体のアイデンティティには対応していないが，オンライントランザクションに使用される一部のアイデンティティは物理アクセスにも使用される場合がある．さらに，本ガイドラインの本改訂版では，マシン間 (ルーター間など) 認証と呼ばれることが多いデバイスアイデンティティや，モノのインターネット (IoT) と一般的に呼ばれる相互接続されたデバイスについては明示的に対応していないが，本ガイドラインは，デバイスへの適用の可能性を残すために，可能な限り一般的な主体を参照するように書かれている．さらに，本ガイドラインは，主体に代わってアプリケーションプログラミングインターフェース (API) へのアクセスを承認することには対応していない．

Additionally, these technical guidelines do not address the identity of subjects for physical access (e.g., to buildings), though some identities used for online transactions may also be used for physical access. Additionally, this revision of these guidelines does not explicitly address device identity, often referred to as machine-to-machine (such as router-to-router) authentication or interconnected devices, commonly referred to as the internet of things (IoT), although these guidelines are written to refer to generic subjects wherever possible to leave open the possibility for applicability to devices. Furthermore, these guidelines do not address authorization of access to Application Programming Interfaces (APIs) on behalf of subjects.

How to Use this Suite of SPs

本ガイドラインは，デジタルアイデンティティの個々の要素を個別の構成要素に分離することにより，デジタルアイデンティティエラーによって引き起こされる悪影響の軽減をサポートする．非フェデレーションシステムの場合，政府機関は Identity Assurance Level (IAL) および Authentication Assurance Level (AAL) と呼ばれる 2つの構成要素を選択する．フェデレーションシステムの場合，3つ目の構成要素である Federation Assurance Level (FAL) も含む．Sec. 5, Digital Identity Risk Management では，リスク評価プロセスの詳細と，リスク評価の結果が，追加の文脈とともに，リスクと使命に基づいた IAL，AAL，FAL の組み合わせの組織の選択をどのように通知するかについて説明する．

These guidelines support the mitigation of the negative impacts induced by a digital identity error by separating the individual elements of digital identity into discrete, component parts. For non-federated systems, agencies will select two components, referred to as Identity Assurance Level (IAL) and Authentication Assurance Level (AAL). For federated systems, a third component, Federation Assurance Level (FAL), is included. Sec. 5, Digital Identity Risk Management provides details on the risk assessment process and how the results of the risk assessment, with additional context, inform organizational selection of IAL, AAL, and FAL combinations based on risk and mission.

ビジネス，セキュリティ，およびプライバシーの適切なリスク管理をミッションのニーズと並行して実施することにより，組織は IAL，AAL，および FAL を個別のオプションとして選択します． 具体的には，組織は，実行される各機能に対応するレベルを個別に選択する必要があります． 多くのシステムは，各 IAL，AAL，および FAL の数値レベルが同じである可能性がありますが，これは要件ではなく，組織は，特定のシステムまたはアプリケーションでそれらが同じであると想定すべきではありません．

By conducting appropriate risk management for business, security, and privacy, side-by-side with mission needs, organizations will select IAL, AAL, and FAL as distinct options. Specifically, organizations are required to individually select levels corresponding to each function being performed. While many systems could have the same numerical level for each IAL, AAL, and FAL, this is not a requirement and organizations should not assume they will be the same in any given system or application.

本ガイドラインで詳述されている アイデンティティ保証の構成要素は次のとおり．

The components of identity assurance detailed in these guidelines are as follows:

  • IAL refers to the identity proofing process.
  • AAL refers to the authentication process.
  • FAL refers to the federation process, when the RP is connected through a federated protocol.

注記：本ガイドラインでは，一般的に，あるいは，まとめて説明する場合，IAL，AAL，FAL を xAL と表す．

Note: When described generically or bundled, these guidelines will refer to IAL, AAL, and FAL as xAL.

SP 800-63 は，次の巻で構成されている．

SP 800-63 is organized as the following suite of volumes:

SP 800-63 Digital Identity Guidelines: デジタルシステムでオーセンティケーター，クレデンシャル，およびアサーションを一緒に使用するリスク評価方法と一般的なアイデンティティフレームワークの概要，および保証レベルを選択するリスクベースのプロセスを提供する．SP 800-63 には，規範的(normative)内容と参考(informative)内容の両方が含まれている．

SP 800-63 Digital Identity Guidelines: Provides the risk assessment methodology and an overview of general identity frameworks, using authenticators, credentials, and assertions together in a digital system, and a risk-based process of selecting assurance levels. SP 800-63 contains both normative and informative material.

[SP800-63A]: 3つの身元確認保証レベル (IAL) のそれぞれでリソースへのアクセスを希望する申請者の，リモートまたは対面での登録および身元確認(identity proofing)の要件を提供する．これは，加入者(subscriber)アカウントの確立と維持，および加入者(subscriber)アカウントへの認証子 (CSP 発行または加入者(subscriber)提供) のバインドに関するクレデンシャルサービスプロバイダー (CSP) の責任を詳述している． SP 800-63A には，規範的(normative)内容と参考(informative)内容の両方が含まれている．

[SP800-63A]: Provides requirements for enrollment and identity proofing of applicants, either remotely or in person, that wish to gain access to resources at each of the three identity assurance levels (IALs). It details the responsibilities of Credential Service Providers (CSPs) with respect to establishing and maintaining subscriber accounts and binding authenticators (either CSP-issued or subscriber-provided) to the subscriber account. SP 800-63A contains both normative and informative material.

[SP800-63B]: 3つの当人認証保証レベル (AAL) のそれぞれで使用できるオーセンティケーターの選択を含む，認証プロセスのタイプに関する推奨事項を提供する．また，紛失や盗難が発生した場合の無効化を含む，オーセンティケーターのライフサイクルに関する推奨事項も提供する． SP 800-63B には，規範的(normative)内容と参考(informative)内容の両方が含まれている．

[SP800-63B]: Provides recommendations on types of authentication processes, including choices of authenticators, that may be used at each of the three authentication assurance levels (AALs). It also provides recommendations on the lifecycle of authenticators, including invalidation in the event of loss or theft. SP 800-63B contains both normative and informative material.

[SP800-63C]: 認証プロセスの結果と関連するアイデンティティ情報をアプリケーションに伝達するためのフェデレーションアイデンティティアーキテクチャとアサーションの使用に関する要件を提供する．さらに，本巻では，有効な認証された主体に関する情報を共有するためのプライバシー強化手法を提供し，主体がデジタルサービスに対して仮名のままである間に強力な多要素認証 (MFA) を可能にする方法について説明する． SP 800-63C には，規範的資料と有益な資料の両方が含まれている．

[SP800-63C]: Provides requirements on the use of federated identity architectures and assertions to convey the results of authentication processes and relevant identity information to an agency application. Further, this volume offers privacy-enhancing techniques to share information about a valid, authenticated subject, and describes methods that allow for strong multi-factor authentication (MFA) while the subject remains pseudonymous to the digital service. SP 800-63C contains both normative and informative material.

Enterprise Risk Management Requirements and Considerations

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

During the process of analyzing factors relevant to digital identity, organizations may determine that measures outside of those specified in this publication are appropriate in certain contexts, for instance where privacy or other legal requirements exist or where the output of a risk assessment leads the organization to determine that additional measures or other process safeguards are appropriate. Organizations, including federal agencies, may employ compensating or supplemental controls not specified in this publication. They may also consider partitioning the functionality of a digital service to allow less sensitive functions to be available at a lower level of assurance.

The considerations detailed below support enterprise risk management efforts and encourage informed, inclusive, and human-centric service delivery. While this list of considerations is not exhaustive, it highlights a set of cross-cutting factors likely to impact decision-making associated with digital identity management.

Security

It is increasingly important for enterprise organizations to assess and manage digital identity security risks, such as unauthorized access, availability issues, impersonation, and other types of fraudulent claims, as well as institute strong identity governance practices. As organizations consult this guidance, they should consider potential impacts to the confidentiality, integrity, and availability of information and information systems that they manage and that their service providers and business partners manage on behalf of the individuals and communities that they serve.

Federal agencies implementing these guidelines need to adhere to their statutory responsibilities, including those under the Federal Information Security Modernization Act (FISMA) of 2014 [FISMA] and related NIST standards and guidelines. NIST recommends that non-federal organizations implementing these guidelines follow equivalent standards to ensure the secure operation of their digital systems.

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

The controls and requirements encompassed by the identity, authentication, and federation assurance levels under these guidelines augment, but do not replace or alter, the information and information system controls as determined under FISMA and the RMF.

Privacy

When designing, engineering, and managing digital identity systems, it is imperative to consider the potential of that system to create privacy-related problems for individuals when processing PII — a problematic data action — and the potential impact of the problematic data action should it occur. Additionally, by focusing on the privacy engineering objectives of predictability, manageability, and disassociability, organizations can determine the types of capabilities a given system may need to be able to demonstrate how organizational privacy policies and system privacy requirements have been implemented.

The Privacy Act of 1974, 2010 Edition, [PrivacyAct] established a set of fair information practices for the collection, maintenance, use, and disclosure of information about individuals that is maintained by federal agencies in systems of records.

When designing and implementing digital identity management processes and systems, privacy risk assessments are required for PII processing under these guidelines. Such privacy risk assessments can be used to support Privacy Impact Assessments under OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 [M-03-22] as well as to select controls from NIST Special Publication 800-53, Security and Privacy Controls for Information Systems and Organizations [SP800-53]. Further, each volume of 800-63 (63A, 63B, and 63C) contains a specific section providing detailed privacy requirements and considerations for the implementation of the processes, controls, and requirements presented in that volume.

Equity

As defined in Executive Order 13985, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government [EO13985], equity refers to 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 person’s ability to engage in an online transaction, such as accessing a critical service like healthcare, is often dependent on their ability to successfully and safely present a digital identity. Given the broad disparities that exist in the U.S. society and globally, many people are either unable to successfully present a digital identity, or they face a higher degree of burden in navigating online services than their more privileged peers, leaving them locked out of critical services or broader participation in the online world. In a public service context, this poses a direct risk to successful mission delivery. In a broader societal context, challenges related to digital access can exacerbate existing inequities and continue systemic cycles of exclusion for historically marginalized and underserved groups.

Readers of this guidance are encouraged to consider existing inequities faced by the populations they serve to identify opportunities to design or operate digital identity systems and processes in ways that best support their needs. Readers are also encouraged to consider any potential or actual impact to the experiences and outcomes of these populations, including disparities between populations, caused by the design or operation of digital identity systems.

For federal agencies implementing these guidelines, EO 13985 directs federal agencies to identify underserved communities for the programs and services that they provide and to determine and address any systemic barriers to underserved communities to provide equitable access to those programs and services. In alignment with the direction set by EO 13985, federal agencies should determine potential barriers communities and individuals may face to enrollment in and access to online benefits and services. They should also identify whether programmatic changes may be necessary to advance equity.

Usability

Usability refers to 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.

Similar to equity, usability requires an understanding of the people interacting with a digital identity system or process, as well as their unique goals and context of use. To provide an effective, efficient, and satisfactory experience, readers of this guidance should take a holistic approach to considering the interactions that each user will engage in throughout the process of enrolling in and authenticating to a service. Throughout the design and development lifecycle of a digital identity system or process, it is important to conduct usability evaluation with representative users performing realistic scenarios and tasks in appropriate context of use.

Digital identity management processes should be designed and implemented so it is easy for users to do the right thing, hard to do the wrong thing, and easy to recover when the wrong thing happens.

Definitions and Abbreviations

See Appendix A for a complete set of definitions and abbreviations.

デジタルアイデンティティモデル (Digital Identity Model)

This section is informative.

概要 (Overview)

SP 800-63 ガイドラインでは，現在市場で入手可能な技術とアーキテクチャを反映したデジタルアイデンティティモデルを使用している．これらのモデルにはさまざまなエンティティと機能があり，複雑さも異なる．単純なモデルでは，加入者(subscriber)アカウントの作成や属性の提供などの機能が 1つのエンティティにグループ化される．より複雑なモデルでは，これらの機能を多数のエンティティ間で分離する．デジタルアイデンティティモデルに含まれるエンティティとそれに関連する機能には，次のものがある．

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

主体 (3つの役割のいずれかで表される):

Subject (represented by one of three roles):

  • Applicant — the subject to be identity proofed
  • Subscriber — the subject that has successfully completed the identity proofing process or has successfully completed authentication
  • Claimant — the subject to be authenticated

クレデンシャルサービスプロバイダー (CSP): 信頼されたエンティティであり，その機能には，アイデンティティサービスへの身元証明申請者の登録や，加入者(subscriber)アカウントへのオーセンティケーターの登録が含まれる． 加入者(subscriber)アカウント は，加入者(subscriber)，加入者(subscriber)の属性および関連するオーセンティケーターの CSP における確立されたレコードである．CSP は、独立した第三者である場合がある．

Credential Service Provider (CSP): A trusted entity whose functions include identity proofing applicants to the identity service and the registration of authenticators to subscriber accounts. A subscriber account is the CSP’s established record of the subscriber, the subscriber’s attributes, and associated authenticators. A CSP may be an independent third party.

Relying Party (RP): 加入者(subscriber)アカウントの情報，またはフェデレーションを使用する場合のアイデンティティプロバイダー (IdP) アサーションに依存するエンティティで，通常はトランザクションを処理したり，情報やシステムへのアクセスを許可したりする．

Relying Party (RP): An entity that relies upon the information in the subscriber account, or an identity provider (IdP) assertion when using federation, typically to process a transaction or grant access to information or a system.

検証者 (Verifier): 認証プロトコルを使用して，主張者(claimant)が 1つ以上のオーセンティケーターを所有および管理していることを確認することにより，主張者(claimant)の身元を確認する機能を持つエンティティ．これを行うには，検証者は，オーセンティケーターと加入者(subscriber)アカウントのバインディングを確認し，加入者(subscriber)アカウントがアクティブであることを確認する必要がある．

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

アイデンティティプロバイダー (IdP): CSP と検証機能の両方を実行するフェデレーションモデル内のエンティティ．IdP は，加入者(subscriber)を認証し，アサーションを発行して 1つ以上の RP と通信する役割を果たす．

Identity Provider (IdP): An entity in a federated model that performs both the CSP and Verifier functions. The IdP is responsible for authenticating the subscriber and issuing assertions to communicate with one or more RPs.

図1 に，非フェデレーションデジタルアイデンティティモデルを構成するエンティティとインタラクションを示す．図2 は，フェデレーションデジタルアイデンティティモデルを示す．

The entities and interactions that comprise the non-federated digital identity model are illustrated in Figure 1. The federated digital identity model is illustrated in Figure 2.

図1. 非フェデレーションデジタルアイデンティティモデルの例

RP によって検証機能が実行される，デジタルアイデンティティプロセス全体のエンティティとエンティティ間のインタラクションを示す，フェデレーションされていないデジタルアイデンティティモデルの概要図．

図1 は，非フェデレーション モデルにおける一般的なインタラクションのシーケンスの例を示している．他のシーケンスでも同じ機能要件を達成することは可能である．身元証明と登録アクティビティの通常の対話シーケンスは次のとおり．

Figure 1 shows an example of a common sequence of interactions in the non-federated model. Other sequences could also achieve the same functional requirements. The usual sequence of interactions for identity proofing and enrollment activities is as follows:

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

非フェデレーションモデルでデジタル当人認証を実行するために 1つ以上のオーセンティケーターを使用する際の通常のやり取りのシーケンスは次のとおり．

The usual sequence of interactions involved in using one or more authenticators to perform digital authentication in the non-federated model is as follows:

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

Figure 2. Federated Digital Identity Model Example
図2. フェデレーションデジタルアイデンティティモデルの例

CSP と検証機能が IdP によって実行される，デジタルアイデンティティプロセス全体のエンティティとエンティティ間のインタラクションを示すフェデレーションデジタルアイデンティティモデルの概要図．

図2 は、フェデレーションモデルにおける一般的なインタラクションの例を示している.

Figure 2 shows an example of those same common interactions in a federated model.

  • Step 1: An applicant applies to an IdP through an enrollment process. Using its CSP function, the IdP identity proofs the applicant.
  • Step 2: Upon successful proofing, the applicant is enrolled in the identity service as a subscriber.
    • A subscriber account and corresponding authenticators are established between the IdP and the subscriber. The IdP maintains the subscriber account, its status, and the enrollment data collected for the lifetime of the subscriber account (at a minimum). The subscriber maintains their authenticators.

フェデレーションモデルで 1つ以上のオーセンティケーターを使用してデジタル当人認証を実行する際の通常の対話シーケンスは次のとおり．

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

  • Step 3: The RP requests authentication from the claimant. The IdP provides an assertion and optionally additional attributes to the RP through a federation protocol.
  • Step 4: The claimant proves possession and control of the authenticators to the verifier function of the IdP through an authentication process.
    • Within the IdP, the verifier and CSP functions interact to verify the binding of the claimant’s authenticators with those bound to the claimed subscriber account and optionally to obtain additional subscriber attributes.
  • Step 5: All communication, including assertions, between the RP and the IdP happens through federation protocols.
  • Step 6: The IdP provides the RP with the authentication status of the subscriber and relevant attributes and an authenticated session is established between the subscriber and the RP.

どちらのモデルでも，検証者は，認証アクティビティ (デジタル証明書の使用など) を完了するために，常に CSP とリアルタイムで通信する必要はない．したがって，検証者と CSP の間の線は，2つのエンティティ間の論理リンクを表す．一部の実装では，検証者，RP，CSP 機能が分散され，分離されている場合がある．ただし，これらの機能が同じプラットフォーム上にある場合，機能間の相互作用は，ネットワークプロトコルを使用するのではなく，同じシステム上で実行されているアプリケーションまたはアプリケーションモジュール間のシグナルになる．

For both models, the verifier does not always need to communicate in real time with the CSP to complete the authentication activity (e.g., some uses of digital certificates). Therefore, the line between the verifier and the CSP represents a logical link between the two entities. In some implementations, the verifier, RP, and CSP functions may be distributed and separated. However, if these functions reside on the same platform, the interactions between the functions are signals between applications or application modules running on the same system rather than using network protocols.

いずれの場合も，RP は主張者(claimant)を認証する前に，CSP または IdP から必要な属性を要求する必要がある．

In all cases, the RP should request the attributes it requires from a CSP or IdP before authenticating the claimant.

次のセクションでは，身元確認(identity proofing)，当人認証(authentication)，およびフェデレーションのためのより詳細なデジタルアイデンティティモデルを提供する．

The following sections provide more detailed digital identity models for identity proofing, authentication, and federation.

登録と身元確認 (Enrollment and Identity Proofing)

前のセクションでは，概念的なデジタルアイデンティティモデルにおけるエンティティとインタラクションについて紹介した．本セクションでは，身元確認と登録プロセスに関する参加者の関係と責任に関する追加の詳細を提供する．

The previous section introduced the entities and interactions in the conceptual digital identity model. This section provides additional details regarding the participants’ relationships and responsibilities with respect to identity proofing and enrollment processes.

[SP800-63A],* 登録と身元確認* は，身元確認および登録プロセスに関する一般的な情報と規範的な要件，および 身元確認保証レベル(IAL) に固有の要件を提供する．「身元証明なし」の IAL0 に加えて，本書では，身元確認プロセスの相対的な強度を示す 3 つの IAL を定義している．

[SP800-63A], Enrollment and Identity Proofing provides general information and normative requirements for the identity proofing and enrollment processes as well as requirements specific to identity assurance levels (IALs). In addition to a “no identity proofing” level, IAL0, this document defines three IALs that indicate the relative strength of an identity proofing process.

この段階で 申請者(applicant) と呼ばれる個人は，CSP に登録することを選択する． 申請者(applicant)の身元確認が成功すると，その個人はその CSP の 加入者(subscriber) としてアイデンティティサービスに登録される．

An individual, referred to as an applicant at this stage, opts to enroll with a CSP. If the applicant is successfully proofed, the individual is then enrolled in the identity service as a subscriber of that CSP.

次に，CSP は加入者(subscriber)アカウントを確立して，各加入者(subscriber)を一意に識別し，その加入者(subscriber)アカウントに登録 (バインド) されたすべてのオーセンティケーターを記録する． CSP は:

The CSP then establishes a subscriber account to uniquely identify each subscriber and record any authenticators registered (bound) to that subscriber account. The CSP may:

  • issue one or more authenticators to the subscriber at the time of enrollment,
  • bind authenticators provided by the subscriber, and/or
  • bind authenticators to the subscriber account at a later time as needed.

CSP は通常，文書化されたライフサイクルに従って加入者(subscriber)アカウントを維持する．ライフサイクルは，加入者(subscriber)アカウントの状態に影響を与える特定のイベント，アクティビティ，および変更を定義する．CSP は通常，加入者(subscriber)に関連付けられた属性の正確性と最新性をある程度確保するために，加入者(subscriber)アカウントと関連するすべてのオーセンティケーターの有効期間を制限する．状態が変更された場合，またはオーセンティケーターの有効期限が近づいていて，更新要件が満たされている場合，オーセンティケーターは更新and/or再発行される場合がある．あるいは，オーセンティケーターは，CSP が作成したポリシーと手順に従って無効化および破棄される場合がある．

CSPs generally maintain subscriber accounts according to a documented lifecycle, which defines specific events, activities, and changes that affect the status of a subscriber account. CSPs generally limit the lifetime of a subscriber account and any associated authenticators in order to ensure some level of accuracy and currency of attributes associated with a subscriber. When there is a status change or when the authenticators near expiration and any renewal requirements are met, they may be renewed and/or re-issued. Alternately, the authenticators may be invalidated and destroyed according to the CSPs written policy and procedures.

加入者(subscriber)は，CSP と良好な関係を維持するために，オーセンティケーターの制御を維持し，CSP ポリシーに準拠する義務がある．

Subscribers have a duty to maintain control of their authenticators and comply with CSP policies in order to remain in good standing with the CSP.

新しいオーセンティケータの発行を要求するために，通常，加入者(subscriber)は既存の有効期限が切れていないオーセンティケータを使用して CSP に対して認証を行う．加入者(subscriber)が有効期限または失効の前にオーセンティケーターの再発行を要求できなかった場合，新しいオーセンティケーターを取得するために，身元確認(完全または省略) および登録プロセスを繰り返す必要がある場合がある．

In order to request issuance of a new authenticator, typically the subscriber authenticates to the CSP using their existing, unexpired authenticators. If the subscriber fails to request authenticator re-issuance prior to their expiration or revocation, they may be required to repeat the identity proofing (either complete or abbreviated) and enrollment processes in order to obtain a new authenticator.

図3 は身元確認と登録のインタラクションの例を示している．

Figure 3 shows a sample of interactions for identity proofing and enrollment.

図3. デジタルアイデンティティモデルの身元確認と登録の例

関係者とプロセスの主要なステップを示す身元確認と登録のシーケンス図

\clearpage

当人認証とライフサイクル管理 (Authentication and Lifecycle Management)

規範的(normative)な要件は，[SP800-63B] 当人認証とライフサイクル管理 に記載されている．

Normative requirements can be found in [SP800-63B], Authentication and Lifecycle Management.

オーセンティケーター

認証システムの従来のパラダイムでは，認証の基礎として次の 3つの要素を指定している．

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

  • Something you know (e.g., a password)
  • Something you have (e.g., an ID badge or a cryptographic key)
  • Something you are (e.g., a fingerprint or other biometric characteristic data)

単一要素認証では，上記の要素の 1つだけが必要であり，ほとんどの場合，「知っているもの」が必要である．同じ要素の複数のインスタンスは，依然として単一要素認証を構成する．たとえば，ユーザーが生成した PIN とパスワードは，どちらも「知っているもの」であるため，2要素にはならない．多要素認証 (MFA) は，複数の異なる要素の使用を指す． 本ガイドラインの目的上，最高のセキュリティ要件を満たすには，2つの要素を使用することが適切である．位置データやデバイスアイデンティティなど他の種類の情報も検証者によって使用され，主張されたアイデンティティのリスクが評価されるが，それらは認証要素とは見なされない．

Single-factor authentication requires only one of the above factors, most often “something you know”. Multiple instances of the same factor still constitute single-factor authentication. For example, a user generated PIN and a password do not constitute two factors as they are both “something you know.” Multi-factor authentication (MFA) refers to the use of more than one distinct factor. For the purposes of these guidelines, using two factors is adequate to meet the highest security requirements. Other types of information, such as location data or device identity, may also be used by a verifier to evaluate the risk in a claimed identity but they are not considered authentication factors.

デジタル認証では，主張者(claimant)は 1つまたは複数のオーセンティケーターを所有して管理する．オーセンティケーターは，加入者(subscriber)アカウントにバインドされている．オーセンティケーターには，正当な加入者(subscriber)であることを証明するために主張者(claimant)が使用できるシークレットが含まれている．主張者(claimant)は，オーセンティケーターを所有して制御していることを示すことによって，ネットワークを介してシステムまたはアプリケーションに対して認証を行う．認証されると，主張者(claimant)は加入者(subscriber)と呼ばれる．

In digital authentication, the claimant possesses and controls one or more authenticators. The authenticators will have been bound with the subscriber account. The authenticators contain secrets the claimant can use to prove they are a legitimate subscriber. The claimant authenticates to a system or application over a network by demonstrating they have possession and control of the authenticator. Once authenticated, the claimant is referred to as a subscriber.

オーセンティケータに含まれるシークレットは，鍵ペア (非対称暗号キー) または共有シークレット (対称暗号キーと記憶されたシークレットを含む) のいずれかに基づいている．非対称鍵ペアは，公開鍵と関連する秘密鍵で構成されます． 秘密鍵はオーセンティケータに格納され，オーセンティケータを所有および管理する主張者(claimant)のみが使用できる．公開鍵証明書などを通じて加入者(subscriber)の公開鍵を持つ検証者は，認証プロトコルを使用して，主張者(claimant)がオーセンティケーターに含まれる関連する秘密鍵を所有および管理していること，つまり加入者(subscriber)であることを検証できる．

The secrets contained in an authenticator are based on either key pairs (asymmetric cryptographic keys) or shared secrets (including symmetric cryptographic keys and memorized secrets). Asymmetric key pairs are comprised of a public key and a related private key. The private key is stored on the authenticator and is only available for use by the claimant who possesses and controls the authenticators. A verifier that has the subscriber’s public key, for example through a public key certificate, can use an authentication protocol to verify the claimant has possession and control of the associated private key contained in the authenticators and, therefore, is a subscriber.

前述のように，オーセンティケータに保存されている共有シークレットは，対称k鍵または記憶されたシークレット (パスワードや PIN など) のいずれかである． 鍵と記憶されたシークレットの両方を同様のプロトコルで使用できるが，2つの重要な違いの 1つは，それらが主張者(claimant)とどのように関係しているかである．対称鍵は一般にランダムに選択され，複雑で，ネットワークベースの推測攻撃を阻止するのに十分な長さであり，加入者(subscriber)が制御するハードウェアまたはソフトウェアに格納される．通常，記憶されたシークレットは，暗記と入力の容易さを促進するために，暗号鍵よりも文字数が少なく，複雑さが軽減されている．その結果，記憶された秘密によって脆弱性が増し，緩和するために追加の防御が必要になる．

As mentioned above, shared secrets stored on an authenticator may be either symmetric keys or memorized secrets (e.g., passwords and PINs). While both keys and memorized secrets can be used in similar protocols, one important difference between the two is how they relate to the claimant. Symmetric keys are generally chosen at random and are complex and long enough to thwart network-based guessing attacks, and stored in hardware or software that the subscriber controls. Memorized secrets typically have fewer characters and less complexity than cryptographic keys to facilitate memorization and ease of entry. The result is that memorized secrets have increased vulnerabilities that require additional defenses to mitigate.

多要素オーセンティケーターのアクティベーション要素として使用される別のタイプの記憶されたシークレットがある．これらは，アクティベーションシークレットと呼ばれる．アクティベーションシークレットは，認証に使用される保存された鍵を解読するために使用されるか，ローカルに保持されている保存された検証者と比較されて，認証鍵へのアクセスを提供する．いずれの場合でも，アクティベーションシークレットはオーセンティケーターとそれに関連付けられたユーザーエンドポイント内に残る．アクティベーションシークレットの例としては，PIV カードのアクティベーションに使用される PIN がある．

There is another type of memorized secret used as an activation factor for a multi-factor authenticator. These are referred to as activation secrets. An activation secret is used to decrypt a stored key used for authentication or is compared against a locally held stored verifier to provide access to the authentication key. In either of these cases, the activation secret remains within the authenticator and its associated user endpoint. An example of an activation secret would be the PIN used to activate a PIV card.

本ガイドラインで使用されているように，オーセンティケータは常にシークレットを含むか構成する．ただし，対面でのやり取りに使用される一部の認証方法は，デジタル認証には直接適用されない．たとえば，物理的な運転免許証は持っているものであり，人間 (警備員など) に対して認証する場合に役立つ場合があるが，オンラインサービスの認証には使用できない．

As used in these guidelines, authenticators always contain or comprise a secret; however, some authentication methods used for in-person interactions do not apply directly to digital authentication. For example, a physical driver’s license is something you have and may be useful when authenticating to a human (e.g., a security guard) but it is not an authenticator for online services.

一部の一般的に使用される認証方法には，シークレットを含んでいないか構成していないため，これらのガイドラインでは使用できない．例えば：

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

  • Knowledge-based authentication, where the claimant is prompted to answer questions that are presumably known only by the claimant, does not constitute an acceptable secret for digital authentication.
  • A biometric also does not constitute a secret and can not be used as a single-factor authenticator.

デジタル認証システムは，次の 2つの方法のいずれかで複数の要素を組み込むことができる．

A digital authentication system may incorporate multiple factors in one of two ways:

  1. システムは，複数の要素が検証者に提示されるように実装される場合がある．
  2. 検証者に提示される秘密を保護するために，いくつかの要因が使用される場合がある．
  1. The system may be implemented so that multiple factors are presented to the verifier, or
  2. Some factors may be used to protect a secret that will be presented to the verifier.

たとえば，項目1 は，記憶されたシークレット (知っているもの) と帯域外デバイス (持っているもの) をペアにすることで満たすことができる．両方のオーセンティケーターの出力は，主張者(claimant)を認証するために検証者に提示される．項目2 の場合，オーセンティケーターとオーセンティケーターシークレットは，アクセスが指紋(あなたのもの) で保護されている主張者(claimant)によって制御される暗号鍵 (持っているもの) を含むハードウェアの一部である可能性がある．生体認証要素と一緒に使用すると，暗号鍵は，主張者(claimant)の認証に使用される出力を生成する．

For example, item 1 can be satisfied by pairing a memorized secret (something you know) with an out-of-band device (something you have). Both authenticator outputs are presented to the verifier to authenticate the claimant. For item 2, the authenticator and authenticator secret could be a piece of hardware that contains a cryptographic key (something you have) that is controlled by the claimant where access is protected with a fingerprint (something you are). When used with the biometric factor, the cryptographic key produces an output that is used to authenticate the claimant.

上記のように，生体認証はデジタル認証の許容可能な秘密を構成しないため，単一要素認証には使用できない．ただし，生体認証は，所持ベースのオー線ティケーターと組み合わせて使用することで，多要素認証の認証要素として使用できる．生体認証特性は，検証の時点で物理的に存在する人物の身元を検証するために使用できる一意の個人属性である．これには，顔の特徴，指紋，虹彩パターン，声紋が含まれるが，これらに限定されない．

As noted above, biometrics do not constitute acceptable secrets for digital authentication and, therefore, cannot be used for single-factor authentication. However, biometrics authentication can be used as an authentication factor for multi-factor authentication when used in combination with a possession-based authenticator. Biometric characteristics are unique, personal attributes that can be used to verify the identity of a person who is physically present at the point of verification. This includes, but is not limited to, facial features, fingerprints, iris patterns, and voiceprints.

加入者(subscriber)アカウント (Subscriber Accounts)

前のセクションで説明したように，加入者(subscriber)アカウントは，登録プロセスの一部として，識別子を介して 1つ以上のオーセンティケーターを加入者(subscriber)にバインドする．加入者(subscriber)アカウントは，CSP によって作成，保存，および維持される．加入者(subscriber)アカウントには，身元確認プロセス中に検証されたすべての属性が記録される．

As described in the preceding sections, a subscriber account binds one or more authenticators to the subscriber via an identifier as part of the registration process. A subscriber account is created, stored, and maintained by the CSP. The subscriber account records all identity attributes validated during the identity proofing process.

当人認証プロセス (Authentication Process)

認証プロセスにより，RP は主張者(claimant)が本人であることを信頼できる．図4 に，認証プロセスの例を示す．その他のアプローチについては，[SP800-63B]の 当人認証とライフサイクル管理 で説明されている．このサンプル認証プロセスは，RP，主張者(claimant)，および検証者/CSP 間のインタラクションを示している．検証者は機能的な役割であり，多くの場合，図4に示すように CSP，RP，またはその両方と組み合わせて実装される．

The authentication process enables an RP to trust that a claimant is who they say they are. Figure 4 shows a sample authentication process. Other approaches are described in [SP800-63B], Authentication and Lifecycle Management. This sample authentication process shows interactions between the RP, a claimant, and a verifier/CSP. The verifier is a functional role and is frequently implemented in combination with the CSP, as shown in Fig. 4, the RP, or both.

図4. 当人認証プロセスの例

関係者とプロセスの主要な手順を示すサンプル認証プロセスのシーケンス図

認証プロセスが成功すると，加入者(subscriber)のアイデンティティにバインドされた 1つ以上の有効なオーセンティケーターを主張者(claimant)が所有し，制御できることが証明される．一般に，これは，検証者と主張者(claimant)の間の対話を含む認証プロトコルを使用して行われる．インタラクションの正確な性質は，システム全体のセキュリティを決定する上で非常に重要である．適切に設計されたプロトコルは，認証中および認証後の両方で，主張者(claimant)と検証者の間の通信の完全性と機密性を保護し，正当な検証者になりすました攻撃者による損害を制限するのに役立つ．

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

ささらに，検証者に配置されたメカニズムにより，攻撃者が認証試行を行うレートを制限するか，そうでなければ不正な試行を遅らせることにより，パスワードや PIN などのエントロピーの低い秘密に対するオンライン推測攻撃を軽減できる．オンライン推測攻撃の前提は，ほとんどの試行が失敗することであるため，通常，これは失敗した試行を追跡し，その数を制限することによって行われる．

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

フェデレーションとアサーション (Federation and Assertions)

規範的(normative)な要件は，[SP800-63C] フェデレーションとアサーション に記載されている．

Normative requirements can be found in [SP800-63C], Federation and Assertions.

一般的な使用法では，フェデレーション という用語は，異なる信頼ドメイン間での情報の共有を含むさまざまなアプローチに適用できる．これらのアプローチは，ドメイン間で共有される情報の種類によって異なる．いくつかの一般的な例は次のとおり．

In general usage, the term federation can be applied to a number of different approaches involving the sharing of information between different trust domains. These approaches differ based on the kind of information that is being shared between the domains. Some common examples include:

  • sharing identifiers (e.g., using a driver’s license number or an email address),
  • sharing authenticators (e.g., using a PKI authenticator for multiple applications),
  • sharing identity assertions (e.g., a federation protocol like OpenID Connect or SAML),
  • sharing account attributes (e.g., a provisioning protocol like SCIM), and
  • sharing authorization decisions (e.g., a policy protocol like XACML).

SP 800-63 ガイドラインは，組織が選択する身元確認(identity proofing)，当人認証(authenticate)，およびフェデレーションアーキテクチャにとらわれず，組織が独自の要件に従ってデジタルアイデンティティスキームを展開できるようにする．ただし，フェデレーションを，組織または個々のアプリケーションに対してローカルなアイデンティティサービスを確立するよりも潜在的に効率的かつ効果的にするシナリオが発生する可能性があえう．以下に，組織がフェデレーションを実行可能なオプションと見なすシナリオの詳細を示す．これらのリストは考慮のために提供されており，包括的なものではない．

The SP 800-63 guidelines are agnostic to the identity proofing, authentication, and federation architectures an organization selects and they allow organizations to deploy a digital identity scheme according to their own requirements. However, there are scenarios that an organization may encounter that make federation potentially more efficient and effective than establishing identity services local to the organization or individual applications. The following lists detail scenarios where the organization may consider federation a viable option. These lists are provided for consideration and are not intended to be comprehensive.

次のいずれかに該当する場合，組織はフェデレーションアイデンティティアサーションを受け入れることを検討する必要がある:

An organization should consider accepting federated identity assertions if any of the following apply:

  1. 潜在的なユーザーは，必要な AAL 以上のオーセンティケーターを既に持っている．
  2. 考えられるすべてのユーザーコミュニティをカバーするには，複数のタイプのオーセンティケータが必要である．
  3. 組織には，加入者(subscriber)アカウントの管理をサポートするために必要なインフラストラクチャがありません (例: アカウントの回復，オーセンティケーターの発行，ヘルプデスク)．
  4. RP の実装を変更せずに，時間の経過とともに主要なオーセンティケータを追加およびアップグレードできるようにしたいという要望がある．
  5. フェデレーションプロトコルはネットワークベースであり，さまざまなプラットフォームや言語での実装が可能であるため，さまざまな環境がサポートされる．
  6. 潜在的なユーザーは複数のコミュニティから来ており，それぞれが独自の既存のアイデンティティインフラストラクチャを持っている．
  7. アカウントの失効や新しいオーセンティケータのバインドなど，アカウントのライフサイクルを一元管理できることが重要．
  1. Potential users already have an authenticator at or above the required AAL.
  2. Multiple types of authenticators are required to cover all possible user communities.
  3. An organization does not have the necessary infrastructure to support management of subscriber accounts (e.g., account recovery, authenticator issuance, help desk).
  4. There is a desire to allow primary authenticators to be added and upgraded over time without changing the RP’s implementation.
  5. There are different environments to be supported, as federation protocols are network-based and allow for implementation on a wide variety of platforms and languages.
  6. Potential users come from multiple communities, each with its own existing identity infrastructure.
  7. The ability to centrally manage account lifecycles, including account revocation and binding of new authenticators is important.

次のいずれかに該当する場合，組織はフェデレーション属性を受け入れることを検討する必要がある．

An organization should consider accepting federated identity attributes if any of the following apply:

  1. サービスにアクセスする利害関係者にとって，仮名が，必要，必要，実行可能，または重要である．
  2. サービスへのアクセスには，部分的な属性リストが必要である．
  3. サービスへのアクセスには，少なくとも 1つの派生属性値が必要である．
  4. 組織は，必須属性の信頼できる情報源または発行元ではない．
  5. 属性は，使用中 (アクセスの決定など) に一時的にのみ必要であり，組織はデータを保持する必要がない．
  1. Pseudonymity is required, necessary, feasible, or important to stakeholders accessing the service.
  2. Access to the service requires a partial attribute list.
  3. Access to the service requires at least one derived attribute value.
  4. The organization is not the authoritative source or issuing source for required attributes.
  5. Attributes are only required temporarily during use (such as to make an access decision), and the organization does not need to retain the data.

フェデレーションの利点 (Federation Benefits)

フェデレーションアーキテクチャには，次のような多くの重要な利点がある．

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

  • Enhanced user experience: For example, an individual can be identity proofed once and reuse the subscriber account at multiple RPs.
  • Cost reduction to both the user (reduction in authenticators) and the organization (reduction in information technology infrastructure).
  • Minimizing data in applications as organizations do not need to collect, store, or dispose of personal information.
  • Minimizing data exposed to applications, using pseudonymous identifiers and derived attribute values instead of copying account values to each application.
  • Mission enablement: Organizations can focus on their mission without worrying about expending resources on identity management.

次のセクションでは，組織がこのタイプのモデルを選択した場合に備えて，フェデレーションアイデンティティアーキテクチャの構成要素について説明する．

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

フェデレーションプロトコルとアサーション (Federation Protocols and Assertions)

フェデレーションプロトコルを使用すると，ネットワーク化されたシステム間でアサーション，認証属性，および加入者(subscriber)属性を伝達できる．フェデレーションシナリオでは，図2 に示すように，CSP は アイデンティティプロバイダー (IdP) と呼ばれるサービスを提供する． IdP は，CSP によって発行されたオーセンティケーターの検証者として機能する．フェデレーションプロトコルを使用して，IdP はこの認証イベントに関するアサーションと呼ばれるメッセージを RP に送信する．アサーションは，加入者(subscriber)の認証イベントを表す，IdP から RP への検証可能なステートメントである．RP は IdP によって提供されるアサーションを受信して使用するが，RP はオーセンティケーターを直接検証しない．

Federation protocols allow for the conveyance of assertions, authentication attributes, and subscriber attributes across networked systems. In a federation scenario, as shown in Figure 2, the CSP provides a service known as an identity provider, or IdP. The IdP acts as a verifier for authenticators issued by the CSP. Using federation protocols, the IdP sends a message, called an assertion, about this authentication event to the RP. Assertions are verifiable statements from an IdP to an RP that represent an authentication event for a subscriber. The RP receives and uses the assertion provided by the IdP, but the RP does not verify authenticators directly.

フェデレーションは，RP と IdP が単一のエンティティではないか，共通の管理下にない場合に一般的に使用されるが，この技術はさまざまな理由で単一のセキュリティドメイン内に適用できる．RP は，アサーション内の情報を使用して加入者(subscriber)を識別し，RP によって制御されるリソースへのアクセスに関する承認の決定を行う．

Federation is generally used when the RP and the IdP are not a single entity or are not under common administration, though this technology can be applied within a single security domain for a variety of reasons. The RP uses the information in the assertion to identify the subscriber and make authorization decisions about their access to resources controlled by the RP.

アサーションの例は次のとおり:

Examples of assertions include:

  • Security Assertion Markup Language (SAML) assertions are specified using a mark-up language intended for describing security assertions. They can be used by a verifier to make a statement to an RP about the identity of a claimant. SAML assertions may optionally be digitally signed.
  • OpenID Connect claims are specified using JavaScript Object Notation (JSON) for describing security, and optionally, user claims. JSON user information claims may optionally be digitally signed.
  • Kerberos tickets allow a ticket-granting authority to issue session keys to two authenticated parties using symmetric or asymmetric key establishment schemes.

Relying Parties

RP は，認証プロトコルの結果に依存して，オンライントランザクションを実行する目的で，加入者(subscriber)の身元または属性に対する信頼を確立する．RP は，加入者(subscriber)のフェデレーションアイデンティティ(仮名または非仮名)，IAL，AAL，FAL，およびその他の要素を使用して，承認の決定を行うことができる．

An RP relies on results of an authentication protocol to establish confidence in the identity or attributes of a subscriber for the purpose of conducting an online transaction. RPs may use a subscriber’s federated identity (pseudonymous or non-pseudonymous), IAL, AAL, FAL, and other factors to make authorization decisions.

フェデレーションを使用する場合，検証者は RP の機能ではない．フェデレーション RP は検証機能を提供する IdP からアサーションを受け取り，RP はアサーションが RP によって信頼されている IdP からのものであることを確認する．RP は，個人属性や有効期限など，アサーション内の追加情報も処理する．RP は，検証者によって提示された特定のアサーションが，IAL，AAL，FAL に関係なく，RP が確立したシステムアクセス基準を満たすかどうかに関する最終的な決定者である．

When using federation, the verifier is not a function of the RP. A federated RP receives an assertion from the IdP, which provides the verifier function, and the RP ensures that the assertion came from an IdP that is trusted by the RP. The RP also processes any additional information in the assertion, such as personal attributes or expiration times. The RP is the final arbiter concerning whether a specific assertion presented by a verifier meets the RP’s established criteria for system access regardless of IAL, AAL, or FAL.

Digital Identity Risk Management

This section is normative.

本章では，各xALのデジタルアイデンティティリスクを評価する方法について詳しく説明する．本プロセスでは，連邦情報セキュリティ近代化法(Federal Information Security Modernization Act) [FISMA] の要件を実装するための NIST ガイダンスの下で，情報および情報システムリスクのリスク管理プロセスを強化する．

This section provides details on the methodology for assessing digital identity risks for each xAL. This process augments the risk management processes for information and information system risk under NIST guidance for implementing Federal Information Security Modernization Act [FISMA] requirements.

デジタルアイデンティティリスク管理プロセスには 4つのステップがある．

  1. 初期影響評価の実施: 本ステップでは，定義された一連の影響カテゴリ―に対して，組織はユーザー集団を評価し，保護されたアプリケーションまたはサービスのアイデンティティシステム (身元確認，当人認証，フェデレーション) の各機能の障害の影響を評価する．本ステップの結果は，文書化された一連の影響カテゴリと関連する影響レベルである．
  2. 初期保証レベルの選択: 本ステップでは，影響カテゴリと影響レベルを評価し，アプリケーションを保護するための適切な保証レベルを決定する．本ステップの結果は，該当するxALごとに特定された初期レベルである．
  3. 保証レベルの決定の調整と文書化: 本ステップでは，詳細なプライバシー，公平性，使いやすさ，および脅威の評価が実施され，最初に選択された保証レベルがアプリケーションの特定のユーザー集団と脅威環境に与える潜在的な影響が決定される．初期の保証レベルが調整され，補完または補足的なコントロールが特定され，すべての決定は文書化される．結果は，実装可能な保証レベルが定義されたデジタルアイデンティティ承認ステートメント (Digital Identity Acceptance Statement， Sec. 5.3.4 参照) である．
  4. 継続的な評価と改善: 本ステップでは，組織のニーズと進化する脅威ベクトルに基づいて，さまざまな要因からアイデンティティシステムのパフォーマンスに関する情報を収集する．この情報は，選択した保証レベルと制御が，ミッション，ビジネス，およびセキュリティのニーズを満たしているかどうかを判断し，発生した可能性のある意図しない損害を監視するために使用される．本ステップの結果は，パフォーマンスメトリクス，評価と是正のための文書化された透明なプロセス，および必要に応じたアイデンティティシステムの継続的な改善である．

There are 4 steps to the digital identity risk management process:

  1. Conduct Initial Impact Assessment: In this step, organizations evaluate their user population and assess the impact of a failure of each function in the identity system (i.e., proofing, authentication, and federation) for their protected application or service against a defined set of impact categories. The outcome of this step is a documented set of impact categories and associated impact levels.
  2. Select Initial Assurance Levels: In this step, the impact categories and impact levels are evaluated to determine the appropriate assurance levels to protect the application. The outcome of this step is an identified initial level for each applicable xAL.
  3. Tailor and Document Assurance Level Determinations: In this step, detailed privacy, equity, usability, and threat assessments are conducted to determine the potential impact of the initially selected assurance level on the specific user population and threat environment of the application. The initial assurance level is tailored, compensating or supplemental controls are identified, and all decisions are documented. The outcome is a Digital Identity Acceptance Statement (see Sec. 5.3.4) with a defined implementable assurance level.
  4. Continuously Evaluate & Improve: In this step, information is collected on performance of the identity system across a diverse set of factors based on organization needs and evolving threat vectors. This information is used to determine if the selected assurance level and controls are meeting mission, business, and security needs and to monitor for unintended harms that may have emerged. The outcomes of this step are performance metrics, documented and transparent processes for evaluation and redress, and ongoing improvements to the identity system as needed.

「段階的な」アプローチとして提示されているが，最初のタスクの実行とタスクの再検討の間の反復サイクルの必要性など，一連の順序からの分岐が必要なプロセスの多くのポイントが存在する可能性がある．たとえば，評価の進行中に新しい規制や要件が導入された場合，組織はプロセスのステップを再検討する必要がある場合がある．さらに，新しい機能，データ使用の変更，および脅威環境の変更により，組織はいつでもデジタルアイデンティティリスク管理プロセスの手順を再検討する必要がある．

While presented as a “stepwise” approach, there can be many points in the process that require divergence from the sequential order, including the need for iterative cycles between initial task execution and revisiting tasks. For example, the introduction of new regulations or requirements while an assessment is ongoing may require organizations to revisit a step in the process. Additionally new functionality, changes in data usage, and changes to the threat environment may at any point require an organization to revisit steps in the digital identity risk management process.

組織は，組織のプロセス，ガバナンス，および企業のリスク管理慣行との統合を満たすために，この全体的なアプローチを適応および修正する必要がある．少なくとも，組織は，運用アプローチや有効化ツールに関係なく，各ステップが実行され，各ステップの規範的な義務と結果が完了し，文書化されていることを確認しなければならない(SHOULD)．

Organizations SHOULD adapt and modify this overall approach to meet organizational processes, governance, and integration with enterprise risk management practices. At a minimum, organizations SHALL ensure that each step is executed and the normative mandates and outcomes of each step are completed and documented regardless of operational approach and enabling tools.

初期影響評価の実施 (Conduct Initial Impact Assessment)

初期影響分析の目的は，RP アプリケーションまたはサービスに固有の身元確認，当人認証，およびフェデレーションにおける障害の潜在的な悪影響を特定し，保証レベルの初期セットを生み出すことである．これらの領域を個別に評価することで，組織はミッションの目的を達成するのに最適なデジタルアイデンティティサービスを開発または取得する際に最大限の柔軟性を得ることができる．

The purpose of the initial impact analysis is to identify the potential adverse impacts of failures in identity proofing, authentication, and federation specific to an RP application or service, yielding an initial set of assurance levels. Assessing these areas separately allows organizations maximum flexibility in developing or acquiring a digital identity service that best enables them to successfully deliver on mission objectives.

影響評価には以下が含まる．

The impact assessment includes:

  • Identifying impacted entities,
  • Identifying a set of impact categories for which harms will be assessed,
  • Identifying potential harms for each of the impact categories,
  • Identifying the levels of impact those potential harms would inflict should failures occur, and
  • Assessing the impact of each type of failure (proofing, authentication, and federation) and the resulting impact level to all affected entities.

本評価の結果は，考えられる障害の種類ごとに — 高，中，低 — で定義された影響レベルである．これは，最初の保証レベル選択への主要な入力として機能する．

The output of this assessment is a defined impact level — High, Moderate, or Low — for each possible type of failure. This serves as the primary input to the initial assurance level selection.

影響を受けるエンティティの特定 (Identify Impacted Entities)

影響を評価する場合，組織は検討中のアプリケーションまたはトランザクションによって影響を受けるエンティティを決定する必要がある．このガイドラインで前述したように，デジタルアイデンティティシステムの障害がもたらすさまざまなエンティティへの影響を考慮することが不可欠である．特に重要なのは，個人への潜在的な影響が企業への影響と並んで考慮されるようにすることである．

When assessing impacts, an organization needs to determine the entities that will be impacted by the application or transaction under consideration. As mentioned earlier in this guideline, it is imperative to consider the impact on different entities resulting from a failure of the digital identity system. Of particular importance is ensuring that the potential impacts to individuals are considered alongside those of the enterprise.

したがって，影響評価には，組織自体に加えて，システムまたはアプリケーションを使用する個人を含めなければならない(SHALL)．さらに，組織は，ミッションパートナー，コミュニティ，および [SP800-30] で特定されたものなど，ミッションとビジネスのニーズに基づいて具体的に含める必要がある他のエンティティを特定する必要がある(SHOULD)．少なくとも，機関は，影響分析を実施する際に，影響が評価されるすべてのエンティティを文書化しなければならない(SHALL)．

Accordingly, impact assessments SHALL include individuals using the system or application in addition to the organization itself. Additionally, organizations SHOULD identify other entities, such as mission partners, communities, and those identified in [SP800-30], that need to be specifically included based on mission and business needs. At a minimum, agencies SHALL document all entities to which impacts will be assessed when conducting their impact analysis.

本項目の結果は，影響が評価される検討中のアプリケーションまたはトランザクションの対象となるエンティティのリストである．

The outcome of this activity is a list of entities subject to the application or transaction under consideration for whom impacts will be assessed.

影響のカテゴリと潜在的な害の特定 (Identify Impact Categories and Potential Harms)

デジタルトランザクションの初期保証レベルは，少なくとも次の各カテゴリの潜在的な影響を評価することによって決定されなければならない(SHALL)．

Initial assurance levels for digital transactions SHALL be determined by assessing the potential impact of, at a minimum, each of the following categories:

  • Damage to mission delivery
  • Damage to trust or reputation
  • Loss of sensitive information
  • Damage to or loss of economic stability
  • Loss of life or damage to safety, health, or environmental stability
  • Noncompliance with laws, regulations, and/or contractual obligations

組織は，その使命に基づいて，必要に応じて追加の影響カテゴリを含める必要がある(SHOULD)．各影響カテゴリを文書化し，組織によって評価されたさまざまなアプリケーションに一貫して適用しなければならない(SHALL)．

Organizations SHOULD include additional impact categories as appropriate based on their mission. Each impact category SHALL be documented and consistently applied across different applications assessed by the organization.

害とは，エンティティが経験するあらゆる悪影響である．それらは，影響カテゴリと，そのアプリケーションに関連付けられた特定のエンティティにどのように適用されるかをより効果的に理解する手段を提供する．機関は，定義された影響カテゴリごとに特定の害を考慮して，影響分析をより適切に通知する必要がある(SHOULD)．各カテゴリの危害の識別は，「エンティティの識別」プロセスで識別されたエンティティごとに行われなければならない(SHALL)．

Harms are any adverse effects that would be experienced by an entity. They provide a means to more effectively understand the impact categories and how they may apply to specific entities associated with that application. Agencies SHOULD consider specific harms for each of the defined impact categories to better inform their impact analysis. Identification of harms for each category SHALL be done for each of the entities identified during “entity identification” process.

各カテゴリに関連する害の例には，次のものが含まれるが，これらに限定されない．

Examples of harms associated with each category include, but are not limited to:

使命の配信への損害:

Damage to mission delivery:

  • Harms to individuals may include the inability to access government services or benefits for which they are eligible.
  • Harms to the organization may include an inability to perform current mission/business functions in a sufficiently timely manner, with sufficient confidence and/or correctness, within planned resource constraints, or an inability, or limited ability, to perform mission/business functions in the future.

信頼または評判への損害:

Damage to trust or reputation:

  • Harms to individuals may include impersonation or damage to image or reputation.
  • Harms to the organization may include damage to trust relationships, image, or reputation including future, potential trust relationships.

機密情報の喪失:

Loss of sensitive information:

  • Harms to individuals includes loss of PII or other sensitive information, which may result in secondary harms such as loss of economic stability, loss of life, physical or psychological injury, impersonation, identity theft, or persistent inconvenience.
  • Harms to the organization may include loss or degradation of intellectual property or other information assets such as classified materials or controlled unclassified information (CUI).

経済的安定性への損害または喪失:

Damage to or loss of economic stability:

  • Harms to individuals may include debts incurred or assets lost as a result of fraud or other harm, damage to or loss of credit, actual or potential employment, or sources of income, and/or other financial loss.
  • Harms to the organization may include costs incurred related to fraud or other criminal activity, loss of assets, devaluation, or loss of business.

生命の損失，または安全，健康，環境の安定性への損害:

Loss of life or damage to safety, health, or environmental stability:

  • Harms to individuals may include death, damage to or loss of physical, mental, or emotional well-being, damage to the environment, or loss of accessible, affordable housing.
  • Harms to the organization may include damage to or loss of the organization’s workforce or the impact of unsafe conditions rendering the organization unable to operate or operating at reduced capacity.

法律，規制，and/or 契約上の義務の不遵守:

Noncompliance with laws, regulations, and/or contractual obligations:

  • Harms to individuals may include damage to or loss of economic stability, safety, privacy, civil liberties, equity, and/or usability due to violations of local, state, and federal laws, regulations, and/or contractual obligations.
  • Harms to the organization may include financial costs, sanctions, liability, etc, due to noncompliance with applicable laws, regulations, contractual requirements, or other requirements in other binding agreements.

本項目の結果は，特定されたエンティティへの影響を評価するために使用される影響カテゴリと害のリストである．

The outcome of this activity will be a list of impact categories and harms which will be used to assess impacts to identified entities.

潜在的な影響レベルの特定 (Identify Potential Impact Levels)

デジタル トランザクションの初期保証レベルは，次の潜在的な影響値のいずれかを使用して，Sec. 5.1.2 の各カテゴリにえ障害が及ぼす潜在的な影響を評価することによって決定される:

  1. 影響の可能性「低: 限定的な悪影響が予想される
  2. 影響の可能性「中」: 深刻な悪影響が予想される
  3. 影響の可能性「高」: 重大または壊滅的な悪影響が予想される

Initial assurance levels for digital transactions are determined by assessing the potential impact a failure would have on each of the categories from Sec. 5.1.2 using one of the following potential impact values:

  1. Low potential impact: could be expected to have a limited adverse effect
  2. Moderate potential impact: could be expected to have a serious adverse effect
  3. High potential impact: could be expected to have a severe or catastrophic adverse effect

注記: アイデンティティシステムの障害がカテゴリに測定可能な結果を引き起こさない場合，影響はない．

Note: If a failure in the identity system causes no measurable consequences for a category, there is no impact.

IAL，AAL，FAL (フェデレーションアイデンティティを受け入れるか提示する場合) の各保証レベルは個別に評価しなければならない(SHALL)．理想的には，評価には，組織の使命を成功裏に遂行するために適用される，個人，組織，他の組織，および国への危害など，さまざまな視点が含まれる．各カテゴリの潜在的な影響の例は次のとおり．

Each assurance level, IAL, AAL, and FAL (if accepting or asserting a federated identity) SHALL be evaluated separately. Ideally, any evaluation will include different viewpoints such as harm to individuals, the organization, other organizations, and the nation as applicable to successful delivery of the organization’s mission. Examples of potential impacts in each of the categories include:

使命の配信の損害:

Damage to mission delivery:

  • Low: at worst, slight outcome disparities exist between individuals that participate in federally funded programs and those that are eligible but unable to participate, or a limited adverse effect on organizational operations or assets, or public interests. Examples of limited adverse effects are: mission capability degradation to the extent and duration that the organization is able to perform its primary functions with noticeably reduced effectiveness, or minor damage to organizational assets or public interests.
  • Moderate: at worst, outcome disparities are evident between individuals that participate in federally funded programs and those that are eligible but unable to participate, or a serious adverse effect on organizational operations or assets, or public interests. Examples of serious adverse effects are: significant mission capability degradation to the extent and duration that the organization is able to perform its primary functions with significantly reduced effectiveness; or significant damage to organizational assets or public interests.
  • High: outcome disparities endure across communities, indicating a systemic pattern of exclusion, avoidance, or other barriers to participation in federally funded programs, or a severe or catastrophic adverse effect on organizational operations or assets, or public interests. Examples of severe or catastrophic effects are: severe mission capability degradation or loss to the extent and duration that the organization is unable to perform one or more of its primary functions; or major damage to organizational assets or public interests.

信頼と評判の損害:

Damage to trust and reputation:

  • Low: at worst, limited, short-term inconvenience, distress, or embarrassment to any party.
  • Moderate: at worst, serious short-term or limited long-term inconvenience, distress, or damage to the standing or reputation of any party.
  • High: severe or serious long-term inconvenience, distress, or damage to the standing or reputation of any party. This is ordinarily reserved for situations with particularly severe effects or which potentially affect many individuals.

機密情報の喪失:

Loss of sensitive information:

  • Low: at worst, a limited release of personal, U.S. government sensitive, or commercially sensitive information to unauthorized parties resulting in a loss of confidentiality with a low impact as defined in [FIPS199].
  • Moderate: at worst, a release of personal, U.S. government sensitive, or commercially sensitive information to unauthorized parties resulting in loss of confidentiality with a moderate impact as defined in [FIPS199].
  • High: a release of personal, U.S. government sensitive, or commercially sensitive information to unauthorized parties resulting in loss of confidentiality with a high impact as defined in [FIPS199].

経済的安定性への損害または喪失:

Damage to or loss of economic stability:

  • Low: at worst, an insignificant or inconsequential financial loss to any party.
  • Moderate: at worst, a serious financial loss to any party.
  • High: severe or catastrophic financial loss to any party.

人命の損失，または安全，健康，環境の安定性への損害:

Loss of life or damage to safety, health, or environmental stability:

  • Low: at worst, minor injury or acute health issue that resolves itself and does not require medical, including mental health, treatment; limited risk of environmental impact in locality where program operations take place.ong-term inconvenience, distress, or damage to the standing or reputation of any party.
  • High: severe or serious long-term inconvenience, distress, or damage to the standing or reputation of any party. This is ordinarily reserved for situations with particularly severe effects or which potentially affect many individuals.

法律，規制，and/or 契約上の義務の不遵守:

Noncompliance with laws, regulations, and/or contractual obligations:

  • Low: at worst, a risk of civil or criminal violations of a nature that would not ordinarily be subject to enforcement efforts, or at worst, an insignificant or inconsequential organization liability.
  • Moderate: at worst, a risk of civil or criminal violations that may be subject to enforcement efforts, or a serious organization liability.
  • High: a risk of civil or criminal violations that are of special importance to enforcement programs, or severe or catastrophic organization liability.

影響分析 (Impact Analysis)

影響分析は，身元確認，当人認証，フェデレーションのプロセスによってどの程度リスクを軽減する必要があるかを判断するのに役立る．これらの決定は，リスク決定を推進する特定の技術に対する欲求ではなく，適用可能な技術と緩和戦略の関連する選択を推進する．

The impact analysis helps determine the extent to which risk must be mitigated by the identity proofing, authentication, and federation processes. These determinations drive the relevant choices of applicable technologies and mitigation strategies, rather than the desire for any given technology driving risk determinations.

ユーザーが主張するアイデンティティの適切な保証レベルを決定するために，組織は潜在的なリスクを評価し，その影響を最小限に抑えるための対策を特定しなければならない(SHALL)．組織は，身元証明，当人認証，フェデレーションの失敗のリスクを個別に評価して，各トランザクションに必要な保証レベルを決定しなければならない(SHALL)．このプロセスには，Sec. 5.1.1 で説明されているように，デジタルアイデンティティシステムによって影響を受けるさまざまなエンティティへの潜在的にさまざまな危害の影響を考慮しなければならない(SHALL)．ビジネスプロセス，ポリシー，およびテクノロジは，リスクの軽減に役立つ場合がある．エンティティは，身元確認，当人認証，フェデレーションに関連する特定のモードの障害の影響を考慮する必要がある(SHOULD)．これには以下が含まれるが，これらに限定されない．

To determine the appropriate level of assurance of the user’s asserted identity, organizations SHALL assess the potential risks and identify measures to minimize their impact. Organizations SHALL assess the risk of identity proofing, authentication, and federation failures separately to determine the required assurance level for each transaction. This process SHALL include consideration of potentially varying impacts of harms to different entities impacted by the digital identity system, as described in Sec. 5.1.1. Business processes, policies, and technologies may help reduce risk. Entities SHOULD consider the impact of specific modes of failures related to identity proofing, authentication, and federation this includes, but may not be limited to:

身元確認:

Identity Proofing:

  • The impact of providing a service to the wrong subject (e.g., an attacker successfully proofs as someone else).
  • The impact of not providing service to an eligible subject due to barriers, including biases, faced by the subject throughout the process of identity proofing.
  • The impact of excessive information collection and retention to support identity proofing processes.

当人認証:

Authentication:

  • The impact of authenticating the wrong subject (e.g., an attacker who compromises or steals an authenticator).
  • The impact of failing to authenticate the correct subject due to barriers, including biases, faced by the subject in presenting their authenticator.

フェデレーション：

Federation:

  • The impact of the wrong subject successfully accessing an application, system, or data (e.g., compromising or replaying an assertion).
  • The impact of releasing subscriber attributes to the wrong application or system.

表1 のようなワークシートを使用すると，組織が分析を完了するために収集した情報を編集するのに役立つ．この種の分析は，身元確認，当人認証，フェデレーションの潜在的な障害の種類ごとに行われ，デジタルアイデンティティシステムとやり取りするエンティティに対する全体的なリスクを判断する．

Using a worksheet similar to Table 1 can assist organizations with compiling the information gathered in order to complete the analysis. This kind of analysis would be done for each type of potential failure for identity proofing, authentication, and federation to determine the overall risks to entities interacting with the digital identity system.

表1 影響カテゴリー

影響カテゴリー 個人への害 組織への害 (その他の害のカテゴリー) 総合影響レベル
使命の配信の損害 L / M / H L / M / H L / M / H  
信頼や評判の損害 L / M / H L / M / H L / M / H  
機密情報の喪失 L / M / H L / M / H L / M / H  
経済的安定性への損害または喪失 L / M / H L / M / H L / M / H  
人命の損失，または安全，健康，環境の安定性への損害 L / M / H L / M / H L / M / H  
法律，規制，and/or 契約上の義務の不遵守: L / M / H L / M / H L / M / H  
Impact Categories Harm to Individuals Harm to the Organization (Other harm categories) Combined Impact Level
Damage to mission delivery L / M / H L / M / H L / M / H  
Damage to trust or reputation L / M / H L / M / H L / M / H  
Loss of sensitive information L / M / H L / M / H L / M / H  
Damage to or loss of economic stability L / M / H L / M / H L / M / H  
Loss of life or damage to safety, health, or environmental stability L / M / H L / M / H L / M / H  
Noncompliance with laws, regulations, and/or contractual obligations L / M / H L / M / H L / M / H  

本ステップの出力は，身元確認，当人認証，およびフェデレーションの失敗に対する定義済みの影響レベルであり，最初の保証レベル選択への主要な入力として機能する．

The output of this step is a defined impact level for failures of identity proofing, authentication, and federation which serve as the primary input to the initial assurance level selection.

初期保証レベルの選択 (Select Initial Assurance Levels)

影響分析は，身元確認，当人認証，フェデレーションの初期保証レベルを選択するプロセスへの主要なインプットとして機能する．保証レベルは，各領域における障害の潜在的な影響の分析に基づいて，これらの領域間で異なる場合がある．これらの初期保証レベルの目的は，使命の必要性，サイバーセキュリティリスク，およびデジタルアイデンティティシステムの組織とユーザーに対するその他の潜在的な影響に基づいて評価および調整される [SP800-63A], [SP800-63B], and [SP800-63C] の付属の巻の要件とガイドラインに反映されている，ベースラインのデジタルアイデンティティ制御とプロセスを特定することである．

The impact analysis serves as a primary input to the process of selecting initial assurance levels for identity proofing, authentication and federation. The assurance levels may differ across these areas based on the analysis of the potential impact of failures in each area. The purpose of these initial assurance levels is to identify baseline digital identity controls and processes, reflected in the requirements and guidelines in the companion volumes of [SP800-63A], [SP800-63B], and [SP800-63C], which will be assessed and tailored based on mission need, cybersecurity risk, and other potential impacts to the organization and users of the digital identity systems.

保証レベル (Assurance Levels)

組織の RP は，サイバーセキュリティのリスクと使命のニーズに基づいて，次の個々の初期保証レベルを選択しなければならない(SHALL)．

An organization RP SHALL select, based on cybersecurity risk and mission needs, the following individual initial assurance levels:

  • IAL: The robustness of the identity proofing process to confidently determine the identity of an individual. IAL is selected to mitigate potential identity proofing failures.
  • AAL: The robustness of the authentication process itself, and the binding between an authenticator and a specific individual’s identifier. AAL is selected to mitigate potential authentication failures.
  • FAL: The robustness of the federation process used to communicate authentication and attribute information (if applicable) to an RP from an IdP. FAL is optional as not all digital systems will leverage federated identity architectures. FAL is selected to mitigate potential federation failures.

xALの詳細 (xAL Descriptions)

アイデンティティ，オーセンティケータ，およびフェデレーションの各保証レベルの概要を以下に示す．

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

本ガイドラインでは，一般的に記述されているかまとめられている場合，IAL，AAL，FAL を xAL と呼ぶ．

When described generically or bundled, these guidelines will refer to IAL, AAL, and FAL as xAL.

身元確認保証レベル (Identity Assurance Level)

IAL1: IAL1 は，権威のある情報源(authoritative source) または信頼できる情報源(credible souece) に対する識別属性の検証，および申請者(applicant)の主張する身元を検証するための基本的なプロセスの使用を必要とする．

IAL1: IAL1 requires validation of identifying attributes against authoritative or credible sources and use of basic processes to verify the claimed identity of the applicant.

IAL2: IAL2 では，特定の属性が強力な証拠によって裏付けられ，権威のある情報源(authoritative source) または信頼できる情報源(credible souece) に照らして検証され，プロセスを使用して申請者(applicant)の主張する身元を検証する必要がある．

IAL2: IAL2 requires identifying attributes to be supported by strong evidence and validated against authoritative or credible sources and use of processes to verify the claimed identity of the applicant.

IAL3: IAL3 では，CSP 担当者とのインタラクティブなプロセスを使用して，物理的な文書を検査することにより，認定された CSP 担当者が識別属性を検証する必要がある．

IAL3: IAL3 requires identifying attributes to be verified by an authorized CSP representative through examination of physical documentation using an interactive process with a CSP representative.

当人認証保証レベル (Authentication Assurance Level)

AAL1: AAL1 は，申請者(applicant)が加入者(subscriber)に登録されたオーセンティケーターを制御するという保証を提供する．AAL1 では，利用可能なさまざまな認証技術を使用した単一要素認証が必要である．認証を成功させるには，主張者(ckaimant)が安全な認証プロトコルを介してオーセンティケーターの所有と管理を証明する必要がある．

AAL1: AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.

AAL2: AAL2 は，申請者(applicant)が加入者(subscriber)に登録されたオーセンティケーターを制御するという高い信頼性を提供する．安全な認証プロトコルを通じて，2つの異なる認証要素の所有と管理の証明が必要である．AAL2 以上では，承認された暗号技術が必要である．

AAL2: AAL2 provides high confidence that the claimant controls authenticator registered to the subscriber. Proof of possession and control of two different authentication factors is required through a secure authentication protocol. Approved cryptographic techniques are required at AAL2 and above.

AAL3: AAL3 は，申請者(applicant)が加入者(subscriber)に登録されたオーセンティケーターを制御するという非常に高い信頼性を提供する．AAL3 での認証は，フィッシング攻撃に抵抗できる暗号化認証プロトコルによる鍵の所有証明に基づいている．

AAL3: AAL3 provides very high confidence that the claimant controls authenticator registered to the subscriber. Authentication at AAL3 is based on proof of possession of a key through a cryptographic authentication protocol capable of resisting phishing attacks.

フェデレーション保証レベル (Federation Assurance Level)

FAL1: FAL1 を使用すると，加入者(subscriber)は IdP からのアサーションを使用して RP にログインできる．このアサーションは，RP によって，IdP から送信され，特定の RP を対象としていることが検証される．アサーションは，攻撃者による変更または構築から保護されている．IdP と RP の間の信頼の合意(trust agreement)と登録は，動的に発生する可能性がある．

FAL1: FAL1 allows for the subscriber to log into the RP using an assertion from the IdP that can be verified by the RP as coming from the IdP and targeted for a specific RP. The assertion is protected from modification or construction by an attacker. The trust agreement and registration between the IdP and RP can happen dynamically.

FAL2: FAL2 では，アサーションが RP でのインジェクションに対して堅牢であるという要件が追加されている．これに対応する手段の1つは，アサーションをブラウザーなどの仲介者を介して渡すのではなく，IdP から RP に直接提示することである．IdP と RP 間の信頼の合意(trust agreement)は動的に発生することはないが，特定の IdP と RP の動的登録は実行時に発生する可能性がある．

FAL2: FAL2 adds the requirement that the assertion be robust against injection at the RP. One means of this is to have the assertion presented directly to the RP from the IdP instead of passing through an intermediary like a browser. The trust agreement between the IdP and RP cannot happen dynamically, but dynamic registration of the specific IdP and RP can occur at runtime.

FAL3: FAL3 は，加入者(subscriber)が認証アサーションの提示と共に，バインドされたオーセンティケーターを使用して RP に直接認証するという要件を追加する．この追加のオーセンティケーターの存在により，RP にアクセスする当事者がアサーションで識別された当事者であるという非常に高い保証が RP に提供される．信頼の合意(trust agreement)と登録を動的にすることはできない．

FAL3: FAL3 adds the requirement that the subscriber authenticate directly to the RP using a bound authenticator along with presenting the authentication assertion. The presence of this additional authenticator provides a very high assurance to the RP that the party accessing the RP is the party identified in the assertion. The trust agreement and registration cannot be dynamic.

初期保証レベルの選択 (Initial Assurance Level Selection)

身元確認，当人認証，およびフェデレーションプロセスにおける障害の潜在的な影響の特定と評価は，組織のデジタルアイデンティティリスク管理プロセスと，それらの領域の保証レベルの初期選択に役立る．これらの最初の選択は，主にサイバーセキュリティリスクに基づくが，使命のニーズや，組織，ユーザー，およびミッションパートナーに対するその他の潜在的な影響に基づいて調整される．

The identification and assessment of the potential impacts of failures in identity proofing, authentication, and federation processes informs the organization’s digital identity risk management process and the initial selection of assurance levels for those areas. These initial selections are primarily based on cybersecurity risk, but will be tailored, based on mission needs and other potential impacts to the organization, users, and mission partners.

組織は，デジタルアイデンティティの障害の潜在的な影響に基づいて初期保証レベルを選択するためのプロセスとガバナンスモデルを開発し，文書化しなければならない(SHALL)．本セクションでは，そのプロセスに含める主要な要素に関するガイダンスを提供する．

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

初期IALの選択 (Selecting Initial IAL)

IAL は，申請者(applicant)が主張した現実の身元を保持しているという保証のレベルを反映している．組織は，リスクベースのアプローチを使用して，RP アプリケーションに最も適切な身元確認要件を選択しなければならない(SHALL)．Sec. 5.3.1 で説明されている影響分析は，最初の IAL の選択に役立つ．この最初の選択は，Sec. 5.3で説明されているように，最終的な IAL を決定する前に，使命のニーズ，リスク許容度，およびプライバシー，公平性，およびユーザビリティへの潜在的な影響に基づいて調整されなければならない(SHALL)．

The IAL reflects the level of assurance that an applicant holds the claimed real-life identity. Organizations SHALL use a risk-based approach to select the most appropriate identity proofing requirements for their RP application. The impact analysis described in Sec. 5.3.1 informs the selection of the initial IAL selection. This initial selection SHALL be tailored, as described in Sec. 5.3, based on mission needs, risk tolerance, and potential impacts to privacy, equity, and usability, before making a final IAL determination.

身元確認は CSP の機能であるため，IAL の選択は，RP アプリケーションの所有者が自分で証明を実行する必要があるという意味ではない．

The IAL selection does not mean the RP application owner will need to perform the proofing themselves since identity proofing is the function of the CSP.

すべての RP アプリケーションで身元確認が必要になるわけではない．RP アプリケーションがデジタルトランザクションを実行するために個人情報を必要としない場合，システムは RP アプリケーションのユーザーの身元確認なしで動作できる．個人情報が必要な場合，RP は，検証済みおよび検証済みの属性が必要かどうか，または自己提示属性が許容されるかどうかを判断する必要がある．自己提示された属性を受け入れることによる潜在的な害がわずかである場合，システムはユーザーの身元確認なしで動作することもできる．そのような場合，[SP800-63A] で説明されている身元確認プロセスはシステムに適用されない．

Not all RP applications will require identity proofing. If the RP application does not require any personal information to execute any digital transactions, the system can operate without identity proofing users of the RP application. If personal information is needed, the RP needs to determine if validated and verified attributes are required or if self-asserted attributes are acceptable. If there are insignificant potential harms from accepting self-asserted attributes, the system may also be able to operate without identity proofing users. In such cases, the identity proofing processes described in [SP800-63A] are not applicable to the system.

身元確認が必要であると組織が判断した場合，最初の IAL は，身元確認の失敗の潜在的な影響に基づいて評価されなければならない(SHALL)．Sec. 5.1で説明されているように，RP アプリケーションの使用または操作によって生じる損害について，組織，個人，他の組織，および国家の観点から潜在的な影響を考慮しなければならない(SHALL)．組織が悪影響を受けることはないかもしれないが，サービスプロバイダーのビジネス慣行によってプライバシーやその他の権利が侵害された個人と同様に，ユーザーは重大な損害を受ける可能性がある． 組織は，RP アプリケーションの全体的な影響レベルを特定する際に最悪のケースを考慮する必要がある(SHOULD)が，異なる影響がある場合は，リスク管理プロセスを使用して最初の選択を調整することができる．

If an organization determines that identity proofing is necessary, the initial IAL SHALL be assessed based on the potential impacts of identity proofing failures. As described in Sec. 5.1, potential impacts SHALL be considered from the perspective of the organization, individuals, other organizations, and the nation, for harms incurred through the use or operation of the RP application. While the organization may not be negatively impacted, the user could be significantly harmed, as could individuals whose privacy or other rights have been violated by the business practices of a service provider. Organizations SHOULD consider the worst-case when identifying the overall impact level of the RP application, but may use risk management processes to tailor their initial selection when there are differing impacts.

RP アプリケーションの全体的な影響レベルを評価する場合，組織は使命の提供への影響を他の影響カテゴリとは別に考慮しなければならない(SHALL)．組織は，使命の遂行に害を及ぼす可能性のある身元確認プロセスの潜在的な失敗を評価して，より厳密な身元確認プロセスの実装によって関連する影響が軽減または悪化するかどうかを判断する必要がある．そのため，組織は，RP アプリケーションの全体的な影響レベルを最初に特定するときに，使命の配信のカテゴリを除外してもよい(MAY)．これは，これらの影響を調整プロセスで考慮する必要があるためである．

When assessing the overall impact level of the RP application, the organization SHOULD consider impacts to mission delivery separately from other impact categories. Potential failures in the identity proofing process that could lead to harms in mission delivery should be assessed by the organization to determine if the associated impacts would be mitigated or exacerbated by the implementation of more rigorous identity proofing processes. As such, the organization MAY exclude the mission delivery category when initially identifying the overall impact level of the RP application, as these impacts will need to be considered in the tailoring process.

組織によって評価された全体的な影響レベルは，さらなる調整が行われる可能性がある IAL の予備的な選択につながる:

The overall impact level assessed by the organization leads to a preliminary selection of the IAL from which further tailoring may be done:

  • Low impact: IAL1
  • Moderate impact: IAL2
  • High impact: IAL3

予備的な選択では，身元確認プロセスでの失敗の潜在的な影響は，より高い保証プロセスによって軽減されるべきであると想定している．これはよくあることだが，組織は，影響分析の一部として特定された特定の障害，影響カテゴリ，および影響を受けるエンティティを考慮して，追加の調整が必要かどうかを判断する必要がある．たとえば，正当な申請者(applicant)の登録に失敗すると，過度の損害が発生する可能性がある場合，組織は，保証の低い身元確認プロセスが適切かどうかを評価する必要がある．

The preliminary selection assumes that higher potential impacts of failures in the identity proofing process should be mitigated by higher assurance processes. While this is often the case, organizations should consider the specific failures, impact categories, and impacted entities identified as part of the impact analysis to determine if additional tailoring is warranted. For example, if a failure to enroll a legitimate applicant could lead to excessive harm, organizations should assess whether lower-assurance identity proofing processes would be appropriate.

追加の調整を含むこのプロセスの結果は，Sec. 5.3 で説明されている追加の潜在的な影響に対して評価される IAL の初期評価である．

The result of this process, including any additional tailoring, is the initial assessment of the IAL, which will be assessed against additional potential impacts as described in Sec. 5.3.

Selecting Initial AAL

The AAL reflects the level of assurance from the authentication process that the claimant is who they claim to be. Organizations SHALL use a risk-based approach to select the most appropriate authentication requirements for their RP application. The impact analysis described in Sec. 5.1.3 informs the selection of the initial AAL selection. This initial selection SHALL be tailored, as described in Sec. 5.3, based on mission needs, risk tolerance, and potential impacts to privacy, equity, and usability, before making a final AAL determination.

The AAL selection does not mean the RP application owner will need to issue authenticators themselves.

The initial AAL SHALL be assessed based on the potential impacts of authentication failures. As described in Sec. 5.1, potential impacts SHALL be considered from the perspective of the organization, individuals, other organizations, and the nation, for harms incurred through the use or operation of the RP application, as the level of harm from a failure could vary significantly across these entities. Organizations SHOULD consider the worst-case when identifying the overall impact level of the RP application, but may use risk management processes to tailor their initial selection when there are differing impacts.

When assessing the overall impact level of the RP application, the organization SHOULD consider impacts to mission delivery separately from other impact categories. Potential failures in the authentication process that could lead to harms in mission delivery should be assessed by the organization to determine if the associated impacts would be mitigated or exacerbated by the implementation of more rigorous authentication controls. As such, the organization MAY exclude the mission delivery category when initially identifying the overall impact level of the RP application, as these impacts will need to be considered in the tailoring process.

The overall impact level assessed by the organization leads to a preliminary selection of the AAL from which further tailoring may be done:

The preliminary selection assumes that higher potential impacts of failures in the authentication process should be mitigated by higher assurance processes. While this is often the case, organizations should consider the specific failures, impact categories, and impacted entities identified as part of the impact analysis to determine if additional tailoring is warranted. Further, organizations should consider legal, regulatory, or policy requirements that govern digital services. For example, the terms of [EO13681] requiring “that all organizations making personal data accessible to citizens through digital applications require the use of multiple factors of authentication,” which would drive the selection of AAL2 or AAL3.

The result of this process, including any additional tailoring, is the initial assessment of the AAL, which will be as assessed against additional potential impacts as described in Sec. 5.3.

Selecting Initial FAL

The FAL reflects the level of assurance in identity assertions that convey the results of authentication processes and relevant identity information to RP systems. Organizations SHALL use a risk-based approach to select the most appropriate federation requirements for their RP application. The impact analysis described in Sec. 5.3.1 informs the selection of the initial FAL selection. This initial selection SHALL be tailored, as described in Sec. 5.3, based on mission needs, risk tolerance, and potential impacts to privacy, equity, and usability, before making a final FAL determination.

The initial FAL SHALL be assessed based on the potential impacts of failures in the presentation or acceptance of assertions in federated identity architectures. Examples of compromise include use of assertion replay to impersonate a valid user or leakage of assertion information through the browser. As described in Sec. 5.1, potential impacts SHALL be considered from the perspective of the organization, individuals, other organizations, and the nation, for harms incurred through the use or operation of the RP application, as the level of harm from a failure could vary significantly across these entities. Organizations SHOULD consider the worst-case when identifying the overall impact level of the RP application, but may use risk management processes to tailor their initial selection when there are differing impacts.

When assessing the overall impact level of the RP application, the organization SHOULD consider impacts to mission delivery separately from other impact categories. Potential failures in federated architectures that could lead to harms in mission delivery MAY be assessed by the organization to determine if the associated impacts would be mitigated or exacerbated by the implementation of more rigorous controls by identity providers. As such, the organization may exclude the mission delivery impact category when initially identifying the overall impact level of the RP application, as these impacts will need to be considered in the tailoring process.

The overall impact level assessed by the organization leads to a preliminary selection of the FAL from which further tailoring may be done:

The preliminary selection assumes that higher potential impacts of failures in federated identity architectures should be mitigated by higher assurance processes. While this is often the case, organizations should consider the specific failures, impact categories, and impacted entities identified as part of the impact analysis to determine if additional tailoring is warranted.

The result of this process, including any additional tailoring, is the initial assessment of the FAL, which will be as assessed against additional potential impacts as described in Sec. 5.3.

Tailor and Document Assurance Levels

Tailoring provides a process to modify an initially assessed assurance level or implement compensating controls based on ongoing detailed impact and risk assessments. Organizations SHOULD implement the assessed assurance level as defined in these guidelines. However, these guidelines provide flexibility to allow for organizations to meet specific mission needs and address unique risk appetites and considerations. Therefore, organizations SHALL establish and document an xAL tailoring process. At a minimum this process:

  1. SHALL include a structured governance approach to allow for decision-making and conflict resolution.
  2. SHALL document all decisions in the tailoring process, including the assessed xALs, modified xALs, and compensating controls in the Digital Identity Acceptance Statement (see Sec. 5.3.4).
  3. SHALL justify and document all risk-based decisions or modifications to the initially assessed xALs in the Digital Identity Acceptance Statement (see Sec. 5.3.4).
  4. SHOULD establish a cross-functional capability to support subject matter analysis of xAL selection impacts in the tailoring process.
  5. SHOULD be a continuous process that incorporates real world operational data to evaluate the impacts of selected xAL controls.

The tailoring process promotes a structured means to balance risks and impacts in the furtherance of protecting systems, data, and services in a manner that enables mission success while supporting equity, privacy, and usability for individuals.

Assess Privacy, Equity, Usability and Threats

When selecting and tailoring assurance levels for specific applications, it is critical that insights and inputs to the process extend beyond an initial, static impact assessment. When transitioning from an initial assurance level to the final xAL selection and implementation, organizations SHALL conduct detailed assessments of the controls defined at the assurance level to determine potential impacts in their operational environment. At a minimum, organizations SHALL assess impacts related to the following areas:

Additionally, organizations SHOULD conduct additional business specific assessments as appropriate to fully represent mission and domain specific considerations not captured here. These assessments SHALL be extended to any compensating or supplemental controls as defined in Sec. 5.3.2 and Sec. 5.3.3.

Identify Compensating Controls

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

Organizations SHOULD implement their identity services per the requirements in these guidelines for their tailored assurance level. However, where organizations are unable to implement a specific control associated with their baseline or tailored assurance level, they MAY select to implement a compensating control. This control MAY be a modification to a digital identity process as defined in these guidelines, but MAY also be applied elsewhere in an application, transaction, or service lifecycle. For example:

Where compensating controls are implemented, organizations SHALL demonstrate comparability of a chosen alternative or document residual risk incurred by deviating from normative requirements. Organizations SHALL implement procedures to document both the justification for any departure from normative requirements and detail the compensating controls employed. The inclusion of compensating controls does not imply that an organization must tailor to a lower xAL. The process of tailoring allows for agencies and service providers to make risk-based decisions in how they implement their xALs and provides a mechanism for documenting and communicating decisions through the Digital Identity Acceptance Statement described in Sec. 5.3.4.

Identify Supplemental Controls

Supplemental controls are those that may be added, in addition to those specified in the organizations tailored assurance level, in order to address specific threats or attacks. Organizations SHOULD identify and implement supplemental controls where they identify threats that may not be addressed in baseline controls. For example:

Where organizations implement supplemental controls, these SHALL be assessed for impacts based on the same factors used to tailor the organization’s assurance level. Supplemental controls SHALL be documented.

Document Results - The Digital Identity Acceptance Statement

The Digital Identity Acceptance Statement documents the results of the digital identity risk management process. This includes the Impact Assessment, Initial Assurance Level Selection, and Tailoring process.

The statement SHALL include, at a minimum:

  1. Initial Impact Assessment Results
  2. Initially assessed xAL,
  3. Tailored xAL and rationale, if tailored xAL differs from initially assessed xAL,
  4. All compensating controls and their comparability or residual risk associated with compensating controls
  5. All supplemental controls

Federal agencies SHOULD include this information in the system authorization package described in [SP800-37].

Continuously Evaluate and Improve

Threat actors adapt, user expectations and needs shift, and missions evolve. As such, risk assessments and identity solutions are not to be set and forgotten. To maintain pace with the constantly shifting environment in which they operate, organizations SHOULD implement a continuous evaluation and improvement program that leverages input from people interacting with the identity system. These programs SHOULD consider feedback from application performance metrics, threat intelligence, fraud analytics, assessments of equity impacts, privacy impact analysis, and user inputs.

Cyber, Fraud, and Identity Program Integrity

Typically, identity solutions are the front door for a critical business or service function. Accordingly, they should not operate in a vacuum. Close coordination of identity functions with cybersecurity teams, threat intelligence teams, and program integrity teams can enable a more complete protection of business capabilities, while constantly improving identity solution capabilities. For example, payment fraud data collected by program integrity teams could provide indicators of compromised subscriber accounts and potential weaknesses in identity proofing implementations. Similarly, threat intelligence teams may receive indication of new TTPs that may impact identity proofing, authentication, and federation processes. Organizations SHOULD establish consistent mechanisms for the exchange of information between critical security and fraud stakeholders.

Where supporting service providers, such as CSPs, are external, this may be complicated, but SHOULD be considered in contractual and legal mechanisms. All data collected, transmitted, or shared SHALL be minimized and subject to a detailed privacy and legal assessment.

References

This section is informative.

General References

[A-130] OMB Circular A-130, Managing Federal Information as a Strategic Resource, July 28, 2016, available at: https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf.

[EO13681] Executive Order 13681, Improving the Security of Consumer Financial Transactions, October 17, 2014, available at: https://www.federalregister.gov/d/2014-25439.

[EO13985] Executive Order 13985, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government, January 25, 2021, available at: https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government

[FISMA] Federal Information Security Modernization Act of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283, available at: https://www.congress.gov/bill/113th-congress/senate-bill/2521.

[M-03-22] OMB Memorandum M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002, September 26, 2003, available at: https://georgewbush-whitehouse.archives.gov/omb/memoranda/m03-22.html.

[NISTIR8062] NIST Internal Report 8062, An Introduction to Privacy Engineering and Risk Management in Federal Systems, January 2017, available at: https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf.

[NISTRMF] Risk Management Framework Overview, available at https://csrc.nist.gov/groups/SMA/fisma/framework.html.

[NISTPF] NIST Privacy Framework, available at https://www.nist.gov/privacy-framework/privacy-framework.

[PrivacyAct] The Privacy Act of 1974, available at https://www.govinfo.gov/content/pkg/USCODE-2020-title5/pdf/USCODE-2020-title5-partI-chap5-subchapII-sec552a.pdf

[SORN] United States Office of Personnel Management (OPM), System of Records Notice (SORN) Guide, April 22, 2010, available at: https://www.opm.gov/information-management/privacy-policy/privacy-references/sornguide.pdf

Standards

[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), BCP 195, RFC 7525,DOI 10.17487/RFC7525, May 2015, available at: https://doi.org/10.17487/RFC7525.

[ISO9241-11] International Standards Organization, ISO/IEC 9241-11 Ergonomic requirements for office work with visual display terminals (VDTs) — Part 11: Guidance on usability, March 1998, available at: https://www.iso.org/standard/16883.html.

[OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, OpenID Connect Core 1.0 incorporating errata set 1, November, 2014. Available at: https://openid.net/specs/openid-connect-core-1_0.html.

[RFC5246] Dierks, T. and E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2, RFC 5246, DOI 10.17487/RFC5246, August 2008, https://www.rfc-editor.org/info/rfc5246.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 5280, DOI 10.17487/RFC5280, May 2008, https://www.rfc-editor.org/info/rfc5280.

NIST Special Publications

NIST 800 Series Special Publications are available at: < https://csrc.nist.gov/publications/sp800l>. The following publications may be of particular interest to those implementing systems of applications requiring digital authentication.

[SP800-30] NIST Special Publication 800-30 Revision 1, Guide for Conducting Risk Assessments, September 2012, available at: https://doi.org/10.6028/NIST.SP.800-30r1.

[SP800-37] NIST Special Publication 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, December 2018, available at: https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final.

[SP800-52] NIST Special Publication 800-52 Revision 2, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, August 2019, available at: https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final.

[SP800-53] NIST Special Publication 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations, September 2020 (incudes updates as of Dec. 10, 2020), available at: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final.

[SP800-53A] NIST Special Publication 800-53A Revision 5, Assessing Security and Privacy Controls in Information Systems and Organizations, January 2022, available at: https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final.

[SP800-57Part1] NIST Special Publication 800-57 Part 1, Revision 5, Recommendation for Key Management, Part 1: General, May 2020, https://dx.doi.org/10.6028/NIST.SP.800-57pt1r5.

[SP800-63A] NIST Special Publication 800-63B-4, Digital Identity Guidelines: Enrollment and Identity Proofing, December 2022, https://doi.org/10.6028/NIST.SP.800-63a-4.ipd.

[SP800-63B] NIST Special Publication 800-63B-4, Digital Identity Guidelines: Authentication and Lifecycle Management, December 2022, https://doi.org/10.6028/NIST.SP.800-63b-4.ipd.

[SP800-63C] NIST Special Publication 800-63C-4, Digital Identity Guidelines: Assertions and Federation, December 2022, https://doi.org/10.6028/NIST.SP.800-63c-4.ipd.

Federal Information Processing Standards

[FIPS199] Federal Information Processing Standard 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004, available at: https://doi.org/10.6028/NIST.FIPS.199.

[FIPS201] Federal Information Processing Standard Publication 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, available at: https://csrc.nist.gov/publications/detail/fips/201/3/final.

Definitions and Abbreviations

This section is informative.

Definitions

A wide variety of terms is used in the realm of authentication. While many terms’ 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.

Access
To make contact with one or more discrete functions of an online, digital service.
Activation
The process of inputting an activation factor into a multi-factor authenticator to enable its use for authentication.
Activation factor
An additional authentication factor that is used to enable successful authentication with a multi-factor authenticator. Since all multi-factor authenticators are physical authenticators, activation factors are either memorized secrets or biometric factors.
Active Attack
An attack on the authentication protocol where the attacker transmits data to the claimant, Credential Service Provider (CSP), verifier, or Relying Party (RP). Examples of active attacks include attacker-in-the-middle (AitM), impersonation, and session hijacking.
Address of Record
The validated and verified location (physical or digital) where a subscriber can receive communications using approved mechanisms.
Allowlist
A documented list of specific elements that are allowed, per policy decision. In federation contexts, this is most commonly used to refer to the list of RPs allowed to connect to an IdP without subscriber intervention. This concept has historically been known as a whitelist.
Applicant
A subject undergoing the processes of enrollment and identity proofing.
Approved Cryptography
Federal Information Processing Standard (FIPS)-approved or NIST recommended. An algorithm or technique that is either 1) specified in a FIPS or NIST Recommendation, or 2) adopted in a FIPS or NIST Recommendation.
Assertion
A statement from a verifier to an RP that contains information about a subscriber. Assertions may also contain verified attributes.
Assertion Reference
A data object, created in conjunction with an assertion, that identifies the verifier and includes a pointer to the full assertion held by the verifier.
Asymmetric Keys
Two related keys, comprised of a public key and a private key, that are used to perform complementary operations such as encryption and decryption or signature verification and generation.
Attack
An unauthorized entity’s attempt to fool a verifier or RP into believing that the unauthorized individual in question is the subscriber.
Attacker
A party, including an insider, who acts with malicious intent to compromise a system.
Attacker-in-the-Middle Attack (AitM)
An attack in which an attacker is positioned between two communicating parties in order to intercept and/or alter data traveling between them. In the context of authentication, the attacker would be positioned between claimant and verifier, between registrant and CSP during enrollment, or between subscriber and CSP during authenticator binding.
Attribute
A quality or characteristic ascribed to someone or something.
Attribute API
An API that provides attribute values, derived attribute values, and related information about one or more subscribers. Access to these APIs are often granted to RPs in the context of an identity API (for a single subscriber) or a provisioning API (for multiple subscribers). This is distinct from an attribute verification API which is used to verify attribute values for a CSP during the identity proofing process.
Attribute Bundle
A packaged set of attributes, usually contained within an assertion. Attribute bundles offer RPs a simple way to retrieve the most relevant attributes they need from IdPs. OpenID Connect scopes [OIDC] are an implementation of attribute bundles.
Attribute Provider
A service that provides a subscriber’s attributes without asserting that the subscriber is present to the RP. An Identity Provider (IdP) is one type of attribute provider used in federated scenarios. Attribute providers often make these attributes available by means of an attribute API.
Attribute Value
A complete statement asserting a property of a subscriber, independent of format. For example, for the attribute “birthday,” a value could be “12/1/1980” or “December 1, 1980.”
Attribute Verification API
An API that provides verification of attribute values for use during an identity proofing process. This API accepts attribute values as input queries and returns whether or not the attribute values can be verified. This is distinct from an attribute API which is used to convey attributes to an RP.
Authenticate
See Authentication.
Authenticated Protected Channel
An encrypted communication channel that uses approved cryptography where the connection initiator (client) has authenticated the recipient (server). Authenticated protected channels provide confidentiality and MitM protection and are frequently used in the user authentication process. Transport Layer Security (TLS) [BCP195] is an example of an authenticated protected channel where the certificate presented by the recipient is verified by the initiator. Unless otherwise specified, authenticated protected channels do not require the server to authenticate the client. Authentication of the server is often accomplished through a certificate chain leading to a trusted root rather than individually with each server.
Authentication
The process of determining the validity of one or more authenticators used to claim a digital identity. Authentication establishes that a subject attempting to access a digital service is in control of the technologies used to authenticate.
Authentication Factor
The three types of authentication factors are something you know, something you have, and something you are. Every authenticator has one or more authentication factors.
Authentication Intent
The process of confirming the claimant’s intent to authenticate or reauthenticate by including a process requiring user intervention in the authentication flow. Some authenticators (e.g., OTP devices) establish authentication intent as part of their operation, others require a specific step, such as pressing a button, to establish intent. Authentication intent is a countermeasure against use by malware of the endpoint as a proxy for authenticating an attacker without the subscriber’s knowledge.
Authentication Protocol
A defined sequence of messages between a claimant and a verifier that demonstrates that the claimant has possession and control of one or more valid authenticators to establish their identity, and, optionally, demonstrates that the claimant is communicating with the intended verifier.
Authentication Secret
A generic term for any secret value that an attacker could use to impersonate the subscriber in an authentication protocol.

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

Authenticator
Something the claimant possesses and controls (typically a cryptographic module or password) that is used to authenticate the claimant’s identity. In some previous editions of SP 800-63, this was referred to as a token.
Authentication Assurance Level (AAL)
A category describing the strength of the authentication process.
Authenticator Output
The output value generated by an authenticator. The ability to generate valid authenticator outputs on demand proves that the claimant possesses and controls the authenticator. Protocol messages sent to the verifier are dependent upon the authenticator output, but they may or may not explicitly contain it.
Authenticator Secret
The secret value contained within an authenticator.
Authenticator Type
A category of authenticators with common characteristics. Some authenticator types provide one authentication factor, others provide two.
Authenticity
The property that data originated from its purported source.
Authoritative Source
An entity that has access to, or verified copies of, accurate information from an issuing source such that a CSP can confirm the validity of the identity evidence supplied by an applicant during identity proofing. An issuing source may also be an authoritative source. Often, authoritative sources are determined by a policy decision of the agency or CSP before they can be used in the identity proofing validation phase.
Authorize
A decision to grant access, typically automated by evaluating a subject’s attributes.
Authorized Party
In federation, the organization, person, or entity that is responsible for making decisions regarding the release of information within the federation transaction, most notably subscriber attributes. This is often the subscriber (when runtime decisions are used) or the party operating the IdP (when allowlists are used).
Back-Channel Communication
Communication between two systems that relies on a direct connection (allowing for standard protocol-level proxies), without using redirects through an intermediary such as a browser. This can be accomplished using HTTP requests and responses.
Bearer Assertion
The assertion a party presents as proof of identity, where possession of the assertion itself is sufficient proof of identity for the assertion bearer.
Binding
An association between a subscriber identity and an authenticator or given subscriber session.
Biometric Reference
one or more stored biometric samples, templates, or models attributed to an individual and used as the object of biometric comparison. For example, a facial image stored digitally on a passport, fingerprint minutiae template on a National ID card or Gaussian Mixture Model for speaker recognition, in a database.
Biometric Sample
An analog or digital representation of biometric characteristics prior to biometric feature extraction. An example is a record containing a fingerprint image.
Biometrics
Automated recognition of individuals based on their biological and behavioral characteristics.
Blocklist
A documented list of specific elements that are blocked, per policy decision. This concept has historically been known as a blacklist.
Challenge-Response Protocol
An authentication protocol where the verifier sends the claimant a challenge (usually a random value or nonce) that the claimant combines with a secret (such as by hashing the challenge and a shared secret together, or by applying a private key operation to the challenge) to generate a response that is sent to the verifier. The verifier can independently verify the response generated by the claimant (such as by re-computing the hash of the challenge and the shared secret and comparing to the response, or performing a public key operation on the response) and establish that the claimant possesses and controls the secret.
Claimant
A subject whose identity is to be verified using one or more authentication protocols.
Claimed Address
The physical location asserted by a subject where they can be reached. It includes the individual’s residential street address and may also include their mailing address.

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

Claimed Identity
An applicant’s declaration of unvalidated and unverified personal attributes.
Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA)
An interactive feature added to web forms to distinguish whether a human or automated agent is using the form. Typically, it requires entering text corresponding to a distorted image or a sound stream.
Core Attributes
The set of identity attributes the CSP has determined and documented to be required for identity proofing.
Credential
An object or data structure that authoritatively binds an identity - via an identifier or identifiers - and (optionally) additional attributes, to at least one authenticator possessed and controlled by a subscriber.

A credential is issued, stored, and maintained by the CSP. Copies of information from the credential can be possessed by the subscriber, typically in the form of a one or more digital certificates that are often contained, along with their associated private keys, in an authenticator.

Credential Service Provider (CSP)
A trusted entity whose functions include identity proofing applicants to the identity service and the registration of authenticators to subscriber accounts. A CSP may be an independent third party.
Cross-site Request Forgery (CSRF)
An attack in which a subscriber currently authenticated to an RP and connected through a secure session browses to an attacker’s website, causing the subscriber to unknowingly invoke unwanted actions at the RP.

For example, if a bank website is vulnerable to a CSRF attack, it may be possible for a subscriber to unintentionally authorize a large money transfer, merely by viewing a malicious link in a webmail message while a connection to the bank is open in another browser window.

Cross-site Scripting (XSS)
A vulnerability that allows attackers to inject malicious code into an otherwise benign website. These scripts acquire the permissions of scripts generated by the target website and can therefore compromise the confidentiality and integrity of data transfers between the website and client. Websites are vulnerable if they display user-supplied data from requests or forms without sanitizing the data so that it is not executable.
Cryptographic Authenticator
An authenticator that proves possession of an authentication secret through direct communication, via the endpoint, with a verifier.
Cryptographic Key
A value used to control cryptographic operations, such as decryption, encryption, signature generation, or signature verification. For the purposes of these guidelines, key requirements shall meet the minimum requirements stated in Table 2 of NIST [SP800-57Part1].

See also Asymmetric Keys, Symmetric Key.

Cryptographic Module
A set of hardware, software, and/or firmware that implements approved security functions (including cryptographic algorithms and key generation).
Data Integrity
The property that data has not been altered by an unauthorized entity.
Derived Attribute Value
A statement asserting a property of a subscriber without necessarily containing identity information, independent of format. For example, instead of requesting the attribute “birthday,” a derived value could be “older than 18”. Instead of requesting the attribute for “physical address,” a derived value could be “currently residing in this district.” Previous versions of these guidelines referred to this construct as an “attribute reference”.
Digital Authentication
The process of establishing confidence in user identities presented digitally to a system. In previous editions of SP 800-63, this was referred to as Electronic Authentication.
Digital Signature
An asymmetric key operation where the private key is used to digitally sign data and the public key is used to verify the signature. Digital signatures provide authenticity protection, integrity protection, and non-repudiation, but not confidentiality protection.
Disassociability
Per [NISTIR8062]: The processing of PII or events without association to individuals or devices beyond the operational requirements of the system.
Eavesdropping Attack
An attack in which an attacker listens passively to the authentication protocol to capture information that can be used in a subsequent active attack to masquerade as the claimant.
Electronic Authentication (E-Authentication)
See Digital Authentication.
Enrollment
The process through which an applicant applies to become a subscriber of a CSP and the CSP validates the applicant’s identity.
Entropy
A measure of the amount of uncertainty an attacker faces to determine the value of a secret. Entropy is usually stated in bits. A value having n bits of entropy has the same degree of uncertainty as a uniformly distributed n-bit random value.
Equity
Per EO 13985, Equity refers to 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.
Federal Information Processing Standard (FIPS)
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.

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

Federated Identifier
The combination of a subject identifier within an assertion and an identifier for the IdP that issued that assertion. When combined, these pieces of information uniquely identify the subscriber in the context of a federation transaction.
Federation
A process that allows the conveyance of identity and authentication information across a set of networked systems.
Federation Assurance Level (FAL)
A category describing the assertion protocol used by the federation to communicate authentication and attribute information (if applicable) to an RP.
Federation Proxy
A component that acts as a logical RP to a set of IdPs and a logical IdP to a set of RPs, bridging the two systems with a single component. These are sometimes referred to as “brokers”.
Federation Transaction
A specific instance of processing an authentication using a federation process for a specific subscriber by conveying an assertion from an IdP to an RP.
Front-Channel Communication
Communication between two systems that relies on redirects through an intermediary such as a browser. This is normally accomplished by appending HTTP query parameters to URLs hosted by the receiver of the message.
Hash Function
A function that maps a bit string of arbitrary length to a fixed-length bit string. Approved hash functions satisfy the following properties:

  1. One-way - It is computationally infeasible to find any input that maps to any pre-specified output; and

  2. Collision resistant - It is computationally infeasible to find any two distinct inputs that map to the same output.

Identity
An attribute or set of attributes that uniquely describe a subject within a given context.
Identity API
An attribute API accessed by an RP for accessing attributes of a specific subscriber. Access to the identity API is generally granted as part of a federation authentication process and limited to the information for a single, specific subscriber.
Identity Assurance Level (IAL)
A category that conveys the degree of confidence that the applicant’s claimed identity is their real identity.
Identity Evidence
Information or documentation provided by the applicant to support the claimed identity. Identity evidence may be physical (e.g. a driver license) or digital (e.g. an assertion generated and issued by a CSP based on the applicant successfully authenticating to the CSP).
Identity Proofing
The process by which a CSP collects, validates, and verifies information about a person.
Identity Provider (IdP)
When using federation, this is the party that manages the subscriber’s primary authenticators and issues assertions derived from the subscriber account.
Identity Resolution
The process of collecting information about an applicant in order to uniquely distinguish an individual within the context of the population the CSP serves.
Issuing Source
An authority responsible for the generation of data, digital evidence (such as assertions), or physical documents that can be used as identity evidence.
Kerberos
A widely used authentication protocol developed at MIT. In “classic” Kerberos, users share a secret password with a Key Distribution Center (KDC). The user (Alice) who wishes to communicate with another user (Bob) authenticates to the KDC and the KDC furnishes a “ticket” to use to authenticate with Bob.

See [SP800-63C] Sec. 11.2 for more information.

Knowledge-Based Verification (KBV)
Identity verification method based on knowledge of private information associated with the claimed identity. This is often referred to as knowledge-based authentication (KBA) or knowledge-based proofing (KBP).
Manageability
Per NISTIR 8062: Providing the capability for granular administration of personally identifiable information, including alteration, deletion, and selective disclosure.
Memorized Secret
A type of authenticator comprised of a character string intended to be memorized or memorable by the subscriber, permitting the subscriber to demonstrate something they know as part of an authentication process.
Message Authentication Code (MAC)
A cryptographic checksum on data that uses a symmetric key to detect both accidental and intentional modifications of the data. MACs provide authenticity and integrity protection, but not non-repudiation protection.
Mobile Code
Executable code that is normally transferred from its source to another computer system for execution. This transfer is often through the network (e.g., JavaScript embedded in a web page) but may transfer through physical media as well.
Multi-Factor
A characteristic of an authentication system or an authenticator that requires more than one distinct authentication factor for successful authentication. MFA can be performed using a single authenticator that provides more than one factor or by a combination of authenticators that provide different factors.

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

Multi-Factor Authentication (MFA)
An authentication system that requires more than one distinct authentication factor for successful authentication. Multi-factor authentication can be performed using a multi-factor authenticator or by a combination of authenticators that provide different factors.

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

Multi-Factor Authenticator
An authenticator that provides more than one distinct authentication factor, such as a cryptographic authentication device with an integrated biometric sensor that is required to activate the device.
Network
An open communications medium, typically the Internet, used to transport messages between the claimant 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, attacker-in-the-middle, session hijacking) and passive (e.g., eavesdropping) attack at any point between the parties (e.g., claimant, verifier, CSP, RP).
Nonce
A value used in security protocols that is never repeated with the same key. For example, nonces used as challenges in challenge-response authentication protocols must not be repeated until authentication keys are changed. Otherwise, there is a possibility of a replay attack. Using a nonce as a challenge is a different requirement than a random challenge, because a nonce is not necessarily unpredictable.
Offline Attack
An attack where 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.
One-to-one (1:1) Comparison
The process in which a biometric sample from an individual is compared to a biometric reference to produce a comparison score.
Online Attack
An attack against an authentication protocol where the attacker either assumes the role of a claimant with a genuine verifier or actively alters the authentication channel.
Online Guessing Attack
An attack in which an attacker performs repeated logon trials by guessing possible values of the authenticator output.
Pairwise Pseudonymous Identifier
An opaque unguessable subscriber identifier generated by a CSP for use at a specific individual RP. This identifier is only known to and only used by one CSP-RP pair.
Passive Attack
An attack against an authentication protocol where the attacker intercepts data traveling along the network between the claimant and verifier, but does not alter the data (i.e., eavesdropping).
Passphrase
A passphrase is a memorized secret consisting of a sequence of words or other text that a claimant uses to authenticate their identity. A passphrase is similar to a password in usage, but is generally longer for added security.
Password
See memorized secret.
Personal Data
See Personally Identifiable Information.
Personal Identification Number (PIN)
A memorized secret typically consisting of only decimal digits.
Personal Information
See Personally Identifiable Information.
Personally Identifiable Information (PII)
As defined by OMB Circular A-130, PII is information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual.
Personally Identifiable Information Processing
An operation or set of operations performed upon personally identifiable information that can include, but is not limited to, the collection, retention, logging, generation, transformation, use, disclosure, transfer, and disposal of personally identifiable information.
Pharming
An attack in which an attacker corrupts an infrastructure service such as DNS (Domain Name System) causing the subscriber to be misdirected to a forged verifier/RP, which could cause the subscriber to reveal sensitive information, download harmful software, or contribute to a fraudulent act.
Phishing
An attack in which the subscriber is lured (usually through an email) to interact with a counterfeit verifier/RP and tricked into revealing information that can be used to masquerade as that subscriber to the real verifier/RP.
Possession and Control of an Authenticator
The ability to activate and use the authenticator in an authentication protocol.
Practice Statement
A formal statement of the practices followed by the parties to an authentication process (e.g., CSP or verifier). It usually describes the parties’ policies and practices and can become legally binding.
Predictability
Per [NISTIR8062]: Enabling reliable assumptions by individuals, owners, and operators about PII and its processing by an information system.
Private Key
The secret part of an asymmetric key pair that is used to digitally sign or decrypt data.
Processing
Per [NISTIR8062]: 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.
Presentation Attack
Presentation to the biometric data capture subsystem with the goal of interfering with the operation of the biometric system.
Presentation Attack Detection (PAD)
Automated determination of a presentation attack. A subset of presentation attack determination methods, referred to as liveness detection, involves measurement and analysis of anatomical characteristics or involuntary or voluntary reactions, in order to determine if a biometric sample is being captured from a living subject present at the point of capture.
Protected Session
A session wherein messages between two participants are encrypted and integrity is protected using a set of shared secrets called session keys.

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

Provisioning API
An attribute API that allows an RP to access to attributes for multiple subscribers for the purposes of provisioning RP subscriber accounts. Access to a provisioning API is generally granted to the RP outside of a specific federated authentication transaction.
Pseudonym
A name other than a legal name.
Pseudonymity
The use of a pseudonym to identify a subject.
Pseudonymous Identifier
A meaningless but unique number that does not allow the RP to infer anything regarding the subscriber but which does permit the RP to associate multiple interactions with the subscriber’s claimed identity.
Public Key
The public part of an asymmetric key pair that is used to verify signatures or encrypt data.
Public Key Certificate
A digital document issued and digitally signed by the private key of a certificate authority that binds an identifier to a subscriber to a public key. The certificate indicates that the subscriber identified in the certificate has sole control and access to the private key. See also [RFC5280].
Public Key Infrastructure (PKI)
A set of policies, processes, server platforms, software, and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.
Reauthentication
The process of confirming the subscriber’s continued presence and intent to be authenticated during an extended usage session.
Registration
See Enrollment.
Relying Party (RP)
An entity that relies upon a verifier’s assertion of a subscriber’s identity, typically to process a transaction or grant access to information or a system.
Remote
(In the context of remote authentication or remote transaction) An information exchange between network-connected devices where the information cannot be reliably protected end-to-end by a single organization’s security controls.
Replay Attack
An attack in which the attacker is able to replay previously captured messages (between a legitimate claimant and a verifier) to masquerade as that claimant to the verifier or vice versa.
Replay Resistance
The property of an authentication process to resist replay attacks, typically by use of an authenticator output that is valid only for a specific authentication.
Resolution
See Identity Resolution.
Restricted
An authenticator type, class, or instantiation having additional risk of false acceptance associated with its use that is therefore subject to additional requirements.
Risk Assessment
The process of identifying, estimating, and prioritizing risks to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, and other organizations, resulting from the operation of a system. It is part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place. Synonymous with risk analysis.
Risk Management
The program and supporting processes to manage information security risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, 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.
Salt
A non-secret value used in a cryptographic process, usually to ensure that the results of computations for one instance cannot be reused by an attacker.
Secure Sockets Layer (SSL)
See Transport Layer Security (TLS).
Session
A persistent interaction between a subscriber and an endpoint, either an RP or a CSP. A session begins with an authentication event and ends with a session termination event. A session is bound by use of a session secret that the subscriber’s software (a browser, application, or OS) can present to the RP to prove association of the session with the authentication event.
Session Hijack Attack
An attack in which the attacker is able to insert themselves between a claimant and a verifier subsequent to a successful authentication exchange between the latter two parties. The attacker is able to pose as a subscriber to the verifier or vice versa to control session data exchange. Sessions between the claimant and the RP can be similarly compromised.
Shared Secret
A secret used in authentication that is known to the subscriber and the verifier.
Side-Channel Attack
An attack enabled by leakage of information from a physical cryptosystem. Characteristics that could be exploited in a side-channel attack include timing, power consumption, and electromagnetic and acoustic emissions.
Single-Factor
A characteristic of an authentication system or an authenticator that requires only one authentication factor (something you know, something you have, or something you are) for successful authentication.
Social Engineering
The act of deceiving an individual into revealing sensitive information, obtaining unauthorized access, or committing fraud by associating with the individual to gain confidence and trust.
Software Statement
Software Statement
A list of attributes describing a piece of software that is cryptographically signed by an authority. Software statements are used most commonly with RPs in a federated scenario.
Special Publication (SP)
A type of publication issued by NIST. Specifically, the SP 800-series reports on the Information Technology Laboratory’s research, guidelines, and outreach efforts in computer security, and its collaborative activities with industry, government, and academic organizations.
Subject
A person, organization, device, hardware, network, software, or service.
Subscriber
An individual enrolled in the CSP identity service.
Subscriber Account
An account established by the CSP containing information and authenticators registered for each subscriber enrolled in the CSP identity service.
Supervised Remote Identity Proofing
A remote identity proofing process that employs physical, technical and procedural measures that provide sufficient confidence that the remote session can be considered equivalent to a physical, in-person identity proofing process.
Symmetric Key
A cryptographic key used to perform both the cryptographic operation and its inverse. For example, to encrypt and decrypt or create a message authentication code and to verify the code.
Synthetic identity fraud
The use of a combination of personally identifiable information (PII) to fabricate a person or entity in order to commit a dishonest act for personal or financial gain.
Token
See Authenticator.
Transaction
A discrete event between a user and a system that supports a business or programmatic purpose. A government digital system may have multiple categories or types of transactions, which may require separate analysis within the overall digital identity risk assessment.
Transport Layer Security (TLS)
An authentication and security protocol widely implemented in browsers and web servers. TLS is defined by [RFC5246]. TLS is similar to the older SSL protocol, and TLS 1.0 is effectively SSL version 3.1. NIST SP 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations [SP800-52], specifies how TLS is to be used in government applications.
Trust Anchor
A public or symmetric key that is trusted because it is directly built into hardware or software, or securely provisioned via out-of-band means, rather than because it is vouched for by another trusted entity (e.g. in a public key certificate). A trust anchor may have name or policy constraints limiting its scope.
Usability
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. [ISO/IEC9241-11]
Validation
The process or act of checking and confirming that the evidence and attributes supplied by an applicant are authentic, accurate and associated with a real-life identity. Specifically, evidence validation is the process or act of checking that presented evidence is authentic, current, and issued from an acceptable source; attribute validation is the process or act of confirming the a set of attributes are accurate and associated with a real-life identity.
Verification
The process or act of confirming that the applicant holds the claimed identity represented by the validated identity attributes and associated evidence. In NIST SP 800-63, the term “verification” is synonymous with “identity verification.”
Verifier
An entity that verifies the claimant’s identity by verifying the claimant’s possession and control of one or more authenticators using an authentication protocol. To do this, the verifier needs to confirm the binding of the authenticators with the subscriber account and check that the subscriber account is active.
Verifier Impersonation
See Phishing.
Zeroize
Overwrite a memory location with data consisting entirely of bits with the value zero so that the data is destroyed and not recoverable. This is often contrasted with deletion methods that merely destroy reference to data within a file system rather than the data itself.
Zero-Knowledge Password Protocol
A password-based authentication protocol that allows a claimant to authenticate to a verifier without revealing the password to the verifier. Examples of such protocols are EKE, SPEKE and SRP.

Abbreviations

Selected abbreviations in these guidelines are defined below.

ABAC
Attribute Based Access Control
AAL
Authentication Assurance Level
CAPTCHA
Completely Automated Public Turing test to tell Computer and Humans Apart
CSP
Credential Service Provider
CSRF
Cross-site Request Forgery
XSS
Cross-site Scripting
DNS
Domain Name System
EO
Executive Order
FACT Act
Fair and Accurate Credit Transaction Act of 2003
FAL
Federation Assurance Level
FEDRAMP
Federal Risk and Authorization Management Program
FMR
False Match Rate
FNMR
False Non-Match Rate
FIPS
Federal Information Processing Standard
FISMA
Federal Information Security Modernization Act
1:1 Comparison
One-to-one Comparison
IAL
Identity Assurance Level
IdP
Identity Provider
IoT
Internet of Things
ISO/IEC
International Organization for Standardization/International Electrotechnical Commission
JOSE
JSON Object Signing and Encryption
JSON
JavaScript Object Notation
JWT
JSON Web Token
KBA
Knowledge-Based Authentication
KBV
Knowledge-Based Verification
KDC
Key Distribution Center
LOA
Level of Assurance
MAC
Message Authentication Code
MFA
Multi-Factor Authentication
N/A
Not Applicable
NARA
National Archives and Records Administration
OMB
Office of Management and Budget
OTP
One-Time Password
PAD
Presentation Attack Detection
PIA
Privacy Impact Assessment
PII
Personally Identifiable Information
PIN
Personal Identification Number
PKI
Public Key Infrastructure
PL
Public Law
PSTN
Public Switched Telephone Network
RMF
Risk Management Framework
RP
Relying Party
SA&A
Security Authorization & Accreditation
SAML
Security Assertion Markup Language
SAOP
Senior Agency Official for Privacy
SSL
Secure Sockets Layer
SMS
Short Message Service
SP
Special Publication
SORN
System of Records Notice
TEE
Trusted Execution Environment
TGS
Ticket Granting Server
TGT
Ticket Granting Ticket
TLS
Transport Layer Security
TPM
Trusted Platform Module
TTP
Tactics, Techniques, and Procedures
VOIP
Voice-over-IP

Change Log

SP 800-63-1

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

SP 800-63-2

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

SP 800-63-3

NIST SP 800-63-3 is a substantial update and restructuring of SP 800-63-2. SP 800-63-3 introduces individual components of digital authentication assurance — AAL, IAL, and FAL — to support the growing need for independent treatment of authentication strength and confidence in an individual’s claimed identity (e.g., in strong pseudonymous authentication). A risk assessment methodology and its application to IAL, AAL, and FAL has been included in this guideline. It also moves the whole of digital identity guidance covered under SP 800-63 from a single document describing authentication to a suite of four documents (to separately address the individual components mentioned above) of which SP 800-63-3 is the top-level document.

Other areas updated in 800-63-3 include:

SP 800-63-4

NIST SP 800-63-4 には，SP 800-63-3 からの大幅な更新と再編成がある．800-63-4 の更新内容は次のとおり．

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

  • Section 2.3 expands security and privacy consideration content of previous revisions. It also adds equity and usability considerations.
  • Section 4.1 includes updated non-federated and federated digital identity models and descriptions.
  • Section 4.4 consolidates informative descriptions and considerations on the use of federated identity architectures and assertions into one section.
  • Section 5 expands upon the risk management content of previous revisions and specifically mandates that organizations take into account impacts to individuals and communities in addition to impacts to the organization. It also elevates risks to mission delivery, including challenges to the provisioning of services to all people who are eligible for and entitled to them, within the risk management process and when implementing digital identity systems. The xAL selection flowcharts, previously found in 800-63-3, section 6, have been replaced with text that elaborates the risk management process along with a sample risk assessment matrix that supports xAL selection. Additionally, the guidelines now mandate continuous evaluation of potential impacts to individuals, communities, and organizations.