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

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 サービスを実装するための技術ガイドラインを組織に提示する.

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

Definitions and Abbreviations

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

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

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

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.