Sun, 05 Mar 2023 05:16:25 +0000

ABSTRACT

本ガイドライン群は, Digital Identity サービスを実装する連邦機関に対する技術的要件を提供するものであり, それ以外の条件下での標準仕様の開発・利用に対する制約を意図したものではない. 本ガイドライン群は, 政府機関がネットワークを介して提供する情報システムを利用するユーザー (従業員, 委託先, 私人など) の Identity Proofing および Authentication について言及している. それぞれのガイドラインが Identity Proofing, Registration, Authenticator, Management Process, Authentication Protocol, Federation および関連する Assertion の各エリアにおいて技術要件を定義する. 本ドキュメントの発行をもって, 本ドキュメントは既存の NIST Special Publication 800-63-3 を置き換えるものとする.

Keywords

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

翻訳者

• 車井 登
  • Transmit Security

ABSTRACT

本ガイドライン群は, Digital Identity サービスを実装する連邦機関に対する技術的要件を提供するものであり, それ以外の条件下での標準仕様の開発・利用に対する制約を意図したものではない. 本ガイドライン群は, 政府機関がネットワークを介して提供する情報システムを利用するユーザー (従業員, 委託先, 私人など) の Identity Proofing および Authentication について言及している. それぞれのガイドラインが Identity Proofing, Registration, Authenticator, Management Process, Authentication Protocol, Federation および関連する Assertion の各エリアにおいて技術要件を定義する. 本ドキュメントの発行をもって, 本ドキュメントは既存の 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

The rapid proliferation of online services over the past few years has heightened the need for reliable, equitable, secure, and privacy-protective digital identity solutions.

Revision 4 of NIST Special Publication 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.

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. 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.
2. 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.
3. 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.
4. 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 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?

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.

Note to Reviewers

The rapid proliferation of online services over the past few years has heightened the need for reliable, equitable, secure, and privacy-protective digital identity solutions.

Revision 4 of NIST Special Publication 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.

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. 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.
2. 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.
3. 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.
4. 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 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?

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.

本書とその関連である[SP800-63A], [SP800-63B], および [SP800-63C] は、Digital Identity サービスを実装するための技術ガイドラインを組織に提示する.

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.

仮想世界と物理世界の境界線が曖昧になり, デジタルとインターネット技術の急速な拡大と繋がりが進む中, 開発者と消費者は同様に, この変化するハイブリッドエコシステムを, それに伴う機会とリスクも含めて理解することが不可欠となっている. このハイブリッドエコシステムとの関わりは, しばしば Digital Identity (オンライン取引に関わる人物を一意に表現すること) を確立する個人の能力と意思によって決定される.

Digital Identity は, デジタルサービスのコンテキストでは常に一意であるが, すべてのコンテキストで常に個人を一意に特定できるわけではない. さらに, Digital Identity はデジタルサービスのコンテキスト内では一意で明確な意味を持つが, Digital Identity の背後にある個人の現実の身元は知られていない場合がある. 本書では, 「人」は自然人のみを指す (すなわち, 法人を指していない).

Digital Identity の確立は, Digital Identity の保有者と, Digital Transaction の相手側にいる個人, 組織, または システムとの間に信頼を示すことを意図している. しかし, このプロセスには課題がある. 物理的な世界での関係や Transaction と同様に, ミスコミュニケーション, なりすまし, 他人の Digital Identity の詐称, およびその他の Attack の機会が多数存在する. 加えて, 個人のニーズ, 制約, 能力, 嗜好が多岐に渡ることを考えると, デジタルサービスは, 広く永続的に参加できるように, Equity と柔軟性を考慮して設計する必要がある.

Digital Identity に関連するリスクは, 企業への潜在的な影響を超えて広がっており, 企業の意思決定に組み込まれる必要がある. 本書は, 個人, コミュニティ, および他の組織に対するリスクをより強固にかつ明示的に考慮するように努めている. 具体的には, 組織はこの指針を使用しながら, 組織のサイバーセキュリティの目標を優先する Digital Identity に関する決定が, Privacy, Equity, Usability, およびプログラムやサービスを利用する個人の経験を中心とするミッションとビジネスパフォーマンスのその他の指標に関連するものなどにどのように影響するか, または対応する必要があるかを検討する必要がある. ミッションの提供において, 人間中心で継続的に情報を提供するアプローチをとることにより, 組織は, サービスを提供するさまざまな人々との信頼を徐々に築き, 顧客満足度を高め, 問題をより迅速に特定し, 効果的で文化的に適切な是正策を個人に提供する機会を持つことができる.

これらのガイドラインは, 連邦プログラムおよびその他の組織が, Digital Identity 管理をサポートするプロセス, ポリシー, データ, 人, および技術を含む Digital Identity システムに関連するリスクを評価および管理するためのモデルを示している. このモデルは, Identity Proofing, Authentication, および Federation という一連のプロセスによってサポートされている. Identity Proofing は, Subject が特定の物理的人物であることを証明する. Digital Authentication プロセスは, Digital Identity を主張するために使用される 1 つまたは複数の Authenticator の有効性を判断し, デジタルサービスに Access しようとする Subject が, (1) Authentication に使用されている技術を管理しており, (2) 以前にサービスにアクセスした Subject と同一であるという信頼を確立するものである. 最後に, Federation プロセスは, システム間で Authentication をサポートするために Identity 情報を共有することを可能にする.

Identity サービスの構成, モデル, および Availability (可用性) は, SP 800-63 の初版が発表されて以来大幅に変化し, 安全, プライベート, および公平なサービスを多様なユーザーコミュニティに展開する際の考慮事項や課題も変化してきている. この改訂は, 全体的な Digital Identity モデルの下でエンティティが果たすであろう機能に基づいて要件を明確にし発展した Identity サービスの新しいモデルおよびアーキテクチャを促進しながら, これらの課題に対処している.

さらに, 本書は Credential Service Provider (CSP), Verifier, および Relying Party (RP) に対する指針を提供し, Digital Identity サービスの実装のために組織が従うべき Risk Management プロセスを説明し, NIST Risk Management Framework [NISTRMF] およびそれを構成する Special Publication 群を補完するものである. この出版物は, NIST RMF を拡張して, Equity と Usability への配慮を Digital Identity Risk Management プロセスに組み込む方法を概説し, 企業の運用と資産だけでなく, 個人, 他の組織, およびより広く社会への影響を考慮することの重要性を強調している. さらに, Digital Authentication は, 個人の情報への不正アクセスのリスクを軽減することで Privacy 保護をサポートするが, Identity Proofing, Authentication, Authorization, および Federation は, しばしば個人情報の処理を伴うため, これらの機能は Privacy リスクを引き起こす可能性もある. したがって, このガイドラインは, 関連する潜在的な Privacy リスクの軽減を支援するための Privacy 要件および考慮事項を含んでいる.

最後に, 本書は, ネットワーク上のデジタル・システムにアクセスするために対象者の Digital Identity を確立, 維持, および Authenticate するための技術要件と推奨事項を組織に提供しているが, 障壁や悪影響に対処し, Equity を育み, ミッション目標を正常に達成するには, 情報技術チームの権限外のサポートオプションを追加する必要がある場合がある.

Scope & Applicability

すべてのデジタルサービスに Identity Proofing または Authentication が必要なわけではないが, このガイダンスは利用者層 (市民, ビジネス・パートナー, 政府機関など) に関係なく, 何らかのレベルの Digital Identity が必要なすべてのオンライン Transaction に適用される.

本ガイドラインは, 公共サービスにアクセスする市民やコラボレーションスペースにアクセスする民間セクターのパートナーなど, 外部ユーザーとやり取りする組織サービスを主に対象としている. しかし, 職員や契約社員がアクセスする連邦システムにも適用される. Personal Identity Verification (PIV) of Federal Employees and Contractors standard [FIPS201] および対応する一連の Special Publication と組織固有の説明書は, 連邦企業向けにこれらのガイドラインを拡張し, Personal Identity Verification (PIV) カードの発行と管理, 派生 PIV Credential としての追加 Authenticator のバインド, PIV システムでの Federation アーキテクチャおよびプロトコルの使用に関する追加の技術統制および手順を規定している.

本ガイダンスの対象とならない Transaction には, 44 U.S.C. § 3542(b)(2) に定義される国家安全保障システムに関連するものが含まれる. デジタルプロセスでさまざまなレベルの Digital Identity Assurance を必要とする民間部門組織, 州, 地方, および部族の政府は, 必要に応じてこれらの標準の使用を検討することができる.

加えて, オンライン Transaction に使用される一部の Identity は (建物など) 物理的 Access の際にも使用される場合があるが, これらの技術ガイドラインは物理的 Access に対する Subject の Identity は扱っていない. また, 今回の改訂では, 機器間 (ルータ間など) Authentication や Internet of Things (IoT) と呼ばれる相互接続されたデバイスの Identity については明示的に触れていないが, デバイスへの適用可能性を残すため, 可能な限り一般的な Subject に言及するよう記述されている. さらに, Application Programming Interfaces (API) に対する Subject の代理については, 本ガイドラインでは触れていない.

How to Use this Suite of SPs

本ガイドライン群は, Digital Identity を個別要素ごとに分割することで, Authentication の誤りがもたらすネガティブインパクトの軽減に寄与する. Non-federated なシステムでは, 各機関はそれらのうち Identity Assurance Level (IAL) と Authenticator Assurance Level (AAL) という2つの要素を用いるであろう. Federated なシステムでは, それに加えて3つ目の要素となる Federation Assurance Level (FAL) も用いることとなろう. Sec. 5, Digital Identity Risk Management では, Risk Assessment プロセスの詳細と, Risk Assessment の結果が, リスクとミッションに基づいて IAL, AAL, FAL の組み合わせを組織的に選択するための追加のコンテキストをどのように提供するかについて説明する.

ミッションのニーズと並行して, ビジネス, セキュリティ, プライバシーの適切な Risk Management を行うことで, 組織は IAL , AAL , FAL を個別のオプションとして選択することになる. 具体的には, 各機能に対応したレベルを個別に選択することが求められる. 多くのシステムでは, IAL, AAL, およびFALの各レベルが同じ数値になる可能性があるが, これは要件ではなく, 組織は任意のシステムまたはアプリケーションでこれらが同じであると仮定すべきではない.

本ガイドライン群において詳しく扱う Identity Assurance の構成要素は以下の通りである.

• IAL は, Identity Proofing プロセスについて述べる.
• AAL は, Authentication プロセスについて述べる.
• FAL は, RP が Federated Protocol で接続されている場合の Federation プロセスについて述べる.

注: 本ガイドラインでは, IAL , AAL , FAL を総称して, xAL と表記する場合がある.

SP 800-63 は以下のような一連の Vol. から構成される:

SP 800-63 Digital Identity Guidelines : SP 800-63 では, Risk Assesment の方法論, デジタルシステムにおける Authenticator, Credential, Assertion を利用した一般的な Identity Framework の概観, およびリスクベースプロセスに基づく各 Assurance Level の選択方法について述べる. SP 800-63 には normative な資料と informative な資料の両方が含まれている.

[SP800-63A]: 3 つの Identity Assurance Level (IAL) ごとに, リソースへの Access を希望する Applicant の登録と Identity Proofing の要件を規定する. この文書では, Subscriber Account の確立および維持, ならびに Subscriber Account への Authenticator (CSP 発行または Subscriber 提供のいずれか) のバインドに関する Credential Service Providers (CSP) の責務について詳述している.

SP 800-63A contains both normative and informative material.

[SP800-63B]: 3つの Authentication Assurance Level (AAL) のそれぞれで使用できる Authentication プロセス (Authenticator の選択など) の種類に関する推奨事項を規定する. また, 紛失または盗難時の無効化など, Authenticator のライフサイクルに関する推奨事項を記載している.

SP 800-63B contains both normative and informative material.

[SP800-63C]: Authentication プロセスの結果および関連する Identity 情報を機関アプリケーションに伝達するための, Federated Identity Architecture および Assertion の使用に関する要件を規定している. さらに, この文書では, 有効な Authenticated Subject に関する情報を共有するためのプライバシー強化技術を提供し, Subject がデジタルサービスに対して匿名のままで強力な Multi-factor Authentication (MFA) を可能にする方法について説明している.

SP 800-63C contains both normative and informative material.

Enterprise Risk Management Requirements and Considerations

効果的な企業 Risk Management は, 基本的に多分野にまたがるものであり, 多様な要因および Equity の考慮が必要である. Digital Identity Risk Management のコンテキストでは, これらの要因には, 情報セキュリティ, Privacy, Equity, および Usability が含まれるが, これらに限定されるものではない. Risk Management の取り組みでは, 企業の資産および業務だけでなく, 個人, 他の組織, および社会により広く関係するこれらの要因を考慮することが重要である.

Digital Identity に関連する要素を分析する過程で, 組織は, たとえば Privacy または他の法的要件が存在する場合, または Risk Management の結果から組織が追加の対策または他のプロセスの安全策が適切であると判断する場合など, 特定の状況において本書に規定されていない対策が適切であると判断する場合があり得る. 連邦政府機関を含む組織は, 本書で規定されていない補正的または補足的な管理を採用することができる. また, よりセンシティビティの低い機能をより低い Level of Assurance で利用できるように, Digital Service の機能の分割を検討することもできる.

以下に詳述する考慮事項は, 企業の Risk Management 努力を支援し, 情報に基づいた包括的で人間中心 のサービス提供を促進する. この考慮事項のリストはすべてを網羅しているわけではないが, Digital Identity 管理に関連する意思決定に影響を与える可能性がある一連の横断的な要因を取り上げている.

Security

企業組織にとって, 不正アクセス, Availability (可用性) の問題, なりすまし, および他の不正などの Digital Identity セキュリティリスクを評価および管理し, 強力な ID ガバナンスプラクティスを確立することはますます重要となっている. 組織は, このガイダンスを参照しながら, 自分たちが管理し, サービスプロバイダやビジネスパートナーがサービスを提供する個人やコミュニティのために管理する情報および情報システムの Confidentiality (機密性), Integrity (完全性), および Availability (可用性) に対する潜在的な影響を検討する必要がある.

本ガイドラインを導入する連邦政府機関は, Federal Information Security Modernization Act (FISMA) of 2014 [FISMA] および関連のNIST標準とガイドラインに基づくものを含む法的責任を遵守する必要がある. NISTは, これらのガイドラインを実施する非連邦組織が, デジタルシステムの安全な運用を確保するために, 同等の規格に従うことを推奨する.

FISMA は, 連邦政府の情報および情報システムを不正なアクセス, 使用, 開示, 破壊, または改ざんから保護するために適切な管理を実施することを連邦機関に求める. NIST RMF [NISTRMF] は, セキュリティ, プライバシー, サイバーサプライチェーンのリスク管理活動をシステム開発のライフサイクルに統合するプロセスを提供する. このガイドラインに基づいてサービスを提供する連邦政府機関や組織は, FISMAや関連するNISTのリスク管理プロセスや出版物の下で要求されるコントロールやプロセスをすでに実施していることを期待している.

これらのガイドラインに基づく Identity, Authentication, および Federation Assurance Level に包含される管理 および要件は, FISMA および RMF に基づいて決定される情報および情報システムの管理を補完するが, 置き換えたり変更することはない.

Privacy

Digital Identity システムを設計, エンジニアリング, および管理する場合, そのシステムが PII を処理 (Processing) するときに個人のプライバシー関連の問題を引き起こす可能性, 問題のあるデータ操作, および問題のあるデータ操作が発生した場合の潜在的な影響を考慮することが不可欠である. さらに, Predictability, Manageability, およびDisassociabilityというプライバシー工学の目標に注目することで, 組織は, 組織のプライバシーポリシーとシステムのプライバシー要件がどのように実装されているかを実証できるように, 特定のシステムに必要な機能の種類を決定することができる.

Privacy Act of 1974, 2010 Edition, [PrivacyAct]は, 連邦機関が記録システムに保持する個人に関する情報の収集, 維持, 使用, 開示に関する一連の公正な情報プラクティスを定めたものである.

Digital Identity 管理プロセスおよびシステムを設計・実装する場合, プライバシー Risk Assessment はこれらのガイドラインに基づく PII Processing に必要となる. そのようなプライバシー Risk Assessment は, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 [M-03-22] に基づくPrivacy Impact Assessments の支援に使用できるほか, NIST Special Publication 800-53, Security and Privacy Controls for Information Systems and Organizations [SP800-53] からコントロールを選択するためにも使用することができる. さらに, 800-63 の各巻 (63A, 63B, 63C) には, その巻で提示されたプロセス, 管理, 要件の実装に関する詳細なプライバシー要件と考慮事項を示す特定のセクションが含まれている.

Equity

Executive Order 13985, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government [EO13985] に規定されているように, Equityとは, 黒人, ラテン系, 先住民, ネイティブアメリカン, アジア系アメリカ人, 太平洋諸島民, その他の有色人種, 宗教的少数派の人々, レズビアン, ゲイ, バイセクシャル, トランスジェンダー, クィア (LGBTQ+) の人々, 障害者, 地方に住む人々, その他根強い貧困や不平等から悪影響を受ける人々など, これまでそうした扱いを受けてこなかった, 恵まれないコミュニティに属する個人を含むすべての個人に対する一貫した体系的かつ公正で公平な扱いを意味する.

ヘルスケアなどの重要なサービスを利用する場合, オンライン Transaction に参加できるかどうかは, 多くの場合, Digital Identityを正しく安全に提示できるかどうかに依存している. 米国社会および世界的に存在する広範な格差を考慮すると, 多くの人々が Digital Identity をうまく提示できないか, またはオンラインサービスを利用する際に, より恵まれた人々よりも高い負担に直面し, 重要なサービスやオンラインの世界への幅広い参加から締め出されることになる. 公共サービスにおいては, このような状況は, ミッションを成功させるための直接的なリスクとなる. より広い社会的背景では, デジタルアクセスに関する問題は, 既存の不公平を悪化させ, 歴史的に疎外され, 十分なサービスを受けていないグループに対する排除の体系的なサイクルを継続させる可能性がある.

このガイダンスの読者は, Digital Identity システムおよびプロセスを彼らのニーズを最もよく支援する方法で設計または運用する機会を特定するために, サービスを提供する集団が直面する既存の不公平を考慮することが推奨される. 読者はまた, Digital Identity システムの設計または運用によって, 集団間の格差を含め, これらの集団経験および結果に潜在的または実際の影響を与えることを考慮するよう推奨される.

このガイドラインを実施する連邦政府機関に対し, EO 13985 は, 連邦政府機関が提供するプログラムおよびサービスについて, 十分なサービスを受けていないコミュニティを特定し, それらのプログラムおよびサービスへの公平なアクセスを提供するために, 十分なサービスを受けていないコミュニティに対する制度的障害を特定し対処するよう指示している. EO 13985 の方向性に沿って, 連邦機関は, コミュニティや個人がオンライン給付やサービスへの登録やアクセスに直面する可能性のある障壁を判断するべきである. また, Equity を高めるためにプログラムの変更が必要であるかどうかを確認する必要がある.

Usability

Usability とは, あるシステム, 製品, サービスを, 特定のユーザーが, 特定の使用状況において, 有効性, 効率性, 満足性をもって, 特定の目標を達成するために使用できる程度を指す.

Equity と同様に, Usability には Digital Identity システムまたはプロセスに触れる人々, および彼ら固有の目標や使用状況の理解が必要である. 効果的, 効率的, かつ満足のいく体験を提供するために, このガイダンスの読者は, Enrollment および Authentication のプロセスを通じて各ユーザーが行うインタラクションを考慮する全体的なアプローチを取る必要がある. Digital Identity システムまたはプロセスの設計および開発ライフサイクルを通じて, 適切な使用状況で現実的なシナリオおよびタスクを実行する代表的なユーザーに対する Usability 評価を実施することが重要である.

Digital Identity 管理プロセスは, ユーザーが正しいことを行うのは簡単で, 間違ったことを行うのは困難であり, 間違ったことが起こったときに回復するのが簡単であるように設計および実装されるべきである.

Introduction

This section is informative.

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.

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.

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.

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

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

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.

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.

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

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.

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.

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

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

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]: 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]: 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]: 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

用語定義と略語の完全なセットについては, Appendix A を参照のこと.

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 ガイドラインでは, 現在市場で入手可能な技術およびアーキテクチャを反映した Digital Identity モデルが使用されている. これらのモデルにはさまざまな主体および機能があり, 複雑さもさまざまである. 単純なモデルは, Subscriber Account の作成および Attribute の提供などの機能を 1 つの主体の下にグループ化する. より複雑なモデルでは, これらの機能をより多くの主体に分割している. Digital Identity モデルに見られる主体およびその関連機能には, 以下のものがある.

Subject (represented by one of three roles):

• Applicant — Identity Proofing される Subject
• Subscriber — Identity Proofing が完了した, または Authentication が完了した Subject
• Claimant — Authentication される Subject

Credential Service Provider (CSP): Identity サービスへの Applicant の Identity Proofing ,および Subscriber Account への Authenticator の登録を含む機能を持つ, 信頼された主体. Subscriber Account は, Subscriber, Subscriber の Attribute , および関連する Authenticator に関する CSP が確立した記録である. CSP は, 独立したサード・パーティである場合もある.

Relying Party (RP): 通常, Transaction を処理し, 情報またはシステムへの Access を許可するために, Subscriber Account の情報, または Federation を使用する場合の Identity Provider (IdP) Assertion に依存する主体.

Verifier: Authentication Protocol を使用して, Claimant が1 つまたは複数の Authenticator を所有および管理していることを検証することにより, Claimant の身元を確認する機能を有する主体. これを行うには, Verifier は Authenticator と Subscriber Account の紐づきを確認し, Subscriber Account がアクティブであることを確認する必要がある.

Identity Provider (IdP): Federated モデルにおける, CSP と Verifier の両方の機能を実行する主体. IdP は, Subscriber の Authentication と, 1つまたは複数の RP と通信するための Assertion の発行を責務とする.

Non-federated Digital Identity モデルを構成する主体および相互作用を, Figure 1 に示す. Federated Digital Identity モデルは Figure 2 に示す.

Figure 1. Non-federated Digital Identity Model Example

Figure 1 はNon-federated モデルでよく見られる相互作用のシーケンスの一例である. 他のシーケンスでも, 同じ機能要件を達成することができる. Identity Proofing および Enrollment のための通常の相互作用のシーケンスは次のとおりである.

• Step 1: Applicantは, Enrollment プロセスを通じて CSP に申請する. CSP は, そのApplicantの身元を証明 (Identity Proof) する.
• Step 2: Proofing に成功すると, Applicant は Identity サービスに Subscriber として Enrollment される.
  • Subscriber Account および対応する Authenticator が, CSP と Subscriber の間で確立される. CSP は Subscriber Account, そのステータス, および Enrollment データを維持する. Subscriber は自分の Authenticator を保持する.

Non-federated モデルにおいて, 1つまたは複数の Authenticator を使用して Digital Authentication を実行する際の, 通常の一連のやりとりは以下のとおりである.

• Step 3: RP が Claimant に Authentication を要求する.
• Step 4: Claimantは, Authentication プロセスを通じて, Authenticator の所有と管理を Verifier に証明する.
  • Verifier は CSP とやり取りして, Claimant の Identity と Subscriber Account の Authenticator の結びつきを検証し, オプションで追加の Subscriber Attribute を取得する.
  • サービスプロバイダの CSP または Verifier の機能は, Subscriberに関する情報を提供する. RP は, 必要とする Attribute を CSP に要求する. RPは, オプションとして, この情報を使用して Authorization の決定を行う.
• Step 5: Subscriber と RP の間に Authenticated Session が確立される.

Figure 2. Federated Digital Identity Model Example

Figure 2 は, Federated モデルにおける同じ共通インタラクションの例である.

• Step 1: Applicantは, Enrollment プロセスを通じてIdPに申請する. IdPは, CSP機能を用いて, Applicant の Identity Proofing を行う.
• Step 2: Proofing に成功すると, Applicant は Identity サービスに Subscriber として Enrollment される.
  • Subscriber Account と対応する Authenticator が, IdP と Subscriber の間で確立される. IdP は, Subscriber Account とその状態, および収集した Enrollment データを Subscriber Account の存続期間中 (最低限) 保持する. Subscriber は Authenticator を保持する.

Federated モデルで1つ以上の Authenticator を使用してデジタル Authentication を行う際の通常の一連のやり取りは, 以下のとおり:

• Step 3: RP は Claimant に Authentication を要求する. IdP は Federation Protocol を通じて, RP に Assertion と, オプションで追加 Attribute を提供する.
• Step 4: Claimant は Authentication プロセスを通じて, IdPの Verifier 機能に対して Authenticator の所有と管理を証明する.
  • IdP 内では, Verifier と CSP の機能が相互に作用し, Claimant の Authenticator と Claimed Subscriber Account にバインドされている Authenticator のバインドを検証し, オプションとして追加の Subscriber Attribute を取得する.
• Step 5: RP と IdP の間の Assertion を含むすべての通信は, Federation プロトコルを通じて行われる.
• Step 6: IdP は RP に Subscriber の Authentication の状況と, 関連する Attribute を提供し, Subscriber と RP の間で Authenticated Session が確立される.

どちらのモデルでも, Verifier は Authentication アクティビティ (たとえば, デジタル証明書の一部の使用など) を完了するために, 常に CSP とリアルタイムで通信する必要はない. したがって, Verifier と CSP の間の繋がりは, 2つのエンティティ間の論理的な繋がりを表している. 一部の実装では, Verifier, RP, およびCSPの機能は分散され, 分離されている場合がある. しかし, これらの機能が同じプラットフォーム上に存在する場合, 機能間のインタラクションは, ネットワークプロトコルを使用するのではなく, 同じシステム上で動作するアプリケーションまたはアプリケーションモジュール間のシグナルとなる.

いずれの場合も, RPは Claimant を Authentication する前に, CSP または IdP に必要な Attribute を要求する必要がある.

以下のセクションでは, Identity Proofing, Authentication, および Federation に関するより詳細な Digital Identity モデルについて説明する.

Enrollment and Identity Proofing

前のセクションでは, 概念的な Digital Identity モデルにおけるエンティティとインタラクションについて紹介した. このセクションでは, Identity Proofing および Enrollment プロセスに関する参加者の関係および責任についての追加的な詳細を説明する.

[SP800-63A], Enrollment and Identity Proofing は, Identity Proofing および Enrollment プロセスに関する一般情報および Normative な要件と, 各 Identity Assurance Level (IAL) に固有の要件を提供する. “No Identity Proofing” レベルである IAL0 に加えて, この文書では Identity Proofing プロセスの相対的な強さを示す 3 つの IAL を定義している.

このステージで Applicant と呼ばれる個人は, CSP に Enroll することを選択する. Applicant の Proof に成功すると, その個人はその CSP の Subscriber として Identity サービスに登録される.

次に, CSP は, 各 Subscriber を一意に識別する Subscriber Account を確立し, その Subscriber Account に登録 (バインド) されたすべての Authenticator を記録する. CSP は, 以下を行うことができる.

• Enrollment 時に, 1つ以上の Authenticator を Subscriber に発行する.
• Subscriber より提供された Authenticator をバインドする, および／または
• 必要に応じて, 後日, Subscriber Account に Authenticator をバインドする.

CSP は一般に, 文書化されたライフサイクルに従って Subscriber Account を維持する. このライフサイクルでは, Subscriber Account の状態に影響する特定のイベント, 活動, および変更が定義される. CSP は一般に, Subscriber に関連する Attribute の正確性と最新性をある程度保証するために, Subscriber Account および関連する Authenticator の有効期間を定める. ステータスに変更があった場合, または Authenticator の有効期限が近づいた場合, および更新要件が満たされた場合, Authenticator は更新および/または再発行されることがある. あるいは, CSP の文書化されたポリシーおよび手続きに従って, Authenticator が無効化され, 破棄されることもある.

Subscriber は, CSP との良好な関係を維持するために Authenticator の管理を維持し, CSP ポリシーを遵守する義務がある.

新しい Authenticator の発行を要求するために, 通常 Subscriber は, 既存の有効期限内の Authenticator を使用して CSP に対して Authentication を行う. Subscriber が有効期限切れまたは失効前に Authenticator の再発行を要求しなかった場合, 新しい Authenticator を取得するために, (完全または省略された形の) Identity Proofing および Enrollment プロセスを再度行うことが要求される場合がある.

Figure 3 に, Identity Proofing と Enrollment のためのインタラクションの例を示す.

Figure 3. Sample Identity Proofing and Enrollment Digital Identity Model

\clearpage

Authentication and Lifecycle Management

Normative な要件は, [SP800-63B], Authentication and Lifecycle Management を参照のこと.

Authenticators

Authentication システムの古典的パラダイムでは, 3つの要素を Authentication の要とする.

• Something you know (例: Password)
• Something you have (例: IDカード, Cryptographic Key)
• Something you are (例: 指紋またはその他の Biometric 特有のデータ)

Single-factor Authentication は, 上記の要素のうち1つだけを必要とし, 多くの場合 “something you know” を必要とする. 同じ要素が複数ある場合でも, Single-factor Authentication となる. 例えば, ユーザーが作成した PIN とPassword は, どちらも “something you know” であるため, 2つの要素とはみなされない. Multi-factor Authentication (MFA) とは, 2つ以上の異なる要素を使用することを指す. 本ガイドライン群の目的においては, 最高のセキュリティー要件を満たすには, 2つの要素を利用するのが適切である. RP や Verifier は Claimed Identity に対するリスク評価のために, 位置データや Device Identity など, 上記以外のタイプの情報を利用することもありうるが, それらは Authentication Factor とは見なされない.

Digital Authentication では, Claimant は1つまたは複数の Authenticator を保持, 管理する. Authenticator は Subscriber Account にバインドされている. Authenticator には, Claimant が正当な Subscriber であることを証明するために使用できる Secret が含まれている. Claimantは, Authenticator を所有し管理していることを証明することにより, ネットワーク上のシステムまたはアプリケーションに対して Authenticate を行う. Authenticate されると, Claimantは Subscriber と呼ばれる.

Authenticator に含まれる Secret は, Key Pair (Asymmetric Cryptographic Key) または Shared Secret (Symmetric Cryptographic Keys, Memorized Secret を含む) のいずれかに基づいている. Asymmetric Key Pair は, Public Key と関連する Private Key で構成される. Private Key は Authenticator 内に保存され, Authenticator を所有し管理する Claimant のみが使用できる. Public Key Certificate などを通じて Subscriber の Public Key を持つ Verifier は, Authentication プロトコルを使用して Claimant が Authenticator に含まれる関連する Private Key を所有し管理していること, すなわち Subscriber であることを Verify する.

上述したように, Authenticator に格納される Shared Secret は, Symmetric Key または Memorized Secret (例えば, パスワードやPIN)のいずれかである可能性がある. Symmetric Key も Memorized Secret も同様のプロトコルで使用することができるが, 両者の重要な違いの1つは, それらが Claimant にどのように関係するかということである. Symmetric Key は一般にランダムに選択され, ネットワークベースの Guessing Attack を阻止するのに十分な複雑さと長さを持ち, Subscriber が管理するハードウェアまたはソフトウェアに格納される. Memorized Secret は, 一般に, 暗記と入力を容易にするために, Cryptographic Key よりも文字数が少なく, 複雑でない. その結果, Memorized Secret は脆弱性が増加し, それを軽減するために追加の防御を必要とする.

Memorized Secret には, また別のタイプとして, Multi-factor Authenticator の Activation Factor として使用されるものがある. これらは Activation Secret と呼ばれる. Activation Secret は Authentication に使用される保存された Key を復号するために使用されるか, または Authentication Key へのアクセスを提供するためにローカルに保存された Verifier と比較される. いずれの場合も, Activation Secret は, Authenticator とそれに関連するユーザーエンドポイント内に留まる. Activation Secretの例は, PIV カードを Activate するために使用される PIN である.

このガイドラインで使用されているように, Authenticator は常に Secret を含むか Secret を構成している. しかし, 対面での対話に使用される Authentication 方法の中には, Digital Authentication に直接適用されないものがある. たとえば, 物理的な運転免許証は, あなたが持っているもの(something you have)であり, 人間 (例：警備員) に対して Authentication する場合には有用かもしれないが, オンライン・サービス用の Authenticator とはならない.

一般的に使用されている Authentication 方法の中には, Secret を含まない, あるいは Secret を構成しないものがあり, そのため本ガイドラインのもとでは使用できない. 例えば, 以下のようなものである.

• Claimant だけが知っていると思われる質問に回答するよう Claimant に促す知識ベース認証 (Knowledge-Based Authentication) は, Digital Authentication の Secret として認められない.
• また, Biometrics は Secret を構成しないため, Single-factor Authenticator として使用することはできない.

Digital Authentication システムは, 以下の2つの方法のどちらかで複数の要素を内包する.

1. 複数の要素が Verifier に提示される.
2. ある要素が Verifier に提示されるシークレットを保護するために利用される.

例えば, 上記1は Memorized Secret (something you know) を Out-of-band Device (something you have) と組み合わせることで実現可能である. 両方の Authenticator Output が Verifier に提示され, Claimant の Authentication に使われる. 上記2は, Authenticator と Authenticator Secret は, Claimant が管理する Cryptographic Key (something you have) を含むハードウェアの一部で, Access が指紋 (something you are) で保護されているものである. Biometric Factor と共に使用される場合, Cryptographic Key を使って Claimant を Authenticate するための Output が出力される.

上述のとおり, Biometricsは, Digital Authentication で利用可能なシークレットとはならないため, Single-factor Authentication に使用することはできない. しかし, Biometrics Authentication は, 所持ベースの Authenticator と組み合わせて使用する場合, Multi-factor Authentication の Authentication Factor として使用することができる. Biometric 特性は, Verification の時点で物理的に存在する人の Identity を確認するために使用できる, 固有の個人の Attribute である. これには, 顔の特徴, 指紋, 虹彩パターン, および声紋が含まれるが, これらに限定されない.

Subscriber Accounts

前節で説明したように, Subscriber Account は, 登録プロセスの一部として, Identifier を介して, 1つ以上の Authenticator を Subscriber にバインドする. Subscriber Account は, CSP によって作成, 保存, および維持される. Subscriber Account は, Identity Proofing プロセス中に検証されたすべての Identity Attribute を記録する.

Authentication Process

Authentication プロセスにより, RPは Claimant による自分こそ本人であるという主張を信頼することができる. Figure 4は Authentication プロセスの例を示している. その他のアプローチについては, [SP800-63B], Authentication and Lifecycle Management で説明されてる. このサンプル Authentication プロセスは, RP, Claimant,および Verifier / CSPの間のインタラクションを示す. Verifier は機能的な役割であり, Fig. 4 に示すように, CSP と組み合わせて実装されることが多いが, RP と組み合わせてもよい.

Figure 4. Sample Authentication Process

Authentication プロセスの成功は, Claimant が Subscriber の Identity にバインドされている1つ以上の有効な Authenticator を所有し管理していることを証明する. 一般に, これは Verifier と Claimant の間のインタラクションを含む Authentication Protocol を使用して行われる. インタラクションの具体的な内容は, システム全体のセキュリティを決定する上で非常に重要である. よく設計されたプロトコルは, Authentication の最中および事後において, Claimant と Verifier の間のコミュニケーションの Integrity (完全性) および Confidentiality (機密性) を保護し, Attacker が正当な Verifier であるかのように偽装できてしまった場合の被害を限定的にする.

また, Verifier 側で Attacker による Authentication 試行レートを制限したり不正な試行を遅延させたりすることで, Password や PIN といった Entropy の低いシークレットに対する Online Guessing Attack の影響を軽減できる. 一般的に Online Guessing Attack ではほとんどの試行が失敗するので, その対策は失敗試行数を制限するというような方式となる.

Federation and Assertions

Normative な要件は [SP800-63C], Federation and Assertions を参照のこと.

一般的に Federation という用語は, 異なる Trust ドメイン間の情報共有を含む多くの異なるアプローチに適用されることがある. これらのアプローチは, ドメイン間で共有される情報の種類によって異なる. 一般的な例としては, 以下のようなものがある.

• Identifier の共有 (例: 運転免許証やメールアドレスの利用),
• Authenticator の共有 (例: 複数のアプリケーションにおける PKI Authenticator の利用),
• Identity Assertion の共有 (例: OpenID Connect や SAML のような Federation Protocol),
• Account Attribute の共有 (例: SCIM のような Provisioning Protocol),
• Authorization Decisions の共有 (例: XACML のような Policy Protocol).

SP 800-63 ガイドラインは, 組織が選択する Identity Proofing, Authentication, および Federation アーキテクチャに関して全てを把握しているわけではなく, 組織が独自の要件に従って Digital Identityスキームを展開することも許容している. しかし, 組織が遭遇するシナリオには, 組織または個々のアプリケーションにローカルな Identity サービスを確立するよりも, Federation のほうが効率的かつ効果的である可能性があるものがある. 以下のリストは, 組織が Federation を有効なオプションと見なす可能性のあるシナリオの詳細を示している. これらのリストは検討のために提供されるものであり, 包括的であることは意図していない.

組織は, 以下のいずれかに該当する場合, Federated Identity Assertion を受け入れることを検討すべきである.

1. 想定される利用者が, 要求されたAAL以上の Authenticator をすでに持っている.
2. 想定されるすべてのユーザーコミュニティをカバーするためには複数のタイプの Authenticator が必要.
3. 組織に, Subscriber Account の管理をサポートするための必要なインフラがない (例：アカウントの回復, Authenticator の発行, ヘルプデスクなど).
4. RP の実装を変更することなく, プライマリ Authenticator の追加やアップグレードが可能であることが望まれる.
5. サポートすべき多くの環境がある. Federation Protocol はネットワークベースであり, 様々なプラットフォームや言語での実装が可能である.
6. 想定される利用者は複数のコミュニティから集まっており, それぞれが既存の Identity インフラを持っている.
7. アカウントの失効や新しい Authenticator のバインドなど, アカウントのライフサイクルを一元的に管理できることが重要である.

組織は, 以下のいずれかに該当する場合, Federated Identity Attributes の受け入れを検討すべきである.

1. Pseudonymity が, サービスに Access する利害関係者に要求される, 必要である, 実行可能である, または重要である.
2. サービスへの Access には, 一部の Attribute リストが必要.
3. サービスに Access するためには, 少なくとも1つの Derived Attribute Value が必要.
4. 組織は, 要求された Attribute の Authoritative Source または Issuing Source ではない.
5. Attribute は使用時 (Access 判断など) に一時的に必要となるだけで, 組織がデータを保持する必要はない.

Federation Benefits

Federated アーキテクチャには, 以下のような多くの重要な利点があるが, これらに限定されるものではない.

• ユーザーエクスペリエンスの向上. 例えば, ある個人が一度 Identity proofing すれば, 複数の RP でその Subscriber Account を再利用することができる.
• ユーザー (Authenticator の削減) と組織 (情報技術インフラの削減) 双方にとってのコスト削減.
• 組織が Personal Information を収集, 保管, 廃棄する必要がないため, アプリケーションのデータを最小化できる.
• アカウントに保存されたそのものの値を各アプリケーションにコピーするのではなく, Pseudonymous Identifier や Derived Attribute Value を使用することで, アプリケーションに公開するデータを最小化できる.
• ミッションの実現: 組織は, Identity Management へのリソースの拡大を気にすることなく, ミッションに集中することができる.

以下のセクションでは, 組織がこのタイプのモデルを選択する場合の, Federated Identity アーキテクチャの構成要素について説明する.

Federation Protocols and Assertions

Federation プロトコルでは, ネットワークシステム間で Assertion, Authentication Attribute, Subscriber Attribute を伝達することができる. Federation のシナリオでは, Figure 2 に示すように, CSP は Identity Provider または IdP と呼ばれるサービスを提供する. IdP は, CSP が発行する Authenticator の Verifier として機能する. Federation プロトコルを使用して, IdP は, この Authentication イベントに関する Assertion と呼ばれるメッセージを RP に送信する. Assertion は, Subscriberの Authentication イベントを表す, IdP から RP への検証可能な Statement である. RP は IdP から提供された Assertion を受信して使用するが, RP が Authenticator を直接 Verify することはない.

Federation は, 一般に RP と IdP が単一のエンティティでない場合, または共通の管理下にない場合に使用されるが, さまざまな理由から単一のセキュリティドメイン内でこの技術を適用することができる. RP は, Assertion 内の情報を使用して Subscriber を識別し, RP が管理するリソースへの Access に関する Authorization の決定を行う.

Assertion の例を以下に挙げる.

• Security Assertion Markup Language (SAML) Assertion はセキュリティー Assertion を記述するためのマークアップランゲージによって規定される. SAML Assertion は Verifier が RP に対して Claimant の Identity に関するステートメントを生成するために利用される. SAML Assertion にはデジタル署名が施されることもある.
• OpenID Connect Claim は, JavaScript Object Notation (JSON) を使ってセキュリティー Claim および任意でユーザー Claim を記述するために規定される. JSON User Information Claims にはデジタル署名が施されることもある.
• Kerberos Ticket は, Ticket-granting Authority が Symmetric または Asymmetric Key ベースの Key Establishment Schemes を利用し, 2つの Authenticated な主体 にSession Key を発行することを可能にする.

Relying Parties

RP は, オンライン Transaction を行うために, Authentication Protocol の結果を頼りに Subscriber の Identity ないしは Attribute に関する確からしさを確立する. RP は, Subscriber の Federated Identity (Pseudonymous なこともあればそうでないこともある), IAL, AAL, FAL およびその他の要素をもとに, Authorization の決定を行う.

Federation を使用する場合, Verifierは RP の機能ではない. Federation を利用する RP は, Verifier 機能を提供する IdP から Assertion を受け取り, その Assertion が RP の信頼する IdP から来たことを確認する. RP は, Assertion に含まれる Personal Attribute や有効期限などの追加情報も処理する. RP は, Verifier から提示された特定の Assertion が, IAL, AAL, FAL にかかわらず, RP の確立したシステム Access の基準を満たしているかどうかを判断する最終裁定者となる.

Digital Identity Model

This section is informative.

Overview

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:

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

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

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.

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.

Figure 1. Non-federated Digital Identity Model Example

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.

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

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.

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.

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.

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

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], 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.

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.

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.

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.

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.

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.

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

Figure 3. Sample Identity Proofing and Enrollment Digital Identity Model

\clearpage

Authentication and Lifecycle Management

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

Authenticators

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

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

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.

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.

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.

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.

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.

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

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.

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 Accounts

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

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.

Figure 4. Sample Authentication Process

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.

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

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

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.

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

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.

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 の Digital Identity リスクを評価するための手法の詳細を示す. このプロセスは, Federal Information Security Modernization Act [FISMA] 要件を満たすための NIST ガイダンスに基づく情報および情報システムの Risk Management プロセスを補強するものである.

Digital Identity の Risk Management には4つのステップが存在する.

1. 初期 Impact Assessment の実施. このステップでは, 組織はユーザー母集団を評価し, 定義された影響カテゴリーのセットに対して, 保護対象のアプリケーションまたはサービスに対する Identity システムの各機能 (例えば Proofing, Authentication, Federation) の障害がもたらす影響を評価する. このステップの成果は, 文書化された一連の影響カテゴリーと関連する影響レベルである.

1. 初期 Assurance Levels の選択: このステップでは, アプリケーションを保護するための適切な Assurance Level を決定するために, 影響カテゴリーと影響度の評価を行う. このステップの成果は, 該当する各 xAL の特定された初期レベルである.

1. Assurance Level の決定の調整と文書化: このステップでは, Privacy, Equity, Usability, 及び脅威に関する詳細なアセスメントを実施し, 最初に選択した Assurance Level が, アプリケーションの特定のユーザー母集団及び脅威環境に与えうる影響を判断する. 最初の Assurance Level は調整され, 補償または補足のコントロールが特定され, すべての決定が文書化される. 成果は, 実装可能な Assurance Level を定義した Digital Identity Acceptance Statement (Sec. 5.3.4 参照) となる.

1. 継続的な評価と改善: このステップでは, 組織のニーズと進化する脅威ベクトルに基づく, 多様な事実に基づく Identity システムのパフォーマンスに関する情報が収集される. この情報は, 選択した Assurance Level およびコントロールがミッション, ビジネス, およびセキュリティのニーズを満たしているかどうかを判断し, 生じている可能性のある意図しない被害を監視するために使用される. このステップの成果は, パフォーマンス指標, 評価および救済のための文書化された透明性のあるプロセス, および必要に応じた Identity システムの継続的な改善である.

“段階的” アプローチとして提示されているが, 最初のタスクの実行とタスクの再検討の間の反復サイクルの必要性など, プロセスには順次順序からの分岐を必要とする多くのポイントが存在し得る. 例えば, 評価を進めている最中に新しい規制や要件が導入された場合, 組織はプロセスのステップを再検討する必要が生じることがある. さらに, 新しい機能, データ使用の変更, および脅威環境の変更により, 組織はいつでも Digital Identity Risk Management プロセスのステップを再検討する必要が生じる可能性がある.

組織は, 組織のプロセス, ガバナンス, 及び企業 Risk Management のプラクティスとの統合に合わせて, この全体的なアプローチを適応及び修正すべき(SHOULD)である. 最低限, 組織は, 運用方法や実現手段にかかわらず, 各ステップを確実に実行し, 各ステップの normative な義務及び成果を完了し, 文書化しなければならない (SHALL).

Conduct Initial Impact Assessment

初期影響分析の目的は, RP アプリケーションまたはサービスに固有の Identity Proofing, Authentication, および Federation における障害の潜在的な悪影響を特定し, 最初の Assurance Level のセットをもたらすことである. これらの分野を個別に評価することにより, 組織は, ミッション目標を成功させるために最も有効な Digital Identity サービスを開発または獲得する上で, 最大限の柔軟性を得ることができる.

影響調査の内容は以下の通り:

• 影響を受ける主体の特定,
• 被害を評価する対象となる一連の影響カテゴリーの特定,
• 影響カテゴリーのそれぞれについて, 潜在的な被害を特定,
• 障害が発生した場合に, それらの潜在的な被害が与える影響のレベルの特定, ならびに
• 各タイプの障害 (Proofing, Authentication, Federation) の影響の評価と, 影響を受けるすべての主体への影響レベルの評価.

この Assessment のアウトプットは, 起こりうる障害の種類ごとに定義された影響度 (高, 中, 低) である. これは, 最初の Assurance Level を選択するための主要なインプットとなる.

Identify Impacted Entities

影響を評価するとき, 組織は検討中のアプリケーションまたは Transaction によって影響を受ける主体を決定する必要がある. このガイドラインで前述したように, Digital Identity システムの障害によって生じる異なる主体への影響を考慮することが不可欠である. 特に重要なのは, 個人に対する潜在的な影響を, 企業の影響と並んで考慮することである.

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

この活動の成果は, 影響を評価する検討中の申請または取引の対象となる主体のリストである.

Identify Impact Categories and Potential Harms

Digital Transaction の初期 Assurance Level は, 少なくとも以下の各カテゴリーの潜在的な影響を評価することにより決定されなければいけない(SHALL).

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

被害とは, ある主体が経験するであろうあらゆる有害な影響のことである. 被害は, 影響分類をより効果的に理解するための手段であり, 影響分類がその用途に関連する特定の主体にどのように適用され得るかを示すものである. 機関は, 影響度分析をより適切に行うため, 定義された影響度分類のそれぞれについて, 具体的な被害を検討すべきである(SHOULD). 各区分に対する損害の特定は, 「主体の特定」プロセスで特定された各主体に対して行われなければいけない(SHALL).

各カテゴリーに関連する被害の例としては, 以下のものが挙げられるが, これらに限定されるものではない.

Damage to mission delivery / ミッション遂行に対する損害

• 個人に対する被害には, 本来受けられるはずの行政サービスや 福利厚生が受けられなくなることが挙げられる.
• 組織に対する被害には, 現在のミッション／ビジネス機能を, 十分な信頼性及び／又は正確性をもって, 計画されたリソースの制約の範囲内で, 十分にタイムリーに実行できないこと, 又は将来的にミッション／ビジネス機能を実行できないこと, 若しくは能力が限定されることが挙げられる.

Damage to trust or reputation / 信用や評判に対する損害

• 個人に対する被害には, なりすましやイメージ・評判の悪化などが挙げられる.
• 組織に対する被害には, 信頼関係, イメージ, または評判 (将来的, 潜在的な信頼関係を含む) の低下が挙げられる.

Loss of sensitive information / 機密情報の損失

• 個人に対する被害には, PII やその他の機密情報の損失が含まれ, その結果, 経済的安定の損失, 生命の損失, 身体的または心理的傷害, なりすまし, Identityの盗難, または持続的な不都合などの二次的被害が挙げられる.
• 組織に対する被害には, 知的財産や, 機密資料や管理された非機密情報 (Controlled Unclassified Information / CUI) などの情報資産の損失や劣化が挙げられる.

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 / 法律, 規制, 契約上の義務のすべて, または一部の不履行

• 個人に対する被害には, 地域・州・連邦の法律, 規制, 契約上の義務のすべてまたは一部の違反による, 経済的安定, 安全, プライバシー, 市民の自由, Equity, Usability のすべてまたは一部への損害や損失が挙げられる.
• 組織に対する被害には, 適用される法律, 規制, 契約上の要件, または他の拘束力のある契約における他の要件の不遵守に起因する金銭的コスト, 制裁, 責任などが挙げられる.

この活動の成果は, 特定された主体への影響を評価するために使用される影響カテゴリーと被害のリストとなる.

Identify Potential Impact Levels

Digital Transaction の Assurance Level は, Sec. 5.1.2 の各カテゴリーで障害が発生した場合の影響を, 以下の潜在的影響値のいずれかを用いて評価することで決定される.

1. 潜在的影響 Low: 悪影響が限定的であると予想される場合
2. 潜在的影響 Moderate: 重大な悪影響を及ぼすと予想される場合
3. 潜在的影響 High: 深刻または壊滅的な悪影響を及ぼすと予想される場合

注: Identity システムの障害がカテゴリに測定可能な結果をもたらさない場合は影響はない.

各 Assurance Level, IAL, AAL, および FAL (Federated Identityを受け入れる, または Asserting する場合) は個別に評価しなくてはいけない(SHALL). 理想的には, どのような評価にも, 個人, 組織, 他の組織, および国に対する被害など, 組織のミッションを成功裏に遂行するために適用可能なさまざまな視点が含まれるようにする. 各カテゴリーにおける潜在的な影響の例としては, 以下が挙げられる.

Damage to mission delivery:

• Low: 最悪の場合で, 連邦政府が資金提供するプログラムに参加する個人と, 参加資格はあるが参加できない個人との間にわずかな結果の格差が存在すること, または組織の運営や資産, あるいは公共の利益に限定的な悪影響がある場合. 限定的な悪影響の例としては, 組織がその主要機能の有効性を顕著に低下させても遂行できる範囲と期間のミッション能力の低下, または組織の資産や公共の利益に対する軽微な損害が挙げられる.

• Moderate: 最悪の場合で, 連邦政府が資金提供するプログラムに参加する個人と, 参加資格はあるが参加できない個人との間に結果の格差が明らかになる, または, 組織の運営や資産, あるいは公共の利益に深刻な悪影響が及ぶ場合. 深刻な悪影響の例としては, 組織がその主要機能を著しく低下した状態で遂行できる範囲と期間の重大な任務能力の低下, または組織の資産や公共の利益に対する重大な損害が挙げられる.

• High: 地域社会全体で成果の格差が続いており, 連邦政府が資金提供するプログラムへの参加に対する排除, 回避, その他の障壁の体系的パターンを示している場合, または組織の運営や資産, あるいは公共の利益に深刻または壊滅的な悪影響を及ぼしている場合. 深刻または壊滅的な影響の例としては, 組織が1つ以上の主要機能を果たせないほど深刻な任務能力の低下または喪失, あるいは組織の資産または公共の利益に対する大きな損害が挙げられる.

Damage to trust and reputation:

• Low: 最悪の場合で, いかなる主体に対しても, 限られた短期間の不便, 苦痛, 困惑を与える場合.

• Moderate: 最悪の場合で, 短期的または限定的な重大な不便, 苦痛, または主体の地位や評判に対する損害が発生する場合.

• High: 主体の地位や評判に深刻なまたは重大な長期的不便, 苦痛, または損害が発生する場合. これは通常, 特に深刻な影響を及ぼす状況, または多くの個人に影響を及ぼす可能性のある状況にのみ適用される.

Loss of sensitive information:

• Low: 最悪の場合で, [FIPS199] で定義されているように, Personal Information, 米国政府の機密情報, 商業上の機密情報が権限のない者に限定的に開示され, 影響が少なく Confidentiality (機密性) が損なわれる場合.

• Moderate: 最悪の場合で, [FIPS199] で定義されているように, Personal Information, 米国政府の機密情報, 商業上の機密情報が不正な者に漏洩し, Confidentiality (機密性) が失われ中程度の影響を与える場合.

• High: Personal Information, 米国政府の機密情報, 商業上の機密情報が不正に流出し, [FIPS199] に定義されているように, 高い影響を与える Confidentiality (機密性) の喪失をもたらす場合.

Damage to or loss of economic stability:

• Low: 最悪の場合で, いかなる主体にとっても, 軽微な, あるいは重要でない金銭的損失となる場合
• Moderate: 最悪の場合で, いかなる主体にとっても深刻な経済的損失となる場合
• High: いかなる主体に対しても, 深刻または破滅的な金銭的損失となる場合

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

• Low: 最悪の場合で, 自然治癒し, 精神衛生を含む医学的治療を必要としない軽傷または急性の健康問題, プログラム運用が行われる地域での環境影響の限定的なリスクの場合
• Moderate: 最悪の場合で, 軽傷の中程度のリスク, または精神衛生を含む医療処置を必要とする傷害の限定的なリスク, または複数の低影響事象の複合的影響, プログラム運用が行われる地域での環境影響の中程度のリスクの場合
• High: 重傷, 外傷, 死亡のリスク, または複数の中程度の影響の複合的影響, プログラム運用が行われる地域での環境影響が高リスクの場合

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

• Low: 最悪の場合で, 通常は執行努力の対象とならない性質の民事上または刑事上の違反のリスク, あるいは最悪の場合で, 軽微なまたは重大でない組織上の責任が生じる場合.
• Moderate: 最悪の場合で, 強制捜査の対象となる民事・刑事上の違反のリスク, あるいは深刻な組織責任を負うことになる場合.
• High: 執行プログラムにとって特に重要な民事上または刑事上の違反, あるいは深刻なまたは壊滅的な組織の責任となるリスクがある場合.

Impact Analysis

影響分析により, Identity Proofing, Authentication, および Federation プロセスによってどの程度までリスクを軽減しなければならないかが決定される. こういった決定は, リスク明確化に役立つ技術への欲求を引き起こすものではなく, 適用可能な技術とリスク軽減策の選択を推進するものである.

ユーザーの Asserted Identity の適切な Assurance Level を決定するため, 各組織は潜在リスクを評価し, その影響を最小限に抑える手段を特定する必要がある (SHALL). 組織は, 各 Transaction に必要な Assurance Level を決定するために, Identity Proofing, Authentication, および Federation の障害のリスクを個別に評価する. このプロセスには, Sec. 5.1.1 に記載されているように, Digital Identity システムの影響を受ける異なる主体に対する潜在的に異なる被害の影響を考慮することが含まなくてはいけない(SHALL). ビジネス・プロセス, ポリシー, および技術は, リスクの軽減に役立つ場合がある. 主体は, Identity Proofing, Authentication, および Federation に関連する特定の障害モードの影響を考慮するべきである(SHOULD) (ただし, これらに限定されない).

Identity Proofing:

• サービスを異なる Subject に提供してしまうことによる影響. (例: Attacker が他人になりすませてしまう)
• Identity Proofing の過程で Subject が受ける偏見を含む障壁のために, 適格な Subject にサービスが提供されないことによる影響.
• Identity Proofing プロセスをサポートするための過剰な情報収集と保持の影響.

Authentication:

• 誤った Subject を Authenticating した場合の影響 (例: Attacker が Authenticator を不正に利用する, または盗むなど).
• Subject が Authenticator を提示する際に直面する偏見などの障壁により, 正しい Subject の Authenticate に失敗した場合の影響.

Federation:

• 誤った Subject がアプリケーション, システム, またはデータへのアクセスに成功した場合の影響 (例: Assertionの侵害や Replay など).
• Subscriber Attribute を誤ったアプリケーションやシステムに開示した場合の影響.

Table 1 のようなワークシートを使用すると, 分析を完了するために収集した情報をまとめる際に組織を支援することができる. この種の分析は Digital Identity システムとインタラクションする主体に対する全体的なリスクを判断するために, Identity Proofing, Authentication, および Federation に対する潜在的な障害の種類ごとに行うことになる.

Table 1 Impact Categories

このステップの成果は, Identity Proofing, Authentication, および Federation の失敗に対する影響レベルを定義したもので, 最初の Assurance Level 選択の主要な入力として機能するものである.

Select Initial Assurance Levels

影響分析は, Identity Proofing, Authentication, および Federation の初期 Assurance Level を選択するプロセスの主要な入力として機能する. Assurance Level は各エリアでの障害の潜在的な影響の分析に基づいて, これらのエリア間で異なる場合がある. これらの初期 Assurance Level の目的は, [SP800-63A], [SP800-63B], および [SP800-63C] の付属巻の要件およびガイドラインに反映される, 基本的な Digital Identity 制御およびプロセスを識別することであり, これらはミッションの必要性, サイバーセキュリティリスク, および組織と Digital Identity システムのユーザーに対するその他の潜在的な影響に基づいて評価および調整される.

Assurance Levels

組織 RP は, サイバーセキュリティリスクとミッションの必要性に基づいて, 以下の個々の初期 Assurance Level を選択しなければならない(SHALL).

• IAL: 個人の Identity を確信を持って決定するための Identity Proofing プロセスの頑強性. IAL は潜在的 Identity Proofing の失敗を軽減することを目的に選択される.
• AAL: Authentication プロセス自体, および Authenticator と特定個人の識別子の紐付けの頑強性. AAL は Authentication 失敗を軽減することを目的に選択される.
• FAL: IdP から RP に Authentication および Attribute 情報 (該当する場合) を伝達するために使用される Federation プロセスの頑強性. すべての Digital システムが Federated Identity アーキテクチャーを採用する訳ではないため, FAL はオプションである. FAL は Federation の失敗を軽減することを目的に選択される.

xAL Descriptions

Identity, Authenticator, Federation Assurance Level の概要はそれぞれ以下にまとめる.

総称的ないしは一括で扱う場合, 本ガイドラン群では IAL, AAL, FAL を xAL と呼ぶこととする.

Identity Assurance Level

IAL1: IAL1 は, Authoritative または信用できる Source に対して識別に用いられる Attribute の Validation, および Applicant の Claimed Identity を検証するための基本的なプロセスの使用を必要とする.

IAL2: IAL2 は, 識別に用いられる Attribute が強力な証拠によって裏付けられ, Authoritative または信用できる Source によって検証され, Applicant の Claimed Identity を検証するプロセスの使用を必要とする.

IAL3: IAL3 は, 認定された CSP 担当者が, CSP 担当者との対話型プロセスを使用した物理的な文書の検査を通じて, 識別に用いられる Attribute を検証することを必要とする.

Authentication Assurance Level

AAL1: AAL1 では, Claimant が Subscriber に紐づく Authenticator を管理下に置いていることが, ある程度の確からしさで確認できる. AAL1 では Single-factor Authentication が必須となり, そこでは幅広い Authentication 技術が利用可能である. Authentication を成功させるには, Claimant がセキュアな Authentication Protocol を通じて Authenticator を保持・管理していることを証明する必要がある.

AAL2: AAL2 では, Claimant が Subscriber に紐づく Authenticator を管理下に置いているということが, 高い確度で保証される. セキュアな Authentication Protocol によって, 2つの異なる Authentication Factor を保持・管理していることを証明する必要がある. AAL2 以上では, Approved Cryptographic テクノロジーも必要となる.

AAL3: AAL3 では, Claimant が Subscriber のアカウントに紐づく Authenticator を管理下に置いているということが, 非常に高い確度で保証される. AAL3 の Authentication は, Phishing 攻撃にも耐えられる Cryptographic Authentication Protocol を用いて, Key の所有を証明することにより行われる.

Federation Assurance Level

FAL1: FAL1 は, Subscriber が IdP からの Assertion を使用して RP にログインすることを可能にし, RP はそれが IdP からのものであり, 特定の RP を対象としていることを検証することができる. Assertion は, Attacker による変更や作成から保護されている. IdP と RP の間の信頼関係の合意 (Trust Agreement) および登録 (Registration) は, 動的に行うことができる.

FAL2: FAL2 では, Assertion が RP でのインジェクションに対して頑強であるという要件が追加される. 一つの手段としては, ブラウザのような仲介者を通さずに, IdP から RP に直接 Assertion を提示することが挙げられる. IdP と RP の間の信頼関係の合意 (Trust Agreement) を動的に行うことはできないが, 特定の IdP と RP の動的な登録 (Dynamic Registration) は実行時に行うことができる.

FAL3: FAL3は, Authentication Assertion の提示とともに, Subscriber にバインドされた Authenticator を使用して RP に直接 Authenticate させるという要件を追加している. この追加 Authenticator の存在により, RPにアクセスする主体が Assertion で識別された主体であることが, RPに対して非常に強く保証される. 信頼関係の合意 (Trust Agreement) および登録 (Registration) は, 動的に行うことはできない.

Initial Assurance Level Selection

Identity Proofing, Authentication, および Federation プロセスにおける障害の潜在的影響の特定と評価は, 組織の Digital Identity Risk Management プロセスおよびこれらの分野の Assurance Level の初期選択に役立つ. これらの初期選択は主にサイバーセキュリティリスクに基づくが, ミッションのニーズおよび組織, ユーザー, ミッションパートナーに対するその他の潜在的影響に基づいて調整される.

組織は, Digital Identity 障害の潜在的な影響に基づいて初期 Assurance Level を選択するためのプロセスおよびガバナンスモデルを構築し, 文書化しなければならない(SHALL). このセクションでは, そのプロセスに含めるべき主な要素に関するガイダンスを提供する.

Selecting Initial IAL

IAL は Applicant が Claimed real-life Identity を保持しているという Level of Assurance を表す. 組織は, リスクベースのアプローチを使用して, RP アプリケーションに最も適切な Identity Proofing 要件を選択するべきである(SHALL). Sec. 5.3.1に記載されている影響分析が, 最初の IAL 選択の情報源となる. この初期選定は, 最終的な IAL の決定を行う前に, Sec. 5.3 に記載されているように, ミッションのニーズ, リスク耐性, Privacy, Equity, Usability への潜在的な影響に基づいて調整されなければならない(SHALL).

Identity Proofing は CSP の機能であるため, IALの選択では RP アプリケーションのオーナーが自ら Proofing を行う必要があることを意味しない.

すべての RP アプリケーションで Identity Proofing が必要になるわけではない. RP アプリケーションが Digital Transaction の実行に Personal Information を必要としない場合, システムは RP アプリケーションの利用者の Identity Proofing を行わずに動作することができる. Personal Information が必要な場合, RP は検証された Attribute が必要か, Self-asserted Attribute が許容されるかを判断する必要がある. Self-asserted Attribute を受け入れることによる潜在的な被害が軽微であれば, システムは利用者の Identity Proofing を行わずに運用することも可能である. このような場合, [SP800-63A] に記述された Identity Proofing プロセスは, システムに適用されない.

組織が Identity Proofing が必要であると判断した場合, 最初の IAL は Identity Proofing の失敗の潜在的な影響に基づいて評価しなければならない(SHALL). Sec. 5.1 に記載されているように, RP アプリケーションの使用または操作によって発生する被害について, 組織, 個人, 他の組織, および国の観点から潜在的影響を考慮しなければならない(SHALL). 組織は悪影響を受けないかもしれないが, ユーザーは大きな損害を受ける可能性があり, サービスプロバイダの商習慣によってプライバシーや他の権利を侵害された個人も同様である. 組織は, RP アプリケーションの全体的な影響度を特定する際に, 最悪のケースを考慮すべきであるが, 影響度が異なる場合は, Risk Management Process を使用して最初の選択を調整すべきである(SHOULD).

RP アプリケーションの全体的な影響レベルを評価する場合, 組織はミッション遂行への影響を他の影響カテゴリーとは別に検討するべきである(SHOULD). ミッション遂行で被害につながる可能性のある Identity Proofing プロセスの潜在的な失敗は, より厳密な Identity Proofing プロセスの実装によって関連する影響が緩和または悪化するかどうかを判断するために, 組織で評価する必要がある. そのため, 組織は, RP アプリケーションの全体的な影響レベルを最初に特定する際に, ミッション遂行のカテゴリを除外してもよい(MAY).

組織が評価した全体的な影響度から, IALを予備的に選択し, そこからさらに調整を行うことができる.

• 影響度 Low: IAL1
• 影響度 Moderate: IAL2
• 影響度 High: IAL3

予備的な選択は Identity Proofing プロセスにおける失敗のより大きな潜在的影響は, より高い保証プロセスによって軽減されるはずであると想定している. このようなケースはよくあるが, 組織は影響分析の一部として特定された特定の障害, 影響カテゴリー, および影響を受ける主体を考慮し, 追加の調整が正当化されるかどうかを判断する必要がある. たとえば, 正当な Applicant の登録に失敗すると過度の被害につながる可能性がある場合, 組織はより低い保証の Identity Proofing プロセスが適切であるかどうかを評価する必要がある.

このプロセスの成果は, 追加の調整も含めて, IALの初期評価となり, Sec. 5.3 で説明されているように, 追加の潜在影響に対して評価されることになる.

Selecting Initial AAL

AAL は, Claimant が本人であるという Authentication プロセスによる Level of Assurance を表す. 組織は, リスクベースのアプローチを使用して, RP アプリケーションに最も適切な Authentication 要件を選択しなくては行けない(SHALL). Sec. 5.1.3 で説明されている影響分析が, 最初の AAL 選択の判断材料となる. この最初の選択は, 最終的な AAL の決定を行う前に, Sec. 5.3 に記載されているように, ミッションのニーズ, リスク耐性, Privacy, Equity, Usability への潜在的な影響に基づいて調整しなくてはいけない(SHALL).

AALを選択することは, RP アプリケーションのオーナーが自ら Authenticator を発行する必要があることを意味するものではない.

初期 AAL は, Authentication 失敗の潜在的な影響に基づいて評価されなければならない(SHALL). Sec. 5.1 に記載されているように, RP アプリケーションの使用または運用に よって発生する被害については, 障害による被害レベルが主体間で大きく異なる可能性があるため, 組織, 個人, 他の組織, 国の観点から潜在的影響を考慮しなければならない(SHALL). 組織は RP アプリケーションの全体的な影響レベルを特定する際に, 最悪のケースを考慮すべきであるが, 影響が異なる場合には Risk Management プロセスを使用して最初の選択を調整すべきである(SHOULD).

RP アプリケーションの全体的な影響レベルを評価する場合, 組織は, ミッション遂行への影響を他の影響カテゴリとは別に検討するべきである(SHOULD). Authentication プロセスにおける潜在的な失敗がミッション遂行に害を及ぼす可能性がある場合, 組織は, より厳格な Authentication 管理の実施により, 関連する影響が緩和または悪化するかどうかを判断するために評価する必要がある. このため, 組織は, RP アプリケーションの全体的な影響レベルを最初に特定する際に, ミッション遂行カテゴリーを除外してもよい(MAY).

組織が評価した全体的な影響度から, AALを予備的に選択し, そこからさらに調整を行うことができる.

• 影響度 Low: AAL1
• 影響度 Moderate: AAL2
• 影響度 High: AAL3

予備的な選択では, Authentication プロセスの失敗による潜在的な影響が, より高い保証のプロセスによって軽減されるはずであると想定している. このようなケースはよくあるが, 組織は, 影響度分析の一部として特定された具体的な障害, 影響カテゴリー, 影響を受ける主体について検討し, 追加的な調整が必要であるかどうかを判断する必要がある. さらに, 組織は Digital サービスを管理する法的, 規制的, または政策的な要件を考慮する必要がある. たとえば, 「デジタルアプリケーションを通じて市民が個人データにアクセスできるようにするすべての組織は, 複数の Authentication 要素を使用することを義務付ける」という [EO13681] の条件は, AAL2 または AAL3 の選択を推進することになる.

このプロセスの成果は, 追加的な調整も含めて, AALの初期評価となり, Sec. 5.3で説明されているように, 追加の潜在影響に対して評価されることになる.

Selecting Initial FAL

FAL は, Authentication プロセスの結果および関連する Identity 情報を RP システムに伝える Identity Assertion の Level of Assurance を表す. 組織は, リスクベースのアプローチを使用して, RP アプリケーションに最も適した Federation 要件を選択しなければならない(SHALL). Sec. 5.3.1 に記載されている影響分析が, 最初の FAL 選択の判断材料となる. この最初の選択は, 最終的な FAL の決定を行う前に, Sec. 5.3 に記載されているように, ミッションのニーズ, リスク耐性, Privacy, Equity, Usability への潜在的影響に基づいて調整されなければならない(SHALL).

初期の FAL は Federated Identity アーキテクチャにおける Assertion の提示または受け入れにおける失敗の潜在的な影響に基づいて評価されなければならない(SHALL). 侵害の例としては, Assertion Replay による有効なユーザーへのなりすましや, ブラウザを介した Assertion 情報の漏洩がある. Sec. 5.1 に記載されているように, RP アプリケーションの使用または操作によって発生する被害について, 組織, 個人, 他の組織, 国の観点から潜在的な影響を検討しなくてはいけない(SHALL). これは, 障害による被害レベルがこれらの主体間で大幅に異なる可能性があるためである. 組織は, RPアプリケーションの全体的な影響レベルを特定する際に, 最悪のケースを考慮すべきであるが, 影響が異なる場合には, Risk Management プロセスを使用して最初の選択を調整することができる.

RP アプリケーションの全体的な影響度を評価する場合, 組織は, ミッション遂行への影響を他の影響カテゴリーとは別に検討すべきである(SHOULD). ミッションの遂行に害を及ぼす可能性のある Federated アーキテクチャの潜在的な障害は, 組織が評価し, ID プロバイダによるより厳格な管理の実施によって関連する影響が緩和または悪化するかどうかを判断してもよい(MAY). このため, 組織は, RP アプリケーションの全体的な影響レベルを最初に特定する際に, ミッション遂行の影響カテゴリーを除外することができる. これらの影響は, 調整プロセスで考慮する必要があるためである.

組織が評価した全体的な影響度から, FALを予備的に選択し, そこからさらに調整を行うことができる.

• 影響度 Low: FAL1
• 影響度 Moderate: FAL2
• 影響度 High: FAL3

予備的な選定では, Federated Identity アーキテクチャにおける障害の潜在的な影響は, より高い保証プロセスによって軽減されるはずであると想定している. このようなケースはよくあるが, 組織は, 影響分析の一部として特定された特定の障害, 影響カテゴリー, および影響を受ける主体を考慮して, 追加の調整が正当化されるかどうかを判断する必要がある.

このプロセスの成果は, 追加的な調整も含めて, FALの初期評価となり, Sec. 5.3 で説明するように, 追加の潜在影響に対して評価されることになる.

Tailor and Document Assurance Levels

調整は, 最初に評価した Assurance Level を修正し, または継続的な詳細な影響と Risk Assessment に基づき, 代替の管理策を実施するプロセスを提供する. 組織は, このガイドラインで定義された評価済み Assurance Level を実施するべきである(SHOULD). しかし, 本ガイドラインは, 組織が特定のミッションのニーズを満たし, 独自のリスク選好及び考慮事項に対処できるよう, 柔軟性を提供するものである. したがって, 組織は, xALの調整プロセスを確立し, 文書化しなければならない(SHALL). 最小限のこのプロセスは以下の通り:

1. SHALL 意思決定と対立の解消を可能にするために, 構造化されたガバナンスのアプローチを含める
2. SHALL 評価された xAL, 修正された xAL, および Digital Identity Acceptance Statement (Sec. 5.3.4 参照) の補償管理を含む, 調整プロセスのすべての決定を文書化する
3. SHALL Digital Identity Acceptance Statement (Sec. 5.3.4 参照) において, 当初評価した xAL に対するすべてのリスクベースの決定または修正の正当性を証明し文書化する.
4. SHOULD 調整プロセスにおける xAL 選択の影響に関する主題分析をサポートするために, 部門横断的な能力を確立する
5. SHOULD 選択された xAL コントロールの影響を評価するために, 実際の運用データを取り入れた継続的なプロセスであること

調整プロセスは, システム, データ, サービスを保護するために, リスクと影響のバランスを取るための構造的な手段を推進するもので, ミッションを成功させるとともに, Equity, Privacy, Usability をサポートする.

Assess Privacy, Equity, Usability and Threats

特定のアプリケーション向けに Assurance Level を選択及び調整する場合, プロセスに対するインサイト及びインプットは, 最初の静的な影響評価を超えて行われることが重要である. 最初の Assurance Level から最終的な xAL の選択及び実施に移行する際, 組織は Assurance Level で定義されたコントロールについて詳細なアセスメントを実施し, 運用環境における潜在的な影響を判断しなければならない(SHALL). 少なくとも, 組織は以下の領域に関する影響を評価しなければならない(SHALL).

• Privacy – 評価された xAL での管理の対象となる個人, および Digital Identity の確立, 管理, または Federation に関連する組織または第三者の慣行の影響を受ける個人の Privacy に対する意図しない結果生じるかどうかを判断すること
• Equity – 統制の実施により, 人々の属性やユーザーグループ間で不公平が生じたり, その状態が継続したりする可能性がないかどうかを判断すること
• Usability – 選択したコントロールの実施により, エンドユーザー・エクスペリエンスに課題が生じるかどうかを判断すること
• Threat – 環境, 脅威要因, 既知の戦術, 技術, 手順 (TTPs) に基づき, 定義された Assurance Level が特定の脅威に対応できるかどうかを判断すること

さらに, 組織は, ここに記載されていないミッションやドメイン特有の考慮事項を完全に把握するために, 必要に応じて追加のビジネス固有のアセスメントを実施するべきである(SHOULD). これらの評価は, Sec. 5.3.2 及び Sec. 5.3.3 に定義されているように, 補償または補足の管理まで拡張しなくてはいけない(SHALL).

Identify Compensating Controls

代替策とは, 定義されたxALの推奨されているものの代わりに組織が採用する管理, 運用, 又は技術的な対策である. これらは, 可能な限り, 基準策が対処しようとするリスクと同じリスクに対処することを意図している.

組織は, 調整された Assurance Level に対して, このガイドラインの要件に従って Identity サービスを実装するべきである(SHOULD). ただし, 組織がベースラインまたは調整済み Assurance Level に関連する特定の制御を実装できない場合は, 代替策を実装することを選択してもよい(MAY). この対策は, このガイドラインで定義された Digital Identity プロセスの修正であってもよいが, アプリケーション, Transaction, またはサービスのライフサイクルの他の場所に適用してもよい. たとえば, 次のようなものである:

• 連邦機関は, このガイドラインに基づく Authoritative Sources による Identity Evidence の検証要件を補うために, Personal Identity Verification [FIPS201] で参照される連邦バックグラウンド調査およびチェックを使用することを選ぶことができる.
• 組織は, エンドユーザー母集団にとって利用可能な Evidence の制約により, より弱い形式の Identity Evidence を使用した検証プロセスを許容している支払アプリケーションについて, より厳しい監査および Transaction 審査プロセスを実施することを選択できる.

代替策を実施する場合, 組織は選択した代替案の比較可能性を証明するか, または Normative 要件から逸脱することによって生じる残留リスクを文書化しなければならない(SHALL). 組織は Normative 要件からの逸脱の正当な理由と, 採用した代替策の詳細を文書化する手順を実施しなければならない(SHALL). 代替となる管理策を含めることは, 組織がより低い xAL に合わせなければならないことを意味するものではない. 調整プロセスにより, 機関およびサービスプロバイダは, xAL の実装方法についてリスクに基づく決定を下すことができ, Sec. 5.3.4 に記載されている Digital Identity Acceptance Statement を通じて決定を文書化し伝達するためのメカニズムが提供される.

Identify Supplemental Controls

補足的な対策とは, 特定の脅威または攻撃に対処するために, 組織が調整した Assurance Level で指定されたものに加えて追加することができるものである. 組織は, 基本的な管理策では対処できない脅威を特定した場合, 補足的な管理策を特定し, 実施すべきである(SHOULD). たとえば, 次のようなものである:

• Proofingプロセスを完了するための不正な試行が多発しているため, 組織は Assurance Level で要求される以上の追加の Identity Evidence に対してエンドユーザーを検証することを選択することができる.
• アクセス試行が特定のリスク要因を示す場合, ユーザーの Identity を確認するために, 組織はリスクスコア分析を実装して re-proofing 機構と組み合わせることを選択することができる.

組織が補足的な対策を導入する場合, 組織の Assurance Level を調整するために使用したのと同じ要素に基づき, これらの影響について評価しなくてはいけない(SHALL). 補足的な対策は文書化しなければならない.

Document Results - The Digital Identity Acceptance Statement

Digital Identity Acceptance Statementは, Digital Identity Risk Management プロセスの結果を文書化したものである. これには, Impact Assessment, 初期 Assurance Level の選択, および調整プロセスが含まれる.

Statement には, 最低限, 以下を含めること:

1. 初期影響調査の結果
2. 初期の xAL 評価,
3. 調整された xAL と当初評価された xAL が異なる場合, 調整されたxALとその根拠,
4. すべての代替策とその比較可能性, または代替策に関連する残存リスク
5. すべての補足的な対策

連邦政府機関は, この情報を [SP800-37] に記載されているシステム Authorization パッケージに含めるべきである(SHOULD).

Continuously Evaluate and Improve

脅威をもたらす主体は適応し, ユーザーの期待とニーズは変化し, ミッションは進化する. このように Risk Assessment と Identity ソリューションは, 定められたあとに忘れ去られるものではない. 常に変化する環境に対応するために, 組織は Identity システムとインタラクションする人々からのインプットを活用する継続的な評価および改善プログラムを実施するべきである(SHOULD). これらのプログラムは, アプリケーション・パフォーマンス測定基準, 脅威インテリジェンス, 不正分析, Equityへの影響の評価, Privacy 影響分析, およびユーザーの入力からのフィードバックを考慮すべきである(SHOULD).

Cyber, Fraud, and Identity Program Integrity

通常, Identity ソリューションは, 重要なビジネスまたはサービス機能のフロントドアである. したがって, 孤立した状態で運用するべきではない. Identity 機能をサイバーセキュリティ・チーム, 脅威インテリジェンス・チーム, およびプログラム・インテグリティ・チームと緊密に連携させることにより, ビジネス機能をより完全に保護し Identity ソリューション機能を常に向上させることができる. たとえば, プログラム・インテグリティ・チームが収集した不正支払のデータは, 漏洩した Subscriber Account および Identity Proofing の実装における潜在的な弱点の指標を提供することができる. 同様に, 脅威インテリジェンス・チームは, Identity Proofing, Authentication, および Federationプロセスに影響を与える可能性のある新しい TTP の兆候を受け取ることができる. 組織は, 重要なセキュリティおよび不正行為の関係者間で情報を交換するための一貫したメカニズムを確立するべきである(SHOULD).

CSP などの支援サービス・プロバイダーが外部にある場合, 複雑になる可能性があるが, 上記のような項目は契約上および法的な仕組みの中で考慮されるべきである(SHOULD). 収集, 送信, または共有するすべてのデータは, 最小化し, 詳細な Privacy および法的な評価を受けなければならない(SHALL).

Digital Identity Risk Management

This section is normative.

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.

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.

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

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.

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

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

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.

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.

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

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.

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.
• Moderate: at worst, moderate risk of minor injury or limited risk of injury requiring medical, including mental health, treatment; or the compounding impact of multiple low impact events; moderate risk of environmental impact in locality where program operations take place.
• High: a risk of serious injury, trauma, or death; or the compounding impact of multiple moderate impact events; high risk of environmental impact in locality where program operations take place.

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.

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.

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.

Table 1 Impact Categories

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

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

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 Descriptions

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

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

Identity Assurance Level

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

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.

Selecting Initial IAL

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.

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.

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.

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.

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.

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

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.

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:

• Low impact: AAL1
• Moderate impact: AAL2
• High impact: AAL3

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:

• Low impact: FAL1
• Moderate impact: FAL2
• High impact: FAL3

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:

• Privacy – to determine unintended consequences to the privacy of individuals that will be subject to the controls at an assessed xAL and of individuals affected by organizational or third-party practices related to the establishment, management, or federation of a digital identity.
• Equity – to determine whether implementation of controls may create or maintain inequities across demographics or user groups.
• Usability – to determine whether implementation of the selected controls will result in challenges to end-user experience.
• Threat – to determine whether the defined assurance level will address specific threats based on environment, threat actors, and known tactics, techniques, and procedures (TTPs).

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:

• A federal agency could choose to use a federal background investigation and checks, as referenced by Personal Identity Verification [FIPS201], to compensate for the identity evidence validation with authoritative sources requirement under these guidelines.
• An organization could choose to implement stricter auditing and transactional review processes on a payment application where verification processes using weaker forms of identity evidence were accepted due to availability of evidence in the end-user population.

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:

• An organization could choose to verify an end user against additional pieces of identity evidence, beyond what is required by the assurance level, due to a high prevalence of fraudulent attempts to complete the proofing process.
• An organization could choose to implement risk-scoring analytics, coupled with re-proofing mechanisms, to confirm a user’s identity when their access attempts exhibit certain risk factors.

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.

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

Authentication 分野で使われる用語は幅広く, 多くの用語は以前のバージョンの SP 800-63 と整合性を保っているものの, いくつかは本リビジョンから定義が変更になっている. 多くの用語に複数の定義がありうるため, 本ドキュメントにおける定義を明確にする必要がある.

Access

オンラインのデジタルサービスの1つ以上の個別機能に接続すること.

Activation

Multi-factor Authenticator に Activation Factor を入力し, Authentication に使用できるようにするプロセス.

Activation factor

Multi-factor Authenticator で Authentication を成功させるために使用される追加の Authentication Factor . すべての Multi-factor Authenticator は物理 Authenticator であるため, Activation Factorは Memorized Aecrets または Biometric Factor のいずれかである.

Active Attack

Attacker が Claimant, Credential Service Provider (CSP), Verifier, Relying Party (RP) に対してデータを送信するような Authentication Protocol における Attack のこと. Active Attack の例としては Man-in-the-Middle Attack (MitM), Impersonation, Session Hijacking などが挙げられる.

Address of Record

許可された手段によって Subscriber が通信を受信可能な, 有効かつ検証済の (物理的またはデジタルの) 場所情報.

Allowlist

ポリシーごとに許可される特定の要素の文書化されたリスト. Federation のコンテキストでは, Subscriber の介入なしにIdPへの接続を許可されるRPのリストを指すのが最も一般的である. この概念は, 歴史的に Whitelist として知られてきた.

Applicant

Enrollment および Identity Proofing のプロセスを受けている Subject.

Approved Cryptography

Federal Information Processing Standard (FIPS) の承認, もしくは NIST の推奨を受けているもの. FIPS ないしは NIST Recommendation に (1) 指定されているか, (2) 採用されているアルゴリズムおよびテクニック.

Assertion

Verifier から Relying Party (RP) に対して送られる, Subscriber の Identity 情報を含んだ Statement. Assertion は検証済 Attribute を含むこともある.

Assertion Reference

Assertion と紐付けて生成されるデータオブジェクトであり, Verifier を識別するとともに, Verifier が所有する Full Assertion へのポインタとして機能する.

Asymmetric Keys

Public Key と Private Key からなる鍵ペア. 暗号化と復号, 署名生成と署名検証など, 対となるオペレーションに用いられる.

Attack

Authorize されていない主体が, Verifier や RP をだまして当該個人を Subscriber だと信じ込ませようとする行為.

Attacker

不正な意図を持ち情報システムに不正アクセスする主体. 内部犯も含む.

Attacker-in-the-Middle Attack (AitM)

Attacker が, 通信を行う2つの当事者の間に位置し, その当事者間を移動するデータを傍受 および/または 変更するための Attack . Authentication のコンテキストでは, Attacker は, Claimant と Verifier の間, Enrollment のコンテキストでは Registrant と CSP の間, Authenticator 紐付けのコンテキストでは Subscriber と CSP の間に介在することとなる.

Attribute

人や物に関する生来の性質や特徴.

Attribute API

1つ以上の Subscriber に関する Attribute Value , Derived Attribute Value および関連する情報を提供する API. これらの API への Access は, (単一 Subscriber のための)Identity API または (複数の Subscriber のための) Provisioning API のコンテキストで RP に付与されることが多い. これは, Identity Proofing プロセス中に CSP の Attribute Value を検証するために使用される Attribute Verification API とは異なる.

Attribute Bundle

パッケージ化された Attribute の集合で, 通常は単一の Assertion に含まれる. Attribute Bundle により, RP は関連する必要な Attribute 一式を IdP から簡単に受け取ることができる. OpenID Connect の scope [OIDC] は Attribute Bundle の1つの実装である.

Attribute Provider

Subscriberが RP に存在することを表明することなく, Subscriber の Attribute を提供するサービス. Identity Provider (IdP) は, Federation のシナリオで使用される Attribute Provider の一種である. Attribute Provider は, しばしば, Attribute API を通じてこれらの Attribute を提供する.

Attribute Value

Subscriber のプロパティーを Assert する完全な Statement . フォーマットは問わない. 例えば “birthday” という Attribute に対しては, “12/1/1980” や “December 1, 1980” などが Attribute Value となりうる.

Attribute Verification API

Identity Proofing プロセスにおいて, Attribute Value の検証を行うための API . この API は Attribute Value を入力クエリとして受け付け, その Attribute Value が検証可能かどうかを返す. RP に Attribute を伝達するための Attribute API とは区別される.

Authenticate

Authentication参照.

Authenticated Protected Channel

接続元 (Client) が 接続先 (Server) を Authenticate しており, Approved Cryptography を用いて暗号化されたコミュニケーションチャネル. Authenticated Protected Channel は Confidentiality (機密性) および MitM 保護を提供するものであり, ユーザーの Authentication プロセスの中でよく使われるものである. Transport Layer Security (TLS) [BCP195] がその例としてあげられ, TLS では接続先が提示した Certificate を接続元が検証することになる. 特に指定がない限り, Authenticated Protected Channel では Server が Client を Authenticate する必要はない. Server の Authentication は, 各 Server 個別の対応ではなく, しばしば Trusted Root から始まる Certificate Chain を用いて行われる.

Authentication

Digital Identity を主張するために使用される 1 つまたは複数の Authenticator の妥当性を判断するプロセス. Authentication は, デジタル・サービスにアクセスしようとする Subject が, Authenticate に使用される技術を管理下に置いていることを証明する.

Authentication Factor

something you know, something you have, および something you are という3種類の Authentication Factor がある. 全ての Authenticator はこれら1つ以上の Authentication Factor を持つ.

Authentication Intent

ユーザーを Authentication フローに介在させるプロセスを経ることによって, Claimant が Authenticate ないしは Reauthenticate を行う意思を確認するプロセス. Authenticator によっては, Authentication Intent をオペレーションの一部に含むこともあれば (e.g., OTP デバイス), ボタンを押させるなどといった特別なステップを要求するものもある. Authentication Intent は, 当該 Endpoint を Proxy として, マルウェアが Subscriber に気づかれずに Attacker を Authenticate してしまうケースに対する対抗策となる.

Authentication Protocol

Claimant が正規の Authenticator の所有および管理権限を示すことで自身の Identity を確立するプロセスにおいて, Claimant と Verifier の間でやりとりされる一連のメッセージの定義. Claimant が意図した Verifier とコミュニケーションしていることを立証するためのプロセスを含むこともある.

Authentication Secret

あらゆる鍵を示す一般的な呼び名. Authentication Protocol において Attacker が Subscriber になりすますために利用することもできる. Authentication Secret は short-term authentication secrets と long-term authentication secrets に分類することができ, 前者は限定的な期間のみ利用可能なもの, 後者は手動でリセットされるまで使い続けられるものを示す. Authenticator Secret は long-term authentication secret の代表的な例であり, Authenticator Output が Authenticator Secret と異なる場合, その Authenticator Output は一般的に short-term authentication secret である.

Authenticator

Claimant が所有および管理するもので, 典型的な例としては暗号モジュールや Password 等がある. Authenticator は Claimant の Identity を Authenticate するために用いられる. SP 800-63 の前エディションまでは token と呼ばれていたものと同等である.

Authentication Assurance Level (AAL)

Authentication プロセスの強度を示すカテゴリー.

Authenticator Output

Authenticator によって生成される出力値. 必要に応じて正当な Authenticator Output を生成することで, Claimant が Authenticator を所有し管理していることを証明できる. Verifier へ送信されるプロトコルメッセージは Authenticator Output によって異なり, プロトコルメッセージが明示的に Authenticator Output を含んでいることもあればそうでないこともある.

Authenticator Secret

Authenticator に内包されるシークレット値.

Authenticator Type

共通の特徴を持つ Authenticator のカテゴリー. Authenticator Type によっては単一の Authentication Factor のみを持つものもあれば, 2つの Authentication Factor を持つものもある.

Authenticity

データが意図された情報源から得られたものであるというプロパティー.

Authoritative Source

Identity Evidence の Issuing Source がもつ正確な情報に Access できる, もしくは検証済みコピーを所有している主体. これにより Identity Proofing 実施時に CSP が Applicant の提出した Identity Evidence の正当性を確認できる. Issuing Source 自身が Authoritative Source であることもありうる. Authoritative Source は, Identity Proofing の検証フェーズの前に, 機関や CSP のポリシーによって決定されることも多い.

Authorize

access を許可するかどうかの判断. 通常は Subject の Attribute を評価することで自動的に判断される.

Authorized Party

Federation において, Federation Transaction 内で情報 (特に Subscriber Attribute) の公開に関する決定を行う責任を負う組織, 人, または実体. これは, 多くの場合, Subscriber (実行時決定が使用される場合) または IdP を運営する当事者 (Allowlist が使用される場合).

Back-Channel Communication

2つのシステム間で直接コネクションを貼って行われるコミュニケーション (標準プロトコルレベルでのプロキシの利用を許容する). ブラウザ等を媒介としたリダイレクトは用いない. HTTP Request & Response により実現可能.

Bearer Assertion

ある主体が Identity を証明するために提示する Assertion であり, Assertion を保有していること自体が Assertion 持参人の Identity 証明として十分であるようなもの.

Binding

Subscriber の Identity と Authenticator や Subscriber Session の間の関連性.

Biometric Reference

個人を特定し, 生体情報比較の対象として使用される, 1つ以上の保存された Biometric Sample , テンプレート, またはモデル. 例えば, パスポートにデジタル保存された顔画像, 国のIDカードに保存された詳細な指紋テンプレート, データベース内の話者認識用の混合ガウスモデルなどである.

Biometric Sample

Biometrics の特徴抽出の前に, Biometrics の特徴をアナログまたはデジタルで表現したもの. 例として, 指紋画像を含むレコード.

Biometrics

個人の行動や生体情報をもとに個人を自動認識すること.

Blocklist

ポリシーごとにブロックされる特定の要素の文書化されたリスト. この概念は, 歴史的に blacklist として知られている.

Challenge-Response Protocol

Verifier が Claimant に対してチャレンジ (通常はランダム値や Nonce) を送信し, Claimant はシークレットと連結 (チャレンジと Shared Secret を一緒にハッシュしたり, チャレンジに対して Private Key による操作を実施) して応答を生成し, Verifier に返却するような Authentication Protocol. Verifier は Claimant が生成した応答を自身のみで検証 (チャレンジと Shared Secret のハッシュを再計算してレスポンスと比較したり, レスポンスに対して Public Key による操作を実施) し, Claimant がシークレットを所有し管理下に置いているを証明することができる.

Claimant

1つ以上の Authentication Protocol により Identity を検証される Subject.

Claimed Address

Subject により, 自分に到達可能だと Assert された物理的位置. 居住地の住所や郵便の届く住所などを含む. 例えば, 外国籍のパスポートを所持している状態で U.S. に在住する人物であれば, Identity Proofing プロセスにおいて住所を要求されることになる. そう言った場合の住所は, “address of record” ではなく “claimed address” となろう.

Claimed Identity

ある Applicant による, 個人に関する未検証かつ未証明な Attribute の申告.

Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA)

利用者が人間か自動化されたエージェントかを区別するために Web フォームに追加する対話的な機能. 典型的には, 歪んだ画像や音声に対応するテキストの入力を求める方式である.

Core Attributes

CSP が Identity Proofing に必要であると判断し, 文書化した Identity Attribute のセット.

Credential

ある Identity および (任意で) 追加の Attribute を, 識別子を通じて, Subscriber が所有ないしは管理する Authenticator に紐付ける, 信頼のおけるオブジェクトもしくはデータ構造. Credentialは, CSP によって発行, 保存, および維持される. Credential からの情報のコピーは, 通常, 1つ以上のデジタル証明書の形で Subscriber が所有することができ, それらはしばしば関連する Private Key とともに Authenticator に含まれている.

Credential Service Provider (CSP)

信頼されたエンティティで, Identity サービスへの Applicant の Identity Proofing や, Subscriber Account への Authenticator の登録などの機能を持つ. CSP は独立した第三者となることがある.

Cross-site Request Forgery (CSRF)

RP に対して Authenticate されている Subscriber が, セキュアな Session を通じて Attacker のウェブサイトに接続する場合に発生する Attack であり, 加入者が無意識のうちに望まないアクションを RP 上で実行してしまうことになる. 例えば, もし銀行のサイトが CSRF に対して脆弱である場合, 単にユーザーが Web メールの本文中の悪意のあるリンクを参照するだけで, 別のブラウザウィンドウで銀行への接続が開かれ, 加入者が意図せず大きな金額の資金移動を Authorize してしまう可能性がある.

Cross-site Scripting (XSS)

Attacker が, 不正なコードを他の無害なページに対して注入することを許してしまう脆弱性. これらのスクリプトはターゲットのウェブサイトで生成されるスクリプトの権限で動作し, ウェブサイトとクライアント間でのデータ転送の Confidentiality (機密性) や Integrity (完全性) を侵害する. ウェブサイトは, ユーザーが入力するデータをリクエストやフォームから受け取り, サニタイズを施して実行不可能にすることなく表示してしまう場合に脆弱である.

Cryptographic Authenticator

エンドポイントを介した Verifier との直接通信により, Authentication Secret の所有を証明する Authenticator .

Cryptographic Key

復号, 暗号化, 署名生成, 署名検証等の暗号論的オペレーションを管理するために用いられる値. 本ガイドライン群では, [SP800-57Part1] の Table 2 で述べられた最低限の要件を満たすものとする. Asymmetric Keys および Symmetric Key も参照のこと.

Cryptographic Module

一式のハードウェア, ソフトウェア, およびファームウェアで, (暗号アルゴリズムや鍵生成を含む) Approved なセキュリティ機能を実装するもの.

Data Integrity

Authorize されていないエンティティによってデータが変更されることがないというプロパティー.

Derived Attribute Value

必ずしも Identity 情報を含まず, 形式に依存せずに Subscriber のプロパティを主張するステートメント. たとえば, Attribute 「誕生日」を要求する代わりに, Derived Value は「18 歳より上」とすることができる. 「物理的な住所」の Attribute を要求する代わりに, 「現在この地域に居住している」とすることができる. 本ガイドラインの以前のバージョンでは, これを “Attribute Reference” と呼んでいた.

Digital Authentication

情報システムに対して, 電子的に表現されたユーザーの Identity の確からしさを確立するプロセス. SP 800-63 の前エディションまでは Electronic Authentication と呼ばれていたもの.

Digital Signature

Private Key を用いてデータにデジタル署名を行い, Public Key を用いて署名検証を行う, Asymmetric Key を用いたオペレーション. Digital Signature は Authenticity Protection (真正性保護), Integrity Protection (完全性保護), Non-repudiation (否認防止) を提供するが, Confidentiality Protection (機密性保護) は提供しない.

Disassociability

[NISTIR8062]より: システムの運用上の必要性を超えて個人またはデバイスに関連付けることなく行われる, PII またはイベントの Processing.

Eavesdropping Attack

Authentication Protocol を受動的に傾聴し, 情報を傍受する Attack. 傍受した情報は, 後続の Claimant に成りすました Active Attack で利用される.

Electronic Authentication (E-Authentication)

Digital Authentication 参照.

Enrollment

Applicant が CSP の Subscriber となるべく申し込み, CSP が Applicant の Identity を検証するプロセス.

Entropy

Attacker がシークレット値を決定することに対峙する際の不確実性の量の尺度. Entropy は通常ビットで表現される. n ビットの Entropy を持つ値は, n ビットの一様乱数と同等の不確実性を持つ.

Equity

EO 13985 によると, Equity とは, 黒人, ラテンアメリカ人, 先住民, アジア系アメリカ人, 太平洋諸島民, その他の有色人種など, これまで十分なサービスを受けてこなかったコミュニティに属する個人を含め, すべての個人を一貫して公平, 公正, かつ公平に扱うことを指す. 宗教的少数派の人々, レズビアン, ゲイ, バイセクシャル, トランスジェンダー, クィア (LGBTQ+) の人々, 障害者, 地方に住む人々, その他根強い貧困や不平等から悪影響を受ける人々など.

Federal Information Processing Standard (FIPS)

Secretary of Commerce は, Information Technology Management Reform Act (Public Law 104-106) に基づいて, National Institute of Standards and Technology (NIST) により連邦政府機関のコンピュータシステムに適用するために開発された標準及びガイドラインを承認する. これらの標準及びガイドラインは NIST によって Federal Information Processing Standards (FIPS) として発行されたものであり, 政府機関で横断的に使われるものである. NIST はセキュリティや相互運用性といった強制力のある連邦政府の要求事項がある場合や, 許容可能な業界標準やソリューションが存在しない場合に, FIPS を開発する. 詳細については背景を参照すること. FIPS ドキュメントは FIPS ホームページ http://www.nist.gov/itl/fips.cfm からオンラインアクセス可能である.

Federated Identifier

Assertion内の Subject Identifier と, その Assertion を発行した IdP の識別子の組合せ. これらの情報を組み合わせると, Federation Transaction のコンテキストで Subscriber を一意に識別できる.

Federation

一連のネットワークシステム間で Identity および Authentication 情報の伝搬を行うためのプロセス.

Federation Assurance Level (FAL)

Federation において Authentication 情報および (場合によっては) Attribute 情報を RP に送る際に用いられる Assertion Protocol のカテゴリー.

Federation Proxy

IdP に対して論理的に RP として動作し, RP に対して論理的に IdP として動作する, 2つのシステムを Bridge するコンポーネント. “Broker” と呼ばれることもある.

Federation Transaction

特定の Subscriber のために, IdP から RP に Assertion を伝え, Federation プロセスを使用して Authentication を行う特定の処理インスタンス.

Front-Channel Communication

ブラウザ等を媒介とし, 2つのシステム間でリダイレクトを用いて行われるコミュニケーション. これは通常メッセージ受信者がホストする URL に HTTP Query Parameter を付与することで実現される.

Hash Function

任意長の短い文字列を固定長の文字列に変換する関数. 承認されている Hash Function は以下のプロパティーを満たす.

1. 一方向性 - 指定された出力結果から対応する入力を特定することが計算上困難であり

2. 衝突困難性 - 同じ出力となる任意の2つの異なる入力を特定することが計算上困難である.

Identity

特定のコンテキストにおいて, ある Subject を他と区別できるかたちで表現する, Attribute ないしは Attribute の集合.

Identity API

特定のSubscriberのAttributeにアクセスするために RP がアクセスする Attribute API . Identity API へのアクセスは, 通常, Federation Authenticationプロセスの一部として付与され, 単一の特定のSubscriberの情報に限定される.

Identity Assurance Level (IAL)

Applicant の Claimed Identity が本人の本物の Identity であることの確からしさの度合いをあらわすカテゴリー.

Identity Evidence

Applicant が Claimed Identity を裏付ける為に提出する情報ないしはドキュメント. Identity Evidence は物理的存在 (e.g. 免許証) なこともあればデジタルな存在 (e.g. CSP が Applicant を Authenticate した上で発行した Assertion) なこともある.

Identity Proofing

CSP が Credential 発行のためにある人物に関する情報を収集, 確認, および検証するプロセス.

Identity Provider (IdP)

Federation を使用するとき, Subscriber の一次 Authenticator を管理し, Subscriber Account から派生する Assertion を発行する主体.

Identity Resolution

CSP がサービスを提供する集団の中で個人を一意に識別するために, Applicant に関する情報を収集するプロセス.

Issuing Source

Identity Evidence として利用可能なデータや Assertion などのデジタルなエビデンス, 物理的ドキュメント等を責任を持って生成するオーソリティー.

Kerberos

MIT で開発された, 幅広く利用されている Authentication Protocol. “classic” な Kerberos では, ユーザーは秘密の Password を Key Distribution Center (KDC) に共有する. ユーザー Alice は他のユーザー Bob と通信するため KDC に対して Authenticate し, KDC は “ticket” を発行する. 当該チケットは Alice が Bob に対して Authenticate する為に利用する. 詳細は [SP800-63C] Section 11.2 を参照.

Knowledge-Based Verification (KBV)

当該個人の Claimed Identity と関連づけられているプライベートな情報を知っていることを根拠とした Identity 検証方法. Knowledge-Based Authentication (KBA) や Knowledge-Based Proofing (KBP) とも呼ばれる.

Manageability

NISTIR 8062より: 個人を特定できる情報の変更, 削除, 選択的な開示を含む, きめ細かい管理機能を提供すること.

Memorized Secret

Subscriber に記憶されることを前提とした, 文字列からなる Authenticator. Subscriber が Authentication プロセスにおいて something they know を立証するために利用できる.

Message Authentication Code (MAC)

暗号理論に基づくデータのチェックサムであり, Synmmetric Key を用いてデータの予期していない変更及び意図的な変更との両方を検知するために用いられる. MAC は Authenticity (真正性) と Integrity (完全性) の保護を行うが, Non-repudiation (否認防止) は行わない.

Mobile Code

実行コードであり, 通常は提供元から別のコンピューターシステムに転送されたのち実行されるもの. 転送は Network を介す (e.g., Web ページに埋め込まれた JavaScript) が, 物理的なメディアを介して転送されることもある.

Multi-Factor

2つ以上の Authentication Factor を要求する Authentication システムや Authenticator の特徴. MFA には, 2つ以上の要素を提供する単一の Authenticator を用いてもよいし, 互いに異なる要素を提供する複数の Authenticator を組み合わせて用いてもよい. Authentication Factor としては, something you know, something you have, something you are の3種類がある.

Multi-Factor Authentication (MFA)

2つ以上の Authentication Factor を要求する Authentication システム. Multi-Factor Authentication は単一の Multi-Factor Authenticator を用いて実現してもよいし, 互いに異なる要素を提供する複数の Authenticator を組み合わせて用いてもよい. Authentication Factor としては, something you know, something you have, something you are の3種類がある.

Multi-Factor Authenticator

2つ以上の Authentication Factor を提供する Authenticator. デバイスをアクティベートする為の Biometric センサーを持った暗号論的 Authentication デバイスなど.

Network

オープンなコミュニケーションの伝達手段. Internet がその代表例である. Network は Claimant とその他の主体の間でメッセージを伝達するために用いられる. 特に明示されない限り, Network のセキュリティは前提とされず, オープンであり, 任意の主体 (e.g., Claimant, Verifier, CSP および RP) 間の任意の点において Active Attack (e.g., なりすまし, Man-in-the-Middle, Session Hijacking) や Passive Attack (e.g., 盗聴) にさらされうるものと想定される.

Nonce

セキュリティプロトコル中で利用され, 同じキーによる繰り返しを許さない値. 例えば, Nonce は Challenge-Response Authentication Protocol のチャレンジとして利用され, Authentication キーが変更されるまでの間繰り返されないものとする (SHALL NOT). さもなければ Replay Attack の可能性がある. Nonce をチャレンジとして利用することと, チャレンジをランダムにすることとは異なる要件である. Nonce は必ずしも予測不可能である必要性はない.

Offline Attack

Attacker が自身で選択したシステムにおいて解析できるような何らかの情報を得る Attack. (典型的には Authentication Protocol 中のやりとりを盗聴したり, システムに侵入してセキュリティファイルを盗む)

One-to-one (1:1) Comparison

個人から採取した Biometric サンプルを Biometric Reference と比較し, 比較スコアを生成するプロセス.

Online Attack

Authentication Protocol において, 正当な Verifier に対して Claimant のふりをしたり, または能動的に Authentication チャネルを改ざんする Attack.

Online Guessing Attack

Attacker が Authenticator Output の取りうる値を推測してログオン試行を繰り返す Attack.

Pairwise Pseudonymous Identifier

CSP が特定の RP に対して生成する, opaque で推測不可能な Subscriber の識別子. この識別子は特定の CSP-RP ペア以外には知られることはなく, 当該ペア間でのみ用いられる.

Passive Attack

Authentication Protocol に対する Attack. Claimant と Verifier との間を Network を介してやり取りされるデータを傍受するが, データは改ざんしない (例. 盗聴).

Passphrase

Passphrase は Claimant が自身の Identity を Authenticate する際に利用する, 単語列や文字列からなる Memoized Secret. Passphrase は Password と似ているが, 一般的には Password より長くセキュリティー的にも強固である.

Password

Memoized Secret 参照.

Personal Data

Personally Identifiable Information 参照.

Personal Identification Number (PIN)

通常10進数の数値のみで構成された Memoized Secret.

Personal Information

Personally Identifiable Information 参照.

Personally Identifiable Information (PII)

OMB Circular A-130 で定義されているように, Personally Identifiable Information とは個人の Identity を識別したり追跡するために用いられる情報である. 単体の情報で個人を識別・追跡可能なものもあれば, 特定の個人に紐付け済もしくは紐付け可能なその他の情報と組み合わせることで識別・追跡可能となるものもある.

Personally Identifiable Information Processing

Personally Identifiable Information に対して行われる操作または一連の操作で, Personally Identifiable Information の収集, 保持, 記録, 生成, 変換, 使用, 開示, 移転, および廃棄を含むが, これらに限定されない.

Pharming

DNS (Domain Name System) のようなインフラストラクチャサービスを汚染する手法により, Subscriber を偽の Verifier/RP へ誘導し, 機微情報を入力させる, 有害なソフトウェアをダウンロードさせる, 詐欺活動に加担させるような Attack.

Phishing

Subscriber を (主に Email を通じて) 偽の Verifier/RP に誘導し, 本物の Verifier/RP に対して Subscriber になりすますための情報を騙し取る Attack.

Possession and Control of an Authenticator

Authenticator Protocol において, Authenticator をアクティベートし利用する能力.

Practice Statement

Authentication プロセスの当事者 (e.g., CSP, Verifier) が従う実践的な内容を正式に記載した文書. 通常, 当事者のポリシーと実行内容が記述されており, 法的拘束力を持つ可能性がある.

Predictability

[NISTIR8062]より: 個人, 所有者, 事業者に対して, PII および PII に対して情報システムが行う Processing に関する信頼性の高い仮定を可能とすること.

Private Key

Asymmetric Key ペアの秘密鍵. データへのデジタル署名や復号に用いられる.

Processing

[NISTIR8062]より: PII の収集, 保持, 記録, 生成, 変換, 使用, 開示, 移転, 及び廃棄を含むが, これらに限定されない, PII に対して行われる操作又は操作の集合.

Presentation Attack

Biometric システムの運用妨害を目的とした Biometric データ読み取りサブシステムへの提示.

Presentation Attack Detection (PAD)

Presentation Attack の自動検知. Presentation Attack Detection 手法のサブセットである liveness detection では, 解剖学的特徴または非自発的または自発的反応の測定および分析を行い, Biometric サンプルが生体の Subject から直接読み取られたものかどうかを判定する.

Protected Session

2者間でやりとりされるメッセージを, Session Key と呼ばれる Shared Secret を用いて暗号化し, Integrity (完全性) を保護する Session. 当該 Session 内で, ある主体が Session Key に加えて1つ以上の Authenticator を所有していることを証明し, もう一方の主体が当該 Authenticator に紐づく Identity (完全性) を検証できる場合, 当該主体は Authenticated であると言う. もし両主体が共に Authenticated となる場合, この Protected Session は Mutually Authenticated であると言える.

Provisioning API

RP Subscriber Account のプロビジョニングを目的として, RP が複数の SubscriberのAttribute にアクセスすることを可能にする Attribute API . Provisioning API へのアクセスは, 通常, 特定の Federated Authentication Transaction の外部で RP に付与される.

Pseudonym

実名 (Legal Name) 以外の名前.

Pseudonymity

Subject の識別に Pseudonym を用いること.

Pseudonymous Identifier

RP による Subscriber に関するいかなる推測をも許さず, かつ RP が複数のインタラクションに渡って Subscriber の Claimed Identity を紐づけられるような, 意味のないユニークな識別子.

Public Key

Asymmetric Key ペアの公開鍵. データへの署名検証や暗号化に用いられる.

Public Key Certificate

Certificate Authority によって発行され, Certificate Authority の Private Key でデジタル署名された電子文書. Public Key Certificate により Subscriber の識別子が Public Key と紐づけられる. 当該 Certificate により識別される Subscriber のみが Private Key の管理および Access を持っていることが暗示される. [RFC5280] も参照のこと.

Public Key Infrastructure (PKI)

Certificate と Public-Private Key Pair を管理する目的で利用される, 一連のポリシー, プロセス, サーバープラットフォーム, ソフトウェア, ワークステーションなど. Public Key Certificate の発行, 管理, 失効を行う能力を備える.

Reauthentication

ある Session において, Subscriber が継続してその場に存在し Authenticate する意思を持っていることを確認するプロセス.

Registration

Enrollment 参照.

Relying Party (RP)

Subscriber の Identity に関する Verifier の Assertion を信頼して, Transaction 処理や情報またはシステムへのアクセスを許可したりする主体.

Remote

(Remote Authentication や Remote Transaction といったコンテキストで) 単一組織によるセキュリティ対策のみでは End-to-End での確実な保護が期待できないような状況下での, Network 接続されたデバイス間の情報交換.

Replay Attack

Attacker が事前に記録しておいた (正当な Claimant と Verifier との間の) メッセージを, Verifier に対して Claimant になりすまして, もしくはその逆方向に, 再送する Attack.

Replay Resistance

Replay Attack 耐性のある Authentication プロセスのプロパティ. 典型的には, 特定の Authentication にのみ有効な Authenticator Output により実現される.

Resolution

Identity Resolution 参照.

Restricted

誤認発生時に追加のリスクが発生するため, 追加要件を要求されるような Authenticator Type, クラス, インスタンス.

Risk Assessment

システムの運用に起因する, 組織の運営 (ミッション, 機能, イメージ, レピュテーションを含む), 組織の資産, 個人および他組織に対するリスクを, 特定, 推定, 優先順位付けするプロセス. Risk Assessment は Risk Management の一部であり, 脅威・脆弱性解析を包含し, 計画済もしくは実施中のセキュリティー管理で施される対策について考察するプロセスである. Risk Analysis と同義.

Risk Management

組織の運営 (ミッション, 機能, イメージ, レピュテーションを含む), 組織の資産, 個人および他組織に対する情報セキュリティーリスクを管理するプログラムや補助的プロセス. (i) リスクに関係するアクティビティーを見極め, (ii) リスクを評価し, (iii) ひとたびリスクが特定されればそれに対応し, (iv) 継続的にリスクをモニタリングする, という一連の行動を含む.

Salt

暗号プロセスにおいて用いられる秘密でない (non-secret) 値で, 通常ある特定の計算結果が Attacker によって再利用されないことを保証するために用いられる.

Secure Sockets Layer (SSL)

Transport Layer Security (TLS) 参照.

Session

Subscriber と RP ないしは CSP のエンドポイントの間の継続的インタラクション. Session は Authentication イベントにより開始され, Session 終了イベントで終了する. Session は Session シークレットにより紐づけられる. Session シークレットは Subscriber のソフトウェア (Browser, アプリケーション, OS) が RP に Subscriber の Authentication イベントの代わりとして提示することができる値である.

Session Hijack Attack

Claimant と Verifier の間の Authentication のやりとりが成功したのち, Attacker が Claimant と Verifier の間に入り込む攻撃. Attacker は Verifier に対して Subscriber のふりをしたり, Subscriber に対して Verifier のふりをしたりして, Session 中のデータ交換をコントロールする. Claimant と RP の間の Session も同様に侵害されうる.

Shared Secret

Subscriber と Verifier が知っている, Authentication で使われるシークレット.

Side-Channel Attack

物理的な暗号システムからの情報漏洩によって可能となる Attack. Side-Channel Attack においては, タイミング, 消費電力, 電磁波放出, 及び音響放射といった特性が利用される.

Single-Factor

単一の Authentication Factor (something you know, something you have, or something you are) を要求する Authentication システムや Authenticator の特徴.

Social Engineering

人を欺いてセンシティブな情報を露呈させたり, Unauthorized Access を得たり, 人と付き合いながら信頼を獲得した上で詐欺を行う活動.

Software Statement

ソフトウェアの一部を記述する Attribute のリストで Authority によって暗号的に署名されている. Software Statement は, Federation シナリオの RP で最も一般的に使用される.

Special Publication (SP)

NIST が発行する出版物の一形態. 特に SP 800 シリーズは, Information Technology Laboratory による研究活動, ガイドライン, コンピュターセキュリティ分野における公共福祉のための支援活動, 民間・政府・学術組織との協調的な活動などに関するレポートとなっている.

Subject

人間, 組織, デバイス, ハードウェア, ネットワーク, ソフトウェア, サービスなど.

Subscriber

CSPアイデンティティサービスに Enrollment された個人

Subscriber Account

CSP Identity サービスに登録された各利用者の情報および Authenticator を含む, CSP が設定するアカウント.

Supervised Remote Identity Proofing

リモートセッションが物理的な対面式 Identity Proofing プロセスと同等と見なすことができる十分な信頼を提供する, 物理的, 技術的および手続き上の措置を採用したリモート Identity Proofing プロセス.

Symmetric Key

暗号化と復号, Message Authentication Code の生成と検証などの, 対となる暗号論的オペレーションの両方で用いられる暗号論的な鍵.

Synthetic identity fraud

Personally Identifiable Information (PII) を組み合わせて個人または団体を偽装し, 個人的または経済的利益を得るために不正な行為を行うこと.

Token

Authenticator 参照.

Transaction

ビジネスやプログラムの目標を支援する, ユーザーとシステムの間の個々のイベント. 政府のデジタルシステムにおいては, デジタル Identity の Risk Assessment において個別の分析が必要な, 複数のカテゴリーないしはタイプの Transaction がある.

Transport Layer Security (TLS)

ブラウザやウェブサーバに広く実装されている Authentication およびセキュリティプロトコル. TLSは [RFC5246] で定義されている. TLSはより古い SSL プロトコルと似ており, 実質的に TLS1.0 は SSL version 3.1 といえる. [SP800-52] (Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations) では, 政府のアプリケーションにおいてどのように TLS を用いるかを定めている.

Trust Anchor

ハードウェアやソフトウェエアに直接埋め込まれていたり, Out-of-band な手法によりセキュアに提供されたりすることで Trust される, Public Key もしくは Symmetric Key. 他の信頼できる主体の保証を受けて Trust を得るものは Trust Anchor とは呼ばない (Public Key Certificate 等). Trust Anchor はそのスコープを制限するような名称やポリシー制約を持つこともある.

Usability

特定のユーザーが特定の利用コンテキストにおいて, 効果的, 効率的かつ十分に特定の目的を果たすためにプロダクトを利用しうる度合い. [ISO/IEC9241-11]

Validation

Applicant から提供された証拠および Attribute が本物であり, 正確であり, 現実の Identity と関連していることをチェックし確認するプロセスまたは行為. 具体的には, Evidence Validation とは, 提示された証拠が本物であり, 最新で許容されるソースから発行されたものであることを確認するプロセスまたは行為であり, Attribute Validation とは, 一連の Attribute が正確で, 現実の身元に関連していることを確認するプロセスまたは行為.

Verification

Applicant が, 検証された Identity Attribute および関連する証拠によって表される Claimed Identity を保持していることを確認するプロセスまたは行為. NIST SP 800-63 では, “Verification” という用語は “Identity Verification” と同義である.

Verifier

Authentication Protocol を利用して, Claimant が1つまたは2つの Authenticator を 所有, 管理していることを検証し, Claimant の Identity を検証する主体. Verifier は上記の目的のため, Authenticator と Identity を紐付ける Credential を確認し, そのステータスをチェックする必要がある場合もある.

Verifier Impersonation

Phishing 参照.

Zeroize

データを破壊し復元できないようにするために, ゼロ値のビットだけで構成されるデータによってメモリを上書きすること. これはしばしばデータそのものを破壊するのではなく, ファイルシステム上のデータへの参照を破壊するだけの削除手法と対比される.

Zero-Knowledge Password Protocol

Claimant が Verifier に対して Authenticate を行う際, Verifier に対して Password を提示する必要がないような Password ベースの Authentication Protocol. 例としては EKE, SPEKE, SRP などが挙げられる.

Abbreviations

本ガイドライン群で選択されている略語を以下に定義する.

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

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:

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

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

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:

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

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