ABSTRACT

これらのガイドラインは、ネットワークを介して政府情報システムとやり取りする利用者（例：従業員、契約者、または民間の個人）の identity proofing、authentication、federation を対象としています。identity proofing、enrollment、authenticators、management processes、authentication protocols、federation、および関連する assertions の各領域における技術要件を定義します。また、役立つ提案として、技術的な推奨事項やその他の参考情報も提示します。これらのガイドラインは、この目的の範囲外にある標準の開発や利用を制約することを意図していません。本刊行物は NIST Special Publication (SP) 800-63-3 に代わるものです。

Keywords

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

Preface

本刊行物およびその関連巻である — [SP800-63A]、 [SP800-63B]、および [SP800-63C] — は、デジタル identity サービスの実装に向けて、組織に対し技術およびプロセスのガイドラインを提供します。

1. Introduction

この節は informative です。

ここ数年でオンラインサービスが急速に広がったことにより、信頼でき、安全で、プライバシーを保護するデジタル identity ソリューションの必要性が高まっています。digital identity は、オンラインサービスの文脈において常に一意です。しかし、ある人が複数の digital identity を持つことはあり得ます。また、digital identity がオンラインサービスの文脈の中で一意で具体的な意味を伝えることはあっても、その digital identity の背後にいる個人の現実世界の identity が知られていない場合があります。オンラインサービスへのアクセス提供に際して、ある人の現実世界の identity に対する信頼が求められない場合、組織は匿名または pseudonymous なアカウントを利用できます。それ以外のすべての利用形態では、digital identity は、digital identity の保持者と、オンラインサービスとやり取りする人物・組織・システムとの間に信頼を確立することを意図しています。しかし、このプロセスには課題が伴う場合があります。誤り、意思疎通の齟齬、そして他者の identity を不正に名乗る攻撃の機会が複数存在します。さらに、個々人のニーズ、制約、能力、嗜好が幅広いことを踏まえると、オンラインサービスは、広範かつ持続的な参加とアクセスを支えるために、柔軟性と顧客体験を念頭に設計される必要があります。

digital identity のリスクは動的であり、連続体として存在します。したがって、digital identity risk management のアプローチは、組織固有のニーズを満たすよう設計された outcome-based な手法を用いてリスクを管理することを目指すべきです。本ガイドラインは、ベースラインの control セットとして機能する、特定の assurance level を定義します。これらの assurance level は、リスク管理に取り組む組織にとっての出発点となること、異なる entity 間の相互運用性を支える共通の構造を提供することなど、複数の利点をもたらします。しかし、組織が identity ソリューションを展開する際に直面するリスク、脅威、考慮事項の全領域を包括的に扱える assurance level を作成することは非現実的です。このため、本ガイドラインは、コンプライアンス志向のアプローチではなく、digital identity ソリューション実装に対する risk-based アプローチを促進し、組織には、本ガイドラインで定義されたプロセスに基づいて control 実装を tailoring することを推奨します。

さらに、digital identity に関連するリスクは、オンラインサービスを提供する組織に対する潜在的な影響を超えて広がります。本ガイドラインは、個人、コミュニティ、その他の組織に対するリスクも、強固かつ明確に扱うよう努めています。組織はまた、digital identity に関する意思決定が、組織のプログラムやサービスとやり取りする個人にどのような影響を与えるか、あるいは個人にどのように配慮する必要があるかも考慮すべきです。個人にとってのプライバシーと顧客体験は、セキュリティと併せて考慮されるべきです。加えて、組織は、コールセンターや対面対応で用いられるものなど、identity management の他の仕組みと並行して digital identity のアプローチを検討すべきです。顧客中心で、かつ継続的に情報に基づく任務遂行のアプローチを採ることで、組織は、サービス対象の人々との信頼を段階的に構築し、顧客体験を改善し、問題をより迅速に特定し、適切で有効な救済手段を個人に提供する機会を得られます。

SP 800-63 の初版が公開されて以降、identity サービスの構成、モデル、可用性は大きく変化し、利用者に対して安全でプライベートで使いやすいサービスを展開するうえでの考慮事項と課題も変化してきました。本改訂版は、全体的なデジタル identity モデルの一部として entity が果たす役割と機能に基づくガイダンスと要件を提示することで、これらの課題に対応します。

さらに、本刊行物は、NIST Risk Management Framework [NISTRMF] およびその構成刊行物を補完するために、credential service providers (CSPs)、verifiers、relying parties (RPs) に向けた指針を提供します。組織がデジタル identity サービスを実装するために従うべき risk management プロセスを記述し、顧客体験に関する考慮事項をどのように組み込むべきかを概説することで、NIST RMF を拡張します。また、enterprise の運用および資産、個人、その他の組織への影響を考慮する重要性を強調します。さらに、identity proofing、authentication、federation のための digital identity management プロセスには通常 personal information の processing が伴い、プライバシーリスクを生じ得ます。したがって、本ガイドラインには、潜在的に関連するリスクの軽減に役立つ privacy の要件および考慮事項が含まれています。

最後に、本ガイドラインは、ネットワーク越しにデジタルシステムへアクセスする subject の digital identity を確立・維持し、認証するための技術要件と推奨事項を組織に提供する一方で、identity および IT チームの管理範囲外であることが多いシステムやプロセスとの統合も推奨します。そのため、本ガイドラインは、組織内での連携を改善し、より有効で現代的で顧客主導のオンラインサービスを提供するための考慮事項も提示します。

1.1. Scope and Applicability

本ガイドラインは、（例：一般市民、ビジネスパートナー、政府の従業員および契約者）といった constituency に関わらず、digital identity に対する一定水準の assurance が必要とされるすべてのオンラインサービスに適用されます。本刊行物において「person」は natural persons のみを指します。

本ガイドラインは主として、公的給付にアクセスする個人や、協働スペースにアクセスする民間セクターのパートナーなど、外部利用者とやり取りする組織のサービスに焦点を当てています。しかし、従業員や契約者がアクセスする連邦システムにも適用されます。Personal Identity Verification (PIV) of Federal Employees and Contractors 標準 [FIPS201] と、それに対応する Special Publications および組織固有の指示は、Personal Identity Verification (PIV) Cards の発行および管理、派生 PIV credential として追加の authenticators を binding すること、ならびに PIV システムにおける federation architectures および protocols の利用のための追加の技術 controls とプロセスを提供することで、連邦 enterprise 向けに本ガイドラインを拡張します。

本ガイドラインの対象外となるオンラインサービスには、 [44 U.S.C. § 3552(b)(6)] で定義される national security systems に関連するものが含まれます。民間セクターの組織や、州・地方・部族政府で、デジタルプロセスにさまざまな水準の digital identity assurance を必要とする場合、適切であればこれらの標準の利用を検討してよいでしょう。

本ガイドラインは、オンラインの systems、services、applications への論理アクセスを扱います。physical access control のプロセスは特に扱いません。ただし、本ガイドラインで定めるプロセスは、適切な場合には physical access の use case に適用できます。さらに、本ガイドラインは、machine-to-machine authentication、相互接続されたデバイス（例：Internet of Things [IoT] デバイス）、または subject に代わって Application Programming Interfaces (APIs) へアクセスすることなど、いくつかの subject を明示的には扱っていません（ただしこれらに限定されません）。

1.2. How to Use This Suite of SPs

本ガイドラインは、identity proofing、authentication、federation の各機能において発生する誤りの負の影響を軽減することを支援します。[Section 3]（Digital Identity Risk Management）では、risk assessment のプロセスと、risk assessment の結果および追加の文脈が、identity proofing、authentication、federation の各プロセスを保護する controls の選択にどのように反映されるかを説明します。controls は、リスクとミッションに基づき、特定のサービスにおける各種 digital identity error の該当タイプを軽減するために必要な assurance level を決定することで選択されます。

具体的には、組織は次の各機能について assurance level[1] を選択する必要があります。

Identity Assurance Level (IAL) は identity proofing の機能を指します。
Authentication Assurance Level (AAL) は authentication の機能を指します。
Federation Assurance Level (FAL) は、relying party (RP) が federated protocol を通じて credential service provider (CSP) または identity provider (IdP) と接続される場合の federation の機能を指します。

SP 800-63 は、次の巻で構成されるスイートとして編成されています。

SP 800-63 Digital Identity Guidelines は、digital identity models、risk assessment methodology、および identity proofing、authentication、federation の assurance level を選択するためのプロセスを説明します。SP 800-63 には normative と informative の両方の内容が含まれます。
[SP800-63A]: 3 つの IAL の各レベルで resources へのアクセスを得たい applicant の remote または対面での enrollment と identity proofing に関する要件を提供します。subscriber accounts の確立および維持、ならびに CSP が発行する、または subscriber が提供する authenticators を subscriber account に binding することに関する CSP の責務を詳述します。SP 800-63A には normative と informative の両方の内容が含まれます。
[SP800-63B] 3 つの AAL の各レベルで利用できる authentication プロセス（authenticators の選択を含む）に関する要件を提供します。また、authenticators の存続期間中に起こり得る事象（例：紛失または盗難時の無効化）に関する推奨事項も提供します。SP 800-63B には normative と informative の両方の内容が含まれます。
[SP800-63C] federated identity architectures と assertions の利用に関する要件を提供し、authentication プロセスの結果および関連する identity information を組織の application に伝達します。SP 800-63C には normative と informative の両方の内容が含まれます。

1.3. Enterprise Risk Management Requirements and Considerations

効果的な enterprise risk management は、設計上、学際的であり、多様な要因と期待の検討を伴います。digital identity risk management の文脈では、これらの要因には、information security、fraud、privacy、customer experience などが含まれます（ただしこれらに限定されません）。risk management の取り組みでは、enterprise の assets と operations、個人、その他の組織に関係するこれらの要因を比較衡量することが重要です。

digital identity に関連する要因を分析する過程で、組織は、特定の文脈において本刊行物で規定されるもの以外の手段が適切であると判断する場合があります（例：privacy またはその他の法的要件が存在する場合、あるいは risk assessment の出力により、追加の手段や代替の手続的 safeguard が適切だと判断される場合）。連邦機関を含む組織は、本刊行物で規定されていない compensating controls または supplemental controls を採用できます。また、オンラインサービスの機能を分割し、機密性の低い機能をより低い assurance level で利用可能にして、セキュリティを損なうことなくアクセス性を向上させることも検討できます。

以下に示す考慮事項は、enterprise risk management の取り組みを支援し、情報に基づく顧客中心のサービス提供を促進します。この考慮事項の一覧は網羅的ではありませんが、digital identity management に関する意思決定に影響を与えやすい横断的要因の一部を強調しています。

1.3.1. Security, Fraud, and Threat Prevention

組織にとって、なりすましによる不正アクセスなど、digital identity の security リスクを評価し管理することはますます重要になっています。組織が本ガイドラインを参照する際には、組織が管理する情報および information systems、ならびに service providers や business partners が、サービス対象の個人やコミュニティのために代行して管理する情報および information systems について、confidentiality、integrity、availability への潜在的影響を考慮すべきです。

本ガイドラインを実装する連邦機関は、Federal Information Security Modernization Act (FISMA) of 2014 [FISMA] の下でのものを含む、法令上の責務を満たすことが求められます。加えて、関連する NIST の標準およびガイドラインにも従う必要があります。NIST は、これらのガイドラインを実装する非連邦組織にも、安全なデジタルシステム運用を確保するため、同等の標準（例：ISO/IEC 27001）に従うことを推奨します。

FISMA は、連邦機関に対し、連邦情報および information systems を、不正アクセス、使用、開示、破壊、または改変から保護するための適切な controls の実装を求めています。NIST RMF [NISTRMF] は、security、privacy、cyber supply chain risk management の活動を system development life cycle に統合するプロセスを提供します。本ガイドラインの下でサービスを提供する連邦機関および組織は、FISMA および関連する NIST の risk management プロセスと刊行物に基づき求められる controls とプロセスを、すでに実装していることが期待されています。

本ガイドラインにおける identity、authentication、federation の assurance levels が包含する controls と要件は、FISMA と RMF の下で定められる情報および information system controls を補強するものであり、置き換えたり改変したりするものではありません。

脅威が進化するにつれ、組織にとって、identity proofing と authentication のプロセスに関連する identity-related fraud のリスクを評価し管理することが重要になります。組織が本ガイドラインを参照する際には、変化する脅威環境、デジタル identity 市場における革新的な anti-fraud 手段の可用性、そして identity-related fraud が自組織の systems と利用者に与える潜在的影響を考慮すべきです。これは、public-facing なオンラインサービスにおいて特に重要であり、identity-related fraud がデジタル政府サービスの提供、公共の信頼、組織の評判に与える影響は大きくなり得ます。

この版では、IAL1 を新しい assurance level として再構成し、authentication の risk と threat models を更新して新たな攻撃を考慮に入れ、phishing-resistant authentication の新しい選択肢を提供し、enrollment プロセスに対する automated attacks を防止するための要件を導入し、強力な identity proofing と authentication を活用できる新技術（例：モバイル運転免許証や verifiable credentials）に備えることで、identity theft および identity-related fraud と戦うための手段を強化しています。

1.3.2. Privacy

デジタル identity システムを設計・実装・管理する際には、そのシステムが personal information の processing（例：収集、保管、利用、破棄）を行うことで、個人にプライバシー関連の問題を生じさせ得ること、そして problematic data actions の潜在的影響を考慮することが不可欠です。personal information の侵害や機微情報の漏えいが起きた場合、組織は、privacy notices において、どの情報が不適切に漏えいしたのか、そして（判明している場合は）その情報がどのように悪用されたのかを、平易な言葉で説明する必要があります。

組織は、自組織の privacy policies と system の privacy requirements がどのように自組織の systems に実装されているかを示す必要があります。本ガイドラインは、privacy を念頭に置いた digital identity risk management の実装を組織が進めるための手段として、次の参照を推奨します。

[NISTPF] NIST Privacy Framework：privacy by design の概念を支える privacy engineering の実践を可能にし、組織が個人の privacy を保護するのに役立ちます
[PrivacyAct] of 1974：記録システムにおいて連邦機関が保持する個人に関する情報の収集、維持、利用、開示のための公平な情報慣行を確立しました
[M-03-22] OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002：personal information の processing または保管に必要となる privacy impact assessments (PIAs) の実施と公表通知を要求します
[SP800-53] Security and Privacy Controls for Information Systems and Organizations：privacy risk および impact assessments で特定されたリスクを軽減するために実装可能な privacy controls を列挙します
[SP800-122] Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)：連邦機関が、personal information とは何か、personal information の confidentiality を保護することと privacy および Fair Information Practices との関係、そして personal information を保護するための safeguards を理解するのを支援します

さらに、SP 800-63 の各巻には、各巻で提示されるプロセス、controls、要件を実装するための詳細な privacy guidance と考慮事項、ならびにデータの収集、保持、最小化に関する normative requirements を提供する特定の節が含まれています。

1.3.3. Customer Experience

本ガイドラインが、組織に対して、現代的で、合理化され、応答性の高い customer experience を作り出す能力を提供することは不可欠です。そのため、ガイドラインは、組織が risk management プロセスにおける意思決定やトレードオフを行う際に、利用者の能力と期待を織り込めるようにしています。本ガイドラインを実装する組織は、効果的な digital identity risk management 戦略を定める一環として、自組織の利用者集団、その能力、そして制約を理解しなければなりません。

応答性が高く有効な customer experience を確保するために、本ガイドラインにはいくつかの主要な追加が行われました。該当する場合には各巻に新技術を追加したことに加え、本巻は次の 2 つの重要な概念を導入します。

Control tailoring. Control tailoring により、組織は、利用者に適した技術とプロセスを展開するために、情報に基づく risk-based な意思決定を行い、customer experience のニーズを満たすために、情報に基づく意思決定を通じてベースライン controls を調整できます。
Continuous improvement programs. 継続的な評価プログラムを確立することで、組織は、リスクをどの程度軽減できているか、利用者のニーズをどの程度満たしているかを評価する能力を得られます。メトリクスと部門横断の評価プログラムを通じて、本ガイドラインは、組織の広範な利用者集団を支える有効で現代的なソリューションを提供するための、データ駆動アプローチの基盤を築きます。

これら 2 つの概念は、本書の [Sec. 3] で詳細に議論されます。

customer experience を改善する一環として、本ガイドラインはまた、利用者に対して「利用者が今いる場所で応える（meet the customer where they are）」ための選択肢を提供する必要性を強調しています。これを継続的改善戦略と顧客中心の設計と組み合わせることで、組織がサービス対象の人々のニーズを最もよく支える機会、プロセス、business partners、そして multi-channel の identity proofing とサービス提供の手法を特定する助けになります。

さらに、usability とは、特定の利用状況の文脈において、有効性、効率性、満足度をもって目標を達成するために system、製品、またはサービスを利用できる度合いを指します。usability は、customer experience、サービス提供、security の主要な目標を支えるものであり、デジタル identity システムまたはプロセスとやり取りする人々、ならびにその固有の能力と利用状況の文脈を理解することを必要とします。

本ガイドラインの読者は、利用者がサービスへの enrollment と service への認証のプロセスを通じて行う各 interaction を、全体として捉えるアプローチを採るべきです。デジタル identity システムまたはプロセスの設計と開発の全体を通じて、代表的な利用者を対象に usability evaluations を実施し、適切な利用状況の文脈で現実的なシナリオとタスクを行うことが重要です。また、usability のガイドラインと考慮事項に従うことで、組織が customer experience の目標を達成する助けになります。digital identity management のプロセスは、利用者が正しいことを行いやすく、誤ったことを行いにくく、誤ったことが起きたときに回復しやすいように設計・実装されるべきです。

\clearpage

1.4. Notations

本ガイドラインは本文中で次の表記上の慣例を用います。

CAPITALS で示される特定の用語は normative requirements を表します。同じ用語であっても CAPITALS でない場合、その用語は normative requirement を表しません。
- 「SHALL」および「SHALL NOT」は、本刊行物に適合するために厳格に従うべき要件を示し、そこからの逸脱は許容されません。
- 「SHOULD」および「SHOULD NOT」は、いくつかの可能性の中で、とりわけ適切として 1 つを推奨することを示し、他を挙げたり排除したりすることはしません。また、ある行動方針が望ましいが必須ではないこと、あるいは（否定形では）ある可能性または行動方針が望ましくないが禁止ではないことを示します。
- 「MAY」および「NEED NOT」は、本刊行物の範囲内で許容される行動方針を示します。
- 「CAN」および「CANNOT」は、可能性と能力 — 物質的、物理的、または因果的 — を示し、否定形では、その可能性または能力が存在しないことを示します。

1.5. Document Structure

本書は次のとおり構成されています。各節は normative（すなわち、コンプライアンスのために必須）または informative（すなわち、必須ではない）のいずれかとしてラベル付けされています。

Section 1 は本書を紹介します。この節は informative です。
Section 2 は digital identity の一般的なモデルを説明します。この節は informative です。
Section 3 は digital identity のリスクモデルを説明します。この節は normative です。
References 節には、本書で引用される刊行物の一覧が含まれます。この節は informative です。
Appendix A には、本書で使用される略語の選択リストが含まれます。この appendix は informative です。
Appendix B には、本書で使用される用語の選択的な glossary が含まれます。この appendix は informative です。
Appendix C には、本書の改訂履歴における変更点の要約リストが含まれます。この appendix は informative です。

一般的に記述される場合、またはまとめて言及する場合、本ガイドラインは IAL、 AAL、FAL を xAL として参照します。各 xAL には 3 つの assurance levels があります。[↩]

2. Digital Identity Model

この節は informative です。

2.1. Overview

本ガイドラインは、市場で現在利用可能な技術およびアーキテクチャを反映した digital identity models を用います。これらのモデルには多様な entity と機能があり、複雑さもさまざまです。単純なモデルでは、機能（例：subscriber accounts の作成、attributes の提供）を単一の entity の下にまとめます。より複雑なモデルでは、これらの機能を複数の entity に分割します。

これらの digital identity models に見られる役割と機能には、次のものがあります。

Subject: 本ガイドラインにおいて subject は person を指し、digital identity のプロセスにおける位置に応じて、次の 3 つの役割のいずれかで表されます。

Applicant — identity proofing と enrollment を受ける subject。
Subscriber — identity proofing と enrollment のプロセスを正常に完了した、または online service へのアクセスのために正常に認証された subject。
Claimant — authentication を受ける資格があると「主張（making a claim）」する subject。

Service provider: Service providers は、online services へのアクセスを許可し提供することに関わる機能の任意の組み合わせを実行できます。例として、credential service provider、relying party、verifier、identity provider などがあります。

Credential service provider (CSP): CSP の機能には、applicants の identity proofing、identity service への enrollment、subscriber accounts の確立、そして authenticators をそれらの account に binding することが含まれます。subscriber account とは、CSP が確立した、subscriber、その subscriber の attributes、および関連付けられた authenticators の記録です。CSP の機能は、独立した third party によって実行される場合もあります。

Relying party (RP): RPs は online transactions と services を提供し、verifier の subscriber identity に関する assertion に依拠して、それらの services へのアクセスを許可します。federation を使用する場合、RP は identity provider (IdP) からの assertions を通じて subscriber account 内の情報にアクセスします。

Verifier: verifier は、authentication protocol を用いて、claimant が 1 つ以上の authenticators を possession and control していることを検証することにより、claimant の identity を確認します。そのために verifier は、authenticators が subscriber account と binding されていることを確認し、subscriber account が有効であることを確認する必要があります。

Identity provider (IdP): federation を使用する場合、IdP は subscriber の primary authenticators を管理し、subscriber account に基づく assertions を発行します。

別個の役割として提示されていますが、CSP、verifier、IdP の機能は、実装に応じて単一の entity が担う場合も、複数の entity に分散する場合もあります（[Sec. 2.5] を参照）。

2.2. Identity Proofing and Enrollment

[SP800-63A] Digital Identity Guidelines: Identity Proofing and Enrollment は、identity proofing と enrollment のプロセスに関する一般的なガイダンス情報と normative requirements、ならびに IAL 固有の要件を提供します。

[SP800-63A] は、identity proofing と enrollment のプロセスに関する一般情報と normative requirements、ならびに IALs に固有の要件を提供します。

[Figure 1] は、identity proofing と enrollment の機能における一般的な transaction sequence を示します。

identity proofing と enrollment は、applicant が identity proofing を開始するときに始まります。多くの場合、CSP が提供する online application へのアクセスを試みることで開始されます。CSP またはその構成サービスは、identity evidence と attributes を applicant に要求し、applicant はそれをオンラインまたは対面の transaction を通じて提出します。CSP は user を resolution し（すなわち user を一意に識別し）、evidence の正確性と authenticity を validation し、attributes の正確性を validation します。applicant が正常に identity-proofed されると、その applicant は当該 CSP の subscriber として identity service に enrollment されます。その後、一意の subscriber account が作成され、1 つ以上の authenticators がその account に registration されます。

subscribers には、自身の authenticators の control を維持し（例：盗難への備え）、CSP との良好な状態を保つために CSP policies に従う責務があります。

[Fig. 1. Sample identity proofing and enrollment digital identity model]

![Sequence diagram of identity proofing and enrollment showing the parties involved and the major steps in the process.]

2.2.1. Subscriber Accounts

enrollment の時点で、CSP は subscriber account を確立し、各 subscriber を一意に識別し、subscriber に関する情報と、その subscriber account に binding されたあらゆる authenticators の情報を記録します。

詳細および normative requirements については、[Sec. 5 of [SP800-63A]] subscriber accounts を参照してください。

2.3. Authentication and Authenticator Management

[SP800-63B] Authentication and Authenticator Management は、許容される authenticator types、その特性（例：phishing resistance）、および各 AAL に適した authentication processes の normative な説明を提供します。

2.3.1. Authenticators

authenticator は、authentication protocol において、1 つ以上の factor の control または possession を示すための手段です。本ガイドラインは、authentication に用いられる 3 種類の authentication factors を定義します。

Something you know（例：password）
Something you have（例：cryptographic key を含む device）
Something you are（例：fingerprint やその他の biometrics characteristic data）

single-factor authentication は、上記のうち 1 つの factor のみを要求し、最も多いのは「something you know」です。同一の factor を複数用いても single-factor authentication に該当します。たとえば、user-generated PIN と password は、いずれも「something you know」であるため、2 factors にはなりません。multi-factor authentication (MFA) は、1 つを超える異なる factor を用いることを指します。

本ガイドラインは、authenticators が常に secret を含む、または secret から構成されることを規定します。authenticator に含まれる secrets は、key pairs（すなわち asymmetric cryptographic keys）または shared secrets に基づきます。shared secrets には、symmetric cryptographic keys、one-time passwords (OTP) を生成するための seeds、passwords が含まれます。asymmetric key pairs は、public key と、それに対応する private key から構成されます。private key は authenticator に格納され、authenticators を possession and control する claimant の利用にのみ提供されます。symmetric keys は一般に、network-based guessing attacks を阻止するのに十分な、ランダムで複雑かつ長いものが選ばれ、subscriber が control する hardware または software に保存されます。

multi-factor authenticator の activation factor としてローカルで用いられる passwords は、activation secrets と呼ばれます。activation secret は、保存された authentication key へのアクセスを得るために使用され、authenticator と、それに関連付けられた user endpoint の内側にとどまります。activation secret の例としては、PIV card を有効化するために用いられる PIN が挙げられます。

biometric characteristics は、authentication の地点に物理的に存在する person の identity を verification するために利用できる、一意で個人的な attributes です。これには、顔の特徴、fingerprints、虹彩のパターンなどが含まれます（ただしこれらに限定されません）。biometric characteristics は single-factor authentication には使用できませんが、physical authenticator（すなわち something you have）と組み合わせることで、multi-factor authentication の authentication factor として利用できます。

一般に使用されている authentication methods の中には secret を含まない、または secret から構成されないものがあり、そのため本ガイドラインの下では使用が受け入れられません。例として次のものがあります。

knowledge-based authentication (KBA) は、claimant のみが知っているはずの質問に claimant が回答するよう促しますが、digital authentication の secret として受け入れ可能なものには該当しません。
biometric characteristic は secret に該当せず、single-factor authenticator として使用できません。

2.3.2. Authentication Process

authentication process は、ある水準の assurance において、claimant が本人の申告どおりの人物であると RP が信頼できるようにします。[Fig. 2] の sample authentication process は、RP、claimant、verifier/CSP の間の interaction を示しています。verifier は機能上の役割であり、しばしば CSP、RP、またはその両方と組み合わせて実装されます（[Fig. 4] に示すとおり）。

[Fig. 2. Sample authentication process]

![Sequence diagram of a sample authentication process showing parties involved and major steps in the process.]

authentication process が成功すると、claimant が subscriber の identity に binding された 1 つ以上の有効な authenticators を possession and control していることが示されます。一般にこれは、verifier と claimant の interaction を伴う authentication protocol を用いて行われます。このとき claimant は、1 つ以上の authenticators を用いて authenticator output を生成し、それを verifier に送信します。verifier はその output を検証し、肯定的な結果を RP に渡します。その後 RP は、verification された subscriber と authenticated session を開始します。

interaction の正確な性質は、システム全体の security を判断するうえで重要です。適切に設計された protocols は、authentication の最中およびその後において、claimant と verifier の間の通信の integrity と confidentiality を保護し、正当な verifier を装う attacker（すなわち phishing）による被害を抑える助けになります。

2.4. Federation and Assertions

Normative requirements は、[SP800-63C] Federation and Assertions に記載されています。

OMB [M-19-17] の Section III（Enabling Mission Delivery through Improved Identity, Credential, and Access Management）は、機関に対して、政府横断の identity federation と相互運用性を支援するよう指示しています。federation という用語は、異なる trust domains 間で情報を共有する複数のアプローチに適用でき、また domains 間で共有される情報の種類に応じて異なる場合があります。本ガイドラインは、ネットワーク化された systems の集合に対し、trust agreements に基づいて identity および authentication information を federation assertions を通じて伝達できるようにする federation processes を扱います。

federated architectures を使用することには、次を含む（ただしこれらに限定されない）多くの利点があります。

user experience の向上（例：subject は一度だけ identity-proofed されればよく、その subscriber account を複数の RPs で使用できる）
subscriber（例：authenticators の削減）と組織（例：information technology infrastructure の削減とアーキテクチャの簡素化）の双方にとってのコスト削減
各 application へ account values を複製する代わりに、pseudonymous identifiers と derived attribute values を用いることで、RPs に露出するデータを最小化
組織が複雑な identity management processes に投入するリソースを減らせるため、mission success を支援

federation process は一般に、RP と IdP が共通の security domain の下で一体的に管理されていない場合における authentication の望ましいアプローチですが、federation は単一の security domain 内にも適用でき、centralized account management や技術的統合など、さまざまな利点をもたらします。

本ガイドラインは、組織が選択する identity proofing、authentication、federation のアーキテクチャに依存せず、組織が自らの要件に従って digital identity scheme を展開できるようにします。しかし、組織または個別の applications にローカルな identity services を確立するよりも、federation の方が効率的かつ有効になり得るシナリオがあります。例として次のものがあります。

潜在的な利用者が、要求される AAL 以上の authenticator をすでに持っている。
想定されるすべての利用者コミュニティをカバーするために、複数種類の authenticators が必要である。
組織が subscriber accounts の管理（例：account recovery、authenticator issuance、help desk）を支えるための必要なインフラを持っていない。
RP の実装を変更せずに、primary authenticators を時間の経過とともに追加・更新できるようにしたい。
federation protocols は network-based であり、幅広い platforms と languages 上での実装を可能にするため、異なる環境を支援する必要がある。
潜在的な利用者が複数のコミュニティにまたがり、それぞれが既存の identity infrastructure を持っている。
組織が、account revocation や新しい authenticators の binding を含む account life cycles を中央で管理できる能力を必要としている。

\clearpage

次のいずれかに当てはまる場合、組織は federated identity attributes の受け入れを検討したいと考えるかもしれません。

pseudonymity が、サービスへアクセスする stakeholders にとって要求される、必要である、実現可能である、または重要である。
サービスへのアクセスに、定義済みの attributes のリストが必要である。
サービスへのアクセスに、少なくとも 1 つの derived attribute value が必要である。
組織が、必要な attributes の authoritative source または issuing source ではない。
attributes が利用中に一時的に必要であり（例：アクセス判断のため）、組織がそのデータを保持する必要がない。

2.5. Examples of Digital Identity Models

non-federated digital identity model を構成する entities と interactions は、[Fig. 3] に示されています。general-purpose federated digital identity model は [Fig. 4] に示され、subscriber-controlled wallet を伴う federated digital identity model は [Fig. 5] に示されています。

[Fig. 3] と [Fig. 4] で説明される 2 つのケースでは、verifier は authentication activity を完了するために、常に CSP とリアルタイムで通信する必要はありません（例：digital certificates を使用できる）。したがって、verifier と CSP の間の線は、両 entity の間の論理的なリンクを表します。いくつかの実装では、verifier、RP、CSP の機能は分散しています。しかし、これらの機能が同一 platform 上に存在する場合、機能間の interactions は、network protocols を用いるのではなく、同一 system 上で動作する applications または application modules 間の信号になります。

2.5.1. Non-Federated Digital Identity Model

[Fig. 3. Non-federated digital identity model example]

![High-level diagram of a non-federated digital identity model showing the entities and interactions between entities of the entire digital identity process, in which the verifier function is done by the RP.]

[Figure 3] は、non-federated model における一般的な interactions の順序の例を示しています。別の順序でも、同じ機能要件を満たすことができます。identity proofing と enrollment activities に関わる一般的な interactions の順序の 1 つは、次のとおりです。

Step 1: applicant は identity proofing と enrollment のプロセスを通じて CSP に申請します。CSP はその applicant を identity-proofed します。
Step 2: identity proofing が成功すると、applicant は subscriber として identity service に enrollment されます。
- subscriber account と対応する authenticators が、CSP と subscriber の間で確立されます。CSP は subscriber account、その status、および enrollment data を maintain します。subscriber は自分の authenticators を maintain します。

Steps 3 から 5 は、steps 1 と 2 に直ちに続けて行うことも、後日に行うこともできます。non-federated model において、1 つ以上の authenticators を用いて digital authentication を行う際の一般的な interactions の順序は、次のとおりです。

Step 3: claimant は RP とのオンラインの interaction を開始し、RP は claimant に authentication を要求します。
Step 4: claimant は authentication process を通じて、verifier 機能に対して authenticators の possession and control を示します。
- verifier は CSP とやり取りし、subscriber account 内で、claimant の identity が authenticators に binding されていることを verify し、必要に応じて追加の subscriber attributes を取得します。
- service provider の CSP または verifier の機能は subscriber に関する情報を提供します。RP は必要とする attributes を CSP に要求します。RP は、この情報を用いて authorization decisions を行うことがあります。
Step 5: subscriber と RP の間に authenticated session が確立されます。

2.5.2. Federated Digital Identity Model With General-Purpose IdP

[Fig. 4. Federated digital identity model example]

![High-level diagram of a federated digital identity model showing the entities and interactions between entities of the entire digital identity process, in which the CSP and verifier functions are done by the IdP.]

[Figure 4] は、federated model における同様の一般的な interactions の例を示しています。

Step 1: applicant は identity proofing と enrollment のプロセスを通じて CSP に申請します。CSP はその applicant を identity-proofed します。
Step 2: identity proofing が成功すると、applicant は subscriber として identity service に enrollment されます。
- subscriber account と対応する authenticators が、CSP と subscriber の間で確立されます。
- IdP は、CSP により直接 provisioning されるか、subscriber account の attributes へのアクセスを通じて間接的に provisioning されます。CSP は subscriber account、その status、および [Sec. 3.1 of [SP800-63A]] に記載された records retention and disposal requirements に従って収集された enrollment data を maintain します。subscriber は自分の authenticators を maintain します。IdP は、subscriber account に対する自らの view、subscriber account に割り当てられたあらゆる federated identifiers、ならびに RPs に attributes と情報を release することに関する policies と decisions を maintain します。

federated model において、1 つ以上の authenticators を用いて digital authentication を行う際の一般的な interactions の順序は、次のとおりです。

Step 3: RP は claimant に authentication を要求し、アクセスまたは authorization decisions のために必要な attributes を IdP に要求します。これにより、IdP に対して federated authentication の要求がトリガーされます。
Step 4: claimant は authentication process を通じて、IdP の verifier 機能に対して authenticators の possession and control を示します。
- claimant の authenticators の binding が、claimed subscriber account に binding されたものと照合されて verify され、必要に応じて追加の subscriber attributes を取得します。
Step 5: RP と IdP は federation protocol を通じて通信します。IdP は federation protocol を通じて、assertion と、必要な追加 attributes を RP に提供します。RP は assertion を verify して、RP の online service へのアクセスのために subscriber の identity と attributes に対する confidence を確立します。RPs は、subscriber の federated identity（pseudonymous または non-pseudonymous）、IAL、AAL、FAL、その他の要因を用いて authorization decisions を行います。
Step 6: subscriber と RP の間に authenticated session が確立されます。

2.5.3. Federated Digital Identity Model with Subscriber-Controlled Wallet

[Fig. 5. Federated Digital Identity Model With Subscriber-Controlled Wallet Example]

![High-level diagram of a federated digital identity model with a subscriber-controlled wallet showing the entities and interactions between entities of the entire digital identity process in which the subscriber controls a device with software (commonly known as a digital wallet) that acts as the IdP.]

[Figure 5] は、subscriber が software を備えた device（すなわち digital wallet）を control する、または IdP として機能する cloud service provider の account（すなわち hosted-wallet）を control する federated digital identity model における interactions の例を示しています。「three-party model」の用語では、CSP は issuer、IdP は holder（すなわち利用者の device、または利用者の behalf で動作する agent）、RP は verifier です。このモデルでは、[Sec. 3.5 of [SP800-63C]] で定義される federation authority を用いて、RP が CSP と trust agreement を確立することが一般的です。この構成により、[Sec. 5 of [SP800-63C]] で述べられているとおり、RP は wallet と直接の trust relationship を持たなくても、subscriber-controlled wallet からの assertions を受け入れられます。

Step 1: applicant は CSP の identity proofing と enrollment のプロセスに申請します。
Step 2: identity proofing が成功すると、applicant は onboarding process を経て subscriber として identity service に enrollment されます。
Step 3: subscriber-controlled wallet は CSP により onboard され、後続の steps で IdP の役割を担えるようになります。
- subscriber は、subscriber account に認証することで CSP の issuance functionality に認証するか、subscriber account によって表される user と同一であることを示すために省略された proofing process を完了します。
- subscriber は activation factor を用いて subscriber-controlled wallet を activation します。
- wallet は signing key と対応する verification key を生成または選択し、wallet が保持する key の proof も含めます。
- CSP は、subscriber attributes と wallet の verification key（またはその key への reference）を含む 1 つ以上の attribute bundles を作成します。
- CSP は、対応する verification key を伴う attribute bundle を subscriber-controlled wallet に issue します。

他の protocols や specifications では、attribute bundles を credentials と呼ぶことがよくあります。本ガイドラインでは credentials を別の概念として用います。衝突を避けるため、本ガイドラインでは attribute bundle という用語を使用します。attribute bundles に関する normative requirements は、[Sec. 3.12.1 of [SP800-63C]] に記載されています。

\clearpage

subscriber-controlled wallet から RP に assertion を提供する際の一般的な interactions の順序は、次のとおりです。

Step 4: RP は claimant に authentication を要求します。これにより、wallet に対して federated authentication の要求がトリガーされます。
Step 5: claimant は subscriber-controlled wallet の possession and control を示します。
- claimant は activation factor を用いて wallet を activation するか、subscriber-controlled wallet が service provider により hosted されている場合は hosted service に認証します。
- wallet は、subscriber account のために CSP が提供した attribute bundle を含む assertion を準備します。
Step 6: RP と wallet は federation protocol を通じて通信します。wallet は federation protocol を通じて、assertion、CSP-signed attribute bundles、および任意の追加 attributes を RP に提供します。RP は assertion を verify して、RP の online service へのアクセスのために subscriber の identity と attributes に対する confidence を確立します。RPs は、subscriber の federated identity（pseudonymous または non-pseudonymous）、IAL、AAL、FAL、その他の要因を用いて authorization decisions を行います。
Step 7: subscriber と RP の間に authenticated session が確立されます。

# 3. Digital Identity Risk Management

_この節は normative です。_

本節では、online services に関連する digital identity
のリスクを評価するための方法論を説明します。これには、online service
の利用者に残る residual risks、service provider 組織、およびその mission と
business partners に対する residual risks
が含まれます。また、それらのリスクを軽減するために、利用しやすく、privacy
を強化する security、および anti-fraud controls
を選択するためのガイダンスを提示します。さらに、選択した controls
の性能を継続的に評価することの重要性を強調します。

Digital Identity Risk Management (DIRM) のプロセスは、2
つの次元に沿ってリスクを特定し管理することに焦点を当てます。(1) online service
を運用することに起因し、identity system
によって対処できる可能性があるリスク、(2) identity system
を実装することにより追加で導入されるリスク、です。

第 1 の次元のリスクは、初期の assurance level の選択に影響し、online service の
compromise に関連し、identity system
によって対処できる可能性があるリスクの特定を目指します。例えば、次のとおりです。

- Identity proofing: imposter が正当な利用者の identity を用いて service
  へのアクセスを得たり credential
  を受け取ったりした場合に、合理的に想定される負の影響（例：attacker
  が誰かになりすますことに成功する）
- Authentication: false claimant が正当に自分のものではない account
  にアクセスした場合に、合理的に想定される負の影響（例：authenticator を
  compromise または盗む attacker）。これはしばしば account takeover attack
  と呼ばれます
- Federation: 誤った subject が online service、system、または data
  に正常にアクセスした場合に、合理的に想定される負の影響（例：assertion の
  compromise または replay）

online service の compromise に関連し、identity system
で対処できるリスクがある場合、初期 assurance level を選択し、その後に第 2
の次元のリスクを検討します。

第 2 の次元のリスクは、identity system
そのものがもたらすリスクの特定を目指し、tailoring
のプロセスに影響します。Tailoring は、初期に評価した assurance level
を修正する、compensating controls または supplemental controls
を実装する、または privacy、usability、現実世界の脅威に対する resilience
といった領域で継続的に実施される詳細な risk assessments に基づいて選択済み
controls を修正するためのプロセスを提供します。

identity system
そのものにより導入されるリスクから生じ得る影響のタイプの例には、次のものがあります。

- Identity proofing: identity proofing のプロセス全体で subject
  が直面する障壁により、正当な subject の identity proofing と enrollment
  が成功しないことによる影響、identity proofing
  のプロセスを支えるために収集・保持された情報の breach
  の被害に遭うことによる影響、または初期 IAL が特定の threats、threat
  actors、fraud に完全には対処できないことによる影響
- Authentication: subject が authenticator を提示する際に直面する障壁（usability
  の問題による障壁を含む）により、正しい subject の authentication
  に失敗することによる影響、初期 AAL が targeted な account takeover models
  に完全には対処できないことによる影響、または特定の authenticator types
  が想定される attacks を軽減できないことによる影響
- Federation: 誤った online service または system に対して real subscriber
  attributes を release してしまうことによる影響、または正当な RP
  に対して不正確または偽の attributes を release してしまうことによる影響

DIRM プロセスの outcomes は、digital identity model の中で entity
が果たす役割に依存します。

1. **relying parties** に対しては、このプロセスの意図は、online services
   および、それらの services を構成する、またはそれらの services
   により影響を受ける applications、transactions、systems を保護するために必要な
   assurance levels と、必要となる tailoring を決定することです。これは、CSP
   services の選択、開発、調達に直接的に寄与します。連邦 RPs は、すべての online
   services について DIRM プロセスを実装 **SHALL** します。
2. **credential service providers and identity providers**
   に対しては、このプロセスの意図は、定義された assurance levels の要件を満たす
   service offerings を設計し、identity system に対する compromises
   を継続的に防御し、RPs のニーズを満たすことです。service offering が normative
   guidance から逸脱する場合、その逸脱は、当該 service を利用する RPs
   に対して明確に伝達 **SHALL** されます。

CSPs と IdPs は、サービス対象の RPs が要求する assurance levels
でのサービスを提供することが期待されています。しかし、本ガイドラインから逸脱する、またはサービスを増強することを選択する
CSPs と IdPs は、簡略化された digital identity risk assessment
を実施し、その変更点を Digital Identity Acceptance Statement に文書化して RPs
に提供することが期待されています（Sec. 3.4.4 を参照）。

このプロセスは、[FISMA] により要求される risk management
プロセスを補強します。online service に対する DIRM impact assessment
の結果は、基盤となる application または system の FISMA impact level
と異なる場合があります。identity
プロセスの失敗は、利用者グループによって異なる水準の影響をもたらし得ます。例えば、決済
system に対する全体として評価された FISMA impact level は、機微な金融 data が
system により processing されるため、「FISMA Moderate」の impact category
になる場合があります。しかし、永続的な account が確立されない guest payments
を行う個人に対しては、authentication と proofing の impact levels
がより低い場合があります。機関の authorizing officials は、online service
を支える基盤 information system の authority to operate (ATO) の一部として、DIRM
プロセスへの adherence
を示す文書を要求することが望まれます（**SHOULD**）。機関の authorizing officials
はまた、CSPs との統合に向けた procurement または ATO プロセスの一部として、DIRM
プロセスへの adherence を示す CSPs
からの文書を要求することが望まれます（**SHOULD**）。

> 本ガイドラインは「FISMA impact level」という用語を使用します。NIST RMF
> の他の刊行物でも、この種の impact categorization を指して system impact level
> という用語が使用されています。

DIRM プロセスには 5 つの step があります。

1. **Define the online service:** 出発点として、組織は、online service の機能
   scope、対象として意図される user groups、各 user group に利用可能な online
   transactions の種類、そして online service がその interfaces を通じて
   processing する基盤 data という観点から、online service
   の説明を文書化します。online service がより広い business process
   の一要素である場合、その役割を文書化し、online service により収集・processing
   されるあらゆる data の用途も文書化します。さらに、組織は、online service
   と、それが一部を構成するより広い business process によって影響を受ける entity
   を特定する必要があります。結果として、online
   service、その利用者、そしてその機能によって影響を受け得る entity
   の説明が得られます。
2. **Conduct initial impact assessment:** この step では、organizations
   は、identity system（すなわち identity proofing、authentication、または
   federation）によって対処できる可能性がある、online service の compromise
   による impacts を評価します。online service の各機能は、定義された harms と
   impact categories のセットに照らして評価されます。online service の各 user
   group は、その user group に利用可能な transactions（すなわち、online service
   の data と機能に対して、その group に付与される
   permissions）に基づいて、個別に検討されます。この step の outcome は、online
   service の各 user group に利用可能な transactions
   を考慮して決定される、impact categories と、それに関連付けられた impact
   levels の文書化されたセットです。
3. **Select initial assurance levels:** この step では、impact categories と
   impact levels を評価し、不正アクセスと fraud から online service
   を保護するための初期 assurance levels を決定します。assurance levels
   を用いて、組織は、関連巻 [SP800-63A]、[SP800-63B]、および [SP800-63C]
   にそれぞれ記載される要件に基づき、各 user group について IAL、AAL、FAL の
   baseline controls を特定します。この step の outcome は、適用可能な場合、各
   user group に対して初期 IAL、AAL、FAL が特定されることです。
4. **Tailor and document assurance level determinations:** この step
   では、詳細な assessments を実施する、または活用して、当初選択した assurance
   levels とそれに関連付けられた controls が privacy、customer
   experience、現在の脅威環境への resistance
   に与える潜在的影響を判断します。Tailoring の結果として、当初評価した
   assurance level の修正、compensating controls または supplemental controls
   の特定（Sec. 3.4.2 および Sec. 3.4.3
   を参照）、またはその両方が生じ得ます。すべての assessments と最終 decision
   は文書化され、正当化されます。outcome は、定義され実装可能な assurance levels
   のセットと、online service の最終的な controls のセットを備えた Digital
   Identity Acceptance Statement（Sec. 3.4.4 を参照）です。
5. **Continuously evaluate and improve:** この step では、identity management
   approach の performance
   に関する情報を収集し評価します。この評価では、business impacts、fraud rates
   への影響、利用者コミュニティへの impacts
   など、多様な要因を考慮します。この情報は、選択した assurance levels と
   controls が mission、business、security、そして（該当する場合には）program
   integrity
   のニーズを満たしているかどうかを判断するうえで不可欠です。また、privacy と
   access に影響する意図しない harms
   を監視する助けにもなります。脅威の状況が進化していくことを綿密に監視し、それらの脅威に対抗し、customer
   experience を改善し、または privacy
   を強化できる新技術や手法を調査することで、改善の機会も検討されるべきです。この
   step の outcomes は、performance
   metrics、評価と救済のための文書化された透明性のあるプロセス、そして identity
   management approach の継続的改善です。

[Fig. 6. High-level diagram of the DIRM Process Flow]

High-level diagram of the Digital Identity Risk Management Process Flow showing
the five steps along with major activities and outcomes for each step

[Figure 6] は、DIRM process flow の各 step における主要な actions と outcomes
を示します。段階的アプローチとして提示されていますが、プロセスには、逐次順序からの逸脱を要する多くの点があり得ます。これには、初期タスクの実行とタスクの再訪との間で反復サイクルが必要になることも含まれます。例えば、assessment
が進行中に新たな規制や要件が導入された場合、組織はプロセスの step
を再訪する必要があるかもしれません。さらに、新機能、data usage
の変更、脅威環境の変化により、組織は DIRM プロセスのいずれの時点でも steps
を再訪する必要が生じ得ます。これには、online service の assurance levels
および／または関連 controls を修正する可能性も含まれます。

組織は、組織のプロセス、governance、enterprise risk management practices
に適合するように、この全体的アプローチを適応・修正することが望まれます（**SHOULD**）。最低限、組織は、DIRM
プロセス全体で用いられる組織固有のプロセスや tools の有無に関わらず、各 step
を実行して文書化し、各 step の normative mandates と outcomes を完了して文書化
**SHALL** します。加えて、組織は、online service
の利用者集団の代表的サンプルと協議し、identity management system の設計と
performance 評価に反映させることが望まれます（**SHOULD**）。

## 3.1. Define the Online Service

online service
を定義する目的は、その機能を理解し、その文脈について共通理解を確立することです。これにより、DIRM
プロセスの後続 steps に情報が提供されます。online service の役割は、より広い
business environment と関連プロセスの一部として文脈化され、online service の
scope、user groups とその期待、processing される data、影響を受ける
entities、その他の関連事項について、文書化された記述が得られます。

RPs は、最低限、次を含む online service の説明を作成 **SHALL** します。

- online service が支える組織の mission および business objectives
- online service に関連する mission および business partner への依存関係
- online service に適用される privacy obligations
  を含む、法的、規制上、契約上の要件
- online service の機能、および processing が想定される data
- online service へのアクセスが必要な user groups、ならびに各 user group
  に利用可能な online transactions の種類と access privileges
- online service、およびそれが一部を構成するより広い business process
  によって影響を受ける entities のセット（online service
  の利用者、組織、サービス対象の集団を含む）
- 既存の DIRM assessments の結果（入力として）および既存 identity
  technologies（すなわち proofing、authentication、または federation）の現状
- 提供対象となるすべての user groups にわたり、identity proofing に必要な
  identity evidence の種類が利用可能である見込み

digital identity system の failure により、不正な user が online service
へのアクセスを得た結果として、異なる entities
に対して生じる予期しない・望ましくない影響、および影響の規模を考慮することは不可欠です。例えば、attacker
が発電所を制御する online service に不正アクセスした場合、悪意ある行為者が取る
actions
は、施設の近隣に住む地域住民に壊滅的な環境影響を与え、発電所がサービスを提供する地域で停電を引き起こす可能性があります。

本書で述べるとおり、_user groups_ と _impacted entities_
を区別することが重要です。online service
は、一定の利用者集合にアクセスを許可し、それらの利用者は、当該 user group
に提供される機能の種類に基づいて、いくつかの user groups
に分割される場合があります。例えば、オンラインの所得税申告および審査サービスには、次の
user groups があり得ます。(1) 個人の tax returns の status
を確認する必要がある市民、(2) 顧客に代わって tax returns を提出する税理士等、(3)
利用者グループに privileges を割り当てたり、必要に応じて新しい user groups
を作成したりする system administrators。Impacted entities には、digital identity
system の failure
が発生した場合に負の結果に直面し得るすべての者が含まれます。これには user groups
の構成員が含まれる可能性が高いものの、system
を直接使用しない者も含まれる場合があります。

したがって、impact assessments の scope には、online application
の利用者だけでなく組織自体も含まれ **SHALL** します。さらに、組織は、mission と
business needs に基づき、特に含める必要がある他の entities（例：mission
partners、communities、および [SP800-30] で特定されるもの）を特定 **SHALL**
します。最低限、組織は、impact assessments を実施する際に、影響を受けるすべての
entities（組織の内部および外部の双方）を文書化 **SHALL** します。

**この step の output は、online service の文書化された説明であり、online
service が提供する機能によって影響を受ける user groups およびその他の entities
の一覧を含みます。この情報は、次節で詳述する impact assessments
を効果的に適用するための基礎となり、文脈を確立します。**

## 3.2. Conduct Initial Impact Assessment

DIRM プロセスのこの step は、第 1 の次元のリスクを扱い、identity system
によって対処できる可能性がある online service へのリスクを特定します。

initial impact assessment の目的は、online service に固有の identity
proofing、authentication、federation の failures がもたらす潜在的な adverse
impacts を特定し、初期 assurance levels のセットを得ることです。RPs は、この
step を実施する際、過去データおよび user focus groups
の結果を考慮することが望まれます（**SHOULD**）。impact assessment には次を含め
**SHALL** します。

- impact categories のセットと、各 impact category に対する潜在的 harms の特定
- impact の levels の特定
- 各 user group に対する impact の level の評価

Sec. 3.1（Define the Online Service）で特定された各 user group に対する impact
の level は、その user group に利用可能な transactions に基づいて個別に考慮
**SHALL** されます。これにより組織は、各 user group に適切な assurance levels
を選択・実装するうえで最大限の柔軟性を得られます。user groups、組織、その他の
entities への impacts が impact assessments
の主要な考慮事項である一方で、組織は規模（例：transactions の影響を受ける
persons の数）も考慮することが望まれます（**SHOULD**）。

**この assessment の output は、各 user group に対して定義された impact
level（すなわち Low、Moderate、または High）です。これは、初期 assurance level
選択への主要な input となります。**

3.3. Identify Impact Categories and Potential Harms

オンラインサービスには、サービスが提供する機能にアクセスするためにauthenticationを行う、個別のユーザおよびユーザグループの集合が存在する。一方で、identity proofing、authentication、またはfederationにおける誤りにより、なりすまし者や攻撃者がオンラインサービスに不正アクセスを得た場合、その影響を受けるentityは、これらのユーザ／ユーザグループよりもはるかに大きな集合となり得る。Sec. 3.1では、このような影響を受けるentityを、オンラインサービスを定義する作業の一部として特定し、文書化する。

このステップでは、組織は、対象のオンラインサービスについて影響を受けるentityに適用されるimpactのカテゴリを特定する。最低限、組織はimpact assessmentにおいて、以下のimpactカテゴリを含めなければならない（SHALL）:

ミッション遂行の劣化
信頼、地位、または評判への損害
情報への不正アクセス
金銭的損失または責任
生命の喪失、または人の安全・人の健康・環境の健康に対する危険

組織は、そのミッションおよび事業目的に基づき、適切に追加のimpactカテゴリを含めるべきである（SHOULD）。各impactカテゴリは文書化され、組織が提供する異なるオンラインサービス全体でDIRMプロセスを実装する際に、一貫して適用されなければならない（SHALL）。

harmsとは、影響を受けるentityが被る、あらゆる不利益な影響を指す。harmsは、impactカテゴリと、それらがオンラインサービスの影響を受ける特定のentityにどのように当てはまり得るかを、効果的に理解するための手段を提供する。各impactカテゴリについて、組織は、Sec. 3.1で特定した影響を受けるentityそれぞれに対する潜在的なharmsを考慮しなければならない（SHALL）。

各カテゴリに関連するharmsの例には、以下が含まれる:

ミッション遂行の劣化:
- 個人に対するharmsには、資格があるにもかかわらず、政府のサービスまたは給付にアクセスできないことが含まれ得る。
- 組織（オンラインサービスを提供する組織、およびオンラインサービスによって支援される組織を含む）に対するharmsには、十分に適時な形で、十分な確信および／または正確性をもって、または計画された資源制約の範囲内で、現行のミッション／事業機能を実行できないこと、あるいは将来においてミッション／事業機能を実行できない、または実行能力が限定されることが含まれ得る。
信頼、地位、または評判への損害:
- 個人に対するharmsには、なりすましの結果としてのイメージまたは評判の毀損が含まれ得る。
- 組織に対するharmsには、負のイメージの助長、既存の信頼関係の悪化、または将来の潜在的な新たな信頼関係を構築できないことにつながる、評判の毀損が含まれ得る。
情報への不正アクセス:
- 個人に対するharmsには、personal informationまたはその他の機微な情報の漏えいが含まれ得る。これにより、金銭的損失、生命の喪失、身体的または心理的な傷害、なりすまし、identity theft、または継続的な不便といった二次的なharmsが生じ得る。
- 組織に対するharmsには、知的財産の持ち出し、削除、劣化、または露出、あるいは機密資料やcontrolled unclassified information (CUI)などの他の情報資産の不正な開示が含まれ得る。
金銭的損失または責任:
- 個人に対するharmsには、詐欺またはその他のharmの結果として負債が生じる、または資産を失うこと、信用の毀損または喪失、実際のまたは潜在的な雇用や収入源の喪失、住居の喪失、および／またはその他の金銭的損失が含まれ得る。
- 組織に対するharmsには、詐欺またはその他の犯罪行為に関連する費用、資産の喪失、価値の低下、または事業の喪失が含まれ得る。
生命の喪失、または人の安全・人の健康・環境の健康に対する危険:
- 個人に対するharmsには、死亡または身体的健康の損傷が含まれ得る。これにより、精神的または情緒的な健康への損傷といった二次的なharms、あるいは地域環境が居住不能となり、潜在的または実際の損害に対処するための介入が必要となるような、環境の健康への影響が生じ得る。
- 組織に対するharmsには、組織の労働力の損傷または喪失、あるいは周辺環境への損傷と、その後の危険な状況の影響が含まれ得る。

この活動の成果は、影響を受けるentityに対する不利益な結果を評価するために用いられる、impactカテゴリとharmsの一覧である。

3.3.1. Identify Potential Impact Levels

このステップでは、組織は、選定したimpactカテゴリそれぞれについて、権限のないユーザがオンラインサービスへのアクセスを得ることによって生じ得るpotential impactのlevelを評価する（Sec. 3.2.1より）。impact levelは、以下のpotential impact valueのいずれかを用いて割り当てられる:

Low: 限定的な不利益な影響が見込まれる
Moderate: 深刻な不利益な影響が見込まれる
High: 重大または壊滅的な不利益な影響が見込まれる

各ユーザグループは、オンラインサービスを通じて、異なる権限および機能の集合を持ち得る。したがって、特定のユーザグループの一員として侵入者が不正アクセスを得た結果として、各impactカテゴリにおける影響を受けるentityの各集合に対する不利益な結果を検討する必要がある。impact level割り当ての、より客観的な根拠を提供するために、組織は、各impactカテゴリについてimpact levelの閾値および例を策定すべきである（SHOULD）。これを行う場合、特に具体的に定義された定量的な値を伴う場合、これらの閾値は文書化され、組織全体におけるDIRM assessmentで一貫して使用されなければならない（SHALL）。これにより、リスクに関する共通理解が可能になる。

各impactカテゴリにおけるpotential impactsの例には、以下が含まれる:

ミッション遂行の劣化:
- Low: 限定的なミッション能力の劣化をもたらすと見込まれ、組織は主要機能を実行できるが、効果がいくらか低下する
- Moderate: 深刻なミッション能力の劣化をもたらすと見込まれ、組織は主要機能を実行できるが、効果が大幅に低下する
- High: 重大または壊滅的なミッション能力の劣化、または損失を一定期間にわたりもたらすと見込まれ、組織が主要機能の1つ以上を実行できなくなる
信頼、地位、または評判への損害:
- Low: いずれの当事者に対しても、限定的で短期の不便、苦痛、または困惑をもたらすと見込まれる
- Moderate: いずれの当事者に対しても、深刻な短期の不便、または限定的な長期の不便、苦痛、または地位・評判への損害をもたらすと見込まれる
- High: いずれの当事者、または多数の個人に対して、重大な、または深刻な長期の不便、苦痛、または地位・評判への損害をもたらすと見込まれる
情報への不正アクセス:
- Low: [FIPS199]で定義されるとおり、組織の運用、組織資産、または個人に対して、限定的な不利益な影響が見込まれる
- Moderate: [FIPS199]で定義されるとおり、組織の運用、組織資産、または個人に対して、深刻な不利益な影響が見込まれる
- High: [FIPS199]で定義されるとおり、組織の運用、組織資産、または個人に対して、重大または壊滅的な不利益な影響が見込まれる
金銭的損失または金銭的責任:
- Low: いずれの当事者に対しても、限定的な金銭的損失または責任をもたらすと見込まれる
- Moderate: いずれの当事者に対しても、深刻な金銭的損失または責任をもたらすと見込まれる
- High: いずれの当事者に対しても、重大または壊滅的な金銭的損失または責任をもたらすと見込まれる
生命の喪失、または人の安全・人の健康・環境の健康に対する危険:
- Low: 自然に解消する、または少量の医療的対応で解消する、人の安全または健康への限定的な影響、あるいは、さらなる損害を防止するか既存の損害を回復するために、せいぜい軽微な介入しか要しない、環境の健康への限定的な影響をもたらすと見込まれる
- Moderate: 重要な医療的対応を必要とする、人の安全または健康への深刻な影響、居住不能期間を生じさせ、さらなる損害を防止するか既存の損害を回復するために重要な介入を必要とする、環境の健康への深刻な影響、または複数のlow-impact事象が重なり合うことによる複合的な影響をもたらすと見込まれる
- High: 重度の傷害、トラウマ、または死亡といった、人の安全または健康への重大または壊滅的な影響、長期または恒久的な居住不能を生じさせ、さらなる損害を防止するか既存の損害を回復するために広範な介入を必要とする、環境の健康への重大または壊滅的な影響、または複数のmoderate impact事象が重なり合うことによる複合的な影響をもたらすと見込まれる

本ガイドラインは3つのimpact levelを提供する。しかし、組織は、より細分化されたimpact levelを定義し、初期impact assessment活動のための独自の方法論を策定してもよい（MAY）。

3.3.2. Impact Analysis

impact analysisは、identity systemのいずれかの機能（すなわち、identity proofing、authentication、federation）が侵害され、特定のユーザグループの一員として侵入者がオンラインサービスへの不正アクセスを得て、影響を受けるentityに負の影響を与えるtransactionを開始することにより生じる、impact（すなわちLow、Moderate、またはHigh）のlevelを検討する。impact analysisは、以下の次元を検討する:

ユーザグループ（Sec. 3.1参照）
影響を受けるentity（Sec. 3.1参照）
impactカテゴリ（Sec. 3.2.1参照）
impact level（Sec. 3.2.2参照）

impact analysisは、各ユーザグループの一員として侵入者が不正アクセスを得た場合に、影響を受けるentityの各種別について、各impactカテゴリごとのimpactのlevelを考慮しなければならない（SHALL）。ユーザグループごとに利用可能なtransactionの集合が異なるため、このanalysisでは各ユーザグループを分けて検討することが重要である。

例えば、水処理施設の制御・運転・監視を可能にするオンラインサービスでは、各ユーザグループ（例: 施設を制御・運転する技術者、監査人および監視担当官、システム管理者）を、オンラインサービスを通じて当該ユーザグループが利用できるtransactionに基づいて個別に検討する。impact analysisは、悪意ある者がユーザグループの一員としてオンラインサービスへの不正アクセスを得た場合に、検討対象のimpactカテゴリそれぞれについて、さまざまな影響を受けるentity（例: 水を飲む住民、施設の所有組織、監査人、監視担当官）に与えるimpactのlevel（すなわちLow、Moderate、またはHigh）を評価する。

impact analysisは、オンラインサービスにアクセスできる各ユーザグループについて実施されなければならない（SHALL）。各impactカテゴリについて、identity management機能の失敗に起因するオンラインサービスの侵害の結果として、影響を受けるentityごとにimpact levelを見積もる。

あるimpactカテゴリについて、いかなるentityにもharmまたはimpactが存在しない場合、impact levelはNoneとして印を付けることができる。

このimpact analysisの出力は、各ユーザグループに対するimpact levelの集合であり、Sec. 3.4に従って、さらなるanalysisのために適切な形式で文書化されなければならない（SHALL）。

3.3.3. Determine the Combined Impact Level for Each User Group

各ユーザグループのimpact assessment levelを組み合わせ、当該ユーザグループにおけるidentity proofing、authentication、および／またはfederation機能の侵害によって、影響を受けるentityが被るリスクを代表する単一のimpact levelを確立する。

組織は、この組合せanalysisに、以下のようなさまざまな方法を適用できる:

さまざまなimpactカテゴリおよび影響を受けるentityにわたって、high-water markアプローチを用いて有効なimpact levelを導出する
異なるimpactカテゴリおよび／または影響を受けるentityに異なる重みを割り当て、平均を取って有効なimpact levelを導出する
組織のミッションおよび優先事項に整合する、その他の組合せロジック

組織は、定義した各ユーザグループについてimpact assessmentを総合的なimpact levelに結合するために用いるアプローチを文書化しなければならず（SHALL）、それを自組織のすべてのオンラインサービスにわたって一貫して適用しなければならない（SHALL）。組合せanalysisの結論として、組織は、各ユーザグループのimpactを文書化しなければならない（SHALL）。

このステップの成果は、identity management system機能（すなわち、identity proofing、authentication、federation）の侵害に起因する、各ユーザグループの有効なimpact levelである。

3.4. Select Initial Assurance Levels and Baseline Controls

有効なimpact level（すなわちLow、Moderate、またはHigh）は、各ユーザグループの初期assurance levelを選択するプロセス（Sec. 3.3.1参照）への主要な入力として機能する。これにより、付属巻 [SP800-63A], [SP800-63B], および [SP800-63C] に含まれる要件およびガイドラインから、対応するbaseline digital identity controlsの集合を特定する。結果として得られる各ユーザグループの初期assurance levelは、3つのdigital identity system機能（すなわち、identity proofing、authentication、federation）のすべてに適用される。

選定されたdigital identity controlsおよびプロセスの初期セットは、identity management systemによって生じる潜在的リスクに基づき、Step 4で評価およびtailoringされる。

3.4.1. Assurance Levels

オンラインサービスの機能および展開されたアーキテクチャに応じて、identity management機能（すなわち、identity proofing、authentication、federation）の1つ以上のサポートが必要となり得る。これらの機能の強度はassurance levelsの観点で記述される。RPは、自らのオンラインサービスに適用されるassurance levelの種類を、以下から特定しなければならない（SHALL）:

IAL: 個人のidentityを特定するための、identity proofingプロセスの堅牢性。IALは、潜在的なidentity proofingの失敗に起因して生じるリスクを低減するために選定される。
AAL: authenticationプロセス自体の堅牢性、およびauthenticatorと特定の個人のidentifierとのbindingの堅牢性。AALは、潜在的なauthenticationの失敗に起因して生じるリスクを低減するために選定される。
FAL: IdPからRPへauthenticationおよびattribute情報を伝達するために用いられる、federationプロセスの堅牢性。FALは、潜在的なfederationの失敗に起因して生じるリスクを低減するために選定される。

3.4.2. Assurance Level Descriptions

各xALの要約を以下に示す。この小節ではassurance levelsの高レベルな記述を示すが、本ガイドラインの読者は、各assurance levelに関する規範的なガイドラインおよび要件について、付属巻 [SP800-63A], [SP800-63B], および [SP800-63C] を参照することが推奨される。

3.4.2.1. Identity Assurance Level

IAL1: IAL1は、主張されたidentityが現実世界に存在することを裏付け、applicantがそのidentityと関連していることについて、一定の保証を提供する。core attributesは、identity evidenceから取得されるか、またはapplicantにより自己申告（self-asserted）される。すべてのcore attributesはauthoritativeまたはcredible sourcesに対してvalidationされ、attributesをidentity proofingプロセスを受ける本人に結び付けるための手順が講じられる。

IAL2: IAL2は、追加のevidenceの収集、およびevidenceのvalidationとidentityのverificationのための、より厳格なプロセスを要求する。

IAL3: IAL3では、現地での立会い付きidentity proofing sessionの一部として、訓練を受けたCSP代表者（すなわちproofing agent）がapplicantと直接やり取りすること、ならびに少なくとも1つのbiometricの収集を要求事項として追加する。

Table 1は、各identity assurance levelにおけるcontrol objectives（すなわちattack protections）を示す。

Table 1. IAL summary

IAL	Control Objectives	User Profile
IAL1	高いスケーラビリティを持つ攻撃を制限する。synthetic identityに対して保護する。侵害されたpersonal informationを用いる攻撃に対して保護する。	personal informationへのアクセスは必要だが限定される。ユーザの行為は限定される（例: 個人のpersonal informationの閲覧および変更）。利用可能なユーザ機能を通じて、詐欺を直接実行することはできない。offlineまたは手動のプロセスが実施されるまで、ユーザは支払いを受け取れない。
IAL2	スケールした攻撃および標的型攻撃を制限する。基本的なevidenceの改ざんおよび窃取に対して保護する。基本的なsocial engineeringに対して保護する。	ユーザはfinancial informationを閲覧および変更できる（例: direct depositの振込先）。利用可能なアプリケーション機能を通じて、個人が直接金銭詐欺を実行できる。ユーザは他のユーザのpersonal informationを閲覧または変更できる。ユーザはproprietary informationの可視性を持つ、またはアクセスできる。
IAL3	高度な攻撃を制限する。高度なevidenceの改ざん、窃取、およびrepudiationに対して保護する。高度なsocial engineering attackに対して保護する。	ユーザは複数の高い機微性を持つ記録に直接アクセスできる。サーバ、システム、またはsecurity dataへの管理者アクセスを持つ。1人または多数のユーザに関する機微な情報を明らかにし得る、大規模なデータ集合にアクセスできる。あるいは、OMB guidanceの下でmajor incidentに該当するbreachを招き得るアクセスを持つ。

3.4.2.2. Authentication Assurance Level

AAL1: AAL1は、claimantがsubscriber accountにboundされたauthenticatorを管理しているという、基本的な確信を提供する。AAL1は、利用可能な広範なauthentication技術を用いたsingle-factorまたはmulti-factor authenticationのいずれかを要求する。verifierは、AAL1でmulti-factor authenticationの選択肢を利用可能にし、その利用を促すことが期待される。authenticationが成功するには、claimantがsecure authentication protocolを通じて、authenticatorのpossession and control of an authenticatorを立証する必要がある。

AAL2: AAL2は、claimantがsubscriber accountにboundされた1つ以上のauthenticatorを管理しているという、高い確信を提供する。secure authentication protocolsの利用を通じて、2つの別個のauthentication factorsのpossession and control of an authenticatorの証明が要求される。approved cryptographic techniquesが要求される。

AAL3: AAL3は、claimantがsubscriber accountにboundされたauthenticatorを管理しているという、非常に高い確信を提供する。AAL3におけるauthenticationは、cryptographic protocolの利用を通じたkeyのpossessionの証明と、activation factorまたはpasswordのいずれかに基づく。AAL3のauthenticationは、phishing resistanceを提供する、持ち出し不可能（non-exportable）なprivate keyを備えたpublic-key cryptographic authenticatorの利用を要求する。approved cryptographic techniquesが要求される。

Table 2は、各authentication assurance levelにおけるcontrol objectives（すなわちattack protections）を示す。

Table 2. AAL summary

AAL	Control Objectives	User Profile
AAL1	攻撃に対する最小限の保護を提供する。passwordに焦点を当てた攻撃を抑止する。	いかなるユーザにもpersonal informationは利用可能ではないが、usabilityの支援およびアプリケーションのcustomizationのために、profileまたはpreference dataが保持される場合がある。
AAL2	multifactor authenticationを要求する。phishing-resistantの選択肢を提供する。	ユーザにより個人のpersonal informationを閲覧または変更できる。ユーザにより限定的なproprietary informationを閲覧できる。
AAL3	phishing resistanceおよびverifier compromise protectionsを要求する。	高い機微性を持つ情報を閲覧または変更できる。複数のproprietary recordsをユーザが閲覧または変更できる。privileged user accessは、OMB guidanceの下でmajor incidentに該当するbreachを招き得る。

3.4.2.3. Federation Assurance Level

FAL1: FAL1は、federation transactionsに対する基本的なlevelの保護を提供し、幅広いuse casesおよびdeployment上の判断を支援する。

FAL2: FAL2は、federation transactionsに対する高いlevelの保護を提供し、federated systemsに対するさまざまな攻撃（federated transactionへのassertionの注入を試みるものを含む）に対して追加の保護を提供する。

FAL3: FAL3は、federation transactionsに対する非常に高いlevelの保護を提供し、federation transactionで伝達される情報がCSPおよびIdPにより確立された内容と一致することについて、非常に高い確信を確立する。

Table 3は、各federation assurance levelにおけるcontrol objectives（すなわちattack protections）を示す。

Table 3. AAL Summary

FAL	Control Objectives	User Profile
FAL1	偽造されたassertionsに対して保護する。	いかなるユーザにも機微なpersonal informationは利用可能ではないが、usabilityの支援またはアプリケーションのcustomizationのために、profileまたはpreference dataが保持される場合がある。
FAL2	偽造されたassertionsおよびinjection attackに対して保護する。	ユーザは、適切なauthentication assurance levels（例: AAL2以上）により、personal informationおよびその他の機微なdataにアクセスできる。
FAL3	IdP compromiseに対して保護する。	federationは主としてattribute exchangeを支援する。ユーザは、OMB guidanceの下でmajor incidentに該当するbreachを招き得る、classifiedまたは高い機微性を持つ情報またはサービスにアクセスできる。

\clearpage

3.4.3. Initial Assurance Level Selection

組織は、digital identity systemにおける失敗のpotential impactsに基づいて、初期assurance levelsおよびcontrolsを選択するためのプロセスとgovernance modelを策定し、文書化しなければならない（SHALL）。以下の小節では、初期assurance levelsを選択するプロセスにおいて考慮すべき主要な要素について、ガイダンスを提供する。

各ユーザグループのoverall impact levelは、digital identity functions内の失敗のimpactsに基づき、評価対象のオンラインサービスについて、初期assurance levelと関連するtechnicalおよびprocess controlsを選択するための基礎として用いられる。初期assurance levelsおよびcontrolsは、DIRMプロセスの次のステップで、さらに評価されtailoringされ得る。

初期impact assessment（Sec. 3.2参照）および、各ユーザグループのcombined impact level determination（Sec. 3.2.4参照）は、identity proofing、authentication、federationのリスクを区別しないが、選定される初期xALsは、それでも異なる場合がある。例えば、初期impact assessmentがlow impactでありIAL1およびFAL1を示す一方で、personal informationにアクセス可能であると判断され、したがってAAL2を要求することもあり得る。同様に、impact assessmentがproofingを要求しないと判断する場合があり、その結果、authenticationおよびfederationのbaselineにかかわらずIALが存在しないこともあり得る。さらなる変更は、Step 4: Tailoringで論じるtailoringプロセスから生じ得る。

このステップの出力は、各ユーザグループについてオンラインサービスに適用される初期xALsの集合である。

3.4.3.1. Selecting Initial IAL

初期assurance levelを選択する前に、RPは、自らのオンラインサービスのユーザに対してidentity proofingが必要かどうかを判断しなければならない。オンラインサービスがdigital transactionsを実行するためにpersonal informationを必要としない場合、identity proofingは不要である。personal informationが必要な場合、RPはvalidationされたattributesが必要か、またはself-asserted attributesで十分かを判断しなければならない。self-asserted attributesを受け入れることによる潜在的harmsが重要ではない場合、systemはidentity proofingなしでも運用できる可能性がある。そのような場合、[SP800-63A]で記述されるidentity proofingプロセスは、当該systemには適用されない。

オンラインサービスがidentity proofingを要求する場合、初期IALは、簡単なマッピングプロセスにより選定される:

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

組織は、自らのアプリケーションにidentity proofingが必要かどうかを文書化しなければならず（SHALL）、必要である場合には、Sec. 3.2.4の有効なimpact level determinationに基づいて、各ユーザグループの初期IALを選定しなければならない（SHALL）。

IALは、applicantが主張する現実世界のidentityを保持していることについての保証のlevelを反映する。初期選定は、identity proofingプロセスにおける失敗のpotential impactsがより高い場合、それをより高い保証のプロセスで低減すべきである、という前提に立つ。

3.4.3.2. Selecting Initial AAL

authenticationは、personal information、protected information、またはsubscriber accountへのアクセスを提供するオンラインサービスに必要である。組織は、authentication assurance levelsおよびauthentication mechanismsの適用に関する意思決定を行う際、オンラインサービスを規律する法的要件、規制要件、またはポリシー要件を考慮すべきである。例えば、[[EO13681]]は「digital applicationsを通じて市民がpersonal dataにアクセスできるようにするすべての組織は、複数のauthentication factorsの利用を要求する」と述べており、当該基準を満たすアプリケーションには、最低でもAAL2を選定することを要求する。

オンラインサービスでauthenticationの実装が必要な場合、初期AALは、簡単なマッピングプロセスにより選定される:

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

組織は、自らのオンラインサービスにauthenticationが必要かどうかを文書化しなければならず（SHALL）、必要である場合には、[Sec. 3.2.4]の有効なimpact level determinationに基づいて、各ユーザグループの初期AALを選定しなければならない（SHALL）。

AALは、authenticatorが登録された相手と同一の個人がclaimantであることについての保証のlevelを反映する。初期選定は、authenticationプロセスにおける失敗のpotential impactsがより高い場合、それをより高い保証のプロセスで低減すべきである、という前提に立つ。

3.4.3.3. Selecting Initial FAL

identity federationは、重複するidentityプロセス（冗長で、コストがかかり、しばしば時間を要する）を回避する利便性の高い顧客体験を含む、多くの利点をもたらす。general-purpose IdP modelまたはsubscriber-controlled wallet modelによるfederationの利点は、[Sec. 5 of [SP800-63C]]で扱っている。しかし、リスクベースの理由、または法的・規制上の要件により、すべてのオンラインサービスがfederationを利用できるわけではない。[M-19-17]と整合する形で、オンラインサービスを運用する連邦機関は、ユーザアクセスの選択肢としてfederationを実装すべきである（SHOULD）。

オンラインサービスがidentity federationを実装する場合、初期FALは、簡単なマッピングプロセスにより選定される:

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

組織は、自らのオンラインサービスでfederationを利用するかどうかを文書化しなければならず（SHALL）、利用する場合には、[Sec. 3.2.4]の有効なimpact level determinationに基づいて、各ユーザグループの初期FALを選定しなければならない（SHALL）。

high impactと評価されたオンラインサービスについて、組織は、IdP compromiseのリスクを評価し、自らのuse caseにFAL2とFAL3のいずれがより適切かを判断するため、追加のassessmentを実施しなければならない（SHALL）。考慮事項には、アクセスされるdataの種類、IdPの所在（例: IdPがenterprise boundaryの内側か外側か）、およびbound authenticatorまたはholder-of-key capabilitiesの利用可能性を含めるべきである（SHOULD）。

FALは、authenticationプロセスの結果と関連するidentity情報をRPのオンラインサービスへ伝達するidentity assertionsにおける保証のlevelを反映する。予備的な選定は、federated identity architecturesにおける失敗のpotential impactsがより高い場合、それをより高い保証のプロセスで低減すべきである、という前提に立つ。

3.4.4. Identify Baseline Controls

各ユーザグループおよび適用される各identity functions（すなわちIAL、AAL、FAL）についての初期assurance levelsの選定は、付属巻 [[SP800-63A]], [[SP800-63B]], および [[SP800-63C]] のガイドラインからbaseline digital identity controlsを選定するための基礎として機能する。[Sec. 3.4]で述べるとおり、baseline controlsには、追加のpotential impactsに照らしてassessmentされるtechnicalおよびprocess controlsが含まれる。

[Sec. 3.3.3]で選定された初期xALsを用いて、組織は、各ユーザグループに適用されるbaseline controlsを、以下のとおり特定しなければならない（SHALL）:

初期IALおよび関連するtechnicalおよびprocess controls（[[SP800-63A]]より）
初期AALおよび関連するtechnicalおよびprocess controls（[[SP800-63B]]より）
初期FALおよび関連するtechnicalおよびprocess controls（[[SP800-63C]]より）

オンラインサービス提供者は、自らのアプリケーションを保護するために適切なxALsを評価し決定しなければならないが、これらのassurance levelsの選定は、オンラインサービス提供者が関連するtechnicalおよびprocess controlsを独立して実装しなければならないことを意味しない。オンラインサービス提供者が実装するidentity modelに基づき、assurance levelsおよび関連するcontrolsの一部または全部は、サードパーティのCSPまたはIdPなどの外部entityにより実装され得る。

このステップの出力は、各ユーザグループに対して割り当てられたxALsおよびbaseline controlsの集合である。

3.5. Tailor and Document Assurance Levels

DIRMプロセスが扱うリスクの第2の次元は、identity management systemに起因するリスクに焦点を当てる。これは、[Sec. 3.3.4]における初期xALsおよび関連するtechnicalおよびprocess controlsの選定が、意図せずもたらす負の結果を表すものである。

tailoringは、継続的な詳細risk assessmentに基づいて、当初assessmentされたassurance levelを修正し、compensating controlsまたはsupplemental controlsを実装するためのプロセスを提供する。これは柔軟性のための経路を提供し、組織が自らの特定のコンテキスト、ユーザ、およびthreat environmentsに整合するrisk management objectivesを達成できるようにする。このプロセスは、identity system自体がもたらすリスク、特定の環境的脅威、ならびにprivacyおよび顧客体験への影響のassessmentに焦点を当てる。組織に対して、特定のリスク領域または結果を優先するものではない。異なる種類のリスクをバランスさせ、組織の成果を満たす意思決定を行う責任は、引き続き組織にある。

組織はtailoringプロセスを実装し文書化することが要求されるが、本ガイドラインは、その結果として初期assurance levelsまたはcontrol setsが修正されることを要求しない。しかし、組織は、選定した初期assurance levelsの成果を十分に考慮するため、tailoringセクションのassessmentsを完了することが期待される。

tailoringステップにおいて、組織は、identity management controlsの実装によりミッション遂行へ与えるimpactに焦点を当てなければならない（SHALL）。これには、正当なユーザが望むオンラインサービスにアクセスできない可能性、またはidentity system（および技術選定）により十分なfrictionまたはfrustrationを経験し、オンラインサービスへのアクセスの試みを断念する可能性が含まれる。

tailoringプロセスの一部として、組織は、自らが利用している、または利用する意図のあるCSPおよびIdPのDigital Identity Acceptance Statementsおよびpractice statementsをレビューしなければならない（SHALL）。しかし、組織は、tailoringの目的のために、組織固有のミッションおよびオンラインサービスにより提供されるコミュニティが十分に考慮されることを確実にするため、組織自身のanalysisも実施しなければならない（SHALL）。その結果として、組織は、選定したCSPに対し、特定のcontrolsの実装を強化すること、または任意選択肢を提供することを要求してもよい（MAY）。これは、組織のミッションおよび提供先コミュニティへのリスクと意図しないimpactに対処するためである。

interoperabilityと一貫性を促進するため、組織は、本書の規範的ガイダンスと整合する形で、assessment済みまたはtailoring済みのxALsを実装すべきである（SHOULD）。しかし、これらのガイドラインは、組織が特定のミッション上のニーズを満たし、独自のrisk appetitesに対応し、安全でアクセス可能なオンラインサービスを提供するために、初期xALsおよび関連controlsをtailoringできる柔軟性を提供する。これを踏まえ、CSPsは、本ガイドラインの規範的記述と異なるtailoring済みcontrol setsを提供してもよく（MAY）、組織はそれを利用してもよい（MAY）。

組織は、自らのxAL tailoringプロセスを確立し、文書化しなければならない（SHALL）。最低限、このプロセスは:

意思決定を可能にする、文書化されたgovernance approachに従わなければならない（SHALL）
tailoringプロセスにおけるすべての意思決定（assessment済みxALs、修正されたxALs、ならびにsupplementalおよびcompensating controlsを含む）を、Digital Identity Acceptance Statementに文書化しなければならない（SHALL）（[Sec. 3.4.4]参照）
初期にassessmentされたxALsに対する、すべてのリスクベースの意思決定または修正を、Digital Identity Acceptance Statementで正当化し文書化しなければならない（SHALL）（[Sec. 3.4.4]参照）
tailoringプロセスにおいて、xAL選定のimpactsに関するsubject-matter analysisを支援するための、クロスファンクショナルな能力を確立すべきである（SHOULD）（例: privacy、顧客体験、fraudおよびなりすましのimpact、ならびにその他の関連領域に関するリスクと考慮事項を説明できるsubject-matter experts）

tailoringプロセスは、ミッションの成功を可能にしつつオンラインサービス、systems、およびdataを保護し、個人に対するsecurity、顧客体験、およびprivacyを支援する形で、リスクとimpactをバランスさせるための構造化された手段を促進する。

3.5.1. Assess Privacy, Customer Experience, and Threat Resistance

特定のオンラインサービスに対するassurance levelsの選定およびtailoringにおいて、考慮事項は[Sec. 3.2]の初期impact assessmentを超えて広がる。[Sec. 3.3.4]の初期assurance level選定から、最終的なxALの選定および実装へ進む際、組織は、初期に選定したxALsに対して定義されたcontrolsの詳細assessmentを実施し、運用環境におけるpotential impactsを特定しなければならない（SHALL）。

最低限、組織は、以下の領域に関連するimpactおよび潜在的な意図しない結果をassessmentしなければならない（SHALL）:

Privacy – assessmentされたxALにおけるcontrolsの対象となる個人のprivacy、およびdigital identityの確立、管理、またはfederationに関連する組織またはサードパーティのpracticeにより影響を受ける個人のprivacyに対して生じ得る、意図しない結果を特定する。privacy assessmentは、privacy assessmentプロセスにおける入力として、既存のPrivacy Threshold Analysis (PTA)またはPrivacy Impact Assessment (PIA)を活用すべきである（SHOULD）。しかし、privacy assessmentの目的は初期assurance level選定から生じるprivacyリスクを特定することであるため、基盤となるinformation systemについて、assurance levelsのbaseline controlsに固有の追加assessmentおよびevaluationが必要となる場合がある。
Customer Experience – 初期assurance levelsの実装が、サービスにアクセスしようとする個人に対し、重大または受け入れがたい障壁を生み得るかどうかを判断する。customer experience assessmentsは、identity management controlsに起因するimpactを考慮しなければならない（SHALL）。これは、controlsが個人に過度の負担、frustrations、またはfrictionsを生じさせないこと、ならびに、さまざまな能力、資源、技術へのアクセス、および経済的状況を持つユーザにサービスを提供するための経路が存在することを確実にするためである。
Threat Resistance – 定義されたassurance levelおよび関連controlsが、運用環境、そのthreat actors、および既知のtactics, techniques, and procedures (TTPs)に基づき、オンラインサービスに対する特定の脅威に対処するかどうかを判断する。threat assessmentsは、identity management functionsの実装環境における、具体的な既知および潜在的な脅威、threat actors、およびTTPsを考慮しなければならない（SHALL）。例えば、ある種の給付プログラムは、家族内の脅威または共謀の影響をより受けやすい場合がある。assessmentに基づき、組織は、オンラインサービスが提供するコミュニティに固有のsupplemental controlsを実装してもよい（MAY）。逆に、threat assessmentが、自らの環境に基づき低いthreat postureが適切であることを示す場合、組織は、assessment済みxALを引き下げる、またはbaseline controlsを修正するようにtailoringしてもよい（MAY）。

組織は、tailoringプロセスが既知の制約に対処することを確実にするため、提供対象のentityおよびコミュニティからの相談およびフィードバックを活用すべきである（SHOULD）。

組織はまた、ここで捉えられていないミッション固有およびドメイン固有の考慮事項を十分に表現するため、適切に追加の事業固有assessmentも実施すべきである（SHOULD）。tailoringフェーズで適用されるすべてのassessmentsは、[Sec. 3.4.2]および[Sec. 3.4.3]で定義されるとおり、いかなるcompensating controlsまたはsupplemental controlsにも拡張されなければならない（SHALL）。identity system costsは、DIRMプロセスへの入力や継続的evaluationの指標として特段含められてはいないが、実装および長期運用におけるコストとcost effectivenessは、責任あるプログラムおよびrisk managementに固有の考慮事項である。利用可能な資金および資源に基づき、組織はトレードオフを行う必要が生じる可能性が高く、その判断はDIRMプロセスとその出力により、より効果的に支えられ得る。assessment済みxALsまたはbaseline controlsに変更をもたらす、あらゆるコストベースの意思決定は、Digital Identity Acceptance Statementに文書化されなければならない（[Sec. 3.4.4]参照）。

このステップの成果は、privacy、customer experience、threat resistance、ならびにその他の次元に関するrisk assessmentsの集合であり、初期assurance levelsのtailoringおよびcompensating controlsとsupplemental controlsの選定に情報を与える。

3.5.2. Identify Compensating Controls

compensating controlは、定義されたxALsにおける規範的control（すなわちSHALL文）に代えて、組織が用いるmanagement、operational、またはtechnical controlである。実行可能な範囲で最大限、compensating controlは、置き換え対象のbaseline controlと同じリスクに対処することを意図する。組織は、baseline controlを実装できない場合、またはrisk assessmentが、compensating controlが組織のrisk toleranceに整合する形でリスクを十分に低減すると示す場合に、compensating controlの実装を選択してもよい（MAY）。このcontrolは、本ガイドラインで定義される規範的記述への修正であってもよく（MAY）、オンラインサービス、digital transaction、またはservice life cycleの別の箇所に適用されてもよい（MAY）。例えば:

連邦機関は、これらのガイドラインの下で求められるauthoritative sourcesによるidentity evidence validationの要件を補うために、連邦の身元調査およびチェック（[[FIPS201]]）を利用することを選択し得る。
組織は、end-user populationに必要なevidenceが欠けていたため、より弱い形態のidentity evidenceを用いたverificationプロセスが受け入れられた支払いアプリケーションにおいて、より厳格な監査およびtransactional reviewプロセスを実装することを選択し得る。

compensating controlsが実装される場合、組織は、compensating control、逸脱の根拠、選択した代替手段のcomparability、および結果として残るresidual risksを文書化しなければならない（SHALL）。compensating controlsを実装するCSPsおよびIdPsは、integrationに先立ち、すべての潜在的RPに対してこの情報を伝達しなければならない（SHALL）。これにより、RPが自らのuse casesにおけるcompensating controlsの受容可能性をassessmentし判断できるようにする。

tailoringのプロセスは、組織およびサービス提供者が、自らのxALsおよび関連controlsをどのように実装するかについて、リスクベースの意思決定を行うことを可能にする。また、[Sec. 3.4.4]で述べるDigital Identity Acceptance Statementを通じて、意思決定を文書化し伝達するための仕組みも提供する。

3.5.3. Identify Supplemental Controls

supplemental controlsは、組織が選定したassurance levelsに対して指定されるbaseline controlsを、さらに強化するために追加され得る。組織は、baseline controlsでは対処されない可能性がある運用環境における特定の脅威に対処するため、supplemental controlsを特定し実装すべきである（SHOULD）。例えば:

proofingプロセスを完了するため、組織は、不正な試行の蔓延が高いことを理由に、assurance levelで要求される範囲を超える追加のidentity evidenceに照らして個人をverificationすることを選択し得る。
組織は、AAL2においてphishing-resistant authenticationのみにユーザを制限することを選択し得る。
組織は、ユーザのアクセス試行が特定のリスク要因を示す場合に、ユーザのidentityを確認するため、risk-scoring analyticsおよびre-proofing mechanismsを実装することを選択し得る。

いかなるsupplemental controlsも、組織のassurance levelをtailoringするために用いられるのと同じ要因に基づいてimpactのassessmentを受けなければならず（SHALL）、文書化されなければならない（SHALL）。

3.5.4. Digital Identity Acceptance Statement

組織は、(i) 組織が管理する各オンラインサービス、ならびに (ii) 組織のミッションを支援するために利用する各外部オンラインサービス（software-as-a-serviceの提供物を含む。例: social media platforms、email services、online marketing services）について、DIRMプロセスの結果を文書化するために、Digital Identity Acceptance Statement (DIAS)を作成しなければならない（SHALL）。特定のCSP/IdPの利用を意図するRPは、当該CSP/IdPのDIASをレビューし、各オンラインサービスについて組織のDIASに関連情報を取り込まなければならない（SHALL）。

組織は、自らのオンラインサービスについて、少なくとも以下を含むDIASを作成しなければならない（SHALL）:

初期impact assessmentの結果
初期にassessmentされたxALs
tailoring済みxAL（tailoring済みxALが初期にassessmentされたxALと異なる場合）およびその根拠
comparabilityまたはresidual risksを含む、すべてのcompensating controls
すべてのsupplemental controls

連邦機関は、この情報を、[[NISTRMF]]で述べるinformation system authorization packageに含めるべきである（SHOULD）。

CSPs/IdPsは、supplemental controlsまたはcompensating controlsを追加した場合を含め、本ガイドラインの規範的ガイダンスから逸脱する場合、提供するサービスについてDIRMプロセスを実装し、DIASを作成しなければならない（SHALL）。提供するassurance levelsおよびcontrolsに対するDIRMを完了するために、CSPs/IdPsは、支援したいと考えるanticipatedまたはrepresentativeなdigital identity servicesに基づいてassessmentを行ってもよい（MAY）。このrisk assessmentを作成するにあたり、CSPs/IdPsは、ユーザ集団および想定コンテキストに関して、現実世界のRPからの入力を求めるべきである（SHOULD）。CSPが作成するDIASは、少なくとも以下を含まなければならない（SHALL）:

主張するxAL、関連controls、ならびに規範的ガイダンスからのあらゆる逸脱の根拠
comparabilityまたはresidual risksを含む、すべてのcompensating controls
すべてのsupplemental controls

組織が利用する外部オンラインサービスに対するDIRMプロセスは、当該サービス提供者からの関連入力を考慮しなければならず（SHALL）、その結果をDIASに文書化しなければならない。外部オンラインサービスについて組織が作成するDIASは、少なくとも以下を含まなければならない（SHALL）:

assessment済みxAL、関連controls、ならびに規範的ガイダンスからのあらゆる逸脱の根拠
comparabilityまたはresidual risksを含む、すべてのcompensating controls
すべてのsupplemental controls

最終的に実装されるxALsは、すべて同一のlevelである必要はない。オンラインサービスの機能、impact assessment、およびtailoringプロセスに基づき、ばらつきが生じ得る。

3.6. Continuously Evaluate and Improve

継続的改善は、脅威および技術環境の変化に歩調を合わせ、risk management objectivesのバランスを取るために対処が必要なプログラム上のギャップを特定するための、重要な手段である。例えば、組織は、オンラインサービスが提供対象とすることを意図しているターゲット集団の一部が、remote identity proofingを支えるために必要な、手頃な価格の高速インターネットサービスへアクセスできないと判断する場合がある。組織は、コミュニティ内でローカルな対面proofingサービスを提供するプログラムを確立することで、このギャップを埋められる。これには、local community center、最寄りのpost office、提携事業者の施設、あるいは個人の自宅など、よりアクセスしやすい場所で個人と会えるproofing agentとの面会予約を提供することが含まれ得る。

自らが運用する環境の変化に対処し、サービス能力のギャップにより迅速に対処するため、組織は、identity management systemとやり取りしたend usersからの入力、およびオンラインサービスのperformance metricsを活用する、継続的evaluationおよび改善プログラムを実装しなければならない（SHALL）。このプログラムは文書化されなければならず（SHALL）、これには、収集されるmetrics、performance evaluationを可能にするために必要なdata sources、ならびに継続的改善プロセスに基づいて適時に行動するためのプロセスが含まれる。このプログラムとその有効性は、成果が達成されていること、およびプログラムが適時に課題へ対処していることを確実にするため、定期的にassessmentされるべきである（SHOULD）。

さらに、組織は、最新の脅威およびfraud tacticsの情報を得るため、進化する脅威状況を監視しなければならない（SHALL）。組織は、最新の脅威およびfraud tacticsに対して、現在のsecurity measuresおよびfraud detection capabilitiesの有効性を定期的にassessmentしなければならない（SHALL）。

3.6.1. Evaluation Inputs

自らのidentity systemのperformanceを十分に理解するため、組織は、継続的evaluationプロセスへの重要なinputsを特定する必要がある。最低限、これらのinputsは以下を含まなければならない（SHALL）:

必要に応じて、統合されたCSP、IdP、およびauthentication functions、ならびにvalidation、verification、fraud management systems
苦情対応プロセス、helpdesk統計、その他のユーザフィードバック（例: surveys、interviews、focus groups）などのcustomer feedback mechanisms
利用可能なthreat analysis、threat reporting、およびthreat intelligence feeds
利用可能なfraud trends、fraud investigation results、およびfraud metrics
継続的なcustomer experience assessmentsおよびprivacy assessmentsの結果

RPは、期待がパートナーおよびベンダーに適切に伝達されることを確実にするため、統合されるいかなるCSP、IdP、またはその他のidentity serviceについても、metrics、reporting requirements、およびdata inputsを文書化しなければならない（SHALL）。

3.6.2. Performance Metrics

組織が利用できる正確なmetricsは、利用する技術、アーキテクチャ、およびdeployment methodsに応じて異なる。加えて、特定のmetricsの利用可能性および有用性は、時間の経過とともに変化する。したがって、本ガイドラインは、あらゆるシナリオに対する包括的なmetricsの集合を定義しようとはしていない。Table 4は、継続的evaluationプログラムの一部として、組織が追跡すべき推奨metricsの集合を提供する（SHOULD）。ただし、組織はこの表に拘束されず（SHOULD）、自組織固有のsystems、技術、およびプログラムのニーズに基づいてmetricsを実装すべきである（SHOULD）。追加のperformance metricsの特定に関する詳細は、[[SP800-55V2]]を参照されたい。Table 4において、unique usersへの参照は、正当なユーザとimpostersの双方を含む。

Table 4. Performance metrics

Title	Description	Type
Pass Rate (Overall)	identity proofingを正常に完了したunique usersの割合	Proofing
Pass Rate (Per Proofing Type)	提供される各type（すなわちremote unattended、remote attended、on-site attended、on-site unattended）について、正常にproofingされたunique usersの割合	Proofing
Fail Rate (Overall)	identity proofingプロセスを開始したが、すべてのステップを正常に完了できないunique usersの割合	Proofing
Estimated Adjusted Fail Rate	fraudulentである疑いがあるidentity proofingの試行を考慮して調整された、failuresの割合	Proofing
Fail Rate (Per Proofing Type)	提供される各type（すなわちremote unattended、remote attended、on-site attended、on-site unattended）について、プロセス上の失敗によりproofingを完了しないunique usersの割合	Proofing
Abandonment Rate (Overall)	identity proofingプロセスを開始したが、プロセスに失敗することなく完了しないunique usersの割合	Proofing
Abandonment Rate (Per Proofing Type)	特定typeのidentity proofingプロセスを開始したが、プロセスに失敗することなく完了しないunique usersの割合	Proofing
Failure Rates (Per Proofing Process Step)	CSPプロセスにおいて、各identity proofing stepの完了に失敗したunique usersの割合	Proofing
Completion Times (Per Proofing Type)	identity serviceの一部として提供される、定義済みの各proofing typeをユーザが完了するのに要する平均時間	Proofing
Authenticator Type Usage	利用可能な各typeごとに、アクティブなauthenticatorを持つsubscriberの割合	Authentication
Authentication Failures	失敗するauthentication eventsの割合（authenticator outputの再入力後に成功するauthentication attemptsは含めない）	Authentication
Account Recovery Attempts	subscriberによって開始されたaccountまたはauthenticator recoveryプロセスの数	Authentication
Confirmed Unauthorized Access or Fraud	組織がanalysisまたはself-reportingを通じて、unauthorizedまたはfraudulentと判断したtotal transaction events（すなわちidentity proofing + authentication events）の割合	Fraud
Suspected Unauthorized Access or Fraud	unauthorizedまたはfraudulentである疑いがあるtotal transaction events（すなわちidentity proofing + authentication events）の割合	Fraud
Reported Unauthorized Access or Fraud	ユーザによりunauthorizedまたはfraudulentであると報告されたtotal transaction events（すなわちidentity proofing + authentication events）の割合	Fraud
Unauthorized Access or Fraud (Per Proofing Type)	利用可能な各proofing typeについて、fraudulentである疑いまたは報告があるidentity proofing eventsの数	Fraud
Unauthorized Access or Fraud (Per Authentication Type)	利用可能な各authentication typeについて、unauthorizedまたはfraudulentである疑いまたは報告があるauthentication eventsの数	Fraud
Help Desk Calls	CSPまたはidentity serviceが受領した通話件数	Customer Experience
Help Desk Calls (Per Type)	提供される各サービス（例: proofing failures、authenticator resets、complaints）に関連して受領した通話件数	Customer Experience
Help Desk Resolution Times	complaintまたはhelp desk ticketを解決するのに要する平均時間	Customer Experience
Customer Satisfaction Surveys	CSPs、RP、またはその双方により実施されたcustomer feedback surveysの結果	Customer Experience
Redress Requests	identity management systemに関連して受領したredress requestsの数	Customer Experience
Redress Resolution Times	identity management systemに関連するredress requestsを解決するのに要する平均時間	Customer Experience

継続的evaluation metricsを生成するために用いられるdataは、必ずしもidentity program、またはidentity management systemsを担う組織内entityに存在するとは限らない。これらのmetricsの意図は、可能な限り既存のdata sourcesと統合し、identity program evaluationにとって重要な情報を収集することである。例えば、customer service representative (CSR)チームは、顧客の要求、苦情、または懸念に関する相当の情報を既に保有している場合がある。identity management systemsを実装し維持する組織は、identity management system関連のcomplaintsまたはissuesを識別するために必要な情報を得るべく、これらのチームと連携することが期待される。

3.6.3. Measurement in Support of Customer Experience Outcomes

継続的改善の主要な目標は、異なるユーザ集団に対するcustomer experience、usability、およびaccessibilityの成果を向上させることである。したがって、組織が収集するmetricsは、支援対象コミュニティに対するidentity management systemsのperformanceについての洞察を提供するため、さらに評価されるべきである（SHOULD）。可能な場合、これらの取り組みは追加のpersonal informationの収集を避け（SHOULD）、代わりにproxy dataの情報に基づくanalysisを用いて、潜在的なperformance issuesを特定すべきである。これには、zip code、geographic region、age、sexなど、利用可能な他のdataに基づき、異なるユーザ集団間でのperformanceの偏差を理解するために、metricsを比較しフィルタリングすることが含まれ得る。

3.7. Redress

幅広い集団を支援するサービスを設計するには、課題を裁定し、必要に応じてredressを提供するプロセスが求められる。サービスの失敗、紛争、その他の課題は通常の運用の一部として生じやすく、そのimpactは、軽微な不便から重大な混乱または損害まで、大きく幅がある。さらに、ある人またはコミュニティが不便として経験する同一の課題が、他の個人やコミュニティに対しては不釣り合いに深刻な損害をもたらす場合がある。

identity-related fraudおよびcybersecurity threatsを抑止しつつ、重要なオンラインサービスへのアクセスを可能にするため、組織が潜在的な課題を想定して計画を立て、公平で、透明性があり、正当なclaimantが容易に利用でき、悪用の試みに対して耐性のあるredressアプローチを設計することが不可欠である。

harmsがいつ、どのように生じ得るかを理解することは、組織が情報に基づいた行動を取るための重要な第一歩である。継続的evaluationおよび改善プログラムは、潜在的harmの事例およびパターンを特定する上で重要な役割を果たし得る。さらに、identity managementを支援するために確立されたものとは別に、課題の裁定とredressへの包括的アプローチの一部として活用できる事業プロセスが存在する場合がある。これらの活動に加え、identity management systemsの利用者が懸念を表明し、redressへの経路を持てることを確実にするため、追加のpracticesを実装できる。これらのpracticesの要件には以下が含まれる:

RPsおよびCSPsは、文書化され、アクセス可能で、追跡可能で、すべての個人が利用でき、かつ手順がpublic-facing websiteで容易に見つけられるissue handling processを通じて、個人がgrievancesを伝えredressを求められるようにしなければならない（SHALL）。
RPsおよびCSPsは、文書化された役割と責任を含め、このissue handling processを実装するためのgovernance modelを整備しなければならない（SHALL）。
issue handling processは、以下のための手順を含む専用機能として実装されなければならない（SHALL）:
- 関連するevidenceを公平にレビューすること
- 課題の解明に資する追加evidenceを要求し収集すること
- 迅速に課題を解決し、是正措置を決定すること
RPsおよびCSPsは、algorithmic support mechanismsが生成したissue adjudication outputsに介入し、上書きできるhuman support personnelを利用可能にしなければならない（SHALL）。
RPsおよびCSPsは、digital identity management systemのissue handling procedures、redressの経路、およびサービスへのアクセスを得るために利用可能な代替手段について、support personnelを教育しなければならない（SHALL）。
RPsおよびCSPsは、end usersが直面する主要な障壁および彼らが抱え得るgrievancesを報告し対処するための支援機能を提供する、personnelおよびtechnologiesのプロセスを実装しなければならない（SHALL）。
RPsおよびCSPsは、issue handling processから導かれた知見を、継続的evaluationおよび改善活動に取り込まなければならない（SHALL）。

組織は、これらおよび他の新たに出現しているredress practicesを検討することが推奨される。支援技術を含め、いかなる新しいredress practiceを採用する前にも、組織は、意図しない結果（特に、redressに関連する目標を相殺したり矛盾したりし得るもの）の導入を避けるため、ユーザとともに当該practiceをテストすべきである（SHOULD）。加えて、組織は、自らのredress mechanismsのintegrityおよびperformanceをassessmentし、当該mechanismsを伴うidentity fraudの試みを防止、検知、およびremediateするcontrolsを実装しなければならない（SHALL）。

3.8. Cybersecurity, Fraud, and Identity Program Integrity

identity functionsを、cybersecurity、privacy、threat intelligence、fraud detection、およびprogram integrityを担うチームと緊密に連携させることにより、事業能力をより完全に保護し、継続的な改善を可能にする。例えば、program integrityチームが収集したpayment fraud dataは、侵害されたsubscriber accountの指標、およびidentity proofing実装における潜在的な弱点を提供し得る。同様に、threat intelligenceチームは、identity proofing、authentication、federationプロセスに影響し得る新たなTTPsを把握する場合がある。組織は、重要な内部securityおよびfraud preventionを担うstakeholers間での情報交換のための、一貫した仕組みを確立しなければならない（SHALL）。組織は、外部stakeholdersおよびオンラインサービスを構成するidentity servicesについても、同様に行うべきである（SHOULD）。

組織が外部identity providers（例: CSPs）により支援される場合、security、fraud、その他のRP機能に関連するdataの交換は、規制またはポリシーにより複雑化し得る。しかし、効果的な情報共有を可能にするために必要な仕組みおよびガイドラインを確立することは、契約上および法的な仕組みにおいて考慮されるべきである（SHOULD）。identity service providerによって収集、送信、または共有されるすべてのdataは、dataを生成するentity（例: CSP）または当該サービスが提供される関連RPのいずれかによる、詳細なprivacyおよび法的assessmentの対象とならなければならない（SHALL）。

さまざまな組織内の機能チームとの調整および統合は、identity functionsに関するより良い成果の達成に役立ち得る。理想的には、そのような調整は、risk managementプロセスおよびoperations life cycleを通じて実施される。付属巻 [[SP800-63A]], [[SP800-63B]], および [[SP800-63C]] は、各identity functionsに関連する具体的なfraud mitigation requirementsを提供する。

3.9. Artificial Intelligence and Machine Learning in Identity Systems

identity solutionsは、biometric matching systemsのperformanceの改善、evidenceまたはattribute validationの自動化、fraudの検知、さらにはユーザ支援（例: chatbots）など、さまざまな形でartificial intelligence (AI)およびmachine learning (ML)を利用する。AIおよびMLの潜在的な応用は広範である一方、これらの技術は新たなリスクを導入したり、意図しない負の結果を生み出したりする可能性もある。

identity systemにおけるAIおよびMLのあらゆる利用（利用形態を問わない）には、以下の要件が適用される:

AI/MLのあらゆる利用は文書化され、これらのsystemsに依存する組織へ伝達されなければならない（SHALL）。CSPs、IdPs、またはverifiersがAI/MLを活用する統合技術を利用する場合、その利用は、これらのsystemsの情報に基づいてアクセス判断を行うすべてのRPsに開示されなければならない（SHALL）。
AI/MLを利用するすべての組織は、自らの技術を利用するいかなるentityに対しても、モデルのtrainingに用いたmethodsおよびtechniques、trainingで用いたdata setsの記述、model updatesの頻度に関する情報、ならびにアルゴリズムに対して完了したすべてのtestingの結果に関する情報を提供しなければならない（SHALL）。
AI/ML systemsを利用する、またはこれらのsystemsを利用するサービスに依存するすべての組織は、そのようなsystemsにより導入され得るリスクを評価するため、NIST AI Risk Management Framework（[[NISTAIRMF]]）を実装すべきである（SHOULD）。
AI/ML systemsを利用する、またはこれらのsystemsを利用するサービスに依存するすべての組織は、そのようなsystemsによりprocessingされるpersonal informationおよびdataについて、privacy risk assessmentsを実施し文書化しなければならない（SHALL）。

practice statementsおよびその内容に関する追加情報は、SP 800-63AのSec. 3.1に記載されている。
privacy risk assessmentsに関する詳細は、NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management（https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf）を参照されたい。
Redressは一般に、harmが生じた後に提供される救済を指す。

References

This section is informative.

[[EO13681]] Obama B (2014) Improving the Security of Consumer Financial Transactions. (The White House, Washington, DC), Executive Order 13681, October 17, 2014. Available at https://www.federalregister.gov/d/2014-25439

[[FIPS199]] National Institute of Standards and Technology (2004) Standards for Security Categorization of Federal Information and Information Systems. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 199. https://doi.org/10.6028/NIST.FIPS.199

[[U.S.C3552]] 44 U.S.C. 3552 - Definitions - Content Details - USCODE-2014-title44-chap35-subchapII-sec3552 Available at https://www.govinfo.gov/app/details/USCODE-2014-title44/USCODE-2014-title44-chap35-subchapII-sec3552

[[FIPS201]] National Institute of Standards and Technology (2022) Personal Identity Verification (PIV) of Federal Employees and Contractors. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 201-3. https://doi.org/10.6028/NIST.FIPS.201-3

[[FISMA]] Federal Information Security Modernization Act of 2014, Pub. L. 113-283, 128 Stat. 3073. Available at https://www.govinfo.gov/app/details/PLAW-113publ283

[[ISO/IEC9241-11]] International Standards Organization (2018) ISO/IEC 9241-11 Ergonomics of human-system interaction – Part 11: Usability: Definitions and concepts (ISO, Geneva, Switzerland). Available at https://www.iso.org/standard/63500.html

[[M-03-22]] Office of Management and Budget (2003) OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002. (The White House, Washington, DC), OMB Memorandum M-03-22, September 26, 2003. Available at https://georgewbush-whitehouse.archives.gov/omb/memoranda/m03-22.html

[[M-19-17]] Office of Management and Budget (2019) Enabling Mission Delivery through Improved Identity, Credential, and Access Management. (The White House, Washington, DC), OMB Memorandum M-19-17, May 21, 2019. Available at https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf

[[NISTAIRMF]] Tabassi E (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). (National Institute of Standards and Technology, Gaithersburg, MD), NIST AI 100-1. https://doi.org/10.6028/NIST.AI.100-1

[[NISTIR8062]] Brooks SW, Garcia ME, Lefkovitz NB, Lightman S, Nadeau EM (2017) An Introduction to Privacy Engineering and Risk Management in Federal Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) NIST IR 8062. https://doi.org/10.6028/NIST.IR.8062

[[NISTRMF]] Joint Task Force (2018) Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-37r2. https://doi.org/10.6028/NIST.SP.800-37r2

[[NISTPF]] National Institute of Standards and Technology (2020) NIST Privacy Framework: A Tool for Improving Privacy Through Enterprise Risk Management, Version 1.0. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Cybersecurity White Paper (CSWP) NIST CSWP 10. https://doi.org/10.6028/NIST.CSWP.10

[[PrivacyAct]] Privacy Act of 1974, Pub. L. 93-579, 5 U.S.C. § 552a, 88 Stat. 1896 (1974). Available at https://www.govinfo.gov/content/pkg/USCODE-2018-title5/pdf/USCODE-2018-title5-partI-chap5-subchapII-sec552a.pdf

[[RFC5280]] Cooper D, Santesson S, Farrell S, Boeyen S, Housley R, Polk W (2008) Internet X.509 Public Key Infrastructure Certification and Certificate Revocation List (CRL) Profile. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 5280. https://doi.org/10.17487/RFC5280

[[RFC8446]] Rescorla E (2018) The Transport Layer Security (TLS) Protocol Version 1.3. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 8446. https://doi.org/10.17487/RFC8446

[[RFC9325]] Sheffer Y, Saint-Andre P, Fossati T (2022) Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 9325. https://doi.org/10.17487/RFC9325

[[SP800-30]] Blank R, Gallagher P (2012) Guide for Conducting Risk Assessments. (National Institute of Standards and Technology, Gaithersburg, MD) NIST Special Publication (SP) NIST SP 800-30r1. https://doi.org/10.6028/NIST.SP.800-30r1

[[SP800-52]] McKay K, Cooper D (2019) Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. (National Institute of Standards and Technology), NIST Special Publication (SP) NIST SP 800-52r2. https://doi.org/10.6028/NIST.SP.800-52r2

[[SP800-53]] Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-53r5, Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53r5

[[SP800-55V2]] Schroeder K, Trinh H, Pillitteri V (2024) Measurement Guide for Information Security: Volume 2 — Developing an Information Security Measurement Program. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-55 Vol. 2. https://doi.org/10.6028/NIST.SP.800-55v2

[[SP800-57Part1]] Barker EB (2020) Recommendation for Key Management: Part 1 – General. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-57pt1r5. https://doi.org/10.6028/NIST.SP.800-57pt1r5

[[SP800-63A]] Temoshok D, Abruzzi C, Choong YY, Fenton JL, Galluzzo R, LaSalle C, Lefkovitz N, Regenscheid A, Vachino M (2025) Digital Identity Guidelines: Identity Proofing and Enrollment. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63A-4. https://doi.org/10.6028/NIST.SP.800-63A-4

[[SP800-63B]] Temoshok D, Fenton JL, Choong YY, Lefkovitz N, Regenscheid A, Galluzzo R, Richer JP (2025) Digital Identity Guidelines: Authentication and Authenticator Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63B-4. https://doi.org/10.6028/NIST.SP.800-63B-4

[[SP800-63C]] Temoshok D, Richer JP, Choong YY, Fenton JL, Lefkovitz N, Regenscheid A, Galluzzo R (2025) Digital Identity Guidelines: Federation and Assertions. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63C-4. https://doi.org/10.6028/NIST.SP.800-63C-4

[[SP800-122]] McCallister E, Grance T, Scarfone KA (2010) Guide to Protecting the Confidentiality of Personally Identifiable Information (PII). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-122. https://doi.org/10.6028/NIST.SP.800-122

ABSTRACT

Keywords

Preface

Table of Contents

1. Introduction

1.1. Scope and Applicability

1.2. How to Use This Suite of SPs

1.3. Enterprise Risk Management Requirements and Considerations

1.3.1. Security, Fraud, and Threat Prevention

1.3.2. Privacy

1.3.3. Customer Experience

1.4. Notations

1.5. Document Structure

2. Digital Identity Model

2.1. Overview

2.2. Identity Proofing and Enrollment

2.2.1. Subscriber Accounts

2.3. Authentication and Authenticator Management

2.3.1. Authenticators

2.3.2. Authentication Process

2.4. Federation and Assertions

2.5. Examples of Digital Identity Models

2.5.1. Non-Federated Digital Identity Model

2.5.2. Federated Digital Identity Model With General-Purpose IdP

2.5.3. Federated Digital Identity Model with Subscriber-Controlled Wallet

3.3. Identify Impact Categories and Potential Harms

3.3.1. Identify Potential Impact Levels

3.3.2. Impact Analysis

3.3.3. Determine the Combined Impact Level for Each User Group

3.4. Select Initial Assurance Levels and Baseline Controls

3.4.1. Assurance Levels

3.4.2. Assurance Level Descriptions

3.4.2.1. Identity Assurance Level

3.4.2.2. Authentication Assurance Level

3.4.2.3. Federation Assurance Level

3.4.3. Initial Assurance Level Selection

3.4.3.1. Selecting Initial IAL

3.4.3.2. Selecting Initial AAL

3.4.3.3. Selecting Initial FAL

3.4.4. Identify Baseline Controls

3.5. Tailor and Document Assurance Levels

3.5.1. Assess Privacy, Customer Experience, and Threat Resistance

3.5.2. Identify Compensating Controls

3.5.3. Identify Supplemental Controls

3.5.4. Digital Identity Acceptance Statement

3.6. Continuously Evaluate and Improve

3.6.1. Evaluation Inputs

3.6.2. Performance Metrics

3.6.3. Measurement in Support of Customer Experience Outcomes

3.7. Redress

3.8. Cybersecurity, Fraud, and Identity Program Integrity

3.9. Artificial Intelligence and Machine Learning in Identity Systems

References