NIST SP 800-63C-4

ABSTRACT

本ガイドラインは、アイデンティティ連携（identity federations）と、それを実装するためにアサーション（assertions）を利用する方法に焦点を当てる。Federation により、特定のクレデンシャルサービスプロバイダが、認証属性および（任意で）加入者属性を、別々に管理される複数の Relying Party (RP) に提供できる。同様に、RP は複数のクレデンシャルサービスプロバイダを利用できる。本ガイドラインは、この目的の範囲外にある標準の開発や利用を制約することを意図しない。本書は、NIST Special Publication (SP) 800-63C を置き換える。

Keywords

assertions、authentication、credential service provider、digital authentication、digital wallets、federations、identity provider。

Preface

本書および関連する付属巻（[SP800-63]、[SP800-63A]、[SP800-63B]）は、デジタル・アイデンティティ・サービスの実装に関する技術的ガイドラインを、組織に提供する。

本書は、連携（federated）アイデンティティ・システムにおける Identity Provider (IdP) と Relying Party (RP) に対する要件を示す。Federation により、特定の IdP は、連携プロトコルおよびアサーションを通じて、別々に管理される複数の RP に対し、認証属性および（任意で）加入者属性を提供できる。同様に、RP はアイデンティティのソースとして複数の IdP を利用できる。

1. Introduction

本節は参考情報である。

Federation とは、RP が加入者の authenticator を直接検証することなく、加入者を RP に対して認証するプロセスである。Identity Provider (IdP) は、[SP800-63A] で定義された加入者アカウントを、連携プロトコルを通じて RP に利用可能な形で提供する。IdP は、加入者の認証イベントを契機としてアサーションを RP に送信する。アサーションは、加入者アカウントに関して RP に提示される、検証可能な主張（statement）である。RP は IdP から提供されたアサーションを検証し、加入者との認証済みセッションを作成し、RP の機能へのアクセスを加入者に付与する。

IdP は次の 2 つのモードのいずれかで動作する。

[SP800-63B] に記載のとおり、加入者アカウントに紐付けられた authenticator の verifier として動作する（詳細は Sec. 4 を参照）。
加入者が制御するデバイス上のソフトウェア（一般に digital wallet と呼ばれる）またはホスト型サービス（一般に cloud wallet と呼ばれる）として動作し、CSP から署名付きの属性バンドルを発行される（詳細は Sec. 5 を参照）。

Federation のプロセスにより、加入者は、各 RP ごとに別個の authenticator を保有・維持することなく、複数の RP からサービスを受けられる。このプロセスは、single sign-on と呼ばれることもある。Federation は、RP と加入者アカウントが同一のセキュリティ・ドメインの下で一体運用されていない場合に、一般に望ましい認証アプローチでもある。これは、加入者が管理すべき追加の authenticator を RP が発行する必要をなくすためである。それでもなお、Federation は、集中型のアカウント管理や技術的統合など、さまざまな利点のために、単一のセキュリティ・ドメイン内でも適用できる。

Federation のプロセスは、信頼合意（trust agreements）を円滑にする federation authority や、プロトコル接続を円滑にする federation proxy など、他の役割として動作する追加の当事者によって補助される場合がある。

1.1. Notations

本ガイドラインでは、本文中で次の表記上の約束を用いる。

大文字で記された特定の用語は、規範的要件（normative requirements）を表す。これらと同じ用語でも 大文字でない場合は、規範的要件を表さない。
- “SHALL” および “SHALL NOT” は、本書に適合するために厳密に従うべき要件であり、いかなる逸脱も許されないことを示す。
- “SHOULD” および “SHOULD NOT” は、複数の可能性の中で特に適切なものが推奨されるが、他を言及したり排除したりしないこと、ある行動方針が望ましいが必須ではないこと、または（否定形として）ある可能性や行動方針が推奨されないが禁止ではないことを示す。
- “MAY” および “NEED NOT” は、本書の範囲内で許容される行動方針を示す。
- “CAN” および “CANNOT” は、（物質的、物理的、因果的な）可能性および能力、または（否定形として）それらが存在しないことを示す。

1.1.1. Cryptographic Terminology

本ガイドラインでは、アサーション、属性バンドル、その他の連携プロトコル要素は、非対称デジタル署名または対称メッセージ認証コード（MAC）により検証される。非対称暗号または対称暗号のいずれかが明示的に要求される場合、sign および signature という語は、必要に応じて symmetric signature や asymmetric signature のように要件を示す修飾を付けて用いる。いずれの選択肢も可能な場合、sign および signature は修飾なしで用いる。

対称署名および非対称署名のいずれについても、署名を作成するために用いる鍵は signing key と呼ばれる。非対称暗号では、signing key は暗号鍵ペアの秘密鍵を指す。同様に、署名を検証するために用いる鍵は verification key と呼ばれる。非対称暗号では、verification key は暗号鍵ペアの公開鍵を指す。対称暗号では、対称鍵が signing key と verification key の両方である。

対称暗号化および非対称暗号化のいずれについても、ペイロードを暗号化するために用いる鍵は encryption key と呼ばれる。非対称暗号では、encryption key は暗号鍵ペアの公開鍵を指し、ペイロードを暗号化する対称鍵をカプセル化するために用いられる。同様に、暗号化されたペイロードを復号するために用いる鍵は decryption key と呼ばれる。非対称暗号では、decryption key は暗号鍵ペアの秘密鍵を指す。対称暗号では、対称鍵が encryption key と decryption key の両方である。

暗号プロセスの中には、実際の利用のために共有鍵を導出するために公開鍵・秘密鍵ペアを用いるなど、複数の鍵を組み合わせて使用するものがある。特に断りがない限り、本ガイドラインは、連携プロトコルに参加する当事者が既知である、または移転される初期の鍵素材に焦点を当て、そこから導出された暗号素材には焦点を当てない。

1.2. Document Structure

本書は次のように構成される。各節は、規範的（すなわち適合のために必須）または参考情報（すなわち必須ではない）のいずれかとして示される。

Section 1 は本書を紹介する。本節は 参考情報 である。
Section 2 は Federation Assurance Levels の要件を説明する。本節は 規範的 である。
Section 3 は連携システムの一般要件を説明する。本節は 規範的 である。
Section 4 は汎用 IdP の要件を説明する。本節は 規範的 である。
Section 5 は加入者が制御する wallet の要件を説明する。本節は 規範的 である。
Section 6 はセキュリティ上の考慮事項を提示する。本節は 参考情報 である。
Section 7 はプライバシー上の考慮事項を提示する。本節は 参考情報 である。
Section 8 はカスタマー体験の考慮事項を提示する。本節は 参考情報 である。
Section 9 は追加の例示シナリオを提示する。本節は 参考情報 である。
References 節は、本書で引用される文献一覧を含む。本節は 参考情報 である。
Appendix A は、本書で使用される略語の選定リストを含む。本付録は 参考情報 である。
Appendix B は、本書で使用される用語の選定グロッサリを含む。本付録は 参考情報 である。
Appendix C は、本書の履歴における変更点の要約リストを含む。本付録は 参考情報 である。

2. Federation Assurance Level (FAL)

本節は規範的である。

本節では、federation assurance levels（FAL）および、各 FAL において連携トランザクションを保護するための要件を定義する。ある FAL の要件を満たすためには、連携トランザクションは、その FAL に対して列挙されたすべての要件を満たすか上回らなければならない（SHALL）。

各 FAL は、FAL が高くなるほどセキュリティが高まる要件の集合によって特徴づけられる。これらの要件をここに示し、以降の節で詳細を述べる。

Audience Restriction

連携プロトコルで提示されるアサーションは特定の RP を対象とし、RP は自身がそのアサーションの意図された audience であることを確認できる。

Replay Protection

連携プロトコルで提示されるアサーションは、複数回提示されないよう保護される。

Assertion Injection Protection

RP は、攻撃者が連携トランザクションを完了し、偽造・取得・改ざんされたアサーションで認証済みセッションを開始することから強固に保護される（Sec. 3.11.1 を参照）。

Trust Agreement Establishment

連携トランザクションにおける当事者の権利と期待が定められ、RP において加入者の認証済みセッションを作成する目的で当事者間の信頼を支える（Sec. 3.5 を参照）。

Identifier and Key Establishment

IdP と RP は、将来の連携トランザクションにおいてアサーションやその他の成果物を検証できるように、識別子および暗号鍵素材を交換している（Sec. 3.6 を参照）。

Presentation

アサーションは、単独（bearer assertion として）で RP に提示するか、または加入者が提示する authenticator と組み合わせて提示できる。

Table 1 は、各 FAL の要件を（規範ではない）要約として示す。各上位レベルは下位レベルの要件をすべて包含して満たす（例: FAL3 の連携プロセスは、FAL3 が FAL2 および FAL1 のすべての要件を満たすため、FAL2 または FAL1 として受け入れ可能である）。Table 1 にない組み合わせも可能であり、各機関は、特定の FAL において要件領域の 1 つ以上でより強い保護を実装することを選択できる。

Table 1. Federation assurance levels

Requirement	FAL1	FAL2	FAL3
Audience Restriction	1 つのアサーションに複数 RP を許可；1 アサーションあたり 1 RP を推奨	1 アサーションあたり 1 RP	1 アサーションあたり 1 RP
Replay Protection	RP ごとに必須	必須	必須
Assertion Injection Protection	すべてのトランザクションで推奨	必須；トランザクションは RP で開始	必須；トランザクションは RP で開始
Trust Agreement Establishment	加入者主導または事前確立	事前確立	事前確立
Identifier and Key Establishment	動的または手動	動的または手動	手動
Presentation	Bearer Assertion	Bearer Assertion	Holder-of-key Assertion または紐付けられた authenticator

多様な連携実装オプションが存在し得るが、FAL は、段階的により安全なデプロイ選択肢を表す明確な指針を提供することを意図している。最適な FAL の選び方の詳細は [SP800-63] を参照。

2.1. Common FAL Requirements

信頼合意または連携トランザクションで FAL が指定されていない場合でも、本節の要件は適用される。

すべての FAL において、すべての連携トランザクションは、RP にアサーションを届け、RP に認証済みセッションを作成するために、Sec. 3 の要件に適合しなければならない（SHALL）。連携プロトコルで用いられるアサーションの例として、OpenID Connect における ID Token や、Security Assertion Markup Language の Assertion 形式がある。

すべての FAL において、RP は IdP からのアサーションを検証しなければならない（SHALL）。これは、加入者の認証イベントを表す有効なアサーションを提供する IdP を RP が信頼する必要があるためである。

Federation に関わるすべての当事者は、Sec. 3.11 で議論されるセキュリティ制御を用いなければならない（SHALL）。

IdP または RP は、ユースケースおよびニーズに応じて、複数の FAL で同時に運用できる場合がある。例えば、IdP は、高リスク機能へのアクセスを提供する RP に対して FAL3 の連携トランザクションを提供しつつ、より低いリスク特性の RP に対して同時に FAL2 を提供できる。同様に、RP は通常の操作には FAL2 を要求しつつ、より影響が大きい／機微な操作については、加入者に対し FAL3 の連携トランザクションを成功させることを要求できる。この能力は他の次元にも及ぶ。例えば、IdP は任意の IAL で本人確認された加入者アカウントへ同時にアクセスでき、任意の AAL で認証を許容できる。IdP と通信する RP は通常、アクセスのために受け入れる最小の IAL と AAL に制約を設ける。その結果、信頼合意は、異なるユースケースにおいて許可・要求される xAL を確立するために必要である（Sec. 2.5 を参照）。

2.2. Federation Assurance Level 1 (FAL1)

FAL1 は、連携トランザクションに対する基本的な保護レベルを提供し、幅広いユースケースとデプロイ判断を可能にする。

FAL1 では、連携プロトコルは Sec. 3.11.1 で議論される assertion injection protection を適用することが望ましい（SHOULD）。連携トランザクションは RP により開始されることが望ましい（SHOULD）。

FAL1 では、IdP は承認された暗号方式を用いてアサーションに署名しなければならない（SHALL）。RP は、想定される IdP に関連付けられた verification key を用いて署名を検証しなければならない（SHALL）。署名はアサーション内容の完全性を保護し、アサーションのソースとしての IdP を検証可能にする。

FAL1 では、アサーションは特定の RP または RP の集合に対して audience-restricted でなければならず（SHALL）、RP は当該アサーションが対象としている RP の一つであることを検証しなければならない（SHALL）。audience に含まれる各 RP は、同一のアサーションが当該 RP に複数回受理されないことを保証するため、アサーション内の replay protection 機構を強制しなければならない（SHALL）。複数の audience を持つアサーションは、複数の RP により受理され得るが、各 RP では 1 回だけ受理される。

FAL1 では、連携識別子は、ユーザー名、メールアドレス、社員番号などの平文の個人情報を含まないことが望ましい（SHOULD NOT）。

FAL1 では、信頼合意は、Sec. 4.3.2 で議論されるとおり、連携トランザクション中に加入者によって確立してもよい（MAY）。または、Sec. 4.3.1 で議論されるとおり、連携トランザクションの前に（すなわち “pre-established” trust agreement として）確立してもよい（MAY）。

2.3. Federation Assurance Level 2 (FAL2)

FAL2 は、連携システムに対する多様な攻撃（連携トランザクションへのアサーション注入の試みを含む）に対し追加の保護を要求することで、連携トランザクションに高い保護レベルを提供する。FAL1 のすべての要件は、ここでより具体的または厳格な要件によって上書きされない限り、FAL2 にも適用される。

FAL2 では、アサーションは Sec. 3.11.1 で議論される assertion injection 攻撃から強固に保護されなければならない（SHALL）。連携トランザクションは RP により開始されなければならない（SHALL）。

FAL2 では、アサーションは単一の RP に対して audience restricted でなければならない（SHALL）。RP はアサーション内の replay protection 機構を強制しなければならない（SHALL）。

FAL2 では、連携識別子は、ユーザー名、メールアドレス、社員番号などの平文の個人情報を含んではならない（SHALL NOT）。

FAL2 では、信頼合意は、連携トランザクションが行われる前に（すなわち “pre-established” trust agreement として）確立されなければならない（SHALL）（Sec. 4.3.1 を参照）。

連邦機関によって、またはその代理として運用され、FAL2 以上でアサーションを提示する IdP は、アサーション生成に用いる signing key を、[FIPS140] Level 1 以上で検証された機構によって保護しなければならない（SHALL）。

2.4. Federation Assurance Level 3 (FAL3)

FAL3 は、連携トランザクションに対して非常に高い保護レベルを提供し、連携トランザクションで伝達される情報が CSP および IdP によって確立された内容と一致することについて非常に高い信頼を確立する。FAL3 は、RP における加入者の追加認証を要求することで、IdP が侵害される可能性にも対処する。FAL1 および FAL2 のすべての要件は、ここでより具体的または厳格な要件によって上書きされない限り、FAL3 にも適用される。

FAL3 では、RP は、アサーションに加えて加入者が authenticator を制御していることを検証しなければならない（SHALL）。この authenticator は、holder-of-key assertion により識別される（Sec. 3.15 を参照）か、または bound authenticator である（Sec. 3.16 を参照）。

FAL3 では、信頼合意は、連携トランザクションが行われる前に（すなわち “pre-established” trust agreement として）確立されなければならない（SHALL）（Sec. 4.3.1 を参照）。

FAL3 では、CSP、IdP、RP の識別子は手動で確立されなければならない（SHALL）。各識別子は、その当事者を表す verification key と一意に関連付けられなければならない（SHALL）。verification key は、信頼合意で示されるとおり、手動または自動のいずれかになり得る、信頼された機構を通じて送信されなければならない（SHALL）。例えば、RP を表す公開鍵証明書を、手動の登録プロセスで IdP にアップロードする。RP は、IdP の公開鍵をダウンロードするために使用できる URL を手動で設定する。別の方法として、IdP と RP はそれぞれの公開鍵を federation authority にアップロードし、同じ場所から相互の鍵をダウンロードしてもよい。加入者が制御する wallet の場合、RP は CSP の公開鍵を表す URL を手動で設定できる。RP はこの公開鍵を取得し、加入者が制御する wallet により提示された属性バンドルの署名を検証するために使用する。鍵の確立、管理、ローテーション、失効、および識別子との関連付けの詳細は Sec. 3.6 を参照。

2.5. Requesting and Processing xALs

IdP は、さまざまな連携パラメータを用いて、さまざまな authenticator を持つ多数の加入者のアイデンティティをアサートできるため、IAL、AAL、FAL は、同じ RP に対してであっても、連携トランザクションごとに変動し得る。

IdP は、信頼合意の一部として RP が受け入れ可能な最小 xAL の集合を指定できる仕組みをサポートしなければならず（SHALL）、連携トランザクションの一部として実行時に、より厳格な最小集合を RP が指定することをサポートすることが望ましい（SHOULD）。RP が特定の xAL を要求した場合、IdP は可能であればその要求を満たすことが望ましく（SHOULD）、RP が要求した xAL を満たせない場合はその要求を失敗させることが望ましい（SHOULD）。IdP は、要求が満たされていない場合でも、結果としての xAL を必ずアサーションで示さなければならない（SHALL）。例えば、加入者が AAL1 で認証されたアクティブなセッションを持つが、RP が AAL2 を要求した場合、IdP は、可能であれば、加入者と IdP のやり取りの中で加入者に AAL2 の認証を求め、IdP におけるセッションのセキュリティを高める必要がある。IdP は、返却するアサーションの一部として、結果としての AAL を送る。これは、AAL1（すなわち step-up 認証要求が満たされなかった）であっても、AAL2（すなわち step-up 認証要求が成功裏に満たされた）であっても同様である。

IdP は、各連携トランザクションについて次の情報を RP に通知しなければならない（SHALL）。

RP に提示される加入者アカウントの IAL、または IAL の主張を行わないことの表示
IdP における加入者の現在アクティブなセッションの AAL、または AAL の主張を行わないことの表示
連携トランザクションの FAL

RP は、信頼合意の条項（Sec. 3.5 を参照）と、アサーションに含まれる情報（Sec. 4.9 および Sec. 5.8 を参照）の組み合わせから、この xAL 情報を取得する。IdP と RP 間のすべてのメッセージにおいて xAL が不変である場合（例: すべての加入者が同一の IAL で本人確認され、同一の authenticator 種別を使用するエンタープライズ・シナリオ）、xAL 情報は IdP と RP の信頼合意の条項に含まれなければならない（SHALL）。信頼合意で指定された可能な値の範囲内で xAL が変動し得る場合、RP が xAL を判断できるよう、十分な情報がアサーション内容の一部として含まれなければならない（SHALL）。

IdP は、特定の連携トランザクションについて IAL または AAL の主張を行わないことを示してもよい（MAY）。その場合、RP は結果としての xAL に既定値を割り当てない。すなわち、信頼合意またはアサーションのいずれにも IAL の宣言がない連携トランザクションは、機能的には「IAL なし」とみなされ、RP は当該アカウントが “IAL1”（本スイートで記述される最小の IAL）を満たすと仮定できない。

RP は、提供する機能へのアクセスのために受け入れる最小の IAL、AAL、FAL を決定しなければならず（SHALL）、保護対象リソースへのアクセスを付与する前に、IdP のすべてのアサーションを評価して、これらの xAL が満たされていることを確実にしなければならない（SHALL）。IdP の応答が要求されたパラメータを満たさない場合、RP はその要求に対処する機構（例: 要求を拒否する、例外処理プロセスに利用者を誘導する）を持たなければならない（SHALL）。RP は、特定の連携認証の IAL、AAL、FAL に基づいて機能を変えてもよい（MAY）。例えば、RP は一般的な機能（例: ダムシステムの状態の閲覧）について AAL2 で認証された連携トランザクションを許可しつつ、高リスク機能（例: ダムシステムの流量変更）については AAL3 を要求できる。同様に、RP は、高リスク機能（例: 機微情報へのアクセス）を、IAL2 で本人確認された特定の加入者アカウントのみに制限しつつ、IAL に関係なくすべての加入者アカウントに基本機能を許可できる。

Federation のプロセスにおいて、RP は、加入者アカウントの IAL を決定する詳細（CSP から IdP に提供された加入者アカウントの詳細）へ直接アクセスできない。加えて、RP は IdP における認証イベントやアクティベーションイベントに関与しないため、AAL を決定できない。RP は、FAL を決定する連携トランザクションの多くの側面を見るが、IdP には、RP に対して意図する FAL を通知することなど、FAL に関する独自の責務もある。したがって、IdP は、各連携トランザクションについて、RP が IAL、AAL、および IdP が意図する FAL を決定するのに十分な情報を提供しなければならない（SHALL）。これは、アサーション、信頼合意での事前取り決め、またはその両方の組み合わせで行ってもよい（MAY）。

RP は、トランザクションで宣言された FAL に対して、連携トランザクションにおける自身の義務を満たしていることを確実にしなければならない（SHALL）。例えば、RP は、提示方式が FAL2 以上の assertion injection protection 要件を満たすこと、および FAL3 では適切な holder-of-key の証明または bound authenticator が提示されることを確実にする必要がある。

3. Common Federation Requirements

本節は規範的である。

連携トランザクションは、IdP が把握する加入者アカウントに基づき、加入者が RP で認証済みセッションを確立できるようにする。連携トランザクションは、認証済みセッションに関連付けられたアイデンティティ属性の集合を RP に提供することもできる。認証済みセッションは、その後、次のようなユースケースを支えるために RP で利用され得る。

RP の機能へアクセスするために加入者をログインさせる
提示された属性に基づいて加入者を識別する
連携トランザクションで提示された加入者属性を処理する

連携トランザクションは、比較的複雑なマルチパーティ・プロトコルを必要とし、微妙なセキュリティおよびプライバシー特性を持つ。特定の連携プロトコル、プロファイル、またはデプロイ構造を評価する際には、しばしば、構成要素となる関係に分解し、それぞれに必要な事項を評価することが有益である。

加入者と CSP
CSP と IdP
加入者と IdP
IdP と RP
加入者と RP

さらに、加入者はしばしば、user agent（例: Web ブラウザ）を通じて CSP、IdP、RP とやり取りし、その結果、user agent が連携プロセスに関与する。これらガイドライン全体で述べる加入者の行動は、任意で user agent 経由にできるが、user agent が不要なアプリケーション種別ややり取りもある（例: native applications）。必要な場合には、user agent に関する要件が明示される。

連携プロトコルの各当事者は、連携システムが意図どおりに機能するために満たすべき、特定の責務と期待を負う。

連携トランザクションは、互いに関連する 3 つの要素で構成される。

Trust Agreements:

Federation の目的で CSP、IdP、RP を接続できるようにするポリシー決定の確立。このポリシーは、接続許可を定める一連の条項によって統治される。

Identifier and Key Establishment:

連携トランザクションに参加する CSP、IdP、RP の暗号鍵と識別子の関連付け。このプロセスにより、当事者は将来の交換に備えて互いを安全に識別できる。

Federation Protocol:

IdP による加入者のアイデンティティ検証と、その後の RP へのアサーション発行。これにより、加入者属性が RP に渡され、RP における加入者の認証済みセッションが確立される。

Federation のプロセスを完成させるには、これらの要素がすべて満たされる必要がある。これが起こる正確な順序や、どのステップにどの当事者が関与するかは、デプロイモデル、プロトコル選択、その他の要因により変わり得る。

3.1. Federation Models

本ガイドラインは、Federation の 2 つのモデル（general-purpose IdPs と subscriber-controlled wallets）に対する要件を示す。subscriber-controlled wallets はさらに、加入者が制御するデバイス上にホストされる場合と、加入者のために運用されるリモートホスト型システム上にホストされる場合がある。これらのモデルは、加入者アカウントの内容が連携システムに利用可能となる方法によって主に区別される。general-purpose IdP では、加入者アカウントは、通常、加入者を伴わないアクションによって CSP から全体または一部が提供される。subscriber-controlled wallet では、加入者アカウントは、属性バンドルの発行を通じて CSP により提供される。

複数アカウントの IdP を組織がホストするような general-purpose IdPs に固有の要件は Sec. 4 で議論する。デバイス上の digital wallet ソフトウェアや cloud-hosted wallet provider のような subscriber-controlled wallets に固有の要件は Sec. 5 で議論する。その他の要件（Sec. 3 の一般要件を含む）は、特に断りがない限り両モデルに適用される。Federation システムの異なるモデルは、信頼と情報の要件を異なる方法で満たす。

Table 2 は、連携システムの異なるモデルに対する要件の（規範ではない）一覧を示し、情報の中核的要素が、IdP からのアサーションまたは CSP からの属性バンドルのいずれで伝達されるかを示す。連携実装が両モデルの側面を持つ場合、該当する節の関連部分が適用される。

Table 2. Federation models

Requirement	Location	General-Purpose IdP	Subscriber-controlled Wallet
IdP issuer identifier	Assertion	必須	任意
IdP issuer identifier	Attribute bundle	任意	任意
IdP verification key	Attribute bundle	任意	必須
Subject identifier	Assertion	必須	任意
Subject identifier	Attribute bundle	任意	一時的プロビジョニングまたはアカウント解決を用いる場合を除き必須
CSP issuer identifier	Attribute bundle	必須	必須

3.2. Roles

3.2.1. Credential Service Provider (CSP)

CSP は、加入者から属性を収集して検証し、それらを加入者アカウントに保存する。CSP はまた、1 つ以上の authenticator を加入者アカウントに紐付け、加入者が authenticator を検証できるシステムへ直接認証できるようにする。

CSP は、連携トランザクションで使用するために、属性、導出属性値、または属性バンドルを IdP に提供する。特に、CSP は、subscriber-controlled wallet が連携プロセスで IdP として機能できるように、署名付き属性バンドルを発行する（Sec. 5.1 を参照）。

3.2.2. Identity Provider (IdP)

IdP は、（CSP により確立された）加入者アカウントと、加入者がアクセスしようとしている RP の間の橋渡しを提供する。IdP は、複数の加入者アカウントに対するサービスとしてデプロイできるほか、加入者のデバイス上の subscriber-controlled wallet のように、単一の加入者が制御するコンポーネントとしてデプロイすることもできる。

IdP は、（general-purpose IdPs の場合は）authenticator の検証、または（subscriber-controlled wallets の場合は）アクティベーション要素の提示により、加入者との認証イベントを確立する。IdP は、認証イベントを表すアサーションを作成する。

IdP は、CSP からの加入者アカウントに対し、次を含む（ただしこれに限られない）Federation 固有の項目を付加する。

連携プロトコルで使用する 1 つ以上の外部連携識別子
どの RP が加入者アカウントのどの属性へアクセスできるかを定義するアクセス権の集合（allowlists や、加入者によって保存された実行時決定など）
連携アカウント利用情報
IdP により収集または割り当てられた追加属性

IdP は、アサーション内、または identity API を通じて、加入者のアイデンティティ属性を利用可能にする（Sec. 3.12.3 を参照）。

一部のシステムでは、これは offering party (OP) とも呼ばれる。

3.2.3. Relying Party (RP)

RP は、IdP からのアサーションを処理し、加入者がアクセスしようとしているサービスを提供する。直接認証モデルとは異なり、RP は加入者アカウントに紐付く authenticator の verifier 機能を提供しない。

アイデンティティ属性は、連携プロセスを通じて、アサーション内または identity API を通じて RP に提供され得る（Sec. 3.12.3 を参照）。これらの属性は、しばしば attribute-based access control (ABAC) におけるアクセス権限の判定や、トランザクションの促進（例: 送付先住所の提供）に用いられる。authorization とアクセス制御の詳細は本ガイドラインの範囲外である。アサーションにどの属性が必要かの要件は、Sec. 4.9 および Sec. 5.8 にある。

これらの属性を保持・管理するために、RP はしばしば、加入者を表す RP subscriber account を維持する。RP subscriber account には、Sec. 3.8 で記述されるとおり、RP ローカルの情報が含まれる。

一部のシステムでは、これは service provider (SP) とも呼ばれる。

3.3. Functions

3.3.1. Trust Agreement Management

連携トランザクションの条項を定義する信頼合意（Sec. 3.5 を参照）は、RP と IdP が相互接続のためにペアワイズの合意を結ぶ場合や、加入者が IdP から RP へ自分のアイデンティティを共有する決定を行う場合など、関係当事者が直接確立・管理できる。別の状況では、信頼合意は federation authority と呼ばれる専用の当事者により管理される場合がある。federation authority は、信頼合意内で異なる役割と機能を満たす当事者のオンボーディングと管理を支援する。federation authority の機能は、当事者がペアワイズで信頼判断を行う必要なく、合意内で相互に信頼するための基盤を提供する。

例えば、federation authority が管理する信頼合意に参加する RP は、その federation authority により承認された任意の IdP が自組織の目的に適していると判断できる。別の方法として、RP は、自身のアプリケーション要件に基づいて、federation authority が承認した IdP の部分集合を選べる。ある IdP が、RP が参加した時点では管理対象の信頼合意に含まれていなかった場合でも、RP は federation authority の継続的な管理の恩恵により、新たに追加された IdP を信頼できる。federation authority は、Sec. 3.5.2 で議論されるとおり、多者間の信頼合意（multilateral trust agreements）で用いられる。

3.3.2. Authorized Party

信頼合意における authorized party とは、加入者属性の開示を含め、信頼合意で扱う特定のリリース判断に責任を持つ組織・人物・実体である。信頼合意は、想定される authorized party と、要求が自動的に許可／自動的に拒否／個人による実行時判断を要する、のいずれになるかのパラメータを規定する。一般公開シナリオでは、authorized party は加入者であることが想定される。加入者の属性開示への同意は、連携トランザクション中の明示的な同意プロセスを通じて収集されることが多い（Sec. 4.6.1.3 を参照）。

エンタープライズ・シナリオでは、authorized party は組織であることが想定される。属性開示の同意は、組織がすべての加入者を代表して決定し、この同意は allowlist（Sec. 4.6.1.1 を参照）として表現され、加入者の直接の判断や関与なしにアイデンティティ属性を開示できるようにする。

authorized party のさまざまな例は Sec. 9.10 にある。

3.3.3. Proxied Federation

一部のアーキテクチャでは、IdP と RP は互いに直接通信しない。federation proxy が、連携プロトコルにおけるすべての通信について、IdP と RP の仲介者として機能する。proxy は、Fig. 1 に示すとおり、上流側では RP として、下流側では IdP として機能する。proxy 経由で通信する場合、上流 IdP と下流 RP は、標準の連携プロトコルを用いて proxy と通信し、加入者は 2 つの別個の連携トランザクションに参加する。その結果、IdPs と RPs に適用されるすべての規範的要件は、それぞれの側における proxy の役割に対しても適用されなければならない（SHALL）。さらに、proxy はチェーニング・シナリオにおいて、下流 proxy に対する上流 IdP として機能できる。

Fig. 1. Federation proxy

Diagram of a federation proxy accepting assertions from an upstream IdP and providing assertions to a downstream RP.

proxy の役割は連携プロトコルに限定される。proxy は、上流 IdP と下流 RP の間の信頼合意の確立や促進には関与しない。同一の当事者が federation authority と proxy の両方を運用して連携トランザクションを促進することはできるが、proxy の機能は federation authority の信頼合意管理の役割とは別である。Federation システムの他のメンバーと同様に、proxy は上流と下流のそれぞれと別個の信頼合意に関与できるし、または多者間合意のように、単一の信頼合意をすべての当事者に適用することもできる。

下流 RP は、proxy により生成されたアサーションを、他の任意の IdP からのアサーションと同様に受け取り検証する。このアサーションは、proxy が上流 IdP から受け取るアサーションに基づく。上流 IdP からのアサーション内容は、proxy が用いる方法に応じて、いくつかの形で扱える。

proxy は、上流 IdP からのアサーション情報を一切持ち込まずに、新しいアサーションを作成できる。このパターンは、下流 RP をブラインド化し、加入者が元々どの上流 IdP から来たのかを RP が知らないようにするのに有用である。
proxy は、上流 IdP からのアサーションの属性を、proxy からのアサーションへコピーできる。このパターンは、下流 RP に対してアサーション内でアイデンティティ属性を運ぶのに有用である。
proxy は、上流 IdP からのアサーション全体を、proxy からのアサーションに含められる。このパターンは、RP が上流 IdP のアサーションと proxy のアサーションを独立に検証できるようにする。

proxy からのアサーションの連携識別子（Sec. 3.4 を参照）は、そのアサーションの発行者として proxy を示さなければならない（SHALL）。

proxied federation モデルは複数の利点を提供し得る。federation proxy は、共通の統合インターフェースを提供し、連携プロトコル、形式、スキーマ間の変換を提供することで、RP と IdP の技術的統合を簡素化できる。また、proxy が RP と IdP を相互にブラインド化する程度に応じて、組織が相互に加入者リストを守りたい場合のビジネス上の秘匿性を提供できる。proxy は Sec. 3.10 で述べるプライバシーリスクの一部を緩和できる一方、追加の当事者が加入者情報の取り扱いに関与するため、新たなリスクも生じる。例えば、攻撃者が proxy を侵害できた場合、IdP や RP を直接狙わなくても、すべての情報が proxy を通過するため、加入者属性や活動へアクセスできる。さらに、proxy は当事者間の連携トランザクションを仲介し、加入者アカウントを接続の両側に紐付けるため、IdP や RP ができる範囲を超えて、加入者がどの RP でどのアイデンティティを使っているかといった追加のプロファイリング（すなわち情報の集約）を行い得る。

ブラインディング技法、その用途、および限界の詳細は Sec. 7.5 を参照。

proxy と下流 RP の間の接続の FAL は、経路全体に沿った最も低い FAL とみなされ、proxy はこれを下流 RP に正確に表現しなければならない（SHALL）。例えば、上流 IdP と proxy の間の接続が FAL1 で、proxy と下流 RP の間の接続が他の点では FAL2 の要件を満たしていても、proxy と下流 RP の間の接続は FAL1 とみなされる。同様に、上流 IdP と proxy の間が FAL2 で、proxy と下流 RP の間が FAL1 のみである場合、proxy を通る全体の接続は FAL1 とみなされる。

加入者が制御する wallet が proxy として機能する可能性もある。その場合、wallet ソフトウェアは、外部 IdP に対して RP として動作し、他の proxy と同様に、その属性を下流 RP に提供する必要がある。

一部のシステムでは、proxy は broker と呼ばれる。

3.3.4. Fulfilling Roles and Functions of a Federation Model

連携トランザクションの役割はさまざまな方法で接続できるが、本ガイドラインではいくつかの一般的なパターンを想定する。期待される信頼合意の構造とコンポーネント間の接続は、採用するパターンにより変わる。

異なる役割と機能は、別々の当事者によって満たされ、相互に統合され得る。例えば、CSP は、CSP と同一の当事者や組織によって運用されていない IdP に、加入者アカウントの属性を提供できる。

単一の当事者が、特定の連携合意内で複数の役割を満たすことも可能である。例えば、CSP がアイデンティティ・サービスの一部として IdP を提供する場合、CSP は加入者アカウント確立プロセスの一部として、IdP へ加入者アカウントをプロビジョニングできる。同様に、RP が IdP と同じセキュリティおよび管理ドメイン内にあっても、技術的、デプロイ上、およびアカウント管理上の利点のために Federation 技術を用いて接続することができる。

これは、federation authority や proxy のような連携システム全体の他の機能についても同様である。役割は似て見えるかもしれないが、両者は根本的に異なり、接続される必要はない。federation authority は当事者間の信頼合意の確立を促進し、proxy は連携プロトコルの接続を促進する。同一の実体がシステム内で federation authority と proxy の両方の機能を満たし、信頼合意と技術的接続の両方を確立する手段を提供することもできる。

3.4. Federated Identifiers

加入者は、アサーション内の情報によって連携トランザクションで識別される。これにより RP は、アサーションを RP subscriber account に関連付けられる。この識別は、アカウント解決プロセス（Sec. 3.8.2 を参照）または federated identifier を通じて行われ得る。

general purpose IdPs において、federated identifier は、加入者アカウントを表す subject identifier と、IdP を表す issuer identifier の論理的な組み合わせである。subject identifier は IdP により割り当てられ、issuer identifier は通常、設定によって IdP に割り当てられる。

subscriber-controlled wallets において、federated identifier は、加入者アカウントを表す subscriber identifier と、属性バンドルを発行した CSP を表す issuer identifier の論理的な組み合わせである。subject identifier は CSP により割り当てられ、issuer identifier は通常、設定によって CSP に割り当てられる。ただし、例えばモバイル運転免許証のケースのように、これらが常に利用可能とは限らない。この場合、アカウント解決は通常、運転免許証番号と、運転免許証の発行者の利用により行われる。このパターンは Sec. 3.8.2 で扱う。

この複数部からなる federated identifier パターンが必要なのは、異なる IdP が subject identifier を独立に管理し、異なる subject に対して subject identifier の選択が衝突する可能性があるためである。そのため、RP は、subject identifier を発行した IdP を考慮せずに subject identifier を処理してはならない。多くのユースケースでは、federated identifier は、複数セッションにわたり、使用した authenticator に依存せず加入者に対して安定しており、RP は複数の認証済みセッションやアカウント変更を通じて加入者を信頼性高く識別できる。ただし、プライバシー強化のために、federated identifier と、RP におけるその利用を一時的（ephemeral）にすることも可能である。federated identifiers とその構成要素は機械可読であることが意図され、ユーザー名などの人間向け識別子とは異なり、加入者が管理したり加入者に露出したりすることは意図していない。

federated identifiers を用いる場合、federated identifier は、その加入者に対して一意でなければならない（SHALL）。federated identifiers は、RP において単一の加入者に関連付けられなければならない（SHALL）。

federated identifiers には、ユーザー名、メールアドレス、社員番号などの平文の個人情報を含めないことが推奨される。この制約は FAL2 以上では要件である。Federation がアカウント解決（Sec. 3.8.2 を参照）を用いる場合、RP subscriber account は federated identifier を用いずに RP により解決できる。

federated identifiers は論理概念であり、通常は subject identifier と issuer identifier と別個の明示的値ではない。代わりに、federated identifiers は、加入者が一意に区別され、異なる IdP から提供される subject identifiers の間で衝突が起きないことを保証するために必要な情報で構成される。

3.4.1. Pairwise Pseudonymous Identifiers (PPI)

状況によっては、共通の subject identifier を使って加入者アカウントが複数の RP で容易にリンクされることを防ぎたい場合がある。pairwise pseudonymous identifier (PPI) は、IdP が、単一の加入者アカウントに対して、異なる RP に対し複数の異なる federated identifier を提供できるようにする。PPI の利用により、異なる RP が共謀して federated identifier を用いて加入者を追跡することを防ぐ。

General Requirements

IdP が RP 向けに生成するアサーション内で pairwise pseudonymous identifiers を用いる場合、IdP は各 RP（Sec. 3.4.1.2 を参照）または RP の集合（Sec. 3.4.1.3 を参照）ごとに異なる federated identifier を生成しなければならない（SHALL）。

氏名、住所、電話番号、メールアドレスなどの一部のアイデンティティ属性は、連携トランザクションの外でも加入者を識別するために使われ得る。PPI をこの種の識別属性と併用する場合でも、複数の RP が共謀すれば、システム間の相関により加入者を再識別できる可能性がある。例えば、2 つの独立した RP がそれぞれ異なる PPI で同じ加入者を見た場合でも、各アサーションで PPI と併せて運ばれる氏名、メールアドレス、住所、その他の識別属性を比較することで、同一人物であると判断できる可能性がある。PPI を識別属性と併用する場合、RP は、適用される法規制要件と整合する形で、加入者データの相関を防ぐプライバシーポリシー、プロセス、および手順を確立しなければならない（SHALL）。

proxied federation モデル（Sec. 3.3.3 を参照）では、proxy が IdP をブラインド化して、加入者がどの RP へアクセスしているかを IdP が知り得ないため、上流 IdP は下流 RP のために PPI を生成できない場合がある。そのような状況では、PPI は一般に、IdP と federation proxy の間で確立される。IdP として動作する proxy は、下流 RP に PPI を提供できる。プロトコルによっては、アイデンティティ・プロトコルが機能するよう、federation proxy が PPI を上流 IdP からの関連識別子へマップする必要がある場合がある。その場合、proxy は、異なる RP における同一加入者を表す PPI を追跡し判定できることになる。PPI から他の識別子へのマッピングは加入者情報とみなされ、Sec. 3.10.1 の要件に従って取り扱われなければならない（SHALL）。

Pairwise Pseudonymous Identifier Generation

PPI は、（ユーザー名、メールアドレス、社員番号など）加入者に関する識別情報を含んではならない（SHALL NOT）。PPI は、加入者に関する情報へアクセスできる当事者に推測されにくくなければならず（SHALL）、攻撃者に推測不能となる十分なエントロピーを提供しなければならない（SHALL）。PPI はランダムに生成して IdP が加入者に割り当ててもよく、または導出が不可逆かつ推測不能な方法で行われる限り、他の加入者情報から導出してもよい（例: [SP800-131A] で議論される、秘密鍵を用いた keyed hash function の使用）。

信頼合意により共有として指定されない限り、PPI は単一の RP にのみ開示されなければならない（SHALL）。

Shared Pairwise Pseudonymous Identifiers

同一の shared PPI は、次のすべての条件を満たす場合に限り、特定の RP の集合に対して用いられなければならない（SHALL）。

信頼合意が、特定の RP の集合に対する shared PPI を規定している。
authorized party が、shared PPI の利用に同意し、かつその利用について通知されている。
それらの RP が、共有のセキュリティ・ドメインまたは共有の法的所有のように、相関に対する運用上の必要性を正当化する、実証可能な関係を有する。
shared PPI の集合に含まれるすべての RP が、そのように相関されることに同意している（すなわち、一方の RP が他方の RP の PPI を、その RP の認識と同意なしに要求できない）。

RP は、shared PPI の要求に関連するプライバシーリスクを検討するため、プライバシーリスク評価を実施しなければならない（SHALL）。追加のプライバシー考慮事項は Sec. 7.2 を参照。

IdP は、意図された RP のみが集合に含まれることを確実にしなければならない（SHALL）。そうでない場合、悪意のある RP が、その集合の一部になりすまして、RP の集合に対する shared PPI を不正に知り得る。

[OIDC] の sector identifier 機能は、RP 群に対する shared PPI を計算する仕組みを提供する。このプロトコルでは、RP の識別子が URL の内容にすべて列挙され、IdP は認証済みの保護チャネル越しにその URL を取得できる。shared PPI は、sector identifier URL とアルゴリズムの他の入力を考慮して計算され、sector identifier URL の内容に列挙されたすべての RP が同一の shared PPI を受け取る。

3.5. Trust Agreements

Trust agreements は、連携トランザクションにおける当事者を支えるために確立される信頼関係の集合を表す構成概念である。信頼合意は、次の関係の 1 つ以上に対処しなければならない（SHALL）。

IdP to CSP:

IdP は、IdP のオンボーディング・プロセスまたは属性バンドルの発行を通じて、加入者アカウント内の属性へのアクセスを CSP が提供することを信頼する。IdP は、加入者アカウント確立に用いられる CSP の本人確認プロセスを信頼する。

CSP to IdP:

CSP は、IdP が加入者のアイデンティティ属性を RP に正確に表現し、合意された機能の外にアイデンティティ属性を開示しないことを信頼する。CSP は、属性が解放される前に加入者の認証またはアクティベーション要素の提示を要求するなど、IdP が属性解放を保護することを信頼する。

RP to IdP:

RP は、IdP が CSP により提供された加入者アイデンティティ属性を正確に表現することを信頼する。RP は、IdP が認証イベントを表現する際に加入者を認証または識別することを信頼する。

IdP to RP:

IdP は、RP が要求した属性を、その表明した目的のためにのみ使用することを信頼する。

RP to CSP:

RP は、CSP が IdP を通じて加入者アイデンティティ属性へのアクセスを提供することを信頼する。RP は、CSP が加入者の本人確認を行い、加入者アカウントを管理していることを信頼する。

すべての連携トランザクションは、適用される当事者間の 1 つ以上の信頼合意の条項によって統治されなければならない（SHALL）。異なる関係は、異なるタイミングおよび異なるプロセスにより確立され得る。例えば、CSP と IdP の間の信頼合意は、一般に、RP と IdP の間の信頼合意とは別であるが、これら当事者の下での連携トランザクションに対する全体の条項集合は、両方の関係から引き出される。

シナリオにより機能のために必要な信頼の組み合わせは異なり、連携モデルに応じて変わり得る。連携トランザクションに適用される個々の信頼合意の組み合わせは、本ガイドラインの要件を満たす。信頼合意は、正式な契約、非公式な動的ユーザー合意、その他の文書化された二者間または多者間の信頼判断など、さまざまな形を取り得る。多くの場合、信頼合意は trust framework を用いて実装でき、当事者が相互に接続するための規則集合を形式化する。trust frameworks は、federation authority が管理する Federation で規則を形式化するために用いられることが多い。

例えば、subscriber-controlled wallets のケースでは、RP は CSP と直接または完全な信頼合意がなくてもアサーションを受け入れ得る。Sec. 5.3 で述べるとおり、関連する信頼合意の規定は、属性バンドル発行プロセスなどに関する CSP の公開情報を RP が評価することにより、RP が一方的に定める場合がある。CSP は、この信頼関係のこの部分が確立されるために RP を知る必要はない。属性利用目的の開示要件を満たすため、RP は CSP に通知することなく、実行時に加入者へその目的を開示できる。

信頼合意は、連携トランザクションで影響する当事者間の条項を確立し、許可される xAL と、連携トランザクションで交換されるアイデンティティ属性の意図された目的を含む。信頼合意は、Sec. 8 で議論されるカスタマー体験要件を確立しなければならない（SHALL）。信頼合意は、信頼合意の対象となる加入者に対して CSP が用いた本人確認プロセスの詳細（補完的制御および例外処理プロセスを含む）を含めなければならない（SHALL）。

すべての信頼合意は、その合意が適用される加入者アカウントの特定の母集団を定義しなければならない（SHALL）。この母集団を定義する正確な手段は本書の範囲外である。多くの場合、母集団は、CSP が管理し IdP を通じて利用可能にする加入者アカウントの全体として定義される。別の場合には、母集団は IdP を通じて利用可能なアカウントの区画化された部分集合として定義される。加入者主導の信頼合意のように、RP が単一の加入者アカウントに対して IdP と別個の信頼合意を確立することも可能である。

単一の連携トランザクションの過程では、すべての当事者のポリシーと期待が曖昧でないことが重要である。したがって、あるトランザクションにおいて有効な信頼合意の集合は 1 つだけであることが望ましい（SHOULD）。これは通常、トランザクションに参加する CSP、IdP、RP の一意の組み合わせによって決定される。ただし、異なる加入者母集団が異なる信頼合意によって統治されるなど、他の形で合意が変動し得る。複数の信頼合意が連携トランザクションに適用される場合、そのすべての適用される信頼合意の条項を合算した集合が、そのトランザクションの有効な信頼合意を構成しなければならない（SHALL）。

当事者間に信頼合意が存在することは、各当事者が他の当事者と別の合意を持つことを妨げない。例えば、IdP は複数の RP と同時に独立した合意を持てるし、RP も同様に複数の IdP と同時に独立した合意を持てる。IdP と RP は、合意の対象外の当事者に対して、信頼合意の存在や条項を開示する必要はない。

信頼合意は、連携関係に関連して期待される／受け入れ可能な IAL、AAL、FAL に関する条項を確立しなければならない（SHALL）。

信頼合意は、Sec. 3.5.3 で議論されるとおり、連携参加者間で救済（redress）および問題を調整するために必要な機構と資料を定義しなければならない（SHALL）。

信頼合意は、すべての当事者に期待されるデータ保持ポリシーを宣言しなければならない（SHALL）。

加入者は通常、信頼合意の条項に直接関与しないが、加入者は信頼合意の条項および結果としての連携トランザクションの影響を受ける。そのため、信頼合意の関連条項は、明確で理解可能な言語で加入者に利用可能にされなければならない（SHALL）。信頼合意の条項は、加入者への開示が行われる前に、機微なセキュリティ情報の露出を避けるため、加入者に条項を通知する責任を負う当事者（例: CSP、IdP、RP、または federation authority）によってレビューされなければならない（SHALL）。

加入者がこれら条項へアクセスする手段と、加入者へ通知する責任当事者は、信頼合意確立の手段および条項内容により変わる。一般的な開示方法には次がある。

加入者がアクセス可能な Web ページで信頼合意条項を提供する
加入者に通知を送る
実行時判断の際に条項の要約を表示し、全文を確認できる選択肢を提供する

信頼合意の確立は、役割とアプリケーションが単一のセキュリティ・ドメイン内に存在する、または法的所有を共有する、エンタープライズ・システムのような場合であっても、すべての連携トランザクションに必要である。そのような場合、信頼合意の確立は組織内プロセスでよく、正式な合意を伴う必要はない。それでも、組織は要求に応じて信頼合意の条項を文書化し、加入者に開示しなければならない。

加入者の user agent は通常、信頼合意の当事者ではない。ただし、加入者が制御する wallet が加入者のブラウザソフトウェア内で動作するなど、user agent が連携トランザクションの役割の一つとして動作する場合は例外である。

（入力は途中で中断しているため、ここまでを翻訳しました。続きが必要なら next と入力してください。）

3.5.1. Bilateral Trust Agreements

二者間の信頼契約では、信頼契約の確立がフェデレーション参加者同士の間で直接行われ、別の当事者によって信頼契約が管理または仲介されることはありません。二者間の信頼契約により、フェデレーションによるアイデンティティを用いてサービスへアクセスできるようにしたい組織同士で、ポイントツーポイントの接続を確立できます。二者間接続にはさまざまな形態があり、静的な契約を伴う大規模エンタープライズアプリケーションや、これまで未知だった RP への加入者主導の動的接続などが含まれます。いずれの場合も、CSP、IdP、RP はフェデレーション接続に関する自らのポリシーを直接管理します。

二者間の信頼契約は、すべての信頼契約に対して示された要件に適合します。ただし、これらの信頼契約は追加の当事者を含まないため、その確立および管理に関して、例えば多者間の信頼契約で義務付けられるような追加の規範的要件は存在しません（[Sec. 3.5.2] 参照）。

3.5.2. Multilateral Trust Agreements

多者間の信頼契約では、フェデレーション参加者は、当事者間の信頼契約の確立を支援するために federation authority に依拠します。このモデルでは、federation authority が信頼契約の下に CSP、IdP、RP を含めることを仲介します。

いずれの役割で当事者を受け入れる（オンボードする）場合でも、federation authority は [Fig. 2] に示すとおり、その当事者が信頼契約の条項に適合していることを確認するための審査（vetting）を実施します。審査の水準は、フェデレーション内で採用されるユースケースやモデルに固有であり、詳細は本書の対象範囲外です。他の多くの機能と同様に、federation authority は審査プロセスを別の当事者に外部委託できますが、最終的には審査結果に対して federation authority が責任を負います。

Fig. 2. Federation authority

federation authority の下で、さまざまな当事者に対する信頼契約の条項を仲介する federation authority の図。

信頼契約は、すべての当事者を審査するために必要な実務を列挙しなければならず（SHALL）、また、その審査プロセスを実施する責任を負う当事者（単数または複数）を示さなければなりません（SHALL）。

少なくとも、CSP、IdP、RP の審査は、次の事項を確立しなければなりません（SHALL）。

CSP は、[[SP800-63A]] に従って加入者アカウントの identity proofing を行う。
CSP は、適用される場合に応じて、[Sec. 4.1] または [Sec. 5.1] の要件に従い、加入者アカウント（属性、派生属性値、属性バンドルを含む）を IdP に対して安全な方法でオンボードする。
IdP（フェデレーショントランザクション中）または CSP（加入者が管理するウォレットに属性バンドルを発行する際）で加入者を認証するために用いられる authenticator は、[[SP800-63B]] に従って用いられる。
IdP が生成する assertion は、適用される場合に応じて、[Sec. 4.9] または [Sec. 5.8] の要件に適合する。
RP は、加入者の属性データの取り扱い（保持、集約、削除、第三者への開示など）に関する要件に適合する。
RP および IdP のシステムは、federation authority が規定する、フェデレーションプロトコルの合意済みプロファイルを使用する。

federation authority は、信頼契約の下にある当事者が、信頼契約における他の当事者の加入（membership）を検証できるようにするプログラム的手段を提供してもよい（MAY）。例えば、federation authority は、システム内で RP に対してアイデンティティを提供するために審査済みの IdP の機能を提供する discovery API を提供できます。別の方法として、federation authority は、登録ステップの間に RP が IdP に提示できる、署名付きの証明（attestation）を提供することもできます。

federation authority は、信頼契約に開示された条項への適合性について、構成員を定期的に再評価しなければなりません（SHALL）。

多者間の信頼契約は、interfederation agreement を作成して、他の主体が管理する別の信頼契約に基づいて信頼を確立してもよい（MAY）。例えば、IdP1 は federation authority A1 との多者間契約の下で審査済みであり、RP2 は federation authority A2 との多者間契約の下で審査済みであるとします。IdP1 と RP2 の接続を仲介するために、新しい federation authority A3 は、A1 からの IdP と A2 からの RP を受け入れる多者間契約を提供できます。IdP1 と RP2 が A3 の権限を受け入れる場合、フェデレーション接続は、この interfederation agreement の後援の下で継続できます。

3.5.3. Redress Requirements

フェデレーショントランザクションは、しばしば複数の主体によって制御される複数の当事者の間で発生し、フェデレーショントランザクションの異なる段階が、加入者が他の当事者に救済（redress）を求める必要が生じる状況につながる可能性があります。

加入者のアイデンティティ属性の受領者として、RP は加入者にとってフェデレーションシステムへの主要な窓口です。場合によっては、加入者は RP の利用に IdP が関与していることを認識していないことがあります。したがって、救済を求めるために RP に連絡する明確で利用しやすい方法を加入者に提供する責務は RP にあります。RP の加入者アカウント（アカウントに格納された属性を含む）、RP の機能、バインドされた authenticator、RP の allowlist、その他 RP の管理下にある事項に関する問題について、RP は加入者に対し、明確で利用しやすい救済手段を提供しなければなりません（SHALL）。IdP または CSP に関わる問題について、RP は適切に、加入者が IdP または CSP との救済プロセスを開始できる手段を加入者に提供しなければなりません（SHALL）。

属性値および派生属性値（フェデレーショントランザクション上で利用可能となるもの）を含む、フェデレーショントランザクションにおける加入者アカウントの利用、IdP の機能、holder-of-key authenticator、IdP の allowlist、その他 IdP の管理下にある事項に関する問題について、IdP は加入者に対して明確で利用しやすい救済手段を提供しなければなりません（SHALL）。特定の RP も関係する問題について、IdP は加入者が RP との救済プロセスを開始できる手段を加入者に提供しなければなりません（SHALL）。IdP に利用可能となっている加入者アカウントに関する問題について、IdP は加入者が CSP との救済プロセスを開始できる手段を加入者に提供しなければなりません（SHALL）。

加入者アカウント（加入者アカウント内のアイデンティティ属性および authenticator を含む）に関する問題について、CSP は加入者に対して明確で利用しやすい救済手段を提供しなければなりません（SHALL）。

救済提供に関する追加要件については、[Sec. 3.6 of [SP800-63]] を参照してください。

3.6. Identifiers and Cryptographic Key Management for CSPs, IdPs, and RPs

信頼契約はフェデレーションを行う許可を確立しますが、フェデレーションにおける当事者同士の安全な接続を実現するものではありません。フェデレーションプロトコル上で通信するために、CSP、IdP、RP は、識別子を暗号鍵および関連するセキュリティ成果物と結び付けられる形で、互いを安全に識別できる必要があります。このようにして、RP は、assertion が意図した IdP から来ていること、または attribute bundle が意図した CSP から来ていることを確実にできます。同様に、IdP は、意図した RP に assertion を送信していることを確実にできます。

RP が IdP または CSP の識別子と暗号鍵を確立するプロセスは discovery と呼ばれます。IdP が RP の識別子と暗号鍵を確立するプロセスは registration と呼ばれます。discovery と registration の両プロセスは、いずれのフェデレーショントランザクションより前にも、またトランザクションそのものの一部としてインラインにも発生し得ます。さらに、discovery と registration の両プロセスは、当事者間で直接行うことも、信頼契約で定義される第三者サービスの利用によって仲介することもできます。これらのプロセスでは、IdP、CSP、RP の間で鍵および識別子を手動で配布する方法と、暗号鍵素材およびメタデータを自動処理で取得できるソースにこれらの主体を関連付ける方法とを組み合わせて利用できます。フェデレーションプロトコルやプロセスによって、これらの識別子と暗号鍵を確立する手順は異なりますが、最終的には、各当事者がプロトコル内で必要に応じて他者を正しく識別できる状態になります。

discovery と registration のプロセスは、フェデレーショントランザクションを統治する信頼契約で定義されるとおり、安全な方法で確立しなければなりません（SHALL）。多くの場合、識別子は暗号鍵素材そのものではなく、信頼できる暗号鍵素材のソースに関連付けられます。例えば、IdP がホストする URL は、その IdP の公開署名鍵を提供する用途に使えます。RP がこの関連付けを手動で設定した場合でも、RP は実行時に実際の暗号鍵素材を取得できます。暗号鍵情報の移転を必要とするプロトコルは、共有シークレットや公開鍵を含め、フェデレーション関係を運用するために必要な暗号鍵情報を交換する際に、認証された保護チャネルを使用しなければなりません（SHALL）。この関係で使用される対称鍵は、フェデレーション参加者の組み合わせ（ペア）ごとに固有でなければなりません（SHALL）。

CSP、IdP（加入者が管理するウォレットを含む）、RP は、信頼契約または別の信頼契約内で異なる目的に供するため、複数の識別子および暗号鍵を持ってもよい（MAY）。例えば、IdP はすべての FAL1 および FAL2 のトランザクションに同一の assertion 署名鍵セットを用い、より高いセキュリティコンテナに格納された別管理の署名鍵セットを FAL3 のトランザクションに用いることができます。

当事者の識別にドメイン名、URI、または他の構造化識別子を用いる場合、ワイルドカードは使用してはなりません（SHALL NOT）。例えば、RP が “www.example.com”、 “service.example.com”、 “gateway.example.com” に配置されているなら、これらの識別子はそれぞれ RP のために登録される必要があります。ワイルドカードの “*.example.com” は使用できません。これは、同じ RP 識別子の下で “user.example.com” や “unknown.example.com” へのアクセスを意図せず許可してしまうためです。

3.6.1. Cryptographic Key Rotation

時間の経過とともに、CSP、IdP、または RP に関連付けられた暗号鍵を更新することが望ましい、または必要になる場合があります。識別子および暗号鍵の更新に許容されるプロセスは、信頼契約で定義されなければならず（SHALL）、また初回の暗号鍵確立と同様に、認証された保護チャネルを用いて実行されなければなりません（SHALL）。

例えば、IdP が URL によって識別される場合、IdP はその URL の配下の場所に、現在の公開鍵セットを公開できます。IdP は必要に応じて、その場所で公開する鍵を更新できます。RP は、必要に応じて既知の場所から公開鍵を取得し、更新された公開鍵が利用可能になった時点でそれを取得できます。

3.6.2. Cryptographic Key Storage

CSP、IdP（加入者が管理するウォレットを含む）、RP は、すべての署名鍵、復号鍵、および対称鍵を安全な方法で保管しなければなりません（SHALL）。暗号鍵の保管は、適用される tamper resistance 要件を含む、適用可能な [[FIPS140]] 要件の対象となります。

状況によっては、暗号鍵をエクスポート不可の方法で保管する必要があります。例えば、加入者のデバイス上の加入者が管理するウォレットで FAL3 に到達する場合です（[Sec. 5.4.1] 参照）。エクスポート不可と見なされるためには、鍵保管は、独立したハードウェア、または secure element、trusted execution environment（TEE）、trusted platform module（TPM）などの、埋め込みプロセッサまたは実行環境のいずれかでなければなりません（SHALL）。これらのハードウェアモジュールまたは埋め込みプロセッサは、ノート PC やモバイルデバイスの CPU のようなホストプロセッサとは分離されています。エクスポート不可の鍵保管は、秘密鍵がホストプロセッサへエクスポートされることを禁止するように設計されなければならず（SHALL）、また秘密鍵が抽出できるようにホストプロセッサによって再プログラム可能であってはなりません（SHALL NOT）。

3.6.3. Software Attestations

ソフトウェアおよびデバイスの attestation は、特に動的で分散したシステムにおいて、識別子と暗号鍵の確立を強化できます。この用法における attestation は、特定のソフトウェア、デバイス、または実行時システムが合意されたパラメータの集合を満たすことを示す、暗号的に束縛された表明です。attestation は、受信者が相互作用しているソフトウェア、デバイス、またはシステムのアイデンティティを確立する文脈で、ソフトウェアから提示されます。attestation により、受信者は、そうでなければ得られない程度の確度で要求を検証できます。

例えば、加入者が管理するウォレットソフトウェアの特定ディストリビューションは、配布者が署名することで、RP がそのソフトウェアの個々のインスタンスを認識できるようにできます。別の例として、RP は federation authority から attestation を発行され、IdP がその RP をフェデレーションの一部として認識できるようにすることもできます。

信頼契約で attestation が要求される場合、またはフェデレーションプロトコルの一部として要求される場合、受領した attestation は受信者によって検証されなければなりません（SHALL）。

動的クライアント登録において、OAuth および OpenID Connect の RP が、署名されたソフトウェア属性セットを通信する手段である software statements に関する詳細は、[[RFC7591]] Sec. 2.3 を参照してください。

3.7. Authentication and Attribute Disclosure

IdP と RP が信頼契約を締結し registration を完了すると、フェデレーションプロトコルを用いて加入者属性を IdP から RP へ渡せるようになります。

加入者のアイデンティティ属性は、フェデレーショントランザクションまたは、侵害された加入者アカウントの識別などの支援機能（[Sec. 3.10.1] 参照）のためにのみ、IdP と RP の間で送信されなければなりません（SHALL）。これは、当事者がフェデレーション目的で allowlist に含まれている場合でも同様です。

加入者のアイデンティティ属性は、加入者がその目的に明示的に同意しない限り、信頼契約で規定された目的以外に RP が使用してはなりません（SHALL NOT）。加入者の属性は、[Sec. 3.11.3] に従って保管および管理されなければなりません（SHALL）。

加入者は、属性が RP に送信されることについて通知されなければなりません（SHALL）。認可された当事者が組織である場合、組織は、承認された RP の一覧およびそれらの RP に送信される属性集合を、加入者が利用できるようにしなければなりません（SHALL）。認可された当事者が加入者である場合、加入者は、[Sec. 4.6.1.3] に記載される IdP における実行時の判断により、属性の開示前にプロンプトされなければなりません（SHALL）。

3.8. RP Subscriber Accounts

RP は通常、加入者をローカルに表現するために RP subscriber account と呼ばれる記録を保持します。RP subscriber account には、RP におけるアクセス権などに加え、加入者のアイデンティティ属性のキャッシュが含まれることがあります。RP subscriber account は、基礎となる可能性のある加入者アカウント（例：CSP や IdP が管理する加入者アカウント）とは別のライフサイクルを持ちます。

RP subscriber account は、加入者に関する属性集合が、RP における加入者アカウントを表すデータレコードに関連付けられたときに provisioned されます。provisioning は、配置パターンに応じて、認証前に行うことも、フェデレーション認証プロセスの結果として行うこともできます（[Sec. 4.6.3] 参照）。RP subscriber account は、provisioning の時点で、1 つ以上の federated identifier と関連付けられてもよく（MAY）、また [Sec. 3.8.2] で議論される account resolution によって、後から federated identifier にリンクされてもよい（MAY）。

RP subscriber account は、RP が信頼する IdP からの 1 つ以上の federated identifier にバインドされている場合、または account resolution プロセスが確立されている場合に、フェデレーション認証に利用できます。フェデレーションプロトコルによる加入者の認証が成功すると、加入者は RP subscriber account によって保護される RP の情報および機能にアクセスできます。

RP subscriber account は、RP が RP 上のアカウントへのすべてのアクセスを取り除いたときに terminated されます。termination には、[Sec. 3.11.3] に従って、アカウントに関連付けられたすべての federated identifier、バインドされた authenticator、属性、およびアイデンティティ情報の削除を含めなければなりません（SHALL）。RP は、元となる加入者アカウントの現時点での有効性にかかわらず、IdP とは独立に RP subscriber account を termination してもよい（MAY）。

RP subscriber account は、アカウントの情報を保持したまま、加入者がそのアカウントを用いて RP にアクセスできない状態になったときに disabled されます。例えば、すべての federated identifier と代替 authenticator が RP subscriber account から削除された場合です。RP は、記録保持を容易にしたり、当該アカウントに関連する不審な挙動を調査したりするために、termination ではなく disable を選択することがあります。

RP は、現在アクセス手段のない RP subscriber account の復旧手段を提供してもよい（MAY）。

RP subscriber account は、認証済みセッションなしに RP で provisioned され得ますが、認証済みセッションは provisioned されたアカウントに基づいてのみ作成できます。[Sec. 3.9] を参照してください。

RP は、RP subscriber account が「関連付けられた federated identifier が 0 件」であり、代替 authenticator（[Sec. 3.8.3] 参照）を含むアクセス手段がなく、さらに account linking（[Sec. 3.8.1] 参照）および account resolution（[Sec. 3.8.2] 参照）を含む復旧手段もない、という状態に到達した場合に、RP が実施する実務およびポリシーを文書化しなければなりません（SHALL）。このような場合、RP subscriber account は disabled または terminated されるべきです（SHOULD）。

RP は、次の場合に加入者へ通知を提供しなければなりません（SHALL）。

既存の RP subscriber account に新しい federated identifier が追加された場合、または
federated identifier が RP subscriber account から削除されたが、アカウントが terminated されない場合。

RP は、RP subscriber account が disabled または terminated されたときに、加入者へ通知を提供するべきです（SHOULD）。RP は、[Sec. 5.4 of [SP800-63A]] に記載のとおり、termination の理由を考慮して、加入者に通知を送るかどうかを決定しなければなりません（SHALL）。

アカウント管理イベントに関して加入者へ通知を提供する際の追加の考慮事項については、[Sec. 4.6 of [SP800-63B]] を参照してください。

3.8.1. Account Linking

単一の RP subscriber account は、複数の federated identifier に関連付けられてもよい（MAY）。この実務は account linking と呼ばれることがあります。RP が加入者に対して、このように複数の加入者アカウントをリンクすることを許可する場合、RP は、すべてのリンク機能について、加入者アカウントに対する認証済みセッションを要求しなければなりません（SHALL）。この認証済みセッションは、新しい federated identifier を RP subscriber account にリンクする前に、既存の federated identifier の 1 つを用いた認証を要求するべきです（SHOULD）。

federated identifier が RP subscriber account から削除されるとき、RP は、削除された federated identifier から RP subscriber account へのアクセスを禁止しなければなりません（SHALL）。

RP は、どのフェデレーションアカウントが RP にアクセスするために用いられるかに応じて、同一アカウントに異なるアクセス権を関連付けてもよい（MAY）。RP が認可およびアクセスをどのように決定するかは、本ガイドラインの対象範囲外です。

3.8.2. Account Resolution

RP が加入者集合に関する既存情報へアクセスでき、その情報が federated identifier と関連付けられていない場合、RP は account resolution と呼ばれるプロセスを実施し、新しい RP subscriber account にどの加入者情報セットを関連付けるかを決定します。

account resolution を行う RP は、federated identifier を RP subscriber account にリンクしてアクセスを許可する前に、IdP に要求する属性が RP のシステム内で加入者を一意に解決するのに十分であることを確実にしなければなりません（SHALL）。RP による各属性の意図された用途は、当該の信頼契約に詳細化され、当該の属性がこのような account resolution に使用されるかどうかも含まれます。

account resolution を行う RP は、加入者に属さない federated identifier に RP subscriber account の情報を関連付けないようにプロセスを設計しなければなりません（SHALL）。

例えば、加入者が管理するウォレットは RP に federated identifier を提供しないかもしれませんが、CSP からの attribute bundle を RP に提供し、RP が加入者を RP subscriber account に一意に解決できるようにすることで、RP が account resolution を行えるようにできます。別の例として、事前 provisioning モデルを用いる RP は、合意された属性集合に基づき、受信した assertion を RP subscriber account に一意に関連付けることができます。

同様の account resolution プロセスは、RP が holder-of-key assertion において使用される authenticator を初めて検証する場合にも用いられます。この場合、RP は、authenticator によって運ばれる属性が、authenticator を受け入れる前に RP subscriber account に一意に解決されることを確実にしなければなりません（SHALL）。

3.8.3. Alternative Authentication Processes

RP は、加入者が RP subscriber account に authenticator を追加・削除できるようにすることで、直接認証プロセスを用いて加入者が RP subscriber account にアクセスすることを許可してもよい（MAY）。RP は、すべての代替 authenticator を管理するために [[SP800-63B]] の要件に従わなければなりません（SHALL）。

RP は [[SP800-63]] で議論される直接認証モデルを使用するため、フェデレーショントランザクションは存在せず、したがって FAL は割り当てられません。

RP がこの種のアクセスを許可する場合、RP は、IdP が RP と共有される情報に関する判断を行えるようにするため、信頼契約において次の事項を開示するべきです（SHOULD）。

RP subscriber account における代替 authenticator の追加・削除のプロセス
加入者が RP にアクセスするために使用できる authenticator に関する制限
フェデレーショントランザクションなしで加入者アカウントへアクセスするために必要な AAL
前回のフェデレーショントランザクションからの経過時間など、加入者に IdP での認証を要求する状況

authenticator 管理イベントに関して加入者へ通知を提供する際の追加の考慮事項については、[Sec. 4.6 of [SP800-63B]] を参照してください。

バインドされた authenticator（[Sec. 3.16] 参照）を、RP への直接アクセスのための代替 authenticator として使用することは可能ですが、これらの用途は互いに異なるため、RP は特定の authenticator が一方または両方のシナリオで使用できるかどうかを判断しなければなりません（SHALL）。

3.9. Authenticated Sessions at the RP

フェデレーショントランザクションの最終目標は、IdP によって検証された assertion に裏付けられた、加入者と RP の間の認証済みセッションを作成することです。この認証済みセッションは、加入者が RP の機能（すなわちログイン）へアクセスすること、加入者を RP に識別させること、またはフェデレーショントランザクションで運ばれる加入者属性を処理することに使用できます。認証済みセッションは、次の条件が真である場合にのみ、RP によって作成されなければなりません（SHALL）。

RP が有効な assertion を処理し、検証した。
assertion が当該トランザクションにおいて期待される IdP からのものである。
assertion を発行した IdP が、assertion の federated identifier によって識別される IdP である。
assertion が RP subscriber account（エフェメラルである場合を含む）に関連付けられている。
RP subscriber account が、信頼契約で指定された方法により RP で provisioned されている。

フェデレーションが識別プロセスの一部として使用される場合、他のプロセスが完了するまで RP subscriber account が確立されないことがあります。

assertion が FAL3 における holder-of-key assertion である場合、assertion に示される authenticator は、RP subscriber account が認証済みセッションに関連付けられる前に検証されなければなりません（SHALL）。これは [Sec. 3.15] で議論されます。assertion がさらに FAL3 におけるバインドされた authenticator による認証を要求する場合、バインドされた authenticator は、RP subscriber account が認証済みセッションに関連付けられる前に検証されなければなりません（SHALL）。これは [Sec. 3.16] で議論されます。

認証済みセッションは、RP によっていつでも終了されてもよい（MAY）。

IdP と RP の双方に対するセッション管理要件の詳細は [[SP800-63B] Sec. 5] を参照してください。汎用 IdP に関する追加のセッション要件については [Sec. 4.7] を参照してください。

3.10. Privacy Requirements

加入者の目的は、RP と相互作用し、RP を利用することです。フェデレーションでは、RP への直接認証の間には関与しない当事者である IdP から、個人属性が移転されます。フェデレーションはまた、加入者の活動や状態について、IdP に広い可視性を与える可能性があります。したがって、フェデレーションには、直接認証には存在しない特有のプライバシー要件があります。

RP が IdP にフェデレーショントランザクションを要求すると、その要求および続くフェデレーショントランザクションの処理は、加入者がどこへログインしているかを IdP に明らかにします。時間の経過とともに、IdP は、特定の加入者がどの RP を利用しているかという知識に基づき、加入者トランザクションのプロファイルを構築し得ます。この集約は、加入者追跡や、加入者のプライバシー上の利益と整合しない方法での加入者アイデンティティ情報の利用といった、新たな機会を生み得ます。

同一の加入者アカウントが複数の RP に対して表明され、それらの RP が相互に通信する場合、共謀する RP は、複数のアプリケーションおよびセキュリティドメインをまたいで加入者の活動を追跡し得ます。IdP は、RP 間での加入者活動の追跡およびプロファイリングに対して、切り離し可能性（disassociability）を提供し、抑止するための技術的措置（例：[Sec. 3.4.1] で説明される pairwise pseudonymous identifiers の使用、プライバシー強化暗号プロトコル）を用いるべきです（SHOULD）。そのような措置を決定する際、IdP は、NIST Privacy Framework [[NIST-Privacy]] などの関連ガイドラインおよび標準を適用するべきです（SHOULD）。

以下の要件は、IdP、RP、またはその両方として行動する連邦機関に特に適用されます。

機関は、プライバシー担当上級機関職員（SAOP）と協議し、Privacy Act の要件が、IdP として行動する機関によって発動されるのか、RP として行動する機関によって発動されるのか、あるいはその両方によって発動されるのかを判断する分析を実施しなければなりません（SHALL）（[Sec. 7.4] 参照）。
機関は、適用される場合に応じて、System of Records Notice（SORN）による対象範囲を公開または特定しなければなりません（SHALL）。
機関は、SAOP と協議し、E-Government Act の要件が、IdP として行動する機関によって発動されるのか、RP として行動する機関によって発動されるのか、あるいはその両方によって発動されるのかを判断する分析を実施しなければなりません（SHALL）。
機関は、適用される場合に応じて、Privacy Impact Assessment（PIA）による対象範囲を公開または特定しなければなりません（SHALL）。
機関は、IdP と RP の間で共有される加入者アイデンティティ情報に関するプライバシーリスク評価を実施しなければなりません（SHALL）。

RP subscriber account のライフサイクルプロセスが、provisioning API（[Sec. 4.6.3] 参照）を通じて RP に属性へのアクセスを与える場合、RP subscriber account のライフサイクルの違い（例：非アクティブ加入者アカウントの分離、disabled および terminated アカウントの能動的な削除）を考慮するため、追加のプライバシー措置が実装されなければなりません（SHALL）。IdP は、provisioning API を通じて RP に提供される属性を最小化しなければなりません（SHALL）。IdP は、provisioning API を通じて利用可能な加入者アカウントの母集団を、信頼契約によって RP を使用することが認可された加入者の母集団に限定しなければなりません（SHALL）。IdP において terminated されたアカウントのアイデンティティ属性が RP に保持されることを防ぐため、IdP は、RP のデータ保持要件、ポリシー、または規制によって制限されない限り、provisioning API を用いて、terminated された加入者アカウントに対応する RP subscriber account を de-provision しなければなりません（SHALL）。この措置は、データ最小化の原則を強化します（例：[Sec. 9.5] の例を参照）。RP subscriber account が複数の federated identifier にリンクされている場合（[Sec. 3.8.1] 参照）、de-provisioning プロセスの結果として、RP subscriber account が RP 上に残存しつつ、別の federated identifier にリンクされる可能性があります。

IdP と RP は、システムの機能を達成するために必要な最小限のデータのみを交換しなければなりません（SHALL）。

加入者によるアイデンティティ属性の開示に対する制御を高めるため、信頼契約は、[Sec. 4.6.1.3] で議論されるとおり、実行時の判断を用いて属性のリリースを制御するべきです（SHOULD）。

フェデレーショントランザクションがエフェメラルな provisioning 機構（[Sec. 4.6.3] 参照）を用いる場合、IdP は、RP がセッション間で情報を保管したり相関させたりすることを防ぐために、RP への各認可要求ごとにエフェメラルな federated identifier を用いるべきです（SHOULD）。

3.10.1. Transmitting Subscriber Information

IdP は、システムが機能するために必要であり、かつ信頼契約によって規定および開示されている範囲に限って、加入者情報の送信を制限しなければなりません（SHALL）。これらの機能には次が含まれます。

identity proofing、認証、または属性 assertion（総称して「identity service」）
加入者からの特定の情報送信要求
identity service に関連する不正対策
identity service に関連するセキュリティインシデントへの対応

IdP が、これらの場合以外の目的で加入者の活動に関する情報を RP からのものとして開示したり、加入者の属性を処理したりする場合、IdP は、その追加処理から生じるプライバシーリスクに見合う、予測可能性および管理可能性を維持するための措置を実装しなければなりません（SHALL）。措置には、明確な通知の提供、加入者同意の取得、属性の選択的利用または開示の有効化などが含まれてもよい（MAY）。IdP が、アイデンティティトランザクション外での情報利用に関する加入者の同意を得る場合、IdP は、その追加処理への同意を identity service の条件としてはなりません（SHALL NOT）。例えば、IdP は、加入者が RP にログインできるようにするために、ニュースレター受信への同意を加入者に要求できません。

RP は、信頼契約で規定および開示されている場合に限り、かつ次の場合に限って、加入者の活動の送信を関連する IdP に制限しなければなりません（SHALL）。

identity service に関連する不正対策
identity service に関連するセキュリティインシデントへの対応

RP が、信頼契約で規定された目的以外で加入者のアイデンティティ情報を使用する場合、RP は加入者に通知し、そのような追加利用について加入者の同意を得なければなりません（SHALL）。

加入者情報は、信頼契約の条項にかかわらず、法律または法的手続に従うために送信されることもあり得ます。

プライバシー工学およびリスク管理に関する追加情報については、[[NISTIR8062]] を参照してください。

より大規模なフェデレーションシステム、特に federation authority によって管理される多者間フェデレーションでは、同一の信頼契約に複数の CSP が関与する場合があります。このような場合、例えば不正対策（例：攻撃者が検知を回避するために異なる CSP 間を別アカウントで渡り歩くことを防ぐ）といった活動のために、CSP 同士が情報を共有することが望ましい場合があります。このような情報共有は不正対策に役立ち得る一方、CSP が、加入者が利用するすべての CSP に対して元々開示されていなかった加入者属性や行動を互いに知り得るため、重大なプライバシー懸念もあります。

同様の情報共有は、CSP から独立して運用され得る IdP（例：リモートシステム上でホストされる加入者が管理するウォレット）間でも望ましい場合があり、同様のプライバシー上の考慮事項があります。

CSP および／または IdP 間のすべての情報送信は、[Sec. 3.10.1] に列挙された IdP に対する制限の対象とならなければなりません（SHALL）。そのような CSP および／または IdP 間の情報共有は、プライバシーリスク評価に含めなければなりません（SHALL）。

CSP を接続する信頼契約の条項は、CSP 間で共有される情報の移転に適用されるポリシーを定義しなければなりません（SHALL）。federation authority によって管理される信頼契約では、federation authority がこれらの条項を定義します。

3.11. Security Controls

IdP および CSP は、少なくとも [[SP800-53]] で定義される moderate ベースラインのセキュリティコントロール、またはそれと同等の連邦（例：[[FEDRAMP]]）もしくは業界標準（本ガイドラインが保護対象とする情報システム、アプリケーション、オンラインサービスについて組織が決定したもの）から、適切に調整されたセキュリティコントロールを適用しなければなりません（SHALL）。RP は、少なくとも [[SP800-53]] で定義される low ベースラインのセキュリティコントロール、または同等の連邦（例：[[FEDRAMP]]）もしくは業界標準（組織が決定したもの）から、適切に調整されたセキュリティコントロールを適用しなければなりません（SHALL）。個人情報を要求または処理する RP は、少なくとも [[SP800-53]] で定義される moderate ベースラインのセキュリティコントロール、または同等の連邦（例：[[FEDRAMP]]）もしくは業界標準から、適切に調整されたセキュリティコントロールを適用しなければなりません（SHALL）。CSP、IdP、RP は、適切なシステムに対する最低限の保証関連コントロール（または同等のもの）が満たされるか、それを上回ることを確実にしなければなりません（SHALL）。

3.11.1. Protection From Assertion Injection Attacks

フェデレーションプロトコルの文脈における assertion injection attack とは、攻撃者が RP に assertion または assertion reference を受理または処理させることで、RP へのアクセスを得たり、正当な加入者の RP へのアクセスを妨害したりしようとする攻撃です。攻撃者は、assertion または assertion reference を取得し、それを脆弱な RP に注入します。攻撃が成功すると、RP は攻撃者のセッションを assertion 内の federated identifier にバインドしてしまい得ます。攻撃者の assertion は、正当な加入者から盗まれたものか、攻撃を遂行するために捏造されたものであり得ます。

assertion injection attack に対する防御は、すべての FAL で推奨され、FAL2 以上では必須です。いずれの場合も、RP は、RP ソフトウェアの性質、使用中のフェデレーションプロトコルの能力、システム全体のニーズに基づき、注入された assertion または assertion reference を攻撃者が提示することを防ぐための合理的な手順を取る必要があります。[ [OIDC] ] と [ [SAML] ] はどちらも、要求中に RP から送信される nonce、バックチャネル通信のための RP 認証、RP がフェデレーショントランザクションを開始し、その状態をプロセス全体で追跡するための方法など、assertion injection 防御のメカニズムを提供します。メカニズムごとに防御の程度は異なり、適用可能な状況も異なります。特定の防御の詳細は、使用されるフェデレーションプロトコルおよび技術により異なりますが、以下のような共通のベストプラクティスにより攻撃対象領域を制限できます。

バックチャネルでの assertion 提示。これにより、RP が IdP からの直接応答以外の assertion を受理することを防ぐ（[Sec. 4.11.1] 参照）。
推測困難な値を用いて、RP における未認証セッションをバックチャネルへの要求と結び付ける。これにより、攻撃者が assertion reference をあるセッションから別のセッションへ注入することを防ぐ。
assertion 要求中に RP が IdP に対して認証することを要求する。これにより、攻撃者が RP からの要求を偽装してフェデレーションプロセスを開始することを防ぐ。
IdP 開始のフェデレーションプロセスを禁止する。これにより、RP が IdP からの未承諾の assertion および assertion reference を受理することを防ぐ。ただし、この禁止は、外部当事者（例：IdP または federation authority）が RP に対して IdP とのフェデレーションプロセス開始を合図し、RP がフェデレーショントランザクションを開始して、そのトランザクション内で安全に応答を待つプロセスを含まない。
IdP からの署名付きフロントチャネル応答を用い、署名の対象に RP 提供の nonce を含める。これにより、攻撃者が assertion reference をあるセッションから別のセッションへ注入することを防ぐ。
HTTP リダイレクトではなく、フロントチャネル通信にプラットフォーム API を使用する。

assertion injection attack は、フィッシング攻撃と組み合わされると特に危険です。攻撃者は、加入者をだまして攻撃者が注入できる有効な assertion を生成させることも、加入者をだまして加入者自身の RP セッションへ攻撃者の assertion を注入させることもできるためです。

3.11.2. Protecting Subscriber Information

IdP と RP の間の通信は、認証された保護チャネルを用いて転送中に保護されなければなりません（SHALL）。加入者と IdP または RP（通常は user agent を介する）の間の通信も、認証された保護チャネルを用いて行われなければなりません（SHALL）。

IdP は、RP がセキュリティポリシーを強制するうえで有用となり得る情報（例：デバイスアイデンティティ、位置情報、システム健全性チェック、構成管理）へアクセスできる場合があります。IdP は、[Sec. 7.2] で説明される加入者への通知および同意の範囲内で、信頼契約の範囲内において、この情報を RP に開示してもよい（MAY）。

アイデンティティ属性は、assertion そのものの外側に含めてもよく（MAY）、その場合、[Sec. 3.12.3] で議論されるとおり、identity API へのアクセスを認可することで提供できます。このようにアイデンティティ情報を分割すると、加入者のプライバシーを保護するのに役立ち、認証 assertion の本質的情報に加えて、個人情報の限定的な開示を可能にします。identity API の利用は、信頼契約の条項に列挙されなければなりません（SHALL）。

派生属性値が利用可能であり RP のニーズを満たす場合、RP は、完全な属性値ではなく派生属性値を要求するべきです（SHOULD）。これは [Sec. 7.3] で説明されます。IdP は、基礎となるフェデレーションプロトコルが許す範囲で、派生属性値をサポートするべきです（SHOULD）。

3.11.3. Storing Subscriber Information

アカウントがアクティブかどうかにかかわらず、IdP と RP は、[[SP800-53]] または同等の連邦（例：[[FEDRAMP]]）もしくは業界標準で定義される調整済みセキュリティコントロールを用いて、加入者アカウントまたは RP subscriber account 内の個人情報を保管しなければなりません（SHALL）。

RP subscriber account が加入者によってアクセスできなくなった場合（例：アカウントに関連付けられた federated identifier がなく、代替認証手段もない場合）、RP は RP subscriber account を termination するべきです（SHOULD）。特に、RP が account linking（[Sec. 3.8.1] 参照）または代替 authenticator（[Sec. 3.8.3] 参照）をサポートする場合、RP は、RP subscriber account を termination せずに、代わりにアカウントを disable して必要な情報を保持することを選択してもよい（MAY）。

IdP と RP は、規制、法律、ポリシーによって別途制限される場合、またはアプリケーションのリスクが加入者情報の保持を本質的に必要と見なす場合を除き、アカウント termination 時に加入者アカウントおよび RP subscriber account 内の個人情報の削除をサポートするべきです（SHOULD）。削除をサポートしない IdP および RP は、法的根拠またはリスクに基づく正当化を提供し、それを信頼契約に文書化しなければなりません（SHALL）。例えば、RP は、アカウントが terminated された後も保持されるアクセスログや監査ログに federated identifier を記録することがあります。しかし、RP が自らの機能のためにそれらを必要としなくなるため、すべてのアイデンティティ属性および個人情報は RP 自身の保管領域から削除されます。

RP subscriber account が terminated されたとき、RP は、規制、法律、ポリシーによって別途制限される場合、またはアプリケーションのリスクが保持を本質的に必要と見なす場合を除き、保管領域からすべての加入者属性を削除しなければなりません（SHALL）。

3.12. Identity Attributes

加入者を表す identity attributes は、フェデレーショントランザクション中に RP に送信されます。これらの属性は、異なる方法で組み合わせられる複数の側面を持ちます。

Bundling:

属性は、IdP によって assertion 内で直接提示される unbundled（すなわち束ねられていない）形態、または [Sec. 3.12.1] で説明されるとおり CSP によって暗号的に署名されたパッケージに bundled された形態のいずれかでなければなりません（SHALL）。

Derivation:

属性は、attribute values（例：生年月日）または derived attribute values（例：成年年齢に達していることの示唆）のいずれかでなければなりません（SHALL）。

Presentation:

属性は、assertion 内で提示され assertion の署名により保護されるか、または保護された identity API の一部として利用可能にされるかのいずれかでなければなりません（SHALL）。

信頼契約は、属性検証に使用されるプロセスおよびソースを記述する CSP の practice statements を指し示さなければなりません（SHALL）。

3.12.1. Attribute Bundles

他のプロトコルや仕様では、attribute bundle を credentials と呼ぶことがよくあります。しかし、この用語は本ガイドライン内で別の概念に用いられるため衝突します。その結果として、本ガイドラインでは “attribute bundle” という用語を使用します。

assertion または identity API で IdP から属性を直接送信する代わりに、attribute values および derived attribute values を、CSP によって署名された bundle として収集できます。これらの attribute bundle は、IdP による保護とは独立に、attribute bundle の暗号的保護を用いて RP によって検証できます。attribute bundle は、加入者が管理するウォレットで一般的に使用されます。属性を束ねるために使用される技術の例には、Selective Disclosure JSON Web Tokens [[SD-JWT]]、[[VC]] で定義される Verifiable Credentials Data Model、[[ISOIEC18013-5]] で定義される mDoc Mobile Security Object があります。

attribute bundle の提示は、束ねられていない属性と同様に IdP によって保護されなければなりません（SHALL）。すなわち、assertion 内で提示される attribute bundle は assertion 全体の署名で保護され、identity API によって利用可能にされる attribute bundle は、その API に対する限定的なアクセス制御によって保護されます。

attribute bundle は、1 つ以上の attribute values および derived attribute values とともに、発行元 CSP を識別する識別子を含みます。これらの attribute value の 1 つは、発行元 CSP が加入者間での一意性を確保する場合に、加入者識別子として機能し得ます。attribute bundle は IdP からの assertion に含まれて運ばれるため、bundle 内の加入者属性は、すべてのトランザクションで完全にすべての RP に開示される必要はなく、代わりに RP に対して選択的に開示できます。選択的開示技術を用いる attribute bundle は、IdP に新しい bundle を発行する必要なく、RP が attribute bundle から読み取れる属性を制限することで、システムのプライバシーを高められます。RP は、attribute bundle の内容すべてを IdP が RP に開示しなくとも、bundle 全体の署名を検証し、bundle のソースが CSP であることを確認できます。

RP は、attribute bundle に固有の署名に加え、assertion 全体の署名などのコンテナ署名も検証しなければなりません（SHALL）。

attribute bundle は、オプションとして、bundle が発行された IdP の検証鍵を含めてもよい（MAY）。その場合、RP は、署名された attribute bundle 内の IdP の検証鍵を用いて assertion に対する署名を検証することで、attribute bundle で主張されるアイデンティティによって assertion が提示されていることを確認しなければなりません（SHALL）。

3.12.2. Derived Attribute Values

いくつかのユースケースでは、RP が機能するために identity attribute の実際の値を知ることは厳密には必要ではなく、その identity attribute から導出された値で十分です。例えば、RP が加入者が成年年齢以上であるかどうかを知る必要がある場合、RP は加入者の生年月日を要求し、その値から成年年齢に関する判定を計算できます。しかし、そうすると、RP の機能要件に真に必要な範囲を超えて、より具体的な情報が RP に明らかになります。代わりに、IdP は、RP の要求時点で加入者の年齢が成年の定義を満たすかどうかを計算し、生年月日そのものではなく、この導出について単純な真偽値（boolean）を返せます。その結果、RP は基礎となる値を見る必要なく処理を継続できます。

derived attribute values は、RP に対してより焦点を絞った情報開示を可能にするため、システムのプライバシーを高めます。フェデレーションシステムの中には、RP が要求時に任意の derived attribute value を動的に問い合わせできるものもありますが、多くの一般的ユースケースは、IdP が共通の derived attribute values を事前計算し、完全な attribute value の代替として提供することで対応できます。プライバシーを保護するため、derived attribute values は、要求者に対して基礎となる attribute value を開示してはなりません（SHALL NOT）。一部の attribute bundle に見られる選択的開示技術は、完全な attribute values と derived attribute values の両方を同一応答に含め、アプリケーションに必要なものだけを開示するために利用できます。

derived attribute values は、assertion に直接含まれる（[Sec. 4.9] および [Sec. 5.8] 参照）か、または attribute bundle に含まれます（[Sec. 3.12.1] 参照）。

3.12.3. Identity APIs

プロファイル情報を含む加入者の属性は、identity API と呼ばれる保護された API を通じて RP に提供されてもよい（MAY）。RP は、assertion と連動して、フェデレーショントランザクション中に identity API への限定的アクセスを付与されます。例えば OpenID Connect では、UserInfo Endpoint が、加入者の属性を取得するための標準化された identity API を提供します。この API は OAuth 2.0 Access Token によって保護されます。この Access Token は、OpenID Connect の assertion である ID Token とともに RP に発行されます。identity API は、アイデンティティ情報が認可された RP にのみ提供されることを確実にするため、送信者拘束（sender-constrained）されたアクセスを要求するべきです（SHOULD）。

identity API で属性を利用可能にすることで、IdP は、RP に伝えるために assertion で運ぶ情報量を減らせます。これは、機微な属性を assertion 自体に含めなくて済むことを意味し、また assertion が小さくなり RP による処理も容易になります。その結果、assertion の内容は、必須フィールド（例：一意の subject 識別子）、IdP における認証イベントに関する情報、フェデレーショントランザクションに関する情報に限定できます。

identity API は、RP が IdP から RP への加入者属性送信の管理を補助することも可能にします。RP は、IdP から提供された属性を RP subscriber account にキャッシュすることがよくあり（[Sec. 3.8] 参照）、それらの属性を最後に IdP から受領した時刻を記録できます。RP は、assertion の中で毎回属性を受け取る代わりに、RP subscriber account を更新する必要があるときにのみ加入者属性を要求できます。IdP は、RP に利用可能な加入者属性のいずれかが IdP 側で更新された時刻を assertion 内で示すことで、この判断を助けられます。このアプローチは、加入者属性が時間に対して安定している場合に特に有用で、RP が毎回の要求でそれらを取得しなくても機能できるようになります。

identity API のすべての利用可能性（API を通じて利用可能な provisioning モデルを含む）は、信頼契約の一部として記録され、開示されなければなりません（SHALL）。identity API へのアクセスは、信頼契約によって時間制限されなければなりません（SHALL）。identity API へのアクセスは、[Sec. 4.6.4] で議論されるとおり、フェデレーショントランザクションの継続時間に加え、属性同期に必要な時間に限定されるべきです（SHOULD）。この時間制限は、assertion の有効時間窓および RP における認証済みセッションの寿命とは別であるため、有効な assertion に関連付けられていない状態で RP が identity API にアクセスできたとしても、それだけでは RP における認証済みセッション確立に十分であってはなりません（SHALL NOT）。

特定の identity API の配置は、IdP が assertion を作成できるすべての加入者について属性を提供できることが期待されます。ただし、フェデレーショントランザクションの文脈で identity API へのアクセスが付与される場合、identity API が提供する属性は、関連する assertion によって識別される単一の加入者にのみ関連付けられなければなりません（SHALL）。identity API が IdP によってホストされる場合、返される属性には加入者の subject 識別子を含めなければなりません（SHALL）。これにより、RP は assertion の subject と返された属性を確実に相関させられます。pre-provisioning による RP subscriber account（[Sec. 4.6.3] 参照）の一部として identity API へのアクセスが提供される場合、RP は通常、フェデレーショントランザクションの文脈外で identity API への包括的アクセスを付与され、これらの要件は適用されません。pre-provisioning のユースケースでは、プライバシー上の考慮事項が評価され、信頼契約の一部として記録されなければなりません（SHALL）。identity API が IdP から外部にホストされる場合は、[Sec. 3.12.3.1] の要件が適用されます。

External Identity APIs

フェデレーションプロトコルで用いられる identity API の多くは IdP の一部としてホストされますが、IdP が、IdP の外部でホストされる external identity API へのアクセスを RP に付与することも可能です。external identity API は通常、CSP 以外の attribute provider によって提供され、加入者アカウントから利用可能なものに加えて加入者の属性を提供します。IdP が external identity API へのアクセスを付与する場合、external identity API から返される情報は、IdP がホストする identity API と同様に加入者に関連付けられます。信頼契約の目的において、IdP は external identity API の内容を加入者アカウントに関連付ける責任を負います。たとえ IdP が external identity API から返されるデータを制御できない場合でも同様です。

external identity API が返す属性は、IdP が直接返すものとは独立であると想定されるため、external Identity API の内容は、IdP が用いる識別子、形式、スキーマとは異なるものを用いてもよい（MAY）。特に、external identity API は、IdP がホストする identity API と同じ federated identifier を使用することは期待されません。例えば、IdP は加入者の医療免許情報へのアクセスを提供できるかもしれません。IdP が免許状態を直接表明する代わりに、IdP は、加入者を表す医療免許機関の記録へのアクセスを RP に提供します。フェデレーションプロトコルは、加入者を表す記録を持つ API へのリンクと、その API への限定的アクセスを可能にする credential を IdP が提供することで、これを可能にできます。RP は、その免許記録が異なる識別子を用いており、そうでなければ RP が相関できない可能性が高いとしても、加入者と医療免許記録との強い関連付けを行えます。IdP は、このリンクを RP に提供する責任を引き続き負います。

external identity API を用いて属性を提供するあらゆる利用は、属性ソースの一覧の一部として、信頼契約によって列挙されなければなりません（SHALL）。

3.13. Assertion Protection

assertion は、攻撃者が有効な assertion を捏造したり、捕捉した assertion を別の RP で再利用したりすることを防ぐための保護を含まなければなりません（SHALL）。必要な保護は検討中のユースケースの詳細に依存し、特定の保護は以下の小節に列挙されます。

3.13.1. Assertion Identifier

assertion は、対象 RP による一意の識別を可能にするため、十分に一意でなければなりません（SHALL）。assertion は、埋め込み nonce、発行タイムスタンプ、assertion 識別子、またはこれらの組み合わせ、あるいは他の技術によって、これを実現してもよい（MAY）。

3.13.2. Signed Assertion

assertion は、発行者（IdP）によって暗号的に署名されなければなりません（SHALL）。RP は、発行者の検証鍵に基づき、そのような各 assertion のデジタル署名または MAC を検証しなければなりません（SHALL）。この署名は、識別子、発行者、audience、subject、および有効時間窓を含む assertion 全体を対象としなければなりません（SHALL）。

assertion 署名は、非対称鍵を用いるデジタル署名、または承認された暗号を用いて、RP と発行者の間で共有される対称鍵を用いる MAC のいずれかでなければなりません（SHALL）。

3.13.3. Encrypted Assertion

assertion の内容は、user agent などの信頼できない第三者に機微な情報が露出することを防ぐために暗号化できます。この保護は、assertion が加入者に関する個人情報を含む場合に特に重要です。

信頼契約は、他の状況において assertion 内容の暗号化を要求してもよい（MAY）。

多くの assertion 形式は assertion 全体の暗号化をサポートしますが、いくつかの assertion 形式は、assertion のうち個人情報部分のみを暗号化でき、assertion 全体を暗号化せずに、RP に対する機微情報の選択的開示を提供します。assertion の一部が暗号化される場合、必要な復号鍵を保持する RP のみが、assertion 内の暗号化情報へアクセスできます。

assertion を暗号化する場合、IdP は、承認された暗号を用いて RP の暗号化鍵で assertion 内容を暗号化しなければなりません（SHALL）。例えば、SAML assertion は XML-Encryption を用いて暗号化でき、OpenID Connect ID Token は JSON Web Encryption（JWE）を用いて暗号化できます。

バックチャネル提示と併用する場合、IdP と RP の間に TLS チャネルを中断する中継者が存在しないとき、assertion は相互認証された TLS 接続により転送中も暗号化できます。

subject 識別子の意味は、SSN、メールアドレス、運転免許番号などの他の識別子と異なり、対象システムに依存します。したがって、subject 識別子だけでは、個人情報保護に基づく暗号化要件を発動しません。

3.13.4. Audience Restriction

assertion は、RP が発行された assertion の意図された対象であるかどうかを認識できるように、audience restriction 技法を用いなければなりません（SHALL）。すべての RP は、assertion injection および、ある RP 向けに生成された assertion が別の RP でリプレイされることを防ぐため、assertion の audience に自らの RP の識別子が含まれていることを確認しなければなりません（SHALL）。

攻撃者が assertion を成功裏にリプレイできる場所を制限するため、IdP は、単一の audience のみに指定された assertion を発行するべきです（SHOULD）。単一 audience への制限は FAL2 以上で必須です。

3.14. Bearer Assertions

bearer assertion は、それ単体で、提示者のアイデンティティの証明として提示できます。同様に、bearer assertion reference も、それ単体で RP に提示され、RP が assertion を取得するために使用できます。攻撃者が、加入者を表す有効な assertion または assertion reference を捕捉または捏造し、それを RP に成功裏に提示できる場合、攻撃者はその RP において加入者になりすますことができます。

bearer assertion または reference の単なる所持だけでは、常に加入者へのなりすましに十分とは限りません。例えば、assertion がバックチャネルフェデレーションモデル（[Sec. 4.11.1] 参照）で提示される場合、トランザクションには、追加のコントロール（例：RP の識別、assertion injection 防御）が置かれ、RP を不正活動からさらに保護できます。

3.15. Holder-of-Key Assertions

holder-of-key assertion（[Fig. 3]）は、加入者が制御する証明書の公開鍵など、RP が独立に検証できる authenticator の一意識別子を含まなければなりません（SHALL）。RP は、加入者が assertion によって識別される authenticator を所持していることを検証しなければなりません（SHALL）。holder-of-key assertion は、authenticator 技術が、IdP と RP の双方が信頼する公開鍵基盤（PKI）に結び付いている場合に、最もよく用いられます。

Fig. 3. Holder-of-key assertions

holder-of-key assertion の利用を示す図。

holder-of-key assertion で識別される authenticator は、加入者が IdP へ認証するために用いる主要 authenticator とは別であってもよい（MAY）。holder-of-key assertion で識別される authenticator は、[[SP800-63B]] の [Sec. 3.2.5] に定義されるとおり phishing-resistant でなければなりません（SHALL）。RP が holder-of-key assertion 内の authenticator に初めて遭遇したとき、RP は、その authenticator が [Sec. 3.8.2] で議論されるとおり、RP subscriber account に一意に解決できることを確実にしなければなりません（SHALL）。

holder-of-key assertion は、暗号化されていない秘密鍵または authenticator として使用される対称鍵を含んではなりません（SHALL NOT）。

加入者が管理するウォレットからの assertion（加入者のデバイス上で実行されるもの）は、holder-of-key assertion と見なすことができます。

[Section 9.6] は、assertion に一覧化されたスマートカード上の証明書の所持証明を提供するために、相互 TLS 接続を使用する、より完全な例を示します。

holder-of-key assertion で使用される authenticator は複数の当事者に提示され得て、これらの authenticator はしばしば identity attributes を含むため、[Sec. 7] で議論される追加のプライバシー考慮事項があります。

3.16. Bound Authenticators

bound authenticator（[Fig. 4]）は、RP subscriber account にバインドされ、RP によって管理される authenticator です。IdP は、assertion が FAL3 において bound authenticator とともに使用されることを示す指標を assertion に含めなければなりません（SHALL）。authenticator の一意識別子（公開鍵など）は、RP subscriber account に保管されなければなりません（SHALL）。RP は、[[SP800-63B]] の [Sec. 3.2.4] で議論される署名付き attestation の含有などにより、bound authenticator の特性を評価するための信頼できる根拠を持つ必要があります。bound authenticator は、authenticator 技術が IdP と RP の双方が信頼する PKI に結び付いていない場合、例えばそのような PKI が存在しない場合に、最もよく用いられます。

Fig. 4. Bound authenticators

RP で管理される bound authenticator の利用を示す図。

bound authenticator は、RP における加入者ごとに一意でなければならず（SHALL）、2 人の加入者が、それぞれの RP subscriber account のために同一の bound authenticator を提示できないようにしなければなりません。すべての bound authenticator は、[[SP800-63B]] の [Sec. 3.2.5] に定義される phishing-resistant 認証メカニズムを使用しなければなりません（SHALL）。したがって、パスワードのような加入者が選んだ値は bound authenticator として使用できません。bound authenticator は、フェデレーショントランザクションに対する FAL3 assertion を処理する文脈で、認証のために受け入れられなければなりません（SHALL）。同一の authenticator を RP への直接認証（[Sec. 3.8.3] 参照）に用いることも可能ですが、そのような利用は bound authenticator とは見なされず、RP はそれらを別個のユースケースとして文書化しなければなりません（SHALL）。

IdP は、許容される bound authenticator の型または特性を、信頼契約の中で指定してもよい（MAY）。

RP が FAL3 assertion を成功裏に受け入れる前に、RP subscriber account には、FAL3 トランザクション中に検証される bound authenticator への参照が含まれていなければなりません（SHALL）。これらの authenticator は、RP によって提供される場合（[Sec. 13.15.1]）も、加入者によって提供される場合（[Sec. 13.15.2]）もあり得て、いずれの場合も、authenticator を RP subscriber account に最初にバインドすることに対して異なる要件が適用されます。

以下のいずれかのイベントが発生した場合、RP は、アウトオブバンド手段（例：以前に加入者に関連付けられたアドレスへのメール）により加入者へ通知を送信しなければならず（SHALL）、また共有シグナリングシステム（[Sec. 4.8] 参照）を用いて IdP へ通知するべきです（SHOULD）。

新しい bound authenticator が RP subscriber account に追加された。
既存の bound authenticator が RP subscriber account から削除された。

authenticator 管理イベントに関して加入者へ通知を提供する際の追加の考慮事項については、[Sec. 4.6 of [SP800-63B]] を参照してください。

3.16.1. RP-Provided Bound Authenticator Issuance

RP が提供する authenticator の場合、RP のシステム管理者は、FAL3 フェデレーショントランザクションで使用するために authenticator を加入者へ直接発行しなければなりません（SHALL）。RP のシステム管理者は、RP subscriber account の識別された subject が、authenticator を発行される当事者であるかどうかを判断するための独立した手段を使用しなければなりません（SHALL）。RP のシステム管理者は、適用される場合に応じて、[[SP800-63A]] の [Sec. 4] における初回 authenticator バインディング要件、または [[SP800-63B]] の [Sec. 4.1.2] における登録後バインディング要件に従わなければなりません（SHALL）。RP のシステム管理者は、bound authenticator の一意識別子（例：authenticator の公開鍵）を RP subscriber account に保管しなければなりません（SHALL）。

例えば、RP が FAL3 認証のために購入した暗号 authenticator の集合を持っているとします。これらの authenticator はそれぞれ特定の RP subscriber account に provisioned されますが、RP のシステム管理者によって統制された環境で保管されます。authenticator を発行するために、RP は、RP のシステム管理者が、IdP からの FAL3 フェデレーショントランザクションを用いて、加入者に RP 管理のワークステーションへ認証させる対面プロセスを使用できます。次にシステム管理者は、RP subscriber account によって示される bound authenticator を加入者に手渡し、それを用いてワークステーションに認証させます。これにより加入者は RP が提供した bound authenticator を所持し、将来のトランザクションで FAL3 に到達するために使用できます。別の方法として、RP のシステム管理者は、加入者の検証済み住所へ authenticator を送付し、加入者が活性化プロセスを通じて受領を確認するようにできます。bound authenticator の利用には依然として IdP からの有効な assertion が必要なため、authenticator のみの傍受では、FAL3 における RP subscriber account へのアクセスには不十分です。

3.16.2. Subscriber-Provided Bound Authenticator Binding Ceremony

RP は、信頼された最初の使用（trust-on-first-use）に基づき、加入者が提供する authenticator を RP subscriber account に関連付けるプロセスを提供してもよい（MAY）。このプロセスは binding ceremony と呼ばれ、典型的な FAL3 フェデレーションプロセスを超える追加要件があります。binding ceremony は、[[SP800-63B]] の [Sec. 4.1.3] で議論される、加入者提供 authenticator のバインディングプロセスと類似しています。

RP subscriber account に bound authenticator が関連付けられていない場合、RP は [Fig. 5] に示すとおり、authenticator、加入者、RP subscriber account の間の接続を確立するために binding ceremony を実施しなければなりません（SHALL）。RP はまず、FAL3 の他のすべての要件を満たす assertion を用いたフェデレーションによって認証済みセッションを確立しなければなりません（SHALL）。これには、assertion が bound authenticator とともに FAL3 で使用される意図を示す指標（例：assertion が authentication class reference または Vectors of Trust [[RFC8485]] の値を含む）が含まれます。加入者は直ちに、提案された authenticator を提示して認証するようプロンプトされなければなりません（SHALL）。authenticator の提示が成功した場合、RP は authenticator の一意識別子（公開鍵など）を保管し、これを federated identifier に関連付けられた RP subscriber account と関連付けなければなりません（SHALL）。加入者が適切な authenticator を用いて RP に対する認証に成功しない場合、binding ceremony は失敗します。binding ceremony のセッションは 5 分以下でタイムアウトしなければならず（SHALL）、また [Sec. 3.9] で説明されるとおり、他の目的の認証済みセッションとして使用されてはなりません（SHALL NOT）。binding ceremony の成功完了後、RP は直ちに IdP に対して FAL3 の新しい assertion を要求しなければなりません（SHALL）。新しい assertion を受領したら、RP は新たにバインドされた authenticator を加入者に要求し（SHALL）、authenticator の出力を検証しなければなりません（SHALL）。

Fig. 5. Subscriber-provided bound authenticator binding ceremony

RP で管理され、加入者によって提供される bound authenticator に対して使用される binding ceremony の手順を示すシーケンス図。

加入者提供の bound authenticator は、加入者がすでに RP が FAL3 トランザクションで使用できる適切な authenticator へのアクセスを持っている場合に特に有用です。例えば、加入者は、[[SP800-63B]] の [Sec. 3.2.5.2] で説明される name-based phishing resistance を用いる単一要素の暗号 authenticator を持っているかもしれません。そのようなデバイスでは、authenticator が各場所で使用される際に IdP と RP は異なる検証鍵を見ることになり、bound authenticator を IdP が容易に検証できません。さらに、RP は authenticator を発行していないため、RP は authenticator の検証鍵を事前に知らず、その検証鍵をどの加入者アカウントに関連付けるべきかも分かりません。代わりに、RP は binding ceremony を用いて、加入者がこのデバイスを FAL3 における bound authenticator として使用できるようにできます。より完全な例は [Sec. 9.7] にあります。

RP は、加入者が FAL3 で複数の加入者提供 authenticator をバインドすることを許可してもよい（MAY）。この場合、RP subscriber account に 1 つ以上の既存 bound authenticator があるなら、binding ceremony は既存の bound authenticator のいずれかを用いて FAL3 に到達します。binding ceremony の初期認証ステップにおいて、RP は既存の bound authenticator による認証を要求して FAL3 に到達しなければなりません（SHALL）。この認証が完了して binding ceremony セッションが確立されたら、RP は新しい authenticator による認証を要求し（SHALL）、それを bound authenticator として RP subscriber account に関連付けなければなりません（SHALL）。RP は、FAL3 の新しい assertion を要求することで binding ceremony を完了します。

RP が bound authenticator がもはや有効ではないと判断する場合に加えて、加入者は、authenticator の紛失、侵害、または技術・プラットフォーム変更により使用不能になるなど、さまざまな理由で bound authenticator の使用をやめることがあります。このような場合、RP は、加入者が加入者提供 bound authenticator を RP subscriber account から削除できるようにしてもよい（MAY）。これにより、その authenticator を FAL3 セッションに用いる能力が削除されます。bound authenticator が削除されるとき、RP は加入者の現在のすべての FAL3 セッションを終了しなければならず（SHALL）、また IdP からの FAL3 における再認証を加入者に要求しなければなりません（SHALL）。RP は、削除対象の authenticator での認証を加入者に求めてはなりません（SHALL NOT）。加入者はアンバインド中に当該 authenticator へアクセスできないことが多く、特に authenticator が紛失または侵害されている場合はなおさらです。すべての bound authenticator が削除されると、加入者は新しい bound authenticator が RP subscriber account に追加されるまで FAL3 に到達できなくなります。この状況は、RP におけるアカウント復旧と同様のリスクをもたらします。

3.17. RP Processing of Holder-of-Key Assertions and Bound Authenticators

RP が bound authenticator に関連付けられた assertion を受領した場合、加入者は、bound authenticator の所持を RP に対して直接証明します。IdP における一次認証と、RP におけるフェデレーション認証は、別々に処理されます。加入者が、IdP における一次認証でも RP における bound authenticator でも同一の authenticator を使用することはあり得ますが、それらが同一であるという前提はありません。

以下の要件は、bound authenticator に関連付けられたすべての assertion に適用されます。

加入者は、assertion 自体の提示に加えて、bound authenticator の所持を RP に対して証明しなければなりません（SHALL）。
holder-of-key assertion について、assertion 内に見いだされる特定の authenticator への参照は、信頼契約で規定されるとおり、assertion 内の他のすべての情報と同等の水準で信頼されなければなりません（SHALL）。
RP は、bound authenticator に加えて assertion を処理し、検証しなければなりません（SHALL）。
bound authenticator による認証の失敗は、RP におけるエラーとなり、RP における認証済みセッションを作成してはなりません（SHALL NOT）。

4. General-Purpose IdPs

この節は規範的である。

general-purpose IdP とは、[Sec. 4.1] で説明されるとおり、IdP を provisioning するプロセスを通じて CSP が加入者アカウントを利用可能にする IdP です。加入者は、[Sec. 4.5] で説明されるとおり、加入者アカウントにバインドされた 1 つ以上の authenticator を用いて IdP に対して認証イベントを提供します。通常、general-purpose IdP は、加入者のデバイス上ではなくリモートサービス上にホストされます。general-purpose IdP は、複数の加入者をサポートすることがよくあります。

4.1. IdP Account Provisioning

IdP を通じてサブスクライバアカウントを利用可能にするには、サブスクライバアカウントを IdP にプロビジョニングする必要がある。サブスクライバアカウントを IdP にプロビジョニングする手段は、trust agreement において開示されなければならない。

IdP がサブスクライバを認証できる必要があるため、IdP は多くの場合 CSP のサービスであり、サブスクライバアカウント内の属性やオーセンティケータにある程度アクセスできる。こうした IdP は一般に、サブスクライバアカウントを保持するアイデンティティおよびアクセス管理システムと同一のセキュリティドメイン内にある。

別のケースでは、サブスクライバアカウント内の 1 つ以上のオーセンティケータを、共通の PKI に結び付いたオーセンティケータのように、セキュリティドメイン外で検証できることがある。これらのケースでは、IdP はオーセンティケータからサブスクライバ属性やアカウント情報を取得し、RP へのフェデレーテッドログインを提供できる。

IdP は、フェデレーテッド識別子などのフェデレーション固有の属性をサブスクライバアカウントに付加する。IdP は、trust agreement によって列挙されるプライバシー要件および保管要件に従い、フェデレーション目的の追加属性を収集できる。

CSP は、サブスクライバアカウントから IdP に対して、属性値、派生属性値、または属性バンドルとして属性を提供できる。CSP は IdP に発行する属性バンドルに署名しなければならない。

サブスクライバアカウントが IdP にプロビジョニングされた後、CSP は trust agreement の当事者ではあるが、フェデレーション取引には直接関与しない。したがって、RP が CSP によってホストされる identity API を通じて属性を取得する場合であっても、この identity API は本ガイドラインの目的において、CSP ではなく IdP の機能と見なされる。

4.2. Federation Transaction

汎用 IdP を含む federation transaction は、IdP におけるサブスクライバアカウントを確立し、RP におけるサブスクライバの authenticated session の成立で完結する。このプロセスを Fig. 6 に示す。

Fig. 6. Federation overview

汎用 IdP を含む federation transaction は、複数段階のプロセスである。

federation が発生する前に、サブスクライバアカウントは CSP によって確立される。このアカウントは、CSP が収集したアイデンティティ属性を、サブスクライバが使用する一連のオーセンティケータに結び付ける。
サブスクライバアカウントは IdP にプロビジョニングされる。IdP は、フェデレーテッド識別子などのフェデレーション固有の属性をサブスクライバアカウントに付加する。
IdP と RP は、サブスクライバを RP に対して認証するためのフェデレーテッド認証取引を開始する。
サブスクライバは、サブスクライバアカウントにバインドされたオーセンティケータを用いて IdP に対して認証する。trust agreement によって義務付けられている場合、承認された当事者（多くの場合サブスクライバ）は、実行時にアイデンティティ情報の開示を承認するよう促される。
IdP は、認証イベントの結果を表す assertion を作成する。この assertion は、trust agreement により確立された条件、RP からのリクエスト、IdP の能力、IdP が把握するサブスクライバアカウント、そして承認された当事者によって許可された属性に基づく。
assertion はネットワークを介して RP に渡される。
RP は IdP から受け取ったこの assertion を処理し、サブスクライバとの authenticated session を確立する。任意で、RP はサブスクライバアカウントを表すアイデンティティ属性を、assertion 内または identity API を通じて IdP から受け取る。

フェデレーテッド取引は、Sec. 3.5 で述べる trust agreement によって可能になる。これらの trust agreement は、どの当事者がどの役割を果たすか、当事者が相互に運用する条件、対象システム同士を接続する許可、そして当事者同士が相互作用する条件を定義する。単一の trust agreement が複数の federation transaction を包含することが多い。利用可能なサブスクライバのアイデンティティ属性、派生属性、属性バンドルの一覧は trust agreement で確立されるが、特定の取引においてどの属性を特定の RP に開示するかという判断は、最終的には federation transaction 中に確定する。RP に渡される最終的な属性、派生属性値、属性バンドルの集合は、次の処理によって選択される。

trust agreement により許容されるもの
RP が要求するもの
承認された当事者が許可するもの

また、IdP と RP は、フェデレーションプロトコルにおいて当事者間で情報を安全に交換するために必要となる暗号鍵および識別子を確立するため、discovery と registration を実施する必要がある（Sec. 4.4 参照）。事前に確立された trust agreement を通じて接続許可を表す既存のポリシー判断がある場合でも、この段階は技術レベルでの接続および統合を伴う。いずれの FAL でも、この段階はサブスクライバが RP へアクセスを試みる前に行うことができる。FAL1 または FAL2 では、この段階が、サブスクライバが RP で IdP を利用しようとする試みに応じて行われることもある。

フェデレーテッド・アイデンティティ取引では、IdP が RP に対するアイデンティティ属性および認証属性の源となる。federation transaction における通常の情報の流れは IdP から RP への一方向である。この情報フローの方向性により、IdP は RP の上流（upstream）にあり、RP は IdP の下流（downstream）にあると見なされる。Sec. 4.8 で述べる shared signals の利用などにより、追加情報が RP から上流へ戻る形で流れることもあり得る。

4.3. Trust Agreements

汎用 IdP の trust agreement は一般に、RP と IdP の間で確立されることが期待されており、RP はフェデレーション取引の信頼の基盤として IdP のアイデンティティに依拠する。CSP と IdP の間の trust agreement は、フェデレーション取引とは独立に確立されることが期待される。

汎用 IdP の trust agreement は、次のいずれかとして確立されなければならない。

フェデレーション取引の前にフェデレーテッド当事者による合意の結果として、または
フェデレーション取引中のサブスクライバによる判断または行為の結果として

4.3.1. Pre-Established Trust Agreements

フェデレーション取引の前にフェデレーテッド当事者によって trust agreement が確立される場合、trust agreement は少なくとも次の条件を確立しなければならない。

IdP が RP に利用可能とできるサブスクライバ属性、派生属性、属性バンドルの集合
サブスクライバによる削除要求の手段が利用可能である場合それを含む、サブスクライバアカウントに対する IdP の属性保管ポリシー
CSP を含む、IdP が該当するサブスクライバ属性、派生属性、属性バンドルを受け取る属性ソース
直接提供されるものか外部プロバイダ経由かを問わず、IdP により利用可能となる identity API、およびそれらの API で利用可能なサブスクライバ属性
IdP が assertion を作成できるサブスクライバアカウントの母集団
identity service の提供を超えるサブスクライバ情報の追加利用
RP が要求できることが許されるサブスクライバ属性、派生属性、属性バンドルの集合（すなわち、提供可能な属性の部分集合）
RP が要求する各属性の目的
RP subscriber account に対して RP が使用するプロビジョニングモデル
サブスクライバ属性を RP に開示する判断の責任を負う承認された当事者（例：IdP 組織、サブスクライバ）
属性共有についてサブスクライバに知らせるためのプロセスおよび技法
必要な場合に承認された当事者から同意を収集するためのプロセスおよび技法
IdP から利用可能な xALs
RP が要求する xALs

trust agreement の条件は、その確立時に RP および IdP の運用者が利用可能でなければならない。trust agreement の条件は、IdP または RP への要求によりサブスクライバが利用可能でなければならない。

IdP および RP はそれぞれ、苦情または問題の解決における有効性の観点から自らの redress メカニズムを評価し、その評価結果を trust agreement の一部として開示しなければならない。redress メカニズムに関する追加の要求事項および考慮事項は Sec. 3.5.3 を参照。

trust agreement の中で FAL3 が許容される場合、trust agreement は holder-of-key assertions（Sec. 3.15 参照）および bound authenticators（Sec. 3.16 参照）に関して次の条件を定めなければならない。

holder-of-key assertions を RP が検証できる手段（例：共通の信頼された PKI システム）
holder-of-key assertions を特定の RP subscriber account と RP が関連付ける手段（例：属性ベースの account resolution または事前プロビジョニング）
bound authenticators を RP が供給するのかサブスクライバが供給するのか
サブスクライバ提供の bound authenticators に用いる binding ceremony の文書化

IdP または RP が shared signaling を使用する場合（Sec. 4.8 参照）、trust agreement の条件は次を確立しなければならない。

シグナル送信を引き起こすイベント
各トリガーに対して送信されるシグナル
各シグナルに含まれる情報
シグナル受信者に期待される挙動

IdP における実行時判断（Sec. 4.6.1.3 参照）は、フェデレーテッド取引において当事者間で送信されるサブスクライバ属性をさらに制限するために用いてよい（例：その属性が trust agreement の条件に含まれていても、実行時判断によりメールアドレスを開示しない選択ができる）。

trust agreement は、目的適合性を維持し、不要なデータ交換およびサブスクライバデータの過剰収集を避けるため、定期的に見直されなければならない。

4.3.2. Subscriber-Driven Trust Agreement Establishment

trust agreement がサブスクライバの判断の結果として確立される場合（例：確立済みの合意がない状態で、サブスクライバが RP と自身の IdP の間で federation transaction を開始する）、trust agreement はサブスクライバを錨として成立する。サブスクライバ主導の trust agreement では、trust agreement は当事者間の正式な契約ではなく、利用規約の集合という形を取る。したがって、次の条件はサブスクライバからの要求により開示されなければならない。

CSP を含む、IdP が該当するサブスクライバ属性を受け取る属性ソース
直接提供されるものか外部プロバイダ経由かを問わず、IdP により利用可能となる identity API、およびそれらの API で利用可能なサブスクライバ属性
IdP が RP に利用可能とできるサブスクライバ属性、派生属性、属性バンドルの集合
サブスクライバによる削除要求の手段が利用可能である場合それを含む、サブスクライバアカウントに対する IdP の属性保管ポリシー
IdP と RP の間の shared signaling の使用
IdP が assertion を作成できるサブスクライバアカウントの母集団
identity service の提供を超えるサブスクライバ情報の追加利用
IdP から利用可能な xALs
RP が要求する xALs

IdP は、苦情または問題の解決における有効性の観点から redress メカニズムを評価し、その評価結果をサブスクライバに開示しなければならない。redress メカニズムに関する追加の要求事項および考慮事項は Sec. 3.5.3 を参照。

サブスクライバ属性の開示は、Sec. 4.6.1.3 で述べるとおり、IdP における実行時判断により管理されなければならない。承認された当事者はサブスクライバでなければならない。

trust agreement の次の条件は、実行時判断の際にサブスクライバへ開示されなければならない。

RP が要求するサブスクライバ属性、派生属性、属性バンドルの集合（すなわち、IdP が利用可能とする属性の部分集合）
RP が要求する各属性の目的
RP subscriber account に対する RP の属性保管ポリシー（サブスクライバによる削除要求の手段が利用可能である場合それを含む）

サブスクライバに開示されるすべての情報は、Sec. 8 で述べるとおり、理解可能で行動に移せる形で伝えられる必要がある。

4.4. Discovery and Registration

汎用 IdP と federation transaction を行うには、Sec. 3.6 で述べるとおり、RP はその IdP と discovery および registration を行う必要がある（Sec. 3.6 参照）。

RP は、trust agreement により定められるとおり、assertion の検証鍵およびその他の関連する設定情報を IdP の識別子と関連付けなければならない。検証鍵および設定情報がネットワーク接続で取得される場合、要求および取得は、trust agreement により IdP の識別子に関連付けられた場所から、authenticated protected channel を介して行われなければならない。多くのフェデレーションプロトコルでは、trust agreement において IdP が管理している、または IdP の代理として提供されていると指定された URL から、RP が公開鍵と設定データを取得することでこれを実現する。また、RP のシステム管理者が IdP 情報を直接 RP ソフトウェアの設定に入力するという、手動の方法で RP を構成することも可能である。

特に multi-lateral trust agreements によって統治されるシステムでは、discovery プロセスが第三者の discovery および registration サービスによって補助されることがある。

さらに、RP は trust agreement に従い、IdP または IdP が信頼する権限主体のいずれかに、自身の情報を登録しなければならない。多くのフェデレーションプロトコルでは、この段階で RP に識別子が割り当てられ、RP はその後の IdP との通信にこの識別子を用いる。

フェデレーションを求める当事者は、trust agreement においてその信頼できる第三者が特定されている場合、discovery および registration のプロセスを補助するために信頼できる第三者を利用してよい。例えばコンソーシアムは、参加者から IdP と RP の設定レコードを直接収集するホステッドサービスを利用できる。RP は IdP に直接 discovery レコードを取りに行く代わりに、このサービスへ行き、対象 IdP の鍵素材を取得する。IdP は逆に、このサービスへ行き、接続に必要な RP の識別子および設定情報を見つける。このサービスは、Sec. 3.5.2 で述べる multilateral trust agreements における federation authority の役割を果たす当事者と同じ当事者によって管理されることが多い。

4.4.1. Manual Registration

すべての FAL において、RP と IdP の暗号鍵および識別子は、RP のシステム管理者が RP の設定を IdP に対して直接または信頼できる第三者を介して提出し、その IdP とともに用いる識別子を受け取るという手動プロセスで交換できる。次に、RP のシステム管理者は、RP をこの識別子と、フェデレーション取引を継続するために必要な追加情報で構成する。

これは手動プロセスであるため、registration は federation transaction の前に行われる。

このプロセスは、手動の設定点が対象システムを、時間の経過とともに更新可能な信頼できる情報源へ向けるといった形で、ある程度の自動化ツールによって補助してよい。そのような自動化が用いられる場合、trust agreement は、許容されるキャッシュ有効期間を含め、暗号鍵配布および割り当ての許容条件を列挙しなければならない。

4.4.2. Dynamic Registration

FAL1 および FAL2 では、RP の暗号鍵および識別子は、RP ソフトウェアが自身の設定を IdP に対して直接または信頼できる第三者を介して提示し、その IdP とともに用いる識別子を受け取るという動的プロセスで交換できる。このプロセスは使用中のフェデレーションプロトコルに固有だが、機械可読な設定データがネットワーク越しに利用可能であることを要する。設定情報の送信はすべて、trust agreement により IdP の識別子に関連付けられたエンドポイントに対して、secure protected channel を介して行われなければならない。

IdP は、情報が複数の RP インスタンスへ漏えいするリスクを考慮し、Sec. 3.4.1 で述べる、動的に登録された RP にアクセスするサブスクライバ向けの PPI の発行など、適切な対策を講じるべきである。

動的 registration は、Sec. 3.6.3 で述べるとおり、RP ソフトウェアおよびデバイスに関する attestation によって補強されるべきである。

[OIDC-Registration] は OpenID Connect IdP における RP の動的 registration のためのプロトコルを定義している。

4.5. Subscriber Authentication at the IdP

フェデレーションの文脈では、IdP は SP800-63B で述べるとおり、サブスクライバアカウントにバインドされたオーセンティケータの検証者として振る舞う。1 つ以上のオーセンティケータを検証することにより、IdP における authenticated session を開始する認証イベントが生成される。この認証イベントが、サブスクライバが存在するという IdP の主張の根拠となる。

IdP は、次のいずれのイベントの前にも、サブスクライバに authenticated session を要求しなければならない。

属性開示の承認
assertion の作成および発行
サブスクライバ主導の trust agreement の確立

セッション管理および再認証に関する追加要件は Sec. 4.7 で述べる。

4.6. Authentication and Attribute Disclosure

trust agreement で定められた承認された当事者は、federation transaction を進めるかどうか、したがって assertion が発行され RP へ属性が開示されるかどうかを決定しなければならない。この判断は、次を含むさまざまな方法で算出できる。

allowlist：システムが federation transaction を自動的に進められる状況を定める
blocklist：システムが federation transaction を進めない状況を定める
実行時判断：承認された当事者（例：サブスクライバ）が、取引を進めるかどうか、およびどのような厳密な条件の下で進めるかを決定できるようにする。実行時判断は保存され、将来の取引に適用できる。

allowlist、blocklist、または実行時判断の適用可能性は、IdP と RP のアイデンティティ、要求されるサブスクライバ属性、要求される xAL、その他の要因を含む federation transaction の側面によって影響を受け得る。これらの判断は、リスク管理システム、federation authority、ローカルのシステムポリシーによって補助され得る。

企業向け Web application の single sign-on を容易にするために、IdP で RP がサブスクライバ集合に対して allowlisted されている非規範的な例については Sec. 9.5 を参照。

IdP は、サブスクライバの苦情または問題に対する効果的な redress の仕組み（例：サブスクライバが不正確な属性値を特定する）を提供しなければならない。redress メカニズムに関する追加の要求事項および考慮事項は Sec. 3.5.3 を参照。

4.6.1. IdP-Controlled Decisions

IdP Allowlists of RPs

事前に確立された trust agreement において、IdP は、サブスクライバの実行時判断なしに IdP から認証および属性を受け取ることを許可された RP の allowlists を設定してよい。RP を allowlist に載せる際、IdP はその RP が trust agreement の条件を順守することを確認しなければならない。IdP は、認証時に allowlisted RP に渡されるアイデンティティ属性を決定しなければならない。IdP は、Sec. 7.2 で述べるとおり、allowlists をサブスクライバが利用できるようにしなければならない。

IdP allowlists は、完全修飾ドメイン名、暗号鍵、または使用中のフェデレーションプロトコルに適用可能な他の識別子によって、RP を一意に識別しなければならない。同一の識別子を共有する任意の実体は、allowlist の目的において同等と見なされなければならない。allowlists は、RP の意図しないなりすましを避けるため、可能な限り具体的であるべきである。RP の allowlist エントリは、ワイルドカードのドメイン識別子を使用してはならない。

RP の IdP allowlist エントリは、allowlisted 判断の一部として含まれる属性を示さなければならない。RP により追加属性が要求される場合、その要求は次のいずれかでなければならない。

承認された当事者による実行時判断の対象となり、要求された追加属性を承認する、
allowlist エントリにある属性のみに編集される、または
IdP によって明確に拒否される。

IdP allowlist エントリは、取引に要求される xALs など、federation transaction の側面に基づいて適用してよい。例えば、IdP は allowlist エントリを用いて、FAL1 の取引では同意画面を省略しつつ、FAL3 の取引ではサブスクライバから同意の確認を要求できる。

IdP Blocklists of RPs

IdP は、サブスクライバが要求した場合であっても IdP から認証 assertion または属性を受け取る権限がない RP の blocklists を設定してよい。RP が IdP の blocklist に載っている場合、IdP はいかなる状況でも当該 RP を対象とする assertion を生成してはならない。

IdP blocklists は、完全修飾ドメイン名、暗号鍵、または使用中のフェデレーションプロトコルに適用可能な他の識別子によって、RP を一意に識別しなければならない。同一の識別子を共有する任意の実体は、blocklist の目的において同等と見なされなければならない。例えば、“*.example.com” というワイルドカードのドメイン識別子は、“www.example.com”、“service.example.com”、“unknown.example.com” の各ドメインに等しく一致する。これら 3 つのサイトはいずれも同一の blocklist エントリによってブロックされる。

IdP Runtime Decisions

trust agreement に含まれるが IdP の allowlist に載っていないすべての RP は、trust agreement により特定された承認された当事者が実行時の認可判断を行うというデフォルトポリシーにより統治されなければならない。実行時判断はフェデレーション取引中に発生するため、承認された当事者は一般に人であり、多くの状況ではサブスクライバである。ただし、システム管理者のような別の当事者が、サブスクライバに代わって促されることもあり得る。サブスクライバ主導の trust agreement では、サブスクライバとの実行時判断が、サブスクライバ属性の開示を認可する唯一許容される手段である。

実行時判断を処理する際、IdP はフェデレーション取引中に承認された当事者へ対話的に促す。承認された当事者は、認証 assertion と特定の属性を RP に開示することに同意する。IdP は、サブスクライバに関するいかなる属性も RP へ送信される前に、承認された当事者へ明示的な通知を行い、肯定的な確認を求めなければならない。少なくとも、この通知は Sec. 7.2 と整合する形で、最も効果的に通知を提供し確認を得られる立場にある当事者によって提供されるべきである。IdP は、取引が承認された場合にどの属性が RP に開示されるかを開示しなければならない。使用中のフェデレーションプロトコルが実行時の任意または選択的な属性開示を許容する場合、承認された当事者には、フェデレーション取引全体を終了させることなく、特定の属性を送信するかどうかを判断する選択肢が与えられなければならない。

承認された当事者がサブスクライバである場合、IdP は、RP に送信される属性値および派生属性値をサブスクライバが閲覧できる仕組みを提供しなければならない。機密情報の無権限な露出（例：ショルダーサーフィン）のリスクを軽減するため、IdP は既定で、サブスクライバに表示される機密情報をマスクしなければならない。マスキングの詳細は、ユーザビリティ上の考慮事項として Sec. 8 を参照。

IdP は、承認された当事者の判断を記憶し、同一の RP に対して同一の属性セットを再送信する仕組みを用いてよい。この仕組みは、IdP によって管理されるサブスクライバアカウントに関連付けられる。そのような仕組みが提供される場合、IdP は、保管の仕組みが使用されていることを承認された当事者へ開示しなければならず、また、将来の時点で記憶されたアクセスを取り消せるようにしなければならない。

4.6.2. RP-Controlled Decisions

RP Allowlists of IdPs

RP は、サブスクライバが IdP を利用するための実行時判断なしに、RP が認証および属性を受け入れる IdP の allowlists を設定してよい。実務上、多くの RP は単一の IdP のみと連携し、その IdP が当該 RP にとって唯一のエントリとして allowlisted される。IdP を allowlist に載せる際、RP はその IdP が trust agreement の条件を順守することを確認しなければならない。この確認は federation authority によって補助され得るし、RP が直接実施してもよい。

RP allowlists は、完全修飾ドメイン名、暗号鍵、または使用中のフェデレーションプロトコルに適用可能な他の識別子によって、IdP を一意に識別しなければならない。allowlists は、IdP の意図しないなりすましを避けるため、可能な限り具体的であるべきである。IdP の allowlist エントリは、ワイルドカードのドメイン識別子を使用してはならない。

RP allowlist エントリは、取引に要求される xALs など、federation transaction の側面に基づいて適用してよい。例えば、RP は FAL1 の取引では実行時判断を用いつつ、FAL3 の取引では allowlisted IdP を要求できる。

RP Blocklists of IdPs

RP は、サブスクライバが要求した場合であっても、RP が認証または属性を受け入れない IdP の blocklists を設定してよい。blocklisted IdP は、同一の federation authority の配下に両者がある場合のように、RP と有効な trust agreement の中に存在し得る。

RP blocklists は、完全修飾ドメイン名、暗号鍵、または使用中のフェデレーションプロトコルに適用可能な他の識別子によって、IdP を一意に識別しなければならない。同一の識別子を共有する任意の実体は、blocklist の目的において同等と見なされなければならない。例えば、“*.example.com” というワイルドカードのドメイン識別子は、“www.example.com”、“service.example.com”、“unknown.example.com” の各ドメインに等しく一致する。これら 3 つのサイトはいずれも同一の blocklist エントリによってブロックされる。

RP Runtime Decisions

RP の trust agreement に含まれるが RP の allowlist に載っていないすべての IdP は、trust agreement に示された承認された当事者が実行時の認可判断を行うというデフォルトポリシーにより統治されなければならない。このモードでは、承認された当事者は、サブスクライバに代わって認証のためにどの IdP に連絡するかを選択または入力するよう、RP によって促される。このプロセスは、サブスクライバがメールアドレスのような人間向け識別子を入力し、その入力値に基づいてプログラムにより当該アドレスの IdP を選択する discovery メカニズムによって補助され得る。実行時判断はフェデレーション取引中に発生するため、承認された当事者は一般に人であり、多くの状況ではサブスクライバである。

RP は、承認された当事者が特定の IdP を利用するという判断を記憶する仕組みを用いてよい。この仕組みは RP における認証の前に用いられるため、RP がこの仕組みを提供する方法（例：authenticated session の外側にあるブラウザクッキー）は、Sec. 3.8 で述べるとおり RP subscriber account とは別である。そのような仕組みが提供される場合、RP は、保管の仕組みが使用されていることを承認された当事者へ開示しなければならず、また、将来の時点で記憶されたアクセスを取り消せるようにしなければならない。

4.6.3. Provisioning Models for RP Subscriber Accounts

RP subscriber account のプロビジョニングプロセスのライフサイクルは、Sec. 3.5 で述べる trust agreement や IdP と RP の配備パターンを含む要因により異なる。しかし、いずれの場合でも、RP subscriber account は、RP における authenticated session の成立に先立ち、次のいずれかの方法で RP にプロビジョニングされなければならない。

Just-In-Time Provisioning

RP subscriber account は、RP が IdP から未知のフェデレーテッド識別子を含む assertion を初めて受け取ったとき、RP subscriber account が存在しないとき、または Sec. 3.8.2 で述べる account resolution プロセスにより既存の RP subscriber account を解決できるときに作成される。Sec. 3.12.3 で述べるとおり、フェデレーションプロセス中に学習された任意のアイデンティティ属性（assertion 内、または identity API を通じて）を、RP subscriber account に関連付けてよい。この方法でプロビジョニングされたアカウントは、それらをプロビジョニングするために用いられた assertion のフェデレーテッド識別子にバインドされる。これはフェデレーションシステムにおける最も一般的なプロビジョニング形態であり、RP と IdP の間の調整を最小限にできる。しかし、このようなシステムでは、RP は自身がキャッシュする属性の管理に責任を負わなければならない。Fig. 7 を参照。

Fig. 7. Just-in-time provisioning

Pre-Provisioning

RP subscriber account は、IdP が属性を RP にプッシュする、または RP が IdP から属性をプルすることにより作成されるか、既存の RP subscriber account にリンクされる。アカウントの事前プロビジョニングは、表現されるサブスクライバが federation transaction を通じて認証する前にプロビジョニングが行われるため、一般にプロビジョニング API を通じて一括で行われる（Sec. 4.6.5 参照）。事前プロビジョニングされたアカウントは、プロビジョニング時にフェデレーテッド識別子にバインドされなければならない。ただし、trust agreement により、account linking ポリシー（Sec. 3.8.1 参照）、account resolution ポリシー（Sec. 3.8.2 参照）、または代替認証メカニズム（Sec. 3.8.3 参照）など、別のアクセス手段が定義されている場合はこの限りではない。このプロビジョニング形態は IdP と RP の側でインフラストラクチャと計画を要するが、これらのプロセスは自動化プロトコルにより補助できる。さらに IdP と RP は、Sec. 4.6.4 で述べるとおり、プロビジョニングされたアカウント集合を時間の経過とともに同期させ続けなければならない。Fig. 8 を参照。

このモデルでは、RP は、まだ RP とやり取りしていない、そして今後もやり取りしない可能性があるサブスクライバに関する属性も受け取る。これは、RP が RP を利用するサブスクライバの部分集合についてのみ情報を受け取り、しかもサブスクライバが初めて RP を利用した後にのみ受け取る他のモデルとは対照的である。federation transaction の前に RP がこの情報へアクセスできることのプライバシー上の考慮事項は、trust agreement において考慮されなければならない。

Fig. 8. Pre-provisioning

Ephemeral Provisioning

assertion を処理する際、RP はその assertion と新規または既存の RP subscriber account の間にリンクを確立するが、authenticated session の終了時にそのリンクを削除する。このプロセスは just-in-time provisioning に類似するが、セッションが完了した時点で、Sec. 3.11.3 に従って、RP はサブスクライバの長期的な記録を保持しない。このプロビジョニング形態は、アクセス権を IdP に完全に外部委任し、RP をより単純で内部状態の少ないものにできるため有用である。この形態が用いられる場合、assertion にフェデレーテッド識別子は不要である。assertion にフェデレーション識別子が供給される場合、RP は RP subscriber account からフェデレーション識別子のあらゆるリンクを削除しなければならない。Fig. 9 を参照。

Fig. 9. Ephemeral provisioning

Other Provisioning Methods

その他の RP subscriber account のプロビジョニングモデルも可能だが、その詳細は本ガイドラインの範囲外である。ただし、代替プロビジョニングモデルの詳細は、IdP と RP のプライバシーリスク評価に含めなければならない。

すべての組織は、その trust agreement の一部としてプロビジョニングモデルを文書化しなければならない。

4.6.4. Attribute Synchronization

フェデレーションプロセスでは、IdP と RP はそれぞれ、サブスクライバアカウントに関連付けられたアイデンティティ属性の独自の保管場所を持つ。IdP はサブスクライバアカウントの属性を直接把握できるが、RP subscriber account は federation transaction 中に提示された属性の部分集合から派生する。したがって、IdP と RP の属性ストアは時間の経過とともに乖離する可能性がある。

RP の観点では、IdP は、IdP が IdP におけるサブスクライバアカウントに関連付けられていると主張する任意の属性についての信頼できる情報源である。しかし、RP は、Sec. 4.6.6 で述べるとおり、RP subscriber account に関連付けるための他の属性を収集し、任意で検証してよい。

IdP がすべての assertion で更新された属性を能動的に RP へプッシュすることも可能だが、この慣行は各取引で個人情報を露出させる。各取引で送信される個人情報量を抑えるため、IdP は、RP が利用可能なサブスクライバアカウント属性が更新されたときに、下流の RP へシグナルを送るべきである。RP は、このシグナルに応答して IdP へ新しい属性を要求し、RP subscriber account を更新してよい。この同期は、shared signaling（Sec. 4.8 参照）、プロビジョニング API（Sec. 4.6.5 参照）、または RP へシグナルを送ること（例：サブスクライバアカウント属性が最後に更新された時刻のタイムスタンプを提供する）により、identity API を通じて更新された属性を要求させる形（Sec. 3.12.3 参照）で実現できる。

RP が identity API へのアクセスを付与されている場合、IdP は federation transaction の終了後に同期操作を実行できるだけの十分な時間、RP が identity API へアクセスできるようにすべきである。identity API は、特に just-in-time provisioning プロセスを伴う初回ログイン時に多用されるが、その後のログインでは、RP が前回取得した後に属性が変化している可能性がある。したがって、RP subscriber account における属性キャッシュを更新できるよう、初回ログインプロセスを超えて RP に identity API へのアクセスが与えられるべきである。例えば、assertion の有効期間が 5 分である場合、RP が RP subscriber account が古いと判断したときに、帯域外で属性を取得して更新できるよう、identity API へのアクセスを 30 分有効にできる。

IdP は、サブスクライバアカウントが終了した場合、またはサブスクライバアカウントの RP へのアクセスが取り消された場合に、下流の RP へシグナルを送るべきである。これは、shared signaling（Sec. 4.8 参照）、プロビジョニング API（Sec. 4.6.5 参照）、または帯域外メカニズムによって実現できる。そのようなシグナルを受け取った場合、RP は trust agreement により定められるとおり、かつ Sec. 3.11.3 に従って RP subscriber account を処理しなければならない。終了理由が疑わしい活動または不正活動である場合、IdP は RP に終了を通知し、その RP との trust agreement で指定されている場合、RP が関連する RP subscriber account の活動を疑わしい活動として確認できるよう、シグナルに理由を含めなければならない。

4.6.5. Provisioning APIs

事前プロビジョニングの一部として、RP は provisioning API と呼ばれる汎用 identity API を通じてサブスクライバ属性へアクセスできるようにされ得る。この種の API は、IdP がある範囲のサブスクライバアカウントの属性をプッシュすることを可能にし、場合によっては RP がこれらのサブスクライバアカウントの属性を直接クエリすることも可能にする。API へのアクセスは federation transaction の文脈外で付与されるため、特定サブスクライバに対する provisioning API へのアクセスは、当該サブスクライバが認証されたことを RP に示すものではない。

特定の RP に利用可能な provisioning API の属性は、Sec. 3.10.1 で述べるとおり、監査およびセキュリティ目的を含め、RP がその機能を果たすために必要なものに限られなければならない。trust agreement の確立の一部として、IdP は、RP に provisioning API へのアクセスが与えられる場合には、そのことを文書化しなければならず、少なくとも次を含めなければならない。

プロビジョニングモデルを用いたアクセスの目的
RP に利用可能とされる属性の集合
API の機能が RP へのプッシュ、RP からのプル、またはその両方であるかどうか
属性が RP に利用可能とされるサブスクライバ母集団

provisioning API へのアクセスは、mutually authenticated protected channel を介して行われなければならない。正確な認証手段は、API の詳細、およびプッシュモデル（すなわち IdP が RP への接続を開始する）かプルモデル（すなわち RP が IdP への接続を開始する）かによって異なる。

provisioning API は、サブスクライバ主導の trust agreement の下では利用可能としてはならない。IdP は、確立された trust agreement の外側にいるいかなる RP に対しても provisioning API を利用可能としてはならない。IdP は、当該 RP との federation transaction および関連機能（例：サブスクライバアカウントの取り消しを通知するシグナリング）を容易にするためのフェデレーテッド・アイデンティティ関係の一部としてのみ、RP に provisioning API へのアクセスを提供しなければならない。IdP は、RP の機能目的のためにアクセスが不要になったとき、または trust agreement が終了したとき、RP の provisioning API へのアクセスを取り消さなければならない。

RP に提供される任意の provisioning API は、IdP の管理および管轄下になければならない。外部の属性プロバイダは、この provisioning API を通じて属性を提供するための情報源として利用してよいが、参照される属性プロバイダが提供する情報の内容および正確性については IdP が責任を負う。

provisioning API が使用中である場合、IdP は、アカウントが終了または無効化された場合など、サブスクライバアカウントの状態が変更されたときに RP へシグナルを送らなければならない。そのようなシグナルを受け取った場合、RP はアカウントからフェデレーテッド識別子のバインディングを削除しなければならない。RP は、サブスクライバが当該アカウントにアクセスできなくなった場合、RP subscriber account を終了してよい。RP は、provisioning API に由来するすべての個人情報を Sec. 3.11.3 に従って扱わなければならない。

SCIM（RFC7644）などの provisioning APIs は、Sec. 9.5 の例に示すように、IdP と RP の間に確立された関係がある enterprise シナリオで用いられることが多い。

4.6.6. Collection of Additional Attributes by the RP

RP は、IdP から提供される属性を超えて、サブスクライバから追加属性を収集し維持してよい。例えば、RP は IdP から提供されない好みの表示名をサブスクライバから直接収集できる。RP はまた、IdP に関連付けられない identity API へ RP がアクセスできるようにする属性プロバイダと別の合意を持つこともできる。例えば、RP は州のライセンス番号を IdP から受け取りつつ、別の属性検証 API を用いて当該ライセンス番号が現在有効かどうかを確認できる。IdP からの assertion はライセンスをサブスクライバにバインドするが、属性検証 API は IdP が共有できない、または権威を持てない追加情報を提供する。

これらの属性は、フェデレーション取引の外側で RP によって収集されるため、trust agreement とは別に統治される。しかし、RP subscriber account に含まれるすべての属性は、出所を問わず、Sec. 3.11.3 に従って保管されなければならない。

RP は、追加属性を収集する目的をサブスクライバに開示しなければならない。これらの属性は、RP の機能として述べられた目的のためにのみ使用されなければならない。追加収集された属性の送信は、Sec. 3.10.1 に従って扱われなければならない。

RP は、サブスクライバがこれらの追加収集属性を RP subscriber account から更新および削除できる、安全かつ効果的な redress の手段を提供しなければならない。redress メカニズムに関する追加の要求事項および考慮事項は Sec. 3.5.3 を参照。

次の要件は、機関が独自の identity service を運用しているか、identity service の一部として外部 CSP を利用しているかに関係なく、連邦機関に適用される。

RP は、追加で収集した属性およびその利用を、System of Records Notice (SORN) の一部として開示しなければならない。

4.6.7. Time-Based Removal of RP Subscriber Accounts

RP が just-in-time provisioning の仕組みを使用している場合、RP がサブスクライバアカウントの存在を知るのは、そのアカウントが RP で初めて使用されたときに限られる。IdP が shared signaling（Sec. 4.8 参照）を用いて終了したサブスクライバアカウントを RP に通知しない場合、RP は IdP からはもはやアクセスできない RP subscriber account を蓄積してしまう可能性がある。これは、RP subscriber account に個人情報を保持すること、および攻撃者が標的にし得る悪用可能なアカウントを提供してしまうことについて、RP にリスクをもたらす。そのような状況では、RP は、アプリケーションの利用パターンに合わせた一定期間が経過してもアクセスされていない RP subscriber account を終了対象として特定する、時間ベースの仕組みを採用してよい。例えば、通常は週次でアクセスされる RP であれば、RP での最終アクセスから 120 日をタイムアウトとして設定し、その RP subscriber account を終了対象としてマークできる。アクセス間隔がより長いことを想定する RP（例：年 1 回利用されるサービス）では、時間ベースの終了に対してはるかに長い期間、例えば 5 年といった期間を設けるべきである。

非アクティブなアカウントを処理する際、RP は、予定されているアカウント終了についてサブスクライバに十分な通知を行い、予定された終了より前にアカウントを再有効化する選択肢をサブスクライバに提供しなければならない。終了時には、RP は Sec. 3.11.3 に従い、RP subscriber account に関連付けられたすべての個人情報を削除しなければならない。

4.7. Reauthentication and Session Requirements in Federated Environments

フェデレーション環境では、RP は IdP におけるセッションとは別に、自身のセッションを管理する。assertion は両方のセッションに関連するが、その有効期間は最終的にはそれらから独立している。

Fig. 10 に示すとおり、assertion は IdP における authenticated session の間に作成され、assertion を処理することで RP における authenticated session が作成される。assertion の有効期間ウィンドウは、RP による assertion の処理を管理するために用いられるが、IdP または RP における authenticated session の存続期間を示すものではない。サブスクライバの IdP におけるセッションがまだ有効である間に、IdP に新しい federation transaction の要求が来た場合、新しい独立した assertion が、その有効期間ウィンドウを持って作成される。同様に、RP が assertion を消費した後は、RP のセッションの有効性は assertion の有効性とは独立している。多くの場合、RP における authenticated session は assertion の有効期間をはるかに超えて存続する。identity API へのアクセスが付与されている場合も同様に、そのアクセスの有効性は assertion の有効性や、RP における authenticated session の存続期間とは独立している。

Fig. 10. Session lifetimes

IdP が IdP におけるサブスクライバのセッションを終了しても、そのサブスクライバが下流の RP で持っている可能性のあるセッションが必ずしも終了するとは限らない。RP と IdP は、フェデレーションプロトコルがサポートしている場合、または shared signaling（Sec. 4.8 参照）を通じて、相互にセッション終了イベントを伝達してよい。

フェデレーション取引の要求時点で、サブスクライバは IdP において事前に確立された authenticated session を持っている可能性があり、それを用いて RP への assertion を生成してよい。IdP は、IdP が把握している、IdP におけるサブスクライバの直近の認証イベントの新しさに関する情報を RP に伝達しなければならず、RP はその情報を用いて認可およびアクセスの判断を行ってよい。使用中のフェデレーションプロトコルの能力に応じて、IdP は、サブスクライバが IdP で新しい認証を行うことを RP が要求できるようにすべきである。例えば、サブスクライバの最後の認証イベントからの最大経過時間を要求できるようにするといった形である。例えば、サブスクライバが 1 件の取引のために IdP で認証したとする。次にサブスクライバが 30 分後に RP で federation transaction を開始する。xAL 要件に応じて、IdP におけるサブスクライバの既存セッションを用いることで、サブスクライバにオーセンティケータの提示を促すことを避けられる。その結果として RP に渡される assertion は、サブスクライバが RP に対して最後に認証した時点が 30 分前であることを示す。RP はその情報を用いて、RP の要件として妥当かどうかを判断できる。認証時刻が RP にとって十分でない場合、RP は IdP に対してサブスクライバへ新しい認証イベントを促すよう要求できる。

RP が assertion を受け取るのと同時に identity API へのアクセスを付与される場合でも、identity API へのアクセスの存続期間は assertion の存続期間とは独立している。その結果、identity API を通じて追加属性を正常に取得できるという RP の能力を、RP のセッションの確立または延長に用いてはならない。同様に、identity API にアクセスできないことを、RP のセッションを終了させるために用いるべきではない。

RP は、フェデレーション取引中に他の non-identity APIs（例：サブスクライバのカレンダー）へのアクセスを付与されることもあり得るが、non-identity APIs は本ガイドラインの範囲外である。

RP は、assertion、認証イベント、または属性が RP の要件を満たさない場合、サブスクライバとの authenticated session を終了してよいし、RP の機能へのアクセスを制限してよい。例えば、RP が「FAL3 の federation transaction の場合にのみ高リスク機能へのアクセスを許可する」ように設定されている一方で、受信した assertion が FAL2 の要件しか満たさない場合、RP は高リスク機能へのアクセスを拒否しつつ低リスク機能へのアクセスは許可する、またはセッション全体を終了することを選択できる。

IdP と RP の双方に適用されるセッション管理要件についての詳細は、SP800-63B Sec. 5 を参照。

4.8. Shared Signaling

一部の環境では、IdP と RP が federation transaction の外側で相互に情報を送ることが有用である。これらのシグナルは、疑わしい不正行為やアカウント状態の変更など、通常は知られ得ない当事者間の重要な状態変化を伝達できる。shared signaling は、Sec. 3.10.1 で述べるとおり、アイデンティティプロセスの許容される機能に限定されなければならない。shared signaling のすべての利用は trust agreement に文書化され、trust agreement で定められた承認された当事者が利用できるようにされなければならない。この文書化には、シグナルが送られる事象、当該シグナルに含まれる情報の種類（個人情報を含む場合はそれも含む）、シグナルとともに送られる追加パラメータ、受信したシグナルに対して期待される処理を含めなければならない。shared signaling の利用は trust agreement の下でプライバシーレビューの対象とされなければならない。shared signals は、対象となるサブスクライバアカウントを特定するために必要なもの（例：アカウント識別子、受信側が相関できる属性）を除き、個人情報を含んではならない。

IdP から RP へのシグナリングは、事前に確立された trust agreement を必要とする。RP から IdP へのシグナリングは、事前確立型およびサブスクライバ主導型の trust agreements の双方で用いてよい。

IdP は、サブスクライバアカウントに関する次の変更について、RP にシグナルを送るべきである。

アカウントが終了、停止、または無効化された。
アカウントが侵害された疑いがある。
アカウントの属性が変更された。これにはフェデレーテッド識別子以外の識別子（例：メールアドレス、証明書のコモンネーム）も含まれる。
当該アカウントで取り得る IAL、AAL、または FAL の範囲が変更された。
オーセンティケータが更新された。

RP subscriber account が侵害された疑いがあるというシグナルを RP が受け取った場合、RP は、そのアカウントが RP で行った行為を不審な活動について確認すべきである。

RP は、RP subscriber account に関する次の変更について、IdP にシグナルを送るべきである。

アカウントが終了、停止、または無効化された。
アカウントが侵害された疑いがある。
RP により bound authenticator が追加された。
RP により bound authenticator が削除された。

サブスクライバアカウントが侵害された疑いがあるというシグナルを IdP が受け取った場合、IdP は、そのアカウントが IdP で行った行為を不審な活動について確認しなければならない。IdP において不審な活動が確認された場合、IdP は、疑わしい期間中に当該サブスクライバアカウントが利用された追加の RP があれば、それらの RP にシグナルを送らなければならない。

IdP と RP の双方からの追加シグナルは、セキュリティレビューの対象とされ、プライバシーリスク評価に含められ、trust agreement で取り扱われなければならない。

RP が複数の IdP への account linking を許容する場合、RP は、リンクされたアカウントに関するシグナルの運用を文書化しなければならない。RP は、shared signals がサブスクライバのリンクされた IdP のアイデンティティを明らかにしないようにしなければならない。

4.9. Assertion Contents

assertion とは、IdP から RP への声明であり、認証済みのサブスクライバに関する認証イベントの情報と、当該サブスクライバについて、または当該サブスクライバに関連付けられた属性値、派生属性値、属性バンドルの集合を含む。属性情報に加えて、assertion は、assertion メタデータ、IdP におけるサブスクライバの認証に関する情報、その他 RP が活用できる情報（例：制約、有効期間ウィンドウ）など、さまざまなデータで構成される。assertion の主要な機能はユーザを RP に対して認証することだが、assertion で伝達される情報は、複数のユースケース（例：identity proofing、認可、Web site のパーソナライズ）において RP により利用できる。本ガイドラインは、選択された解決策が本書に含まれる必須要件をすべて満たす限り、RP のユースケースや、アイデンティティをフェデレートするために用いられるプロトコルまたはデータペイロードの種類を制限しない。

assertion は、IdP におけるサブスクライバの個別の認証イベントを表さなければならず、また RP においても個別の認証イベントとして処理されなければならない。

すべての assertion は、次の属性を含まなければならない。

Issuer identifier：assertion の発行者（すなわち IdP）の識別子。
Audience identifier：assertion の消費者として意図される当事者（すなわち RP）の識別子。FAL1 では、assertion は複数の Audience identifier を含み得る。
Issuance time：IdP が assertion を発行した時刻を示すタイムスタンプ。
Validity time window：当該期間の外では、サブスクライバを認証し RP で authenticated session を開始する目的において、RP が assertion を有効として受け入れてはならない期間。これは通常、発行時刻のタイムスタンプに加え、assertion の失効時刻のタイムスタンプによって伝達される。
Assertion identifier：この assertion を一意に識別する値であり、攻撃者が過去の assertion をリプレイするのを防ぐために用いられる。
Authentication time：IdP が一次の認証イベントを通じて、IdP においてサブスクライバの存在を最後に検証した時刻を示すタイムスタンプ。
Signature：assertion 全体を対象とするデジタル署名または MAC（検証鍵識別子を含む）。

RP subscriber account が ephemeral provisioning プロセスを使用しない場合、サブスクライバは、フェデレーテッド識別子（Sec. 3.4 参照）または account resolution プロセス（Sec. 3.8.2 参照）により、assertion 内で識別されなければならない。

サブスクライバがフェデレーテッド識別子で識別される場合、assertion は次を含まなければならない。

Subject Identifier：assertion が適用される当事者（すなわちサブスクライバ）の識別子

フェデレーション取引の次の側面は、assertion の内容に含まれる情報、または適用される trust agreement を通じて提供されなければならない。

IAL、および identity proofing プロセス中に用いられた検証の種類（例：バイオメトリクス、住所検証）、サブスクライバアカウントを確立するために用いられた identity proofing プロセスの指示、または IAL を主張しないことの指示
サブスクライバが IdP に対して認証した際に用いられた AAL、または AAL を主張しないことの指示
assertion が表すフェデレーションプロセスについて、IdP が意図する FAL

利用可能であれば、assertion は IdP における認証方法について追加情報を含むべきである（例：使用されたオーセンティケータが phishing-resistant であるかどうか）。情報を担う技術には、Vectors of Trust（RFC8485）や、OIDC および SAML における authentication class references などがある。

FAL2 以上では、assertion は次を含まなければならない。

Nonce：RP のフェデレーション要求に含まれる暗号学的 nonce

FAL3 では、assertion は次のいずれかを含まなければならない。

holder-of-key assertion の公開鍵、鍵識別子、またはその他の識別子、または
この assertion を処理するために bound authenticator の検証が必要であることを示す指示。

assertion はサブスクライバ認証シークレット（例：パスワード）を含んではならない。

assertion は、次を含む追加項目も含めてよい。

属性値および派生属性値：サブスクライバに関する情報
属性バンドル：CSP からの署名付きバンドルにおける属性の集合
サブスクライバアカウント：IAL を得るために用いられた制御の集合など、サブスクライバアカウントに関する追加詳細
属性メタデータ：NISTIR8112 で述べるものなど、1 つ以上のサブスクライバ属性に関する追加情報
認証イベント：使用されたオーセンティケータのクラスなど、認証イベントに関する追加詳細

RP は、次のすべてが真であることを確認することで assertion を検証しなければならない。

Signature validation：assertion の署名が有効であり、かつその署名が、assertion を送っている IdP に属する検証鍵に対応していることを確認する。
Issuer verification：assertion が想定される IdP によって発行されたことを確認する。
Time validation：validity time window が現在のタイムスタンプに対して許容範囲内であることを確認する。
Audience restriction：この RP が assertion の意図された受信者であることを確認する。
Nonce：RP の要求に含まれる暗号学的 nonce（該当する場合）が提示物に含まれていることを確認する。
Transaction terms：assertion が表す IAL、AAL、FAL が適用される trust agreement の下で許容され、かつ RP の必要性に適していることを確認する。
Assertion identifier：assertion が当該 RP において、その validity time window の中でリプレイされていないことを確認する。

フェデレーテッド識別子を用いてサブスクライバを識別する RP は、subject identifiers を IdP をまたいで本質的にグローバル一意であるものとして扱ってはならない。代わりに、assertion の subject identifier の値は、Sec. 3.4 で述べるとおり、assertion の発行者の管理下にある名前空間で処理される。これにより、RP は複数の IdP と連携しても、異なる IdP 由来の subject を誤って同一視しないで済む。

RP へのアイデンティティ属性の開示はすべて trust agreement の条件に従う。Section 3.10 には、assertion に属性を提示する際のプライバシー要件が含まれている。RP は、assertion を受け取る同一の応答内、または別の仕組みにより、identity API への限定的なアクセスを付与されることがある（Sec. 3.12.3 参照）。RP はこの API を用いて、assertion 自体には含まれないサブスクライバの追加のアイデンティティ属性を取得できる。これらの属性も trust agreement の条件に従う。

assertion の validity time window は、発行時刻から失効時刻までの時間である。このウィンドウは、RP が assertion を処理しサブスクライバのローカルアプリケーションセッションを作成できるだけ十分に大きい必要があるが、IdP と RP の間の妥当な時計ずれを含め、その確立に必要以上に長くすべきではない。長寿命の assertion は盗難やリプレイのリスクが高く、短い assertion の validity time window はこのリスクを軽減する。assertion の validity time windows を、RP のセッションを制限するために用いてはならない。詳細は Sec. 4.7 を参照。

4.10. Assertion Requests

フェデレーション取引が RP により開始される場合、RP の assertion 要求は次を含まなければならない。

RP の識別子
assertion で返される暗号学的 nonce

RP の要求には、次も追加で含めるべきである。

RP が要求するアイデンティティ属性の集合と、RP における利用目的。これは trust agreement により許可されるものの部分集合である。
IdP における認証イベントに対する要件

フェデレーション取引が IdP により開始される場合（FAL1 では）、これらの要件は適用されない。フェデレーション取引は、FAL2 以上では常に RP により開始される。

4.11. Assertion Presentation

多くのフェデレーションプロトコルでは、RP と IdP は 2 つの方法で相互に通信し、いずれも IdP から RP へ assertion を渡すために用いられる。

back channel：サブスクライバを直接関与させない、RP と IdP の直接接続を通じて
front channel：サブスクライバおよびサブスクライバのブラウザまたはデバイスを含むリダイレクトにより、第三者を介して

それぞれのモデルにはトレードオフがあるが、いずれも assertion の適切な検証を要する。assertion は、Sec. 3.3.3 で詳述するように、異なる提示方式を用いる IdP と RP の間のフェデレーションを容易にするために、プロキシされることもあり得る。

4.11.1. Back-Channel Presentation

Fig. 11 に示す back-channel presentation モデルでは、サブスクライバは、一般に front channel を通じて RP に提示するための assertion reference を与えられる。assertion reference 自体にはサブスクライバに関する情報は含まれず、攻撃者による改ざんおよび捏造に対して耐性を持たなければならない。RP は assertion reference を IdP に提示して assertion を取得する。これを実現する方法は、使用中のフェデレーションプロトコルにより異なる。authorization code flow および OIDC の hybrid flow の一部では、assertion（すなわち ID Token）は、assertion reference（すなわち Authorization Code）と引き換えに back channel で提示される。SAML-Bindings の artifact binding profile では、SAML assertion が back channel で提示される。

Fig. 11. Back-channel presentation

Fig. 11 に示すとおり、back-channel presentation モデルは 3 つのステップで構成される。

IdP は、front channel を通じてサブスクライバに assertion reference を送る。
サブスクライバは、front channel を通じて RP に assertion reference を送る。
RP は、assertion reference と自身の RP の資格情報を back channel を通じて IdP に提示する。IdP は資格情報を検証し、assertion を返す。

assertion reference は次を満たさなければならない。

単一の RP による使用に限定されなければならない。
単回使用でなければならない。
期限付きでなければならず、有効期間ウィンドウは 5 分を超えないことが望ましい。
RP の IdP に対する認証と併せて提示されなければならない。
攻撃者にとって予測可能または推測可能であってはならない。

このモデルでは、RP は assertion を IdP に直接要求するため、サブスクライバを含む第三者による傍受や改変の可能性が最小化される。back-channel 方式は front-channel 方式よりも多くのネットワーク取引を要するが、情報は必要な当事者のみに限定される。RP は自身の要求の結果として IdP から直接 assertion を受け取ることのみを想定するため、攻撃対象領域が縮小される。その結果、assertion を RP に直接注入することがより困難になり、この提示方式は FAL2 以上に推奨される。IdP と RP は既に直接接続されているため、back-channel presentation 方式は Sec. 3.12.3 で述べる identity APIs の利用も容易にする。

（定義上）単一 Audience の assertion reference が multi-audience の assertion になることは技術的には可能だが、起こりにくい。このため、back-channel presentation は実務上、single-audience assertions とともに用いることにほぼ限定される。

IdP からサブスクライバへの assertion reference の伝達、およびサブスクライバから RP への assertion reference の伝達は、authenticated protected channel を介して行われなければならない。RP から IdP への assertion reference の伝達、およびその逆方向の伝達も、authenticated protected channel を介して行われなければならない。

RP は、cross-site scripting (XSS) および cross-site request forgery (CSRF) 対策を用いる、フェデレーション取引の正しい段階以外で提示された assertion references を拒否する、または Sec. 3.11.1 で述べる他の受容された技法を用いることにより、捏造または捕捉された assertion references の注入から自身を保護しなければならない。assertion references が IdP に提示されたとき、IdP は、assertion reference を提示している RP が、assertion reference を生じさせた assertion request を行った同一の RP であることを検証しなければならない。これに関する例は Sec. 9.12 で述べられており、OIDC の authorization code flow に加え、FAPI や iGov などの追加のセキュリティプロファイルを含む。

フェデレーションプロキシ（Sec. 3.3.3 参照）では、上流の IdP は assertion reference と assertion をプロキシに対して audience 制限し、プロキシは、新たに作成する assertion references または assertions を下流の RP に対して制限する。

4.11.2. Front-Channel Presentation

Fig. 12 に示す front-channel presentation モデルでは、IdP が assertion を作成し、サブスクライバの user agent のような第三者を介して RP に送る。implicit flow および OIDC の hybrid flow の一部では、assertion（すなわち ID Token）が front channel で提示される。SAML-WebSSO で定義される SAML Web SSO プロファイルでは、SAML assertion が front channel で提示される。

Fig. 12. Front-channel presentation

front-channel presentation 方式は、IdP と RP 以外の当事者に assertion を露出させ、assertion に含まれる個人情報が漏えいするリスクを増大させる。加えて、assertion が攻撃者に捕捉されリプレイされる攻撃対象領域も増える。その結果、他の仕組みが利用可能な場合、front-channel presentation は推奨されない。

RP は assertion identifier を用いて、特定の assertion がその validity time window の間に高々 1 回だけ提示されることを保証しなければならない。

RP は、XSS および CSRF 対策を用いる、フェデレーション取引の正しい段階以外で提示された assertions を拒否する、または Sec. 3.11.1 で述べる他の受容された技法を用いることにより、捏造または捕捉された assertions の注入から自身を保護しなければならない。

IdP からサブスクライバへの assertion の伝達、およびサブスクライバから RP への assertion の伝達は、authenticated protected channel を介して行われなければならない。

汎用 IdP では、front-channel 通信は HTTP リダイレクトで実現されることが一般的であり、assertion の内容が HTTP リクエスト URL の一部として利用可能になる。HTTP エコシステムの性質により、これらのリクエスト URL は、アクセスログ、Web プロキシ、ブラウザ履歴など、予期しない場所で利用可能になることがある。これらの痕跡は federation transaction をはるかに過ぎても残存し、他の文脈でも利用可能であり、assertion を読み取る攻撃対象領域を増大させる。その結果、HTTP リダイレクトを用いて assertions を front-channel で提示する IdP は、Sec. 3.13.3 で述べるとおり、assertion 内のすべての個人情報を暗号化しなければならない。これらの特性を共有しない他の front-channel presentation 方式（例：HTTP form-post binding、アプリケーション固有 URL）でも、assertion 内のすべての個人情報を暗号化するべきである。

5. Subscriber-Controlled Wallets

このセクションは規範的である。

subscriber-controlled wallet は、Sec. 5.1 で述べるとおり、CSP が属性バンドルの発行によりサブスクライバアカウントの属性を利用可能にする IdP である。サブスクライバは、Sec. 5.4 で述べる activation factor またはオーセンティケータを用いて wallet を有効化する。通常、subscriber-controlled wallet はサブスクライバが管理するデバイス上で動作し、単一のサブスクライバのみを表す。しかし、wallet は、cloud wallet と呼ばれることのある配備パターンで、リモートシステム上にホストされることもある。

5.1. Issuing Attribute Bundles to the Subscriber-Controlled Wallet

CSP が subscriber-controlled wallet に属性バンドルを発行する場合、そのプロセスは次のステップを含まなければならない。

サブスクライバは、CSP の identity proofing プロセスを用いるか、またはサブスクライバアカウントに対して認証することにより、CSP の発行機能に対して自身のアイデンティティを証明する。
サブスクライバは activation factor を用いて wallet を有効化する。これは、ホストされた wallet サービスに対して認証することを伴い得る。
wallet は署名鍵と対応する検証鍵を生成または選択する。wallet は、自身の署名鍵の保有を CSP に対して証明する。
CSP は、サブスクライバ属性と wallet の検証鍵（またはその鍵への参照）を含む 1 つ以上の属性バンドルを作成する。
wallet は、後で RP に提示するために属性バンドルを保管する。

subscriber-controlled wallet は、CSP への各発行要求ごとに異なる署名鍵および検証鍵を生成して使用してよい。

CSP は、要求してきた各 wallet に対して一意の属性バンドルを作成しなければならず、個別の wallet からの各要求ごとに一意の属性バンドルを作成するべきである。

多くの subscriber-controlled wallets は、複数の CSP からの属性バンドルを同時に保持できる。一部の技術では、複数の CSP からの属性バンドルを単一の assertion の中で同時に提示することが可能である。この場合、複数の属性バンドルの主張は、本ガイドラインにおける assertion 要件に適合しなければならない。

5.1.1. Invalidating Attribute Bundles for the Subscriber-Controlled Wallet

CSP は、subscriber-controlled wallet に発行された属性バンドルを無効化する手段を提供しなければならない。このプロセスは、次の場合に用いられる。

サブスクライバアカウントが終了し、その結果下流のフェデレーション行為が無効になる場合
デバイスの紛失、盗難、または侵害により wallet を終了する必要がある場合
属性バンドルが攻撃者に開示される、または他の形で侵害される場合

これを実現するため、CSP は、有効期間ウィンドウが限定された属性バンドルを発行するべきである。CSP は、属性バンドルの状態（すなわち、特定のバンドルが CSP により失効させられたかどうか）を独立に検証する手段を提供するべきである。そのようなサービスが提供される場合、そのサービスは、特定の属性バンドルが特定の RP で使用されたことを CSP が把握できないよう、プライバシーを保全する方式で配備されなければならない。

5.2. Federation Transaction

subscriber-controlled wallet との federation transaction は、サブスクライバアカウントに対する IdP としてサブスクライバのデバイスを確立し、RP におけるサブスクライバの authenticated session を作成する。このプロセスを Fig. 13 に示す。

Fig. 13. Federation with a subscriber-controlled wallet

subscriber-controlled wallet との federation transaction は、複数のステップで行われる。

CSP はサブスクライバの identity proofing を行い、サブスクライバアカウントを作成する。
CSP はサブスクライバアカウントから wallet に属性バンドルを発行する。これは、サブスクライバがサブスクライバアカウント内のオーセンティケータを検証する、または短縮された proofing プロセス（例：proofing 時に取得したバイオメトリクスを用いてアイデンティティを検証する）を完了することを含む。
wallet は CSP から署名付き属性バンドルを受け取り、それにより wallet が IdP として振る舞えるようになる。
RP は、通常はサブスクライバの行為を通じて、wallet にフェデレーテッド認証取引を要求する。
サブスクライバは activation factor を通じて wallet を有効化する。ホストされた wallet の場合、これは wallet サービスに対する認証である。
wallet は、RP の要求、サブスクライバの行為、および wallet が利用可能な属性バンドルに基づいて assertion を作成する。
wallet は assertion を RP に提示する。
RP は assertion を検証し、サブスクライバの authenticated session を作成する。このプロセスには、CSP からの属性バンドルの検証が含まれる。

5.3. Trust Agreements

subscriber-controlled wallet のアーキテクチャおよび設計により、フェデレーテッド取引を支える trust agreements は、汎用 IdP の場合よりも直接的ではない。プライバシー上の結果を維持し、ユーザ取引の追跡を防ぐため、CSP と RP は通常、互いに直接通信しない。次の要件は、すべての subscriber-controlled wallet シナリオに適用される。

サブスクライバ属性の開示は、Sec. 4.6.1.3 で述べるとおり、wallet が管理する実行時判断を用いて管理されなければならない。
承認された当事者はサブスクライバでなければならない。
次の条件は、実行時判断の際にサブスクライバへ開示されなければならない。
- RP が要求するサブスクライバ属性、派生属性、属性バンドルの集合（利用可能とされる属性の部分集合）
- RP が要求する各属性の目的

RP が要求する xALs も、実行時にサブスクライバへ開示してよい。

サブスクライバに開示されるすべての情報は、Sec. 8 で述べるとおり、理解可能で行動に移せる形で伝えられる必要がある。

5.3.1. CSPs and RPs

subscriber-controlled wallet シナリオにおける CSP と RP の間の trust は、通常は双方向ではない。一般的なケースでは、RP は、federation transaction 中に subscriber-controlled wallets が提示する属性バンドルの情報源として CSP を信頼する一方、CSP は RP を直接把握していることは期待されない。この RP と CSP の間の trust 関係は、エコシステムの構成員（RP、CSP、subscriber-controlled wallets）を代表する包括的な trust agreements を定義する federation authority（Sec. 3.5.2 参照）により補助され得る。そうした trust agreements は次を含まなければならない。

CSP が属性バンドルにおいて wallet に利用可能とするサブスクライバ属性および派生属性の集合
wallet が RP に利用可能とできるサブスクライバ属性および派生属性の集合
CSP が表現できるサブスクライバアカウントの母集団
CSP からの属性バンドルに関連付けられるサブスクライバアカウントの IAL または発行プロセス
CSP の属性バンドル発行に関連する発行プロセス
subscriber-controlled wallets がサポートする FALs
RP が要求し得る各属性の許容される目的
属性バンドルを通じて提供されるサブスクライバデータの保護および管理に関する RP の期待事項

trust は、RP が CSP とその属性バンドル発行プロセスに関する公開情報を評価することにより、一方向に確立してよい。これを容易にするため、CSP は、RP が評価できるよう、信頼できる場所に次の情報を公開しなければならない。

CSP が属性バンドルにおいて wallet に利用可能とするサブスクライバ属性および派生属性の集合
wallet が RP に利用可能とできるサブスクライバ属性および派生属性の集合
CSP が表現できるサブスクライバアカウントの母集団
CSP の属性バンドルに関連付けられるサブスクライバアカウントの IAL または発行プロセス

これらの情報は、CSP の属性バンドル発行を評価し、discovery サービスを通じて CSP の機能を利用可能とする federation authority のような信頼できる第三者により提供してよい。

RP と CSP の間の trust は、事前確立型（Sec. 4.3.1 参照）またはサブスクライバ主導型（Sec. 4.3.2 参照）のいずれかの方法で実現してよい。例えば、RP は、特定の CSP の集合からの属性バンドルのみを自らの目的のために受け入れるよう静的に構成できるし、あるいは、実行時にサブスクライバへ同意を求めることにより、任意の CSP からの属性バンドルを受け入れてもよい。この trust 関係はまた、属性バンドルの検証を超えて、CSP により承認された subscriber-controlled wallet 識別子を検証する手段（例：federation authority を通じて提供される discovery サービス）を RP に提供することで、より明示的にもできる。

5.3.2. CSPs and Subscriber-Controlled Wallets

CSP と subscriber-controlled wallets の間の trust 関係は、常に直接的な性質を持つ。したがって、CSP と、CSP が属性バンドルを発行する subscriber-controlled wallets の間には trust agreement が存在しなければならない。この trust agreement は、少なくとも次を含まなければならない。

CSP が属性バンドルにおいて wallet に利用可能とするサブスクライバ属性および派生属性の集合
wallet が RP に利用可能とできるサブスクライバ属性および派生属性の集合
subscriber-controlled wallet が属性バンドルの発行を支援するために実装する必要がある任意のプロセス（例：PAD、データ収集、リスクスコアリング）
wallet サービスのデータ保管およびセキュリティ運用
任意の assertion の生成に先立ち、サブスクライバが wallet サービスへアクセスするために使用する activation factors または AALs
subscriber-controlled wallets がサポートする FALs
RP への属性開示に関連して wallet が強制する必要がある許容される目的、または任意の制約

5.3.3. RPs and Subscriber-Controlled Wallets

subscriber-controlled wallet シナリオにおける trust の主要な拡張は、RP が CSP による属性バンドルおよびその発行プロセスを評価することによって行われる。しかし、wallet は、CSP により署名された属性バンドルを含む assertions において RP に提示される情報を、RP がどの程度信頼するかにおいて重要な役割を果たす。

subscriber-controlled wallet の機能および能力に関する情報は、RP が特定の取引をどの程度信頼するかを判断する助けとなる。この情報は、属性バンドルを提示するサブスクライバが、その属性バンドルが表す個人であるという確信を示し得る。例えば、wallet がサブスクライバをローカルでどのように認証するか、検証鍵をどのように保護するか、CSP または RP が示す trust agreement の要件をどのように強制するかといった情報はすべて、RP のフェデレーションおよびアクセス判断の改善を支える。したがって、subscriber-controlled wallets は、次を RP に開示しなければならない。

assertion の提示前にサブスクライバを認証するために使用する有効化または認証方式
wallet が属性バンドルを保護する方法に関するセキュリティ機能
鍵管理に関する情報
subscriber-controlled wallet のソフトウェア完全性に関する指示

これらの情報は、実行時または wallet メタデータの discovery メカニズムを通じて提供してよい。このトピックの詳細は Sec. 5.8 を参照。

5.3.4. FAL3 for Subscriber-Controlled Wallets

subscriber-controlled wallet からの assertion は常に、CSP からの署名付き属性バンドル内に wallet の検証鍵の 1 つへの参照を含むため、サブスクライバが管理するデバイス上で動作する subscriber-controlled wallets は、holder-of-key assertions のすべての要件が満たされる場合（Sec. 3.15 参照）、holder-of-key assertions を発行できる能力を持つ。これらの assertions は、FAL3 のすべての要件が満たされる場合（Sec. 2.4 参照）、FAL3 に到達するために用いてよい。

ホストされたサービス上の subscriber-controlled wallet の検証鍵は、サブスクライバが鍵素材を（サブスクライバ管理デバイスの場合のように）管理していないため、それ単独では holder-of-key assertions の要件を満たさない。FAL3 に到達するため、ホストされたサービス上の subscriber-controlled wallet との federation transactions は、holder-of-key assertion（Sec. 3.15 参照）または bound authenticator（Sec. 3.16 参照）のいずれかを用いなければならない。Sec. 2.4 における FAL3 のすべての要件が満たされなければならない。例えば、ホストされたサービス上の subscriber-controlled wallet からの holder-of-key assertion は、wallet の検証鍵とは別のオーセンティケータの検証鍵を含み得る。サブスクライバは、この追加のオーセンティケータを、wallet の assertion とともに RP に提示することになる。

5.4. Wallet Activation

subscriber-controlled wallet は、wallet の署名鍵から署名付きアーティファクトが作成される次の行為について、サブスクライバから activation factor の提示を求めなければならない。

発行プロセス中に、wallet の署名鍵の保有証明を CSP に提示すること
RP に提示するための assertion に署名すること

subscriber-controlled wallet は、wallet の署名鍵から署名付きアーティファクトが作成されるその他のすべての操作の前にも、activation factor の提示を求めるべきである。例えば、AAL2 以上で wallet をオーセンティケータとして使用するには、SP800-63B の Sec. 3.2.10 に従い activation factor の提示が必要である。

wallet は、サブスクライバの関与を要求せずに、同一の CSP から過去に発行された属性バンドルの再発行を要求してよい。

サブスクライバが管理するデバイス上で動作する subscriber-controlled wallets については、activation factor の提出は、ホストデバイス（例：スマートフォン）のロック解除とは別の操作でなければならない。ただし、ホストデバイスのロック解除に用いるものと同一の activation factor を、有効化操作で用いることは許される。組織は、CSP により、または CSP を代表して管理され（例：モバイルデバイス管理を通じて）、かつ、短い（組織が定めた）非アクティブタイムアウトおよび上記要件を満たすデバイス activation factors を持つよう制約されている subscriber-controlled wallets について、この要件を緩和してよい。オーセンティケータの activation factors に関する追加の議論は、SP800-63B の Sec. 3.2.10 にある。

リモートサービス上でホストされる subscriber-controlled wallets については、wallet の有効化は wallet サービスに登録されたオーセンティケータを用いて行われる。このオーセンティケータは、CSP におけるサブスクライバアカウントにバインドされているものとは別であってよい。

5.4.1. Key Storage

assertion への署名に使用される鍵は、デバイス間で同期または共有されてはならず、wallet 実装は Sec. 3.6.2 で述べるとおり、非エクスポート可能な鍵保管を用いるべきである。

wallet の署名鍵が FAL3 の holder-of-key オーセンティケータとして使用される場合、その鍵は Sec. 3.6.2 で述べるとおり、非エクスポート可能な鍵保管に格納されなければならない。

5.5. Discovery and Registration

subscriber-controlled wallet と federation transaction を実行するため、RP はまず、trust agreement により定められた安全なプロセスを通じて CSP の属性バンドル検証鍵を特定しなければならない。一部のシステムでは、これは CSP により管理されていることが知られている URL から CSP の属性バンドル検証鍵を取得することで達成される。別のシステムでは、配備前に RP に対して CSP の検証鍵が手動で設定される。複数者間 trust agreements により統制されるシステムでは、このプロセスは、federation authority により提供されるような第三者の discovery および registration サービスにより支援され得る。

署名付き属性バンドルには、バンドルを発行した CSP と、subscriber-controlled wallet に関連付けられた 1 つ以上の検証鍵が含まれる。RP は、CSP が subscriber-controlled wallets に属性バンドルを発行するプロセスを信頼しているため、subscriber-controlled wallet の署名鍵の 1 つの保有証明を用いて作成されたこれらのバンドルの提示を信頼できる。

多くの場合、RP が subscriber-controlled wallet に登録するプロセスは、federation transaction の間に RP がその鍵とメタデータを IdP と交換する動的プロセスになることが想定される。subscriber-controlled wallet の性質上、特定の RP が wallet のインスタンスに事前登録することは困難だが、trust agreement に定められた信頼できる第三者を用いることで支援できる。

フェデレーションを行おうとする当事者は、trust agreement に当該信頼できる第三者が特定されている場合、discovery と registration のプロセスを支援するためにその第三者を用いてよい。例えば、あるエコシステムに discovery と registration を管理する集中サービスがあるとする。RP がエコシステムに参加する際、RP は信頼できるサービスに自らを登録し、CSP の検証鍵をダウンロードし、wallet と用いるための識別子を受け取る。CSP が subscriber-controlled wallet に属性バンドルを発行する際、subscriber-controlled wallet には、エコシステム内の有効な RP 識別子の一覧をどこで見つけられるかが通知される。RP が wallet に接続する際、wallet は、RP が wallet に直接登録しなくても、RP の識別子を検証できる。同様に、RP は、wallet の検証鍵または識別子に対する CSP の署名を検証することで、wallet の検証鍵を信頼できる。

5.6. Authentication and Attribute Disclosure

federation transaction を進行させるかどうか、ひいては assertion が発行され属性が RP に開示されるかどうかの判断は、承認された当事者の役割で行動するサブスクライバにより決定されなければならない。この判断は、設定されたポリシーおよび trust agreements に基づいて wallet がサブスクライバの判断を支援できるよう、allowlists および blocklists の利用により補強してよい。subscriber-controlled wallet は、同一の RP における将来の行為のために、サブスクライバから別途の承認を得ずに済むよう、サブスクライバの判断を記憶してよい。保存された承認判断の利用は、Sec. 5.4 で述べる wallet activation の要件に優先するものではない。

subscriber-controlled wallet は、承認された当事者（すなわちサブスクライバ）による開示判断を記憶し、同一の RP からの将来の要求に適用するための仕組みを提供してよい。そのような仕組みが提供される場合、subscriber-controlled wallet は、保存の仕組みが使用中であることを承認された当事者に開示しなければならず、また、承認された当事者が将来その記憶されたアクセスを取り消せるようにしなければならない。

subscriber-controlled wallet は、CSP からの属性バンドルに含まれる属性の部分集合を選択的に開示できる手段を提供するべきである。

CSP は、サブスクライバの苦情または問題（例：サブスクライバが不正確な属性値を特定する、subscriber-controlled wallet に過去に発行された属性バンドルを無効化する必要がある）に対する、安全かつ有効な救済手段を提供しなければならない。救済メカニズムに関する追加の要件と考慮事項は Sec. 3.5.3 を参照。

5.7. Assertion Requests

フェデレーション取引が RP により開始される場合、RP の assertion 要求は次を含まなければならない。

RP の識別子
暗号学的 nonce
RP が要求するアイデンティティ属性、派生属性、属性バンドルの集合と、RP における利用目的

フェデレーション取引が IdP により開始される場合（FAL1 では）、これらの要件は適用されない。フェデレーション取引は、FAL2 以上では常に RP により開始される。

5.8. Assertion Contents

subscriber-controlled wallet からの assertion は次を含まなければならない。

CSP からの署名付き属性バンドル
Audience identifier：assertion の消費者として意図される当事者（すなわち RP）の識別子
Issuance time：wallet が assertion を発行した時刻を示すタイムスタンプ
Validity time window：当該期間の外では、サブスクライバを認証し RP で authenticated session を開始する目的において、RP が assertion を有効として受け入れてはならない期間。これは通常、発行時刻のタイムスタンプに加え、assertion の失効時刻のタイムスタンプによって伝達される。
Assertion identifier：この assertion を一意に識別する値であり、攻撃者が過去の assertion をリプレイするのを防ぐために用いられる。例えば、wallet が生成し assertion に含める一意の nonce とできる。
Signature：非対称暗号を用いたデジタル署名であり、assertion 全体を対象とするもの

assertion は次を含めてよい。

Subject identifier：assertion が適用される当事者（すなわちサブスクライバ）の識別子
Issuer identifier：assertion の発行者（すなわち subscriber-controlled wallet）の識別子

フェデレーション取引の次の側面は、assertion の内容に含まれる情報、または適用される trust agreement を通じて提供されなければならない。

assertion で表されるサブスクライバアカウントの IAL、発行プロセスの指示、または IAL を主張しないことの指示
wallet を有効化するために用いられる activation method の性質
assertion が表すフェデレーションプロセスについて、wallet が意図する FAL

subscriber-controlled wallet がリモートサービスとしてホストされる場合、ホストされた wallet サービスにおけるサブスクライバの現在のセッションの AAL は、assertion の内容に含まれる情報、または適用される trust agreement を通じて提供されなければならない。この場合、利用可能であれば、assertion は IdP における認証方法について追加情報を含むべきである（例：使用されたオーセンティケータが phishing-resistant であるかどうか）。この情報を担う技術には、Vectors of Trust（RFC8485）や、OIDC および SAML における authentication class references などがある。

FAL2 以上では、assertion は次を含まなければならない。

Nonce：RP のフェデレーション要求に含まれる暗号学的 nonce

FAL3 では、assertion は次のいずれかを含まなければならない。

holder-of-key assertion の公開鍵、鍵識別子、またはその他の識別子。これは、subscriber-controlled wallet が assertion に署名するために使用するのと同一の鍵であってよい。
この assertion を処理するために bound authenticator の検証が必要であることを示す指示。

assertion はサブスクライバ認証シークレット（例：パスワード）を含んではならない。

CSP からの署名付き属性バンドルは次を含まなければならない。

Keys：subscriber-controlled wallet が assertion に署名するために使用する鍵の検証鍵、または鍵識別子
Issuer identifier：属性バンドルの発行者（すなわち CSP）の識別子
Issuance time：CSP が属性バンドルを発行した時刻を示すタイムスタンプ
IAL：属性バンドルで表されるサブスクライバアカウントの IAL を示す指示、または IAL を主張しないことの指示
Signature：非対称暗号を用いたデジタル署名であり、属性バンドル全体を対象とするもの
Attribute values and derived attribute values：サブスクライバに関する情報

RP subscriber account が ephemeral provisioning プロセス（Sec. 4.6.5 参照）または account resolution プロセス（Sec. 3.8.2 参照）を使用しない場合、サブスクライバは、フェデレーテッド識別子（Sec. 3.4 参照）を用いて assertion の中で識別されなければならない。issuer identifier は署名付き属性バンドルを発行した CSP のものでなければならず、subject identifier は署名付き属性バンドルに含まれ、属性バンドルを発行した CSP の名前空間で処理されなければならない。

CSP からの署名付き属性バンドルは validity time window を含むべきである。これは、当該期間の外では、サブスクライバを認証し RP で authenticated session を開始する目的において、RP が属性バンドルを有効として受け入れてはならない期間として定義される。これは通常、発行時刻のタイムスタンプに加え、属性バンドルの失効時刻のタイムスタンプによって伝達される。

CSP からの署名付き属性バンドルは、IAL を決定するために用いられた制御の集合など、サブスクライバアカウントに関する追加情報を含めてよい。

追加のアイデンティティ属性および派生属性値を属性バンドルに含めてよい。これらの属性は、基盤となる属性バンドルがそのような方法を提供する場合、選択的開示方式を用いて RP に利用可能とされなければならない。選択的開示では、属性の全体集合ではなく部分集合が開示される。これは、RP が定義する取引完了に必要な最小集合により駆動される場合もあれば、実行時にサブスクライバが選択することで駆動される場合もある。

assertion に含まれるが署名付き属性バンドルの外側にあるアイデンティティ属性は、自己主張（self-asserted）と見なされなければならない。RP は、これらの追加属性を自身の検証プロセスを用いて検証してよい。

5.9. Assertion Presentation

assertion は authenticated protected channel を通じて RP に提示されなければならない。

提示には、RP の要求に暗号学的 nonce が含まれている場合、その nonce を含めなければならない（これは FAL2 以上で必須である）。RP は、フェデレーションプロトコルに従い nonce を検証しなければならない。

提示の仕組みが wallet または RP 以外のコンポーネントを経由して assertion を渡す場合、assertion 内の個人情報は Sec. 3.13.3 で述べるとおり、wallet により RP の暗号化鍵を用いて暗号化されるべきである。

プライバシーを強化するため、提示の仕組みは、異なる RP 間でサブスクライバおよびその情報のリンク可能性を排除できる機能を提供するべきである。

RP は、XSS および CSRF 対策を用いる、フェデレーション取引の正しい段階以外で提示された assertions を拒否する、または Sec. 3.11.1 で述べる他の受容された技法を用いることにより、捏造または捕捉された assertions の注入から自身を保護しなければならない。可能な場合、サブスクライバが管理するデバイス上で動作する subscriber-controlled wallets は、assertion を RP に届ける際、HTTP リダイレクトではなくプラットフォーム API を用いるべきである。

5.10. Assertion Validation

RP は、CSP からの検証鍵を用いて、assertion 内のすべての署名付き属性バンドルの署名を検証しなければならない。RP は、署名付き属性バンドルに含まれる subscriber-controlled wallet の検証鍵を用いて、assertion の署名を検証しなければならない。

RP は、次のすべてが真であることを確認することで assertion を検証しなければならない。

Bundle verification：バンドルが、RP に assertion を提示している wallet に対して発行されたことを確認する。
Issuer verification：RP が特定の wallet を要求している場合、assertion が要求された wallet により発行されたことを確認する。
Time validation：validity time window が現在のタイムスタンプに対して許容範囲内であることを確認する。
Audience restriction：この RP が assertion の意図された受信者であることを確認する。
Nonce：RP の要求に含まれる暗号学的 nonce が提示物にも含まれていることを確認する。
Transaction terms：assertion が表す IAL、AAL、FAL が適用される trust agreement の下で許容され、かつ RP の必要性に適していることを確認する。
Assertion identifier：wallet が提供する nonce など、取引固有の assertion identifier を検証することにより、assertion が当該 RP において、その validity time window の中でリプレイされていないことを確認する。

さらに、CSP が属性バンドルを無効化するための仕組みを提供している場合、RP は、Sec. 5.1.1 で述べるとおり、その仕組みを用いて、属性バンドルが発行以降に CSP により無効化されたかどうかを判断するべきである。この検証の仕組みは、有効期間が長い、または不定の属性バンドルに特に適している。なぜなら、CSP による能動的な無効化は、属性バンドルの失効よりもはるかに前に起こり得るためである。

5.11. RP Subscriber Accounts

subscriber-controlled wallets に想定されるアーキテクチャおよび trust agreements により、RP subscriber account は just-in-time または ephemeral provisioning モデル（Sec. 4.6.3 参照）で管理される可能性が高い。これらのいずれの場合も、RP は wallet からの assertion を正常に検証した後、RP subscriber account を作成し、それを（利用可能であれば）フェデレーテッド識別子に関連付ける。pre-provisioning モデルも使用できる。例えば、RP が確立された account linking プロセス（Sec. 3.8.1 参照）を持ち、既知の一意属性または属性集合を用いて wallet ベースのアイデンティティを既存アカウントにリンクできる場合である。

wallet ベースの属性バンドルを使用する多くの RP では、Sec. 3.8.2 で述べるとおり、RP は account resolution プロセスを用いて、属性バンドル内の情報を RP における機能の集合へリンクする。RP subscriber account が ephemeral ではなく、かつフェデレーテッド識別子が存在する場合、RP は、subscriber-controlled wallet により提示されたフェデレーテッド識別子を RP subscriber account に関連付け、同一サブスクライバに対する将来のフェデレーション取引でそのフェデレーテッド識別子を使用するべきである。フェデレーテッド識別子が存在しない場合（例：mDL の場合）、RP は、各フェデレーション取引のたびに、サブスクライバを RP subscriber account に解決するために必要な属性を要求する必要がある。この属性集合は、正確な解決を達成するために必要な最小限のものでなければならない。複数のフェデレーテッド識別子へのリンクは、Sec. 3.8.1 で述べるとおり管理されなければならない。

RP は、サブスクライバ情報の管理に関する運用を trust agreement の一部として開示しなければならない。RP は、RP subscriber account 内の情報を訂正するための有効な救済手段をサブスクライバに提供しなければならない。救済メカニズムに関する追加の要件と考慮事項は Sec. 3.5.3 を参照。

6. Threats and Security Considerations

このセクションは参考情報である。

フェデレーテッド認証プロセスは、CSP、IdP、RP を含む複数のコンポーネント間の協調を伴うため、攻撃者がフェデレーテッドアイデンティティ取引を侵害する追加の機会が存在し、また、攻撃が成功した場合の追加の影響も生じる。本セクションは、フェデレーションに適用可能な攻撃と緩和策の多くを要約する。

6.1. Federation Threats

非フェデレーションの認証と同様に、攻撃者の動機は通常、RP が提供するリソースまたはサービスへのアクセス（またはより高いレベルのアクセス）を得ることである。攻撃者はサブスクライバになりすますことも試み得る。不正または侵害された IdPs、RPs、user agents（例：ブラウザ）、および典型的な federation transaction の外側にいる当事者が、潜在的な攻撃者である。攻撃を達成するため、攻撃者は assertions および assertion references を傍受または改変し得る。さらに、2 つ以上のエンティティが、assertion データの完全性または機密性を直接侵害することでフェデレーションプロトコルを覆そうとする場合もある。これらのタイプの脅威については、権限を超えようとするあらゆる承認された当事者は攻撃者と見なされる。

フェデレーテッドシステムでは、IdP に対する攻撃が、その IdP にアイデンティティおよびセキュリティ情報を依存している RP へ伝播し得る。その結果、ある機関の RP を標的とする IdP への攻撃は、別の機関の RP へ横展開する可能性がある。これらの攻撃を緩和するため、RP は、悪意のある、または侵害されたアカウントを特定するために、独立した監視および脅威評価能力を維持する必要がある。さらに、適切なプライバシー制御を備えた情報共有または shared signaling の能力を維持することは、IdP や CSP、ならびに影響を受け得る他の RP における調査および是正を促進し得る。

CSP 間、および単一の CSP 内のサブスクライバアカウント間での identity proofing 運用の逸脱は避けられない。CSP と IdPs は、各アカウントに適用された制御に関する情報を伝達する能力を維持し、適切な場合に RP の判断および調査を支援する必要がある。

Table 3. Federation threats

フェデレーションの脅威／攻撃	説明	例
Assertion Manufacture or Modification	攻撃者が偽の assertion を生成する	侵害された IdP が、適切に認証されていないクレーム者のアイデンティティを主張する
	攻撃者が既存の assertion を改変する	侵害されたプロキシが認証 assertion の AAL を変更する
Assertion Disclosure	assertion が第三者に可視となる	ネットワーク監視により、サブスクライバの登録住所が外部の当事者に明らかになる
Assertion Repudiation by the IdP	IdP が後になって取引に署名していないと主張する	ユーザが RP で不正なクレジットカード取引を行い、IdP がログイン記録がないと主張する
Assertion Repudiation by the Subscriber	サブスクライバが取引を行っていないと主張する	ユーザ合意（例：契約）を強制できない
Assertion Redirect	assertion が意図しない文脈で使用され得る	侵害された user agent が assertion を攻撃者に渡し、攻撃者が別の場所でそれを使用する
Assertion Reuse	同一の RP に対して assertion が複数回使用され得る	傍受された assertion が、攻撃者により自身のセッションを認証するために使用される
Assertion Substitution	攻撃者が別のサブスクライバ向けの assertion を使用する	IdP と RP の間でセッションハイジャック攻撃が起きる
Revoked or Stale Attributes	攻撃者が RP の属性利用を悪用する	失効したメールアドレスを含む属性バンドルが RP に提示され、攻撃者がそのメールアドレスを RP で利用できるようになる

6.2. Federation Threat Mitigation Strategies

Sec. 3.11 で論じたセキュリティ制御に加え、上記の脅威の緩和に資する仕組みが Table 4 に示されている。

Table 4. Mitigating federation threats

フェデレーションの脅威／攻撃	脅威緩和メカニズム	規範参照
Assertion Manufacture or Modification	IdP で assertion に暗号学的署名を行い、RP で検証する	3.5, 3.12.2
	IdP を認証する authenticated protected channel を介して assertion を送る	4.11
	推測不可能なランダム識別子を assertion に含める	3.12.1
Assertion Disclosure	RP を認証する authenticated protected channel を介して assertion を送る	4.9, 5.8
	特定の RP のために assertion を暗号化する（mutually authenticated protected channel により達成され得る）	3.12.3
Assertion Repudiation by the IdP	不否認を支える署名鍵で IdP が assertion に暗号学的署名を行い、RP が署名を検証する	3.12.2
Assertion Repudiation by the Subscriber	holder-of-key assertions または bound authenticators を持つ assertions を発行する。オーセンティケータの保有証明が、サブスクライバの関与を RP に対して検証する	3.14, 3.15
Assertion Redirect	assertion が発行された先の RP のアイデンティティを署名された内容に含める。RP が自分が意図された受信者であることを検証する	3.12.4
Assertion Reuse	assertion の署名対象内容に、短い有効期間を伴う発行タイムスタンプを含める。RP が期間を検証する	4.9, 5.8
	RP が、設定可能な時間ウィンドウ内で消費された assertions を追跡し、特定の assertion が 1 回を超えて使用されないことを保証する	3.12.1
Assertion Substitution	assertions に、RP により要求へ暗号学的にバインドされた assertion request への参照、またはその他の nonce を含めることを保証する	4.9, 5.8
	要求と同じ authenticated protected channel で assertions を送る（例：back-channel presentation）	4.11.1
Revoked or Stale Attributes	有効な time windows を持つ新しい assertions を保証する	4.9, 5.8
	assertions とは独立に属性バンドルの有効性を確認できるようにする	5.1.1

7. Privacy Considerations

このセクションは参考情報である。

7.1. Minimizing Tracking and Profiling

フェデレーションは RP とサブスクライバに多くの利点をもたらすが、サブスクライバがフェデレーション参加者を信頼できることを要する。Section 3 および Sec. 3.4.1 は、追跡およびプロファイリング能力の増大から生じるプライバシーリスクを最小化することを目的とする、複数の技術要件を扱っている。例えば、サブスクライバが同じ IdP を用いて複数の RP に認証すると、IdP は、フェデレーションがなければ存在しなかったサブスクライバ取引のプロファイルを構築できる。そうしたデータが利用可能であることは、サブスクライバにより予期されない、または望まれない利用に対して脆弱にし、フェデレーテッドサービスの採用をサブスクライバが控える要因になり得る。

Section 3.10 は、Sec. 3.10.1 に列挙された目的以外のために属性を処理することにより生じ得るプライバシーリスクに見合う形で、IdPs が予測可能性（すなわち、個人・所有者・運用者が、個人情報とその情報システムによる処理について信頼できる前提を置けるようにすること）および管理可能性（すなわち、変更、削除、選択的開示を含む個人情報の粒度の細かい管理を可能にすること）の目的を維持するための措置を用いることを求める。

IdPs は、サブスクライバに non-identity services を提供することを含め、属性を処理するためのさまざまな事業目的を持ち得る。しかし、元の収集目的と異なる目的で属性を処理することは、個人が追加処理を想定していない、またはそれに抵抗がある場合に、プライバシーリスクを生じさせ得る。IdPs は、追加処理から生じるプライバシーリスクに見合う適切な措置を決定できる。例えば、適用される法律、規制、またはポリシーがない場合、サブスクライバが要求した non-identity services を提供するために属性を処理する際、同意取得が必須ではない場合があるが、通知は、処理に関する信頼できる前提（すなわち予測可能性）をサブスクライバが維持する助けになり得る。属性のその他の処理は、同意取得や、特定の属性の利用または開示についてサブスクライバにより多くの制御を与えること（すなわち管理可能性）を要する、異なるプライバシーリスクを伴い得る。サブスクライバの同意は意味のあるものである必要がある。したがって、IdPs が同意措置を用いる場合でも、追加利用への受諾を、identity service の提供条件にすることはできない。

提案された処理が、許可された処理の範囲外に当たるかどうか、または適切なプライバシーリスク緩和措置が何かについて疑問がある場合は、SAOP に相談すること。

holder-of-key assertions が FAL3 で使用される場合、同一のオーセンティケータが通常 IdP と RP の両方で使用される。この技術要件を満たせるオーセンティケータでは、同一のオーセンティケータがさらに複数の RP で使用される可能性が高い。さらに、無関係な RP が同一のオーセンティケータを直接認証に使用することもあり得る。そうしたすべての RP は、共謀して、ネットワークを通じてサブスクライバを追跡するために、同一オーセンティケータの利用を当事者間で開示し得る。これは、per-provider identifiers が使用されている場合でも、オーセンティケータが assertion とは別に識別可能であり得るため同様である。加えて、holder-of-key assertions に適した多くのオーセンティケータは、assertion や identity API とは別に、オーセンティケータ出力の一部として送信されるアイデンティティ属性を含む。これらの追加属性は、フェデレーションプロトコル内にない場合でも、プライバシーリスク評価の対象としなければならない。

Section 3.10 はまた、NISTIR8062 で述べる disassociability（すなわち、システムの運用要件を超えて個人またはデバイスに関連付けることなく、個人情報またはイベントを処理できるようにすること）を提供し、サブスクライバ活動の追跡およびプロファイリングを防ぐための技術的措置の利用を推奨する。Sec. 3.3.3 で述べる proxied federation や、Sec. 3.4.1 で述べる pairwise pseudonymous identifiers などの技術的措置は、運用要件を超えた追跡やプロファイリングをより困難にすることで、ポリシーの有効性を高め得る。しかし、これらの措置にも限界があり、サブスクライバ属性、統計的な人口統計、その他 IdP と RP の間で共有される種類の情報に基づいて追跡が起こり得る。

属性バンドルは発行元 CSP へ追跡可能であるため、この技術を用いると、属性がどこから発行されたかに基づいて、異なる wallets および RPs をまたいでサブスクライバを追跡できてしまう可能性がある。属性バンドル発行者を単一の発行当局にまとめることで、RP に対して属性の最終的な出所を不明瞭にする代償と引き換えに、属性ソースの開示リスクを低減できる。ゼロ知識証明や 1 回限り利用の属性バンドルといった技術は、属性バンドルのプライバシーをさらに強化し得る。

不正の影響を受けやすいエンタープライズシステムやサービスなどの一部ユースケースでは、特に高い IAL において、システムを保護する手段としてサブスクライバの現実世界のアイデンティティを追跡することが想定される。どの情報が送信されるのかをサブスクライバに知らせ教育し、サブスクライバがその情報を確認できるようにすることは、IdP と RP の責任である。

フェデレーションに対するサブスクライバの信頼を築くため、サブスクライバは、自身の情報がどのように処理されるかについて信頼できる前提を形成できる必要がある。例えば、どの情報が送信されるのか、取引に必要な属性と任意の属性がどれかを理解できること、任意の属性を RP に送るかどうかをサブスクライバが決められることは有用である。これに応じて、Sec. 3.5 は、サブスクライバに関する属性が任意の RP に送信される前に、承認された当事者からの積極的な確認を得ることを要求する。

複数の RP が shared pairwise pseudonymous identifier（Sec. 3.4.1.3 参照）を共有すべきタイミングを判断する際、trust agreement は、サブスクライバがそのような RP のグルーピングをどう理解するかを考慮し、その理解を助けるための有効な通知の手段を提供する。有効な通知では、ユーザ体験設計の標準や研究に加え、情報処理から生じ得るプライバシーリスクの評価が考慮される。考慮すべき要因は多岐にわたり、処理に関してサブスクライバが持ち得る前提の信頼性や、フェデレーションに関与する異なるエンティティの役割などが含まれる。しかし、複雑で法律的なプライバシーポリシーへのリンクや、相当数のサブスクライバが読まず理解もしない一般利用規約は、決して有効な通知ではない。

Sec. 3.5 は、どの当事者が通知を提供すべきかを特定していない。場合によっては、フェデレーションの当事者が、通知を提供し同意を得るためにサブスクライバと直接の接点を持たないことがある。複数の当事者が通知提供を選択することもあり得るが、当事者は、契約や trust framework ポリシーを用いて、どの当事者が通知を提供し確認を得るかを事前に決定できる。特に、その決定が、サブスクライバが通知を読んで十分情報に基づく選択を行えることを中心に据えた要因に基づく場合である。

IdP は、サブスクライバの属性にアクセスし得るすべての RP をサブスクライバに知らせることが求められる。RP が IdP の allowlist（Sec. 4.6.1.1 参照）にある場合、サブスクライバは、属性開示について実行時に同意を求められない。この single sign-on のシナリオは、サブスクライバにとってよりシームレスなログイン体験を可能にし、サブスクライバは、自分がフェデレーション取引に参加していることにすら気づかない場合がある。IdP は、trust agreement の条件の一部として、allowlisted RPs の一覧をサブスクライバが利用できるようにする。この情報により、サブスクライバは、どの RP が自分の属性にアクセスし得るのか、どのような状況で、どのような目的でアクセスし得るのかを把握できる。

将来の取引を容易にするために、IdP がサブスクライバアカウント内にサブスクライバの IdP における実行時判断を保存していた場合、IdP は、実行時判断で過去に承認された RP をサブスクライバが確認および取り消しできるようにする必要もある。この一覧には、どの属性が承認されたか、承認がいつ記録されたかに関する情報が含まれる。同様に、RP におけるサブスクライバの実行時判断が何らかの形で保存される場合、RP もまた、実行時判断で承認された IdP をサブスクライバが確認および取り消しできるようにする必要がある。

7.3. Data Minimization

フェデレーションは、RP に露出するデータを最小化でき、サブスクライバに対するプライバシー保護をもたらし得る。RP は、機能するために必要な最小限の情報のみを要求し、サブスクライバアカウントで利用可能なすべての情報を要求してはならない。IdP は RP のユースケースに必要なものを超えて追加属性を収集することがあり得るが、IdP が送信するのは、RP が明示的に要求した属性に限られる。

場合によっては、RP の機能は属性の完全な値を必要としない。例えば、RP はサブスクライバが 13 歳以上かどうかを知る必要があるが、生年月日の完全な日付は不要かもしれない。潜在的に機微な個人情報の収集を最小化するため、RP は派生属性値を要求できる（例：質問「サブスクライバは 13 歳以上か？」回答「Y/N」または「Pass/Fail」）。これは、RP による機微で不要な個人情報の収集を最小化する。これに応じて、Sec. 3.11.2 は、可能な場合、RP が完全な属性値ではなく派生属性値を要求することを推奨する。この RP 要件を支えるため、IdPs は可能な場合に派生属性値をサポートするべきである。

収集する個人情報を最小化しプライバシーを保護するため、IdPs は可能な場合、RP にデータを提供する際に仮名的な選択肢をユーザに与えるべきである。同様に、RP のポリシーとして仮名性が可能である場合、RP はユーザに対して仮名的な選択肢を要求するべきである。IdPs と RPs の双方は、不必要なデータ送信を最小化するよう努める必要がある。

7.4. Agency-Specific Privacy Compliance

Section 3.10 は、プライバシー遵守要件を判断するために SAOP に相談するという機関要件を示している。フェデレーションが Privacy Act of 1974（PrivacyAct）や、PIA を実施することを求める E-Government Act of 2002（E-Gov）を発動させるかどうかなど、プライバシーリスクを評価して軽減し、遵守義務について機関に助言するため、デジタル認証システム開発の初期段階から機関の SAOP を関与させることが極めて重要である。例えば、機関がフェデレーションにおける IdP として機能する場合、機関がフェデレートする任意の RP のために IdP が資格情報を保持することになるため、Privacy Act の要件が発動し、新規または既存の Privacy Act SORN のいずれかでのカバーが必要になる可能性が高い。しかし、機関が第三者 IdP を使用する RP である場合、RP で機関が保持するデータとして RP から渡されたものが何かに応じて、デジタル認証が Privacy Act の要件を発動させないこともあり得る。そのような場合、機関は、そうしたデータをカバーするより広範なプログラムレベルの SORN を持っている可能性がある。

SAOP は、PIA が必要かどうかを判断するうえでも同様に機関を支援できる。これらの考慮事項は、フェデレーション取引の利用だけを理由として Privacy Act SORN や PIA を作成することを要求するものとして読まれるべきではない。多くの場合、デジタル認証プロセス全体を包含する PIA と SORN を起草するか、またはオンラインアクセスを確立しようとしているプログラムや給付について論じる、より大きなプログラムレベルの PIA の一部としてデジタル認証プロセスを含めることが、最も合理的である。

デジタル認証には多くのコンポーネントがあるため、SAOP が各個別コンポーネントを把握し理解していることが重要である。例えば、機関がフェデレーテッド IdP または RP のサービスを提供または利用する場合、他のプライバシー成果物が適用され得る（例：Data Use Agreements、Computer Matching Agreements）。SAOP は、追加でどの要件が適用されるかを判断することにおいて機関を支援できる。さらに、デジタル認証の個別コンポーネントを十分に理解することは、SAOP が、遵守プロセスまたは他の手段を通じて、プライバシーリスクを適切に評価し軽減することを可能にする。

7.5. Blinding in Proxied Federation

主に統合を簡素化するために存在する一部のプロキシ構造は、加入者のプライバシー保護を追加では提供しない場合がありますが、他の構造は、さまざまなブラインディング技術を通じて、加入者に対して多段階のプライバシーを提供します。プライバシーポリシーは、IdP、RP、およびフェデレーション・プロキシによる、加入者属性および認証トランザクションデータ（例：最終的な IdP と RP の識別情報）の適切な利用を規定する場合があります。

ブラインディングは、データの入手をより困難にすることで、これらのポリシーの実効性を高めることもあります。プロキシベースのシステムには 3 つの当事者が存在し、プロキシは、当事者の 1 つ以上（自分自身を含む）から情報を隠すために使用できます。ダブルブラインド・プロキシでは、IdP と RP は互いの識別情報を知らず、両者の関係はプロキシとのみ成立します。トリプルブラインド・プロキシでは、プロキシは通過するデータの内容を把握できません。ブラインディングのレベルが上がるほど、技術的および運用上の実装の複雑さも増す可能性があります。プロキシは、取引の両側で適切な当事者へトランザクションを対応付け、取引に関与する全当事者の暗号鍵を管理する必要があるため、完全なトリプルブラインド・プロキシを実運用で実装することは非常に困難です。

ブラインディング技術を用いた場合でも、ブラインド化された当事者が、開示された属性データやメタデータ（例：タイムスタンプ、属性バンドルのサイズ、属性の署名者情報）から保護対象の加入者情報を推測できる可能性があります。IdP は、フェデレーションに参加するエンティティに関する識別情報が露見するリスクを低減するため、追加のプライバシー強化アプローチを検討してもよいでしょう。

Table 5 は、プロキシ型フェデレーションで用いられるブラインディング実装のスペクトラムを示します。この表は例示目的であり、網羅的でも特定技術に依存するものでもありません。

Table 5. Proxy characteristics

プロキシ種別	RP が IdP を把握	IdP が RP を把握	プロキシが RP と IdP 間を追跡可能	プロキシが加入者の属性を閲覧可能
属性付き非ブラインディング・プロキシ	はい	はい	はい	はい
非ブラインディング・プロキシ	はい	はい	はい	該当なし
属性付きダブルブラインド・プロキシ	いいえ	いいえ	はい	はい
ダブルブラインド・プロキシ	いいえ	いいえ	はい	該当なし
属性の有無を問わないトリプルブラインド・プロキシ	いいえ	いいえ	いいえ	いいえ

8. Customer Experience Considerations

This section is informative.

ユーザー中心設計、カスタマーエクスペリエンス、ユーザビリティの標準的な用語に合わせ、この節では人間の当事者を指す語として “user” を用います。多くの場合、ここでの “user” は、申請者、申立人、または加入者の役割にある主体であり、これらは本ガイドラインの他の箇所で説明されています。カスタマーエクスペリエンスは、ユーザビリティ、アクセシビリティ、選択可能性の結節点に位置します。ユーザーのニーズを考慮することで、組織は、不必要な摩擦や不満を最小化しつつ、応答性が高く安全なデジタル ID ソリューションを提供できます。

8.1. Usability

ISO/IEC9241-11 は、ユーザビリティを「指定されたユーザーが、指定された利用状況（文脈）において、指定された目標を、有効さ、効率、満足度をもって達成するために、システム、製品またはサービスを利用できる程度」と定義しています。この定義は、有効さ・効率・満足度を達成するために必要な主要要素として、ユーザー、目標、利用状況（文脈）に焦点を当てています。ユーザビリティを達成するには、これらの主要要素を考慮する包括的なアプローチが必要です。

ユーザビリティの観点から、フェデレーテッド ID システムの主要な潜在的利点の 1 つは、複数の authenticator を管理することに伴うユーザーの疲労（user fatigue）という問題に対処できる点です。これは従来、ユーザー名とパスワードで問題となってきましたが、物理・デジタルを問わず、多数の authenticator を管理する必要性が増すことは、ユーザビリティ上の課題となります。

[SP800-63A] の Sec. 8.1 および [SP800-63B] の Sec. 8.1 で述べられているとおり、総合的なユーザー体験はデジタル ID システムの成功にとって重要です。これは、フェデレーテッド ID システムでは特に当てはまります。なぜならフェデレーションは、多くのユーザーにとって馴染みの薄いユーザー対話パラダイムであり、ユーザーの過去の認証体験が期待値に影響し得るためです。

フェデレーテッド ID システムにおける総合的なユーザー体験は、正当なユーザーにとって可能な限り滑らかで容易であるべきです。これは、ユーザビリティ標準（例：ISO 25060 シリーズ）や、確立されたユーザー対話設計のベストプラクティスに従うことで実現できます。

本ガイドラインおよび考慮事項は、ユーザーの観点から記述されています。

1973 年リハビリテーション法の Section 508 は、情報技術における障壁を取り除き、連邦機関に対して、電子情報技術を障害のある人々にとってアクセス可能にすることを要求するために制定されました。本ガイドラインは Section 508 の要件を直接的に主張するものではありませんが、ID サービス提供者には Section 508 の規定に準拠することが期待されます。Section 508 への準拠に加えて、連邦機関およびそのサービス提供者には、ID システムのライフサイクル全体でアクセシビリティが優先されるよう、障害のある人々の体験を念頭に置いてサービスやシステムを設計することが一般に期待されます。

8.1.1. General Usability Considerations

フェデレーテッド ID システムは、以下を満たすべきです。

ユーザー負担（例：不満、学習コスト）を最小化する
- 必要となるユーザー操作の回数を最小化する。
- 単一の IdP に紐づく複数の加入者アカウントを、ユーザーが迅速かつ容易に選択できるようにする。例えば、アカウント選択機能（account chooser）により、ユーザーは、潜在的な IdP の一覧から IdP を選んでフェデレーション処理を開始するのではなく、最近アクセスした加入者アカウントの一覧から選択できます。
- ユーザー負担の最小化と、ユーザーが十分に情報に基づく意思決定を行えるようにするための情報提供とのバランスを取る。
馴染みの薄い技術用語や詳細の使用を最小化する（例：基本概念が明確に説明されていれば、ユーザーは IdP や RP という用語を知る必要はなく、FAL の具体値を知る必要も、その影響が明確に伝達されていれば不要である）。
特に単一の security domain 内にある場合、IdP と RP を通じて一貫性があり統合されたユーザー体験を目指す。
図表、イラスト、よくある質問（FAQs）、チュートリアル、例などのリソースを提供して、ユーザーが ID を理解できるように支援する。リソースは、ユーザー情報がどのように扱われるか、および取引当事者（例：RPs、IdPs、プロキシ）が互いにどのように関係するかを説明するべきです。
明確で、誠実で、有意味なコミュニケーションをユーザーに提供する（すなわち、表現は明示的で理解しやすいべきである）。
場所やデバイスに依存しないオンラインサービスをユーザーに提供する。
信頼関係を明示して、情報に基づく信頼判断を支援する。信頼関係はしばしば動的で、文脈に依存します。ユーザーは、ある属性やトランザクションについて、特定の IdPs や RPs を他より信頼しやすい場合があります。例えば、価値の高い個人情報（例：金融・健康）を含むウェブサイトでは、フェデレーテッド ID システムの利用に慎重になるユーザーがいます。個人情報の機微性の捉え方によっては、商用 IdPs に対して広告やデータ利用への懸念から不安を抱くユーザーもいます。一方で、政府サービスへの一般的な不信や、商用提供物への慣れから、政府 IdPs より商用 IdPs に信頼を置くユーザーもいます。いずれの場合でも、フェデレーション取引に関与するエンティティについて End-User に明確に示し、可能であれば、幅広い利害関係者の認識に対応できる選択肢を提供することが重要です。
ユーザー向け情報については、[SP800-63A] Sec. 8 に定めるユーザビリティ考慮事項に従う。
技術支援をどのように、どこで得られるかを明確に伝える。例えば、オンラインのセルフサービス機能、チャット、ヘルプデスク支援の電話番号へのリンクを提供する。技術支援を得るために、取引当事者（例：RPs、IdPs、プロキシ）の間をユーザーが行き来するような誘導は避ける。
代表的ユーザーと現実的なタスクを用い、適切な文脈で統合的かつ継続的なユーザビリティ評価を実施し、ユーザー観点からフェデレーテッド ID システムの成功を確実にする。

8.1.2. Specific Usability Considerations

この節は、フェデレーテッド ID システムに関して特定された具体的なユーザビリティ考慮事項を扱います。この節は、フェデレーテッド ID システムに関するあらゆるユーザビリティ要因を網羅的に扱うことは意図していません。むしろ、ユーザビリティ文献におけるより大きく普遍的なテーマ、主として ID に関するユーザーの視点、ユーザー採用、信頼、フェデレーテッド ID 空間に関する認知に焦点を当てています。場合によっては実装例も示しますが、特定の解決策を規定するものではありません。言及する実装は、特定のユーザビリティ要件に対応する革新的技術アプローチを促すための例です。システム設計・コーディング、仕様、API、最新のベストプラクティスに関する標準も参照してください。実装は、多くの要因に左右され、画一的な解決策が適用できないことに留意が必要です。

User Perspectives on Online Identity

ユーザーがフェデレーテッド ID システムに慣れている場合でも、フェデレーテッド ID には複数のアプローチがあり、ユーザーデータがどのように扱われるか、特にプライバシーや情報共有の観点で、信頼できる期待値を確立する必要があります。ユーザーと実装者は、ID について異なる概念を持ちます。ユーザーは ID を「ログインして自分のプライベートな空間にアクセスすること」と捉えます。実装者は ID を、authenticator、assertion、保証レベル、サービス提供に必要な最小限の ID 属性という観点で捉えます。この乖離があるため、フェデレーテッド ID システムにおける ID の概念を、ユーザーが正確に形成できるよう支援することが不可欠です。良い ID のモデルは、ユーザーに基盤を与え、フェデレーテッドシステムの利点とリスクを理解させ、システムの採用と信頼を促進します。

収集する個人情報を最小化しプライバシーを保護するため、IdPs と RPs は、仮名（pseudonymous）識別の利点と欠点、どの情報が伝送されるか、その目的は何かをユーザーに知らせるべきです。

ID の多くの性質は、ユーザーがフェデレーション内外で ID をどのように管理するかに影響します。ユーザーはサイバー空間の外でも文脈に応じて複数の ID を管理しているのと同様に、フェデレーテッド環境でも自分の ID を管理することを学ぶ必要があります。したがって、ID と文脈がどのように使われるかをユーザーに明確にする必要があります。以下の要因を考慮すべきです。

異なるユーザーロールを区別できるよう、必要な文脈とスコープをユーザーに提供する。例えば、ユーザーが自分自身のために行動しているのか、雇用主など他者を代表して行動しているのかを区別する。
IdPs、RPs、アカウントなどのエンティティを区別できるよう、固有で有意味かつ説明的な識別子をユーザーに提供する。この種のユーザー向け識別子は、通常ユーザーに露出しないプロトコル内部の識別子に加えて提供される可能性が高い。
データの所有権と、変更を行う権限を持つ者についてユーザーに情報を提供する。ID およびそれに関連するデータは、複数の主体によって更新・変更される場合があります。例えば、医療データの一部は患者が所有し更新しますが、別のデータは病院や医師の診療所のみが更新します。
属性を容易に検証・閲覧・更新できるようにする。ID およびユーザーロールは時間とともに変化します（例：住所、健康、金融データ）。属性更新や属性開示の意思決定機能が同時に提供されない場合もあります。ユーザーが属性を変更する手続きが広く周知され、文書化され、容易に実行できることを確実にしてください。コア属性の更新をユーザーに認めることについての詳細は、[SP800-63A] Sec. 5.3 を参照してください。
関連する加入者アカウントまたは RP subscriber account が無効化・終了している場合でも、データ更新の手段をユーザーに提供する。更新データを追跡する際には、適用され得る監査・法的・ポリシー上の制約を考慮する。
ユーザーが自分の ID を完全に削除し、自分に関するすべての情報（取引履歴を含む）を削除できる手段を提供する。特定のケースでは、RP が RP subscriber account 内のデータの一部を保持する義務があるため、削除よりもアカウントの無効化の方が適切な場合があります。適用され得る監査・法的・ポリシー上の制約により、こうした操作が妨げられる可能性を考慮する。
サイトまたはアプリケーションのデータ保持ポリシーについて、明確で見つけやすい情報をユーザーに提供する。
組織のデータアクセス・ポリシーに従い、適切な匿名性および仮名性の選択肢をユーザーに提供し、必要に応じてそれらの ID 選択肢を切り替えられるようにする。
各 IdP と RP の接続を管理できる手段（完全な分離や、RP による 1 つ以上の属性へのアクセスの除去を含む）を提供する。

User Perspectives of Trust and Benefits

ユーザーによるフェデレーテッド ID システムの採用には、多くの要因が影響します。どの技術でも同様に、ユーザーは要因ごとに重視度が異なります。ユーザーはしばしば、採用判断の前に知覚される利点とリスクを比較衡量します。IdPs と RPs が、ユーザーが情報に基づく判断を行えるよう十分な情報を提供することは重要です。信頼（trust）と信頼の階層（tiers of trust）は、フェデレーテッド ID システムの基本原則であり、ユーザー採用を促進し得ます。さらに、良いユーザー体験はフェデレーションへの需要増につながり、RPs 側の採用拡大を引き起こす可能性があります。

ユーザー採用を促進するため、IdPs と RPs はユーザーとの信頼を確立・醸成し、採用の利点とリスクを理解できるよう支援する必要があります。以下の要因を考慮すべきです。

適切な対話型 UI と通知を用いることで、情報開示をユーザーが制御できるようにし、明示的な同意を得る（Sec. 7.2 参照）。通知の内容・サイズ・頻度のバランス、特定コミュニティに合わせた通知の調整などが必要であり、ユーザーが含意を十分理解しないままクリックで通過してしまうことを避ける。
属性共有について、以下を考慮する。
- 共有される属性および属性値をユーザーが検証できる手段を提供する。良いセキュリティプラクティス（Sec. 3.11.2 および Sec. 6 参照）に従う。
- すべてか無かではなく、属性の一部リストへの同意を可能にする。ユーザーが全情報の共有に同意しない場合でも、ある程度のオンラインアクセスを許容する。
- ユーザーが何を共有しているのかを明確に伝える。特に、属性を選択的に開示できる場合は重要である。
- 共有属性リストに対する同意をユーザーが更新できるようにし、影響を受ける RPs など関係当事者へ更新同意を伝達する手段を提供する。
- 不必要な情報をユーザーに提示しない。例えば、認証応答の一部として RP に共有される場合でも、システム生成属性（例：pairwise pseudonymous identifiers）を表示しない。
- ユーザーステップとナビゲーションを最小化する。例えば、OAuth や OpenID Connect に一般的に見られるように、フェデレーション・プロトコルに属性同意を組み込む。
- IdP が主張した無効な属性情報や、RP が収集した無効な属性情報からユーザーが回復できるよう、有効な救済（redress）手段を提供する。救済の要件は [SP800-63] Sec. 3.6 も参照してください。
- 同一属性に対する要求について、ユーザーが属性共有へ同意する回数を最小化する。同意要求の頻度を抑えることは、ユーザーの不満を避ける。
- 特に加入者管理のウォレット内で、ユーザーが自分のデータがどこで使われたかを確認できるようにする。
制約された用途のためにのみ情報を収集し、情報開示を最小化する（Sec. 7.3 参照）。明示的同意なしの不要・過剰な収集・開示や追跡はユーザー信頼を損ないます。例えば、RP でユーザーがアクセスし得るすべての取引ではなく、現在の取引に関連する属性のみをユーザーに要求する。
フェデレーテッド ID の利用に伴う利点とリスクを、ユーザーに対して明確かつ誠実に伝える。ユーザーが価値を見出す利点には、時間節約、使いやすさ、管理すべきパスワード数の削減、利便性の向上などが含まれます。

リスクに関するユーザーの懸念は、フェデレーテッド ID システムの採用意欲に悪影響を与えることがあります。ユーザーは、信頼、プライバシー、セキュリティ、フェデレーテッドシステムにおける単一障害点への懸念を抱く場合があります。例えば、単一の IdP が一時的または恒久的に利用不能になると、複数の RPs へのアクセスを失うことを恐れるユーザーがいます。また、新しい認証プロセスを学ぶことに不安や混乱を感じるユーザーもいます。フェデレーテッド ID システムの採用を促進するには、知覚される利点が知覚されるリスクを上回る必要があります。

User Mental Models and Beliefs

ユーザーの信念や認知は、特定の結果を期待し、特定の行動を取りやすくさせます。社会科学では、このような信念・認知・傾向を “mental models” と呼びます。例えば、人々は外食についてのメンタルモデルを持ち、ファストフード、カフェテリア、よりフォーマルなレストランなど各店舗での行動や期待を導きます。そのため、すべての店に精通していなくても、各店で適切に振る舞う方法を理解できます。

フェデレーションに関する良好で完全なメンタルモデルの形成を支援することで、ユーザーは単一の具体的実装を超えて一般化できます。フェデレーテッド ID システムがユーザー視点で設計されない場合、ユーザーが誤った、または不完全なメンタルモデルを形成し、採用意欲に影響するおそれがあります。以下の要因を考慮すべきです。

取引当事者（例：RPs、IdPs、プロキシ）の作業関係と情報フローを明確に説明し、誤解を避ける。説明では、IdPs や RPs という一般名詞ではなく、実際のエンティティ名を用いる。
- 見た目に無関係なエンティティ同士が作業関係を持つ理由をユーザーが理解できるよう、目立つ視覚的手がかりと情報を提供する。例えば、フェデレーテッド ID システムの情報フローを理解していないために、政府サービスとオンラインの個人活動が混ざることを懸念するユーザーがいます。
- RP が自サイトから IdP へ制御をリダイレクトする必要がある場合、ユーザーに目立つ視覚的手がかりと情報を提供する。例えば、目的の RP へアクセスするために IdP でログインしていることをユーザーに知らせるため、IdP の UI 内に RP のブランド表示を行う。
取引当事者（例：RPs、IdPs、プロキシ）の真正性を判断できる明確で使いやすい手段（例：視覚的な保証）をユーザーに提供する。これは、特にルートドメインが変わる場合（例：.gov から .com へ）に、あるドメインから別ドメインへ移動することへの不安を軽減するのにも役立ちます。例えば、IdP の URL を表示して、悪意あるサイトによるフィッシングでないことをユーザーが確認できるようにする。
ログインとログアウトについて、視覚的手がかりを含め、ユーザーに明確な情報を提供する。実装によっては、フェデレーテッドアカウントで RP にログインすると、IdP と RP の双方で長時間セッションが作られる場合があります。ユーザーは、RP でセッションを終了しても IdP でのセッションが必ずしも終了しないことに気付かない場合があり、IdP から明示的にログアウトする必要があります。IdP セッションを終了するために明示的ログアウトが必要であることをユーザーに注意喚起できる明確な情報が必要です。IdP と RP の双方が、自動ログアウト機能（ユーザーが認証してからの時間、またはセッション内での非アクティブ時間に基づき、能動的にログアウトする）を備える場合もあります。ユーザーが何もしなくてもセッションが終了し得るタイミングを明確に知らせることは、不満、作業の損失、または安全でない回避策（例：予期しないタイムアウトを避けるために安全なサイトからデータをコピーする）を避ける上で重要です。
信頼合意（trust agreement）の条項と結果について、技術用語を排した、明確で理解しやすい説明をユーザーに提供する。
システム内での属性の目的と利用について、ユーザーに明確で理解しやすい説明を提供し、属性が開示・伝送される当事者を明確に開示する。

8.2. Customer Success Considerations

カスタマーエクスペリエンスの主要な側面は、ユーザー人口のニーズを予測し、その人口に適した形でフェデレーションを提供することです。カスタマーエクスペリエンス上のリスクや課題を評価するにあたり、IdPs と RPs は、自身のフェデレーテッド ID サービスが提供する対象ユーザー人口を考慮し、そのニーズと能力を支えるソリューションを展開すべきです。

フェデレーションは高度に技術的なプロセスです。End-User に露出するプロセスのうち、カスタマーエクスペリエンスに直接影響し、かつ認証および ID 証明（identity proofing）のカスタマーエクスペリエンス考慮事項で既に扱われていないものはほとんどありません。例外は 2 つあります。1) IdP の選択と記憶のプロセス、2) エラー処理および IdP と RP のヘルプデスク間のコミュニケーションです。ここで述べる内容に加え、IdP は、ID 証明、属性検証、登録（enrollment）に関するカスタマーエクスペリエンス（[SP800-63A] Sec. 8.2 参照）および authenticator に関する考慮事項（[SP800-63B] Sec. 8.2 参照）も考慮する必要があります。

8.2.1. Provide a Clear Means for Selecting and Remembering IdPs

ユーザーは、特に IdPs の数が多い場合、複数の IdPs から選ぶことに苦労することがあります。ユーザーに IdP の選択肢を提示する単一の方法があるわけではありませんが、複数の IdPs を活用する RPs には、提示設計についてユーザーテストを実施し、ユーザーの反応を理解し、選択肢を伝える最良の方法を評価することが推奨されます。さらに、IdPs の実務や能力に関する情報を提供することで、RP は、ユーザーが自分の手段と能力に最も適合する IdP を選べるよう、より良く支援できます。

ユーザーにとっての別の課題は、加入者アカウントを確立した IdP を覚えておくことです。これは、RP とその IdPs とのやり取りが稀な場合に特に当てはまります。ユーザーとの継続的なやり取りを効果的かつ成功させるため、RPs には、以前に使用した IdP へユーザーを誘導する仕組みを開発することが推奨されます。これは、加入者の入力（例：メールアドレス）による参照機構、または過去セッションで使用した IdP の記憶などの形を取り得ます。これを実装することで、以下のような問題に対処できます。

IdP や認証情報を忘れたユーザーのアカウント回復活動
既存の IdP/CSP に紐づくアカウントを持っているにもかかわらず、ユーザーが新しい IdP を選ぶことで発生する、不必要で時間のかかる再度の証明（reproofing）
新しい IdP/CSP で再証明するユーザーにより RP が被るコスト増

8.2.2. Provide Clear Paths to Support and Assistance

RPs と IdPs は、技術支援をどのように、どこで得られるかを明確に伝える必要があります。例えば、オンラインのセルフサービス機能、チャット、ヘルプデスク支援の電話番号へのリンクを提供します。技術支援を得るために、取引当事者（例：RPs、IdPs、プロキシ）の間をユーザーが行き来するような誘導は避けてください。

さらに、参加エンティティ間の連携は、良好なカスタマーエクスペリエンスの実現に不可欠です。IdP と RP のサポートチームは、ユーザーが誤った当事者に問い合わせてしまった場合に、適切に誘導できる必要があります。例えば、RP のウェブサイト機能がなぜ失敗しているのかを理解しようとしてユーザーが IdP のヘルプデスクに電話した場合、IdP のサポート担当者は、ユーザーを案内できる情報、または問題解決を支援できる RP 側のサポート能力へ誘導できる必要があります。フェデレーテッドモデルにおけるこの分散責任は、設計、ユーザビリティ、運用、継続改善の計画で対処されない場合、ユーザーの不満と混乱を招きやすい接点を生みます。

本ガイドラインは、一般に経験される顧客摩擦を緩和するため、IdPs と RPs に対する規範的要件（normative requirements）を定めています。しかし、規範的要件が、アプリケーションごとに異なる潜在的なカスタマーエクスペリエンス問題のすべてを予見することは困難です。したがって、IdPs と RPs は、加入者が問題や課題を報告できる仕組みを提供し、代替の認証・アクセス戦略について助言できる必要があります。

9. Examples

This section is informative.

この節では、本ガイドラインの要件と併せて用いられるフェデレーションの例シナリオをいくつか示します。これらのシナリオは例示目的であり、本ガイドラインが課す要件を超える追加要件を示すものではありません。

9.1. Mapping FALs to Common Federation Protocols

OpenID Connect (OIDC)、SAML、および各種デジタルウォレット技術は、異なる FAL の要件に到達するために活用できる多様な機能を提供します。Table 6 は、これらのプロトコルで特定の FAL に到達するために展開し得る具体的オプションの例を示します。この表は、所与の FAL への規範的な対応付け（mapping）を表すものではなく、FAL を確立する際にはフェデレーション・プロセス全体を考慮する必要がある点に注意してください。また、各 FAL は、この表に記載されていないプロセス、展開、手順によっても到達し得ます。

Table 6. FAL protocol examples

	OIDC	SAML	Wallet
FAL1	[OIDC] のすべてのコアフロー（すなわち Authorization Code、Implicit、Hybrid）は、assertion（すなわち ID Token）を JSON Web Signatures により署名することを要求するよう設定できます。Assertions は、フロントチャネルおよびバックチャネルの多様な方法で提示されます。これらのフローはいずれも、手動登録および動的クライアント登録の両方で構築できます。[OIDC-Basic] や [OIDC-Implicit] のようなプロファイルは、相互運用可能な展開のための追加ガイダンスを提供します。	[SAML-WebSSO] プロファイルは、XML D-Sig を用いて assertions に署名し、フロントチャネルで assertion を提示することを可能にします。SAML の展開は、一般に手動登録でセットアップされ、FAL1 以上の要件を満たし得ます。登録は、フェデレーション当局によって管理される場合もあります。	加入者の CSP は、[OIDC4VCI] を用いて、加入者が選択したウォレットソフトウェアへ属性バンドルを発行します。RP は、[OIDC4VP] を用いて加入者のウォレットに属性を要求し、assertion と属性バンドルが適切に形成され署名されていることを検証します。RP は、加入者主導の対話に基づいて assertions を受け入れ、事前に受け入れる CSP の一覧をあらかじめ設定しません。
FAL2	バックチャネルで ID Token を提示するフロー（例：Authorization Code、Hybrid）は、一定の assertion 注入（injection）保護を提供し得ます。	[SAML-Bindings] で定義される SAML の Artifact Binding は、SAML assertions のバックチャネル提示を可能にし、一定の assertion 注入保護を提供し得ます。	RP は、使用されるウォレットを事前に知らなくても、所定の目的のために属性バンドルを受け入れる CSP の集合を信頼するよう設定できます。デバイス上の assertion 提示方法を用いることで、ウォレットは assertion 注入保護を提供できます。
FAL3	ID Token は holder-of-key および bound authenticator の assertion 提示に必要な claims を含め得ますが、出版時点では、それを行う業界標準プロファイルは存在しません。	SAML Holder-of-Key プロファイルは、他の展開選択と組み合わせれば、このレベルの assertion 要件に適合し得ます。	RP は、フェデレーション当局によって管理され、任意のウォレットのオンボーディングに厳格なプロセスを持つ CSP との信頼合意を受け入れます。属性バンドルの提示に加え、ウォレットは proof 内で認証鍵の所持証明を送信し、holder-of-key プロセスにより RP が FAL3 に到達できるようにします。加入者管理のウォレットからの assertion と bound authenticator を組み合わせることも可能です。

実運用の展開では、FAL に影響する事項以外にも追加の考慮が存在します。特に OpenID Connect (OIDC) では、identity API（すなわち UserInfo Endpoint）や追加 API へのアクセスを付与することが一般的です。API アクセスの安全性は本ガイドラインのスコープ外ですが、OpenID Connect (OIDC) の実装は、FAL の向上と歩調を合わせて、すべての API 呼び出しの安全性を高めるよう努めるべきです。例えば、加入者保有の署名鍵の検証を要する holder-of-key assertion を FAL3 で要求するのに加えて、OpenID Connect (OIDC) システムは、API アクセスに sender-constrained access tokens を要求することもあり得ます。これは、各 API 呼び出しにおいて RP が保有する署名鍵の検証を必要とします。

9.2. Direct Connection to an Agency’s IdP

Agency A は、加入者アカウントを発行し管理しており、フェデレーション処理を通じてこれらの加入者アカウントをオンラインで利用できるようにするため、OpenID Connect (OIDC) の IdP をセットアップして運用します。

RP は、Agency A の加入者向けに assertions を受け入れるため、IdP と 1 対 1（pairwise）の trust agreement を締結します。RP は、この合意の一部として、IdP から必要とする属性集合を宣言します。trust agreement は、フェデレーション取引における属性開示の決定者が加入者（authorized party）であることを規定します。

IdP は、従業員番号を一方向暗号関数に通して、加入者アカウントの固有識別子を作ることで、加入者アカウントの federated identifier を生成します。この識別子により、RP が内部識別子を算出することはできませんが、氏名やメールアドレスなど他属性の変更があっても安定的に維持されます。

trust agreement の条件に従い、加入者は RP に初めてログインする際に IdP からプロンプトされます。IdP は、加入者の属性を RP と共有することに対する同意をランタイムで加入者に求め、加入者の同意画面に、RP がこれら属性を使用する目的を表示します。さらに IdP は、この同意判断を記憶することを加入者に求めます。この保存された判断により、将来の要求では IdP が保存された同意に基づいて処理し、同一の RP が同一の属性を要求する限り、加入者へ再度プロンプトしません。

assertion は OpenID Connect (OIDC) の ID Token として整形され、フェデレーテッドログインを成立させるための最小限の属性集合を含みます。federated identifier を除き、assertion には加入者を特定し得る情報は含まれません。assertion に加えて、RP には OAuth 2.0 の Access Token が与えられ、RP は IdP がホストする OpenID Connect (OIDC) UserInfo Endpoint にアクセスできます。RP は、加入者が初めて RP を利用するときなど、必要に応じてこの API を呼び出して追加属性を取得できます。この RP は just-in-time のプロビジョニングモデルに従うため、加入者の federated identifier を初めて見たとき、RP はその federated identifier のために RP subscriber account を作成し、identity API を呼び出して加入者属性で RP subscriber account を埋めます。その後、この加入者の将来の認証では、IdP は加入者属性の最終更新時刻のタイムスタンプを含めます。RP は、更新時刻が、最後に API を呼び出した時刻より新しい場合に identity API を呼び出します。さらに、RP はビジネスニーズとアカウント管理期待に基づき、年 2 回、identity API を通じて能動的に更新（refresh）します。

9.3. Multilateral Federation Network

Agencies A、B、C はそれぞれ、加入者アカウント向けに OpenID Connect (OIDC) を提供する IdP を持ちます。3 つの機関すべてが、独立機関によって運営され、機関間接続を提供する多国間フェデレーションに参加します。フェデレーション当局は、それぞれの IdP が当該機関を代表していることを独立に検証します。フェデレーション当局は、[OIDFed] のような discovery 仕様を用いて、多国間フェデレーションに属するすべての機関の IdPs の discovery 記録を公開します。これにより、フェデレーション内の RPs は、フェデレーション合意の規則の下で、所定の機関のアカウントへアクセスするために使用できる IdP の特性を discovery できます。

RPs X と Y は、Agencies A、B、C のログインを許可したいと考え、フェデレーションへの参加意思を宣言し、必要な属性の一覧をフェデレーション当局へ送ります。フェデレーション当局は RP の要求を評価し、多国間フェデレーションの trust agreement に追加します。これにより、両 RP は、必要に応じて、3 つの各 IdP へ登録できます。

両 RP は、フェデレーション・プロキシを介さず、3 つの各 IdP と直接やり取りします。新しい IdP または RP が多国間フェデレーション合意に追加されると、既存の IdPs と RPs は新しいコンポーネントとそのパラメータについて通知を受けます。

IdPs と RPs は、フェデレーション当局の庇護の下で共有シグナリングチャネルを確立します。これにより、任意の IdP または RP は、特定アカウントに関わる不審または悪意のある行為を、フェデレーション当局の下で他メンバーへ報告できます。

9.4. Issuance of a Credential to a Digital Wallet

Agency B は、デジタルウォレット技術を用いて、加入者アカウントをフェデレーションで利用可能にします。ウォレットへ属性バンドル（この技術領域では “credentials” として知られる）を発行するための Agency B の合意は、連邦政府全体でデジタルウォレットを管理するために設立されたフェデレーション当局によって仲介されます。フェデレーション当局は、多国間合意の下で各機関の CSP の同一性を確立し、Agency B の CSP のみが、多国間 trust agreement の中で Agency B の加入者管理ウォレットをオンボードできるようにします。

ある加入者は、Agency B の加入者アカウントで使いたいデジタルウォレットを自デバイス上で実行しています。加入者は、デジタルウォレットソフトウェアを Agency B の CSP に向けます。加入者は、生体要素を用いてデジタルウォレットを有効化し、ウォレットは加入者アカウントのために CSP へオンボーディング要求を行います。この要求には、ウォレットが保有する署名鍵の所持証明が含まれます。CSP はウォレットの証明を検証し、ウォレットデバイスからの追加 attestation を処理します。

加入者はオンボーディング中に CSP へ認証します。CSP は、フェデレーション当局からの trust agreement の条項を加入者へ提示し、当該デジタルウォレットへ ID を発行したいかどうかの確認を求めます。加入者には、ウォレットで利用可能となる属性集合が知らされます。

CSP は、加入者属性と、デジタルウォレットの verification key への参照を含む属性バンドルを作成します。CSP はこの属性バンドルに自身の署名鍵で署名し、バンドルをデジタルウォレットへ返します。

その後、加入者が RP にアクセスする必要がある場合（認証でも ID 証明でも）、RP は、RP のニーズに合う属性バンドルを加入者のウォレットへ問い合わせます。RP は同じフェデレーション当局と trust agreement を持ち、多国間 trust agreement の規則の下で発行された ID を信頼することに同意します。IdP として動作するデジタルウォレットは、RP の要求が、Agency B の CSP から発行された属性バンドルで満たせることを識別します。デジタルウォレットは、ローカル生体要素を用いてデジタルウォレットソフトウェアの IdP 機能を有効化するよう加入者へ促します。さらに、当該 RP へ要求された属性を提示したいかどうかの確認を加入者へ求めます。加入者が承諾すると、ウォレットの IdP 機能は、ウォレットの署名鍵を用いて RP 向けの assertion を作成します。この assertion には、CSP からの署名付き属性バンドルが含まれます。IdP は assertion を RP へ届けます。

RP は署名付き assertion を受領し、フェデレーション当局によって識別された CSP の verification keys を用いて、CSP からの属性バンドルの署名を検証します。次に RP は、assertion 内で識別された verification key を用いて assertion の署名を検証します。これらの検査が成功すると、RP は、assertion 内の情報に基づいて、RP 上で加入者を表す RP subscriber account を作成します。

9.5. Enterprise Application Single-Sign-On

組織は一般に、allowlist と事前プロビジョニング済みアカウントを用いて、機関内の潜在的な加入者すべてにエンタープライズアプリケーションを提供します。

このシナリオでは、Agency E は、機関の OpenID Connect (OIDC) IdP を通じて Agency E の全従業員へエンタープライズ級サービスを提供するため、RP と 1 対 1 の合意を結びます。この trust agreement の一部として、IdP は RP 向けの SCIM ベースの provisioning API へのアクセスを許可します。IdP は各加入者アカウントに対して federated identifier を作成し、provisioning API を用いて federated identifiers とそれに関連する属性を RP へプッシュします。これにより、RP は、IdP システム上のすべての加入者について、RP subscriber account を事前にプロビジョニングできます。結果として、特定アカウントがまだ RP にログインしたことがなくても、RP は全アカウントに対して機能（例：アクセス権、データ共有、メッセージング）を提供できます。

trust agreement の条件により、RP は IdP の allowlist に登録されます。allowlist のエントリには、以下がすべて真であればフェデレーション取引が自動的に継続できることが記載されます。

加入者は Agency E に有効な加入者アカウントを持つ。
加入者は AAL2 以上で IdP に認証している。
RP は、assertion 内の federated identifier と基本的な認証イベント情報のみを要求する。その他の必要属性は provisioning API から入手できるため。
フェデレーション取引は FAL2 である。

RP がフェデレーション取引を開始するとき、RP の要求は、加入者が AAL2 で認証された有効セッションを持つ必要があることを示します。RP は “openid” scope のみを要求し、これは IdP からの assertion に含まれるのが federated identifier のみであることを示します。RP は、FAL2 に到達するためのパラメータでバックチャネル要求を開始します。結果として、機関が RP のオンボーディング時に全アカウントを代表してサービス利用へ同意しているため、加入者はランタイムで同意を求められません。これにより、セキュリティドメイン境界を越えるフェデレーションプロトコルを用いていても、加入者はシームレスな single sign-on 体験を得られます。IdP はランタイム判断を使用しないため、allowlist パラメータからの逸脱がある場合、フェデレーション取引は失敗します。

RP subscriber accounts は provisioning API を用いて同期されます。加入者アカウントが IdP で作成・変更・削除されると、IdP は provisioning API を用いて RP subscriber account の状態を更新します。これにより、RP は各加入者アカウントについて最新の状態を維持できます。例えば、加入者アカウントが IdP で終了すると、provisioning API は対応する RP subscriber account を即時終了するよう RP に通知します。RP は、監査およびアクセスログ内の識別子と参照を除き、当該アカウントのローカルキャッシュ属性をすべて削除します。

9.6. Holder-of-Key FAL3 With a Smart Card

加入者は、スマートカード上に暗号 authenticator を持っています。このスマートカード上の証明書は、trust agreement で規定された共有 PKI システムを用いることで、IdP と RP の双方が独立に検証できます。この種の authenticator は、FAL3 における holder-of-key assertion で使用できます。

加入者は、FAL3 のフェデレーション取引を要求する RP からフェデレーションを開始します。加入者はスマートカードを用いて IdP に認証します。IdP は、assertion が FAL3 での使用を意図していることを示すフラグを持つ assertion を作成します。assertion はさらに、holder-of-key assertion で使用される証明書の共通名（CN）とサムプリントを含みます。

RP が assertion を受領すると、通常どおり assertion を処理し、FAL3 フラグと証明書属性を確認します。加入者は証明書を用いて RP に認証し、RP は、加入者が提示した証明書が IdP からの assertion 内の証明書と一致することを検証します。一致が確認できると、RP は FAL3 で加入者との安全なセッションを確立します。

9.7. FAL3 With a Non-PKI Bound Authenticator

加入者は WebAuthn プロトコルを話すハードウェア暗号 authenticator を持っています。この authenticator はいかなる PKI システムにも紐づかず、authenticator デバイスは通常の認証処理で、IdP と RP の双方へ、互いに異なりリンクされない verification keys を提示します。この種の authenticator も、bound authenticator として FAL3 で使用できます。

この例では、加入者が IdP でこの認証デバイスを使用する際、Key1 の所持証明を提示します。加入者が同じデバイスを RP で使用する際、Key2 の所持証明を提示します。論理的には 2 つの別々の authenticator ですが、加入者の観点では、同一デバイスを複数箇所で使用しています。

フェデレーション取引を開始するため、加入者は Key1 を用いて IdP に認証します。IdP はその後、FAL3 としてフラグ付けされた assertion を作成します。IdP は Key2 の存在や使用を把握できないため、assertion は、加入者が FAL3 に到達するために bound authenticator を使用している旨を示します。RP がこの assertion を処理すると、assertion 内の federated identifier に関連する RP subscriber account を確認し、そのアカウントに Key2 を用いる bound authenticator があることを見つけます。RP は加入者に Key2 を用いた認証を求めます。Key2 が検証されると、RP は FAL3 で加入者との安全なセッションを確立します。

9.8. Holder-of-Key FAL3 With Referred Token Binding

加入者は、自身の IdP によって信頼されるが RP には知られていない証明書を用いて IdP に認証します。これは、IdP と RP が共有 PKI 環境にないためです。しかし、IdP と RP は TLS の referred token binding 拡張をサポートします。加入者が証明書を IdP に提示すると、IdP は加入者証明書の CN とサムプリントを含む assertion を作成します。IdP は、assertion または assertion reference とともに token binding ヘッダを返します。これらのヘッダが RP に提示されると、RP はそれらを用いて、assertion の内容を加入者の証明書に対応付けられます。RP は依然として証明書の検証を行う必要がありますが、token binding により、authenticator の証明書チェーンを別途信頼する必要なく検証できます。このプロセスは、holder-of-key FAL3 取引の要件を満たします。

9.9. Ephemeral Federated Attribute Exchange

RP は、加入者の識別情報を知る必要なく、特定属性（例：年齢の証明、機関所属）にアクセスしたい場合があります。RP は取引処理に必要な derived attribute values のみを要求します。このケースでは、加入者が年齢に達しているか、機関に所属しているかの単純な真偽値を要求します。フェデレーション処理により、RP と加入者の間に認証済みセッションが作成されます。しかし RP は、ephemeral なプロビジョニング機構を用い、取引記録のみを保持し、加入者を特定し得る追加属性は保持しません。IdP は pairwise pseudonymous identifier を RP に提供します。IdP は RP subscriber account が ephemeral であることを知っているため、加入者の RP 利用に影響を与えることなく、要求ごとに別個の PPI を RP に提供できます。IdP は、ランタイムで加入者に derived attributes の開示を求め、RP が情報変化を黙ってポーリングし続けることを防ぎます。

9.10. Multiple Different Authorized Parties and Trust Agreements

加入者が複数の RPs でサービスを利用すると、要件や体験が異なる複数の trust agreements が存在することになります。このシナリオでは、加入者は単一の IdP を通じたアカウントを持ち、3 つの異なる RPs で利用します。それぞれ異なる種類の trust agreement と、同意・通知に関する異なる要件を持ちます。

Organizational Authorized Party:

事前に確立された trust agreement により、機関は、機関内の全加入者が利用可能なエンタープライズサービス（すなわち RP）へ接続できます。この trust agreement の authorized party は機関であり、IdP は RP への allowlist エントリを設定し、RP の用途のために要求される共通属性集合を含めます。加入者がエンタープライズサービスへログインすると、その接続は trust agreement により信頼済みとして確立されているため、サービスに関するランタイム判断を求められません。trust agreement の詳細は IdP から加入者へ提供され、RP に開示される属性一覧と、その用途が含まれます。

Individual Authorized Party:

同じ機関内で利用可能な別サービス（すなわち別の RP）に対して、別の事前確立 trust agreement が作成されます。この trust agreement は、RP への属性情報の開示に関する authorized party が加入者であることを規定します。各加入者は、サービスへログインする際に、属性を RP に開示する同意を求められます。プロンプトには、加入者が適切なセキュリティ判断を行えるための文脈が含まれ、trust agreement の詳細へのリンクと、開示される属性一覧および用途が示されます。IdP は加入者にこの同意判断を保存させ、将来この加入者が同じ RP にログインするとき、trust agreement と RP の要求が変わらない限り、加入者は再度同意を求められません。

Subscriber-Driven Service Access:

加入者主導の trust agreement は、加入者が自身の IdP にとって未知の RP へアクセスする際に確立されます。RP は IdP に要求するすべての属性の用途を加入者へ通知し、IdP は加入者に属性を RP へ開示する同意を求めます。IdP はさらに、RP が機関にとって未知であることを加入者へ警告し、加入者が安全な判断を下すために、RP から受け取った情報を加入者に提供します。

これらのシナリオはいずれも、同一の加入者アカウントに関するものです。

9.11. Shared Pairwise Pseudonymous Identifiers for Multiple RPs

3 つのアプリケーション群が、特定ミッションを支えるために展開され、コラボレーション、文書保管、カレンダー機能を可能にします。個別アプリケーションの性質により、これらは別々の RPs として展開されますが、共通の trust agreement を用いて同一 IdP に紐づけられます。trust agreement は、3 つの RPs に shared PPI を発行し、アプリケーションが個別加入者アカウントを相互に連携できる一方で、他アプリケーションとは連携できないようにすることを規定します。IdP は、アプリケーション群のためのランダム化識別子と、各加入者アカウントの固有識別子を組み込むアルゴリズムを用いて shared PPI を生成します。その結果、3 つの RPs は加入者ごとに同一の PPI を取得しますが、他の RP には同じ識別子は発行されません。

9.12. RP Authentication to an IdP

フェデレーション取引は通常、複数のネットワーク呼び出しにまたがって行われます。このプロセス全体を通じて、IdP と RP は、前段階と同じ当事者と話していること、そして最終的には、取引相手として期待している当事者と話していることを把握する必要があります。

異なる技術は、フェデレーションプロトコルの種類やシステム要件に応じて異なる保証度を提供します。例えば、[OIDC] の Authorization Code Flow により、RP は取引前に shared secret または private key を IdP に登録でき、バックチャネルで assertion を取得するための RP の要求を IdP が強力に認証できます。さらに、[RFC7636] の Proof Key for Code Exchange プロトコルにより、RP は推測不可能な secret を動的に作成し、それをフロントチャネルではハッシュ化した形で送信し、その後 assertion reference とともにバックチャネルで完全な形で送信できます。これらの技術を組み合わせることで、より高い保証が得られます。

フェデレーション当局は認証プロセスを支援することもできます。RP が自分の public key と identifier をフェデレーション当局に登録している場合、IdP は、RP が事前に自己登録することを要求する代わりに、フェデレーション当局から適切な verification keys を取得するだけで済みます。

特定のフェデレーションプロトコルの技術プロファイルは本ガイドラインのスコープ外ですが、[FAPI] のような高セキュリティプロファイルは、実装者が安全なフェデレーションプロトコルを展開するための広範なガイドラインを提供します。

9.13. Cloud Wallet

ある機関の CSP は、加入者が属性バンドルをクラウドホスト型のウォレットサービスへ発行できるようにします。このシナリオでは、CSP は加入者の代理として、専用のオンボーディングプロセスを通じてクラウドウォレットサービスをオンボードします。加入者はクラウドウォレットに認証し、CSP におけるクラウドウォレットのオンボーディングプロセスを開始します。加入者は CSP に認証し、クラウドウォレットへの属性バンドル発行を承認します。CSP は属性バンドルを生成してクラウドウォレットへ配信し、クラウドウォレットは加入者の代理として属性バンドルを保管します。

後に加入者が RP へ認証する必要がある場合、加入者は RP に対して自身のクラウドウォレットを使用するよう指示します。RP はクラウドウォレットとのフェデレーション取引を開始します。クラウドウォレットは加入者に認証と、属性バンドルを RP に開示する同意を求めます。クラウドウォレットは assertion を生成して RP に配信します。RP は assertion と CSP からの属性バンドルを検証します。

References

This section is informative.

[[ACCOUNT-CHOOSER]] Dingle P, Bray T (2015) OpenID AccountChooser Basic API Profile 1.0.（OpenID Foundation, San Ramon, CA）入手先: openid.net/wordpress-content/uploads/2011/12/account-chooser-basic1.html

[[E-Gov]] E-Government Act of 2002, P.L. 107-347, 116 Stat. 2899, 44 U.S.C. § 101 (2002). 入手先: gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf

[[FAPI]] Fett D, Bradley J, Heenan J (2024), FAPI 2.0 Security Profile (draft).（OpenID Foundation, San Ramon, CA）入手先: openid.bitbucket.io/fapi/fapi-2_0-security-profile.html

[[FEDRAMP]] General Services Administration (2022), How to Become FedRAMP Authorized. 入手先: fedramp.gov/

[[FIPS140]] National Institute of Standards and Technology (2019) Security Requirements for Cryptographic Modules.（U.S. Department of Commerce, Washington, DC）, Federal Information Processing Standards Publication (FIPS) FIPS Pub 140-3. doi:10.6028/NIST.FIPS.140-3

[[iGov]] Varley M, Grassi P (2023) International Government Assurance Profile (iGov) for OpenID Connect 1.0 - draft 04.（OpenID Foundation, San Ramon, CA）入手先: openid.net/specs/openid-igov-openid-connect-1_0.html

[[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）入手先: iso.org/standard/63500.html

[[ISO/IEC18013-5]] International Standards Organization (2021) ISO/IEC 18013-5 Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application.（ISO, Geneva, Switzerland）入手先: iso.org/obp/ui/en/#iso:std:iso-iec:18013:-5:ed-1:v1:en

[[NISTIR8062]] Brooks S, Garcia M, Lefkovitz N, Lightman S, Nadeau E (2017) An Introduction to Privacy Engineering and Risk Management in Federal Systems.（National Institute of Standards and Technology, Gaithersburg, MD）, NIST IR 8062, January 2017. doi:10.6028/NIST.IR.8062

[[NISTIR8112]] Grassi PA, Lefkovitz NB, Nadeau EM, Galluzzo RJ, Dinh AT (2018) Attribute Metadata: A proposed Schema for Evaluating Federated Attributes.（National Institute of Standards and Technology, Gaithersburg, MD）, NIST IR 8112. 入手先: pages.nist.gov/NISTIR-8112/NISTIR-8112.html

[[NIST-Privacy]] 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 CSWP 10. doi:10.6028/NIST.CSWP.10

[[OIDC]] Sakimura N, Bradley J, Jones M, de Medeiros B, Mortimore C (2014) OpenID Connect Core 1.0 incorporating errata set 1.（OpenID Foundation, San Ramon, CA）入手先: openid.net/specs/openid-connect-core-1_0.html

[[OIDC-Basic]] Sakimura N, Bradley J, Jones M, de Medeiros B, Mortimore C (2022) OpenID Connect Basic Client Implementer’s Guide 1.0.（OpenID Foundation, San Ramon, CA）入手先: openid.net/specs/openid-connect-basic-1_0.html

[[OIDC-Implicit]] Sakimura N, Bradley J, Jones M, de Medeiros B, Mortimore C (2022) OpenID Connect Implicit Client Implementer’s Guide 1.0.（OpenID Foundation, San Ramon, CA）入手先: openid.net/specs/openid-connect-implicit-1_0.html

[[OIDC-Registration]] Sakimura N, Bradley J, Jones M (2023) OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2.（OpenID Foundation, San Ramon, CA）入手先: openid.net/specs/openid-connect-registration-1_0.html

[[OIDC4VCI]] Lodderstedt T, Yasuda K, Looker T (2024) OpenID for Verifiable Credential Issuance First Implementer’s Draft.（OpenID Foundation, San Ramon, CA）入手先: openid.net/specs/openid-4-verifiable-credential-issuance-1_0-ID1.html

[[OIDC4VP]] Terbu O, Lodderstedt T, Yasuda K, Looker T (2023) OpenID for Verifiable Presentations Second Implementer’s Draft.（OpenID Foundation, San Ramon, CA）入手先: openid.net/specs/openid-4-verifiable-presentations-1_0-ID2.html

[[OIDFed]] Hedberg R, Jones M, Solberg A, Bradley J, De Marco G, Dzhuvinov V (2024) OpenID Federation 1.0 - draft 41.（OpenID Foundation, San Ramon, CA）入手先: openid.net/specs/openid-federation-1_0.html

[[PrivacyAct]] Privacy Act of 1974, Pub. L. 93-579, 5 U.S.C. § 552a, 88 Stat. 1896 (1974). 入手先: govinfo.gov/content/pkg/USCODE-2020-title5/pdf/USCODE-2020-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.（IETF）, RFC 5280. doi:10.17487/RFC5280

[[RFC7591]] Richer J, Jones M, Bradley J, Machulak M, Hunt P (2015) OAuth 2.0 Dynamic Client Registration Protocol.（IETF, Reston, VA）, RFC 7591. doi:10.17487/RFC7591

[[RFC7636]] Sakimura N, Bradley J, Agarwal N (2015) Proof Key For Code Exchange by OAuth Public Clients.（IETF, Reston, VA）, RFC 7636. doi:10.17487/RFC7636

[[RFC7644]] Hunt P, Grizzle K, Morteza A, Wahlstroem E, Mortimore C (2015) System for Cross-domain Identity Management: Protocol.（IETF, Reston, VA）, RFC 7644. doi:10.17487/RFC7644

[[RFC8446]] Rescorla E (2018) The Transport Layer Security (TLS) Protocol Version 1.3.（IETF）, RFC 8446. doi:10.17487/RFC8446

[[RFC8485]] Richer J (2018) Vectors of Trust.（IETF）, RFC 8485. doi:10.17487/RFC8485

[[RFC9325]] Sheffer Y, Saint-Andre P, Fossati T (2022) Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).（IETF）, RFC 9325. doi:10.17487/RFC9325

[[SAML]] Ragouzis N, Hughes J, Philpott R, Maler E, Madsen P, Scavo T (2008) Security Assertion Markup Language (SAML) V2.0 Technical Overview.（OASIS Open, Woburn, MA）, SAML 2.0. 入手先: docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

[[SAML-Bindings]] Cantor S, Frederick H, Kemp J, Philpott R, Maler M (2005) Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0.（OASIS Open, Woburn, MA）, SAML 2.0. 入手先: docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

[[SAML-WebSSO]] Hughes J, Cantor S, Hodges J, Hirsch F, Mishra P, Philpott R, Maler E (2005) Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0.（OASIS Open, Woburn, MA）, SAML Profiles 2.0. 入手先: docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

[[Section508]] General Services Administration (2022) IT Accessibility Laws and Policies. 入手先: section508.gov/manage/laws-and-policies/

[[SD-JWT]] Fett D, Yasuda K, Campbell B (2025) Selective Disclosure for JWTs (SD-JWT).（IETF, Reston, VA）Internet Draft. 入手先: datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

[[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 SP 800-52r2. doi: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 SP 800-53r5（2020-12-10 時点までの更新を含む）doi:10.6028/NIST.SP.800-53r5

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

[[SP800-63]] Temoshok D, Galluzzo R, LaSalle C, Lefkovitz N, Regenscheid A, Choong YY, Proud-Madruga D, Gupta S (2025) Digital Identity Guidelines.（National Institute of Standards and Technology, Gaithersburg, MD）, NIST SP 800-63-4. doi:10.6028/NIST.SP.800-63-4

[[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 SP 800-63A-4. doi:10.6028/NIST.SP.800-63A-4

[[SP800-63B]] Temoshok D, Fenton JL, 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 SP 800-63B-4. doi:10.6028/NIST.SP.800-63B-4

[[SP800-131A]] Barker E, Roginsky A (2019) Transitioning the Use of Cryptographic Algorithms and Key Lengths.（National Institute of Standards and Technology, Gaithersburg, MD）, NIST SP 800-131Ar2. doi:10.6028/NIST.SP.800-131Ar2

[[VC]] Sporny M, Longley D, Chadwick D. (2022) Verifiable Credentials Data Model v1.1.（W3C）W3C Recommendation. 入手先: w3.org/TR/vc-data-model/

List of Symbols, Abbreviations, and Acronyms

AAL\ Authentication Assurance Level

ABAC\ Attribute-Based Access Control

API\ Application Programming Interface

CN\ Common Name

CSP\ Credential Service Provider

CSRF\ Cross-Site Request Forgery

FAL\ Federation Assurance Level

FEDRAMP\ Federal Risk and Authorization Management Program

FIPS\ Federal Information Processing Standards

IAL\ Identity Assurance Level

IdP\ Identity Provider

JWT\ JSON Web Token

MAC\ Message Authentication Code

OIDC\ OpenID Connect

PIA\ Privacy Impact Assessment

PIN\ Personal Identification Number

PKI\ Public-Key Infrastructure

PPI\ Pairwise Pseudonymous Identifier

RP\ Relying Party

SAML\ Security Assertion Markup Language

SAOP\ Senior Agency Official for Privacy

SCIM\ System for Cross-Domain Identity Management

SORN\ System of Records Notice

TLS\ Transport Layer Security

XSS\ Cross-Site Scripting

Glossary

This section is informative.

デジタル ID の領域では、多種多様な用語が使われます。多くの定義は SP 800-63 の以前の版と整合していますが、本改訂で変更されたものもあります。これらの用語の多くは単一で一貫した定義を欠くため、ここでの定義に注意深く目を向ける必要があります。

account linking\ 複数の federated identifiers を単一の RP subscriber account に関連付けること、またはその関連付けの管理。

account resolution\ federation transaction および trust agreement の外側で、RP が事前に保持している情報に基づいて、RP subscriber account を関連付けること。

activation factor\ multi-factor authenticator による authentication を成功させるために使用される追加の authentication factor。

allowlist\ ポリシー判断に従って許可される特定要素の、文書化された一覧。federation の文脈では、subscriber の介入なしに IdP へ接続できる RPs の一覧を指すことが最も一般的。この概念は歴史的に whitelist と呼ばれてきた。

approved cryptography\ 暗号化アルゴリズム、hash function、乱数ビット生成器、または同様の技法で、FIPS により承認されるか NIST が推奨するもの。承認されたアルゴリズムおよび技法は、FIPS または NIST の推奨により指定または採用される。

assertion\ subscriber の認証イベントに関する情報を含む、IdP から RP への声明。Assertions には、attribute values、derived attribute values、および attribute bundles の形で、加入者の ID attributes が含まれることもある。

assertion injection attack\ フェデレーテッドプロトコルの文脈において、攻撃者が assertion または assertion reference を脆弱な RP に注入することで、RP に不正な assertion を受け入れ／処理させて RP へのアクセスを得る、または正当な subscriber のアクセスを拒否する攻撃。

assertion reference\ assertion と併せて作成され、authenticated protected channel 上で assertion を取得するために RP が用いるデータオブジェクト。

assertion presentation\ assertion を RP へ伝送する方法。

asymmetric keys\ public key と private key からなる 2 つの関連 cryptographic keys で、暗号化／復号、署名検証／生成などの補完的操作を行うために使用される。

attribute\ 誰かまたは何かに帰属する性質または特性。identity attribute は subscriber の ID に関する attribute（例：氏名、生年月日、住所）。

attribute bundle\ CSP からの attribute values と derived attribute values のパッケージ。このパッケージは、CSP または IdP との相互作用から独立に validation を可能にするための必要な暗号学的保護を備える。attribute bundles は、加入者管理のウォレットと併用されることが多い。

attribute provider\ subscriber が RP に存在することを必ずしも主張せずに、加入者の attributes へのアクセスを提供する identity API の提供者。

attribute value\ フォーマットに依存せず、subscriber の identity attribute を主張する完全な記述。例えば、attribute が “birthday” の場合、値は “12/1/1980” や “December 1, 1980” となり得る。

audience restriction\ メッセージを特定の対象（audience）に制限し、受信者が意図しない別受信者向けメッセージを無自覚に processing することを防ぐ制約。federation protocols では、assertions は特定の RPs へ audience-restricted され、別の RP 向けに生成された assertion を誤って受け入れることを防ぐ。

authenticate\ authentication を参照。

authenticated protected channel\ 受信者（サーバ）を開始者（クライアント）が authenticated した上で、approved cryptography を用いて暗号化される通信チャネル。authenticated protected channels は、機密性と能動的中間者に対する保護を提供し、ユーザー authentication プロセスで頻繁に用いられる。TLS と DTLS は、開始者が受信者の証明書を検証する authenticated protected channel の例である。特段の指定がない限り、authenticated protected channels はサーバがクライアントを認証することを要求しない。サーバ認証は、通常、信頼されたルートへ至る証明書チェーンにより達成される。

authenticated session\ protected session を参照。

authentication\ claimant が、subscriber account に紐づけられた 1 つ以上の authenticators の所持および制御を証明し、当該アカウントに関連付けられた subscriber であることを示すプロセス。

authentication assurance level (AAL)\ authentication プロセスの強度を表すカテゴリ。

authentication key\ authenticator が authenticator output を生成するために使用する private または対称鍵。

authenticator\ subscriber が所持し制御するもの（例：cryptographic module や password）で、claimant の身元を authenticate するために使用される。authenticator type および multi-factor authenticator も参照。

authenticator binding\ 特定の authenticator と subscriber account の関連付けを確立し、その authenticator が（他の authenticators と併用される場合も含め）当該アカウントの subscriber を認証できるようにすること。

authorize\ アクセスを付与する判断。通常は subject の attributes を評価することで自動化される。

Change Log

This appendix is informative.

本付録は、SP 800-63C の初版以降に行われた変更の概要を示します。

trust agreements と registration/discovery（鍵確立）を、フェデレーションプロセスにおける独立したステップとして確立する。
すべての FAL に、trust agreements の確立と registration に関する要件がある。
FAL の定義は、暗号化要件をもはや含まない。代わりに、FAL に関係なく、assertion 内の個人情報が信頼できない当事者を通過する場合に暗号化が発動する。
FAL2 は assertion 注入保護を要求する。
FAL3 は、古典的な holder-of-key assertions に加え、RP 管理の authenticators を含む、より一般的な bound authenticators を許容する。
IAL/AAL/FAL の伝達を要求する。
RP subscriber accounts の定義と議論を追加する。
RP subscriber account のプロビジョニングモデルと議論を追加する。
general-purpose IdPs から分離された特定要件を持つ加入者管理ウォレットモデルを追加する。
コア文書セクションを再構成し、共通要件、general-purpose 要件、加入者管理ウォレット要件を別セクションで扱う。
IdPs と RPs の救済（redress）要件を追加する。
明示的な例を含むエンタープライズおよび動的ユースケースを全体に追加する。

NIST SP 800-63C-4

ABSTRACT

Keywords

Preface

Table of Contents

1. Introduction

1.1. Notations

1.1.1. Cryptographic Terminology

1.2. Document Structure

2. Federation Assurance Level (FAL)

2.1. Common FAL Requirements

2.2. Federation Assurance Level 1 (FAL1)

2.3. Federation Assurance Level 2 (FAL2)

2.4. Federation Assurance Level 3 (FAL3)

2.5. Requesting and Processing xALs

3. Common Federation Requirements

3.1. Federation Models

3.2. Roles

3.2.1. Credential Service Provider (CSP)

3.2.2. Identity Provider (IdP)

3.2.3. Relying Party (RP)

3.3. Functions

3.3.1. Trust Agreement Management

3.3.2. Authorized Party

3.3.3. Proxied Federation

3.3.4. Fulfilling Roles and Functions of a Federation Model

3.4. Federated Identifiers

3.4.1. Pairwise Pseudonymous Identifiers (PPI)

General Requirements

Pairwise Pseudonymous Identifier Generation

Shared Pairwise Pseudonymous Identifiers

3.5. Trust Agreements

3.5.1. Bilateral Trust Agreements

3.5.2. Multilateral Trust Agreements

3.5.3. Redress Requirements

3.6. Identifiers and Cryptographic Key Management for CSPs, IdPs, and RPs

3.6.1. Cryptographic Key Rotation

3.6.2. Cryptographic Key Storage

3.6.3. Software Attestations

3.7. Authentication and Attribute Disclosure

3.8. RP Subscriber Accounts

3.8.1. Account Linking

3.8.2. Account Resolution

3.8.3. Alternative Authentication Processes

3.9. Authenticated Sessions at the RP

3.10. Privacy Requirements

3.10.1. Transmitting Subscriber Information

3.10.2. Sharing Information Between CSPs

3.11. Security Controls

3.11.1. Protection From Assertion Injection Attacks

3.11.2. Protecting Subscriber Information

3.11.3. Storing Subscriber Information

3.12. Identity Attributes

3.12.1. Attribute Bundles

3.12.2. Derived Attribute Values

3.12.3. Identity APIs

External Identity APIs

3.13. Assertion Protection

3.13.1. Assertion Identifier

3.13.2. Signed Assertion

3.13.3. Encrypted Assertion

3.13.4. Audience Restriction

3.14. Bearer Assertions

3.15. Holder-of-Key Assertions

3.16. Bound Authenticators

3.16.1. RP-Provided Bound Authenticator Issuance

3.16.2. Subscriber-Provided Bound Authenticator Binding Ceremony

3.17. RP Processing of Holder-of-Key Assertions and Bound Authenticators

4. General-Purpose IdPs

4.1. IdP Account Provisioning

4.2. Federation Transaction

4.3. Trust Agreements

4.3.1. Pre-Established Trust Agreements

4.3.2. Subscriber-Driven Trust Agreement Establishment

4.4. Discovery and Registration

4.4.1. Manual Registration

4.4.2. Dynamic Registration

4.5. Subscriber Authentication at the IdP

4.6. Authentication and Attribute Disclosure

4.6.1. IdP-Controlled Decisions