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

ABSTRACT

These guidelines provide technical requirements for federal agencies implementing digital identity services and are not intended to constrain the development or use of standards outside of this purpose. This guideline focuses on the use of federated identity and the use of assertions to implement identity federations. Federation allows a given credential service provider to provide authentication attributes and (optionally) subscriber attributes to a number of separately-administered relying parties. Similarly, relying parties may use more than one credential service provider. This publication will supersede NIST Special Publication (SP) 800-63C.

Keywords

assertions; authentication; credential service provider; digital authentication; electronic authentication; electronic credentials; federations.

Note to Reviewers

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

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

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

Revision 4 of NIST Special Publication 800-63, Digital Identity Guidelines, intends to respond to the changing digital landscape that has emerged since the last major revision of this suite was published in 2017 — including the real-world implications of online risks. The guidelines present the process and technical requirements for meeting digital identity management assurance levels for identity proofing, authentication, and federation, including requirements for security and privacy as well as considerations for fostering equity and the usability of digital identity solutions and technology.

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

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

1. 更なる公平性: このドラフトは，以前の改訂のリスク管理の内容を拡張することを目指しており，組織への影響に加えて，個人やコミュニティへの影響を説明することを機関に明確に義務付けている．また，リスク管理プロセス内およびデジタルアイデンティティシステムの実装時に，ミッションの提供に対するリスクを高める．これには，資格のあるすべての人にサービスを提供するという課題が含まれる．さらに，ガイダンスは現在，人口統計全体にわたる，潜在的な影響の継続的な評価を義務付けており，生体認証のパフォーマンス要件，および顔認識を利用するものなどの生体認証ベースの技術の責任ある使用のための追加のパラメーターを提供している．

1. Advance Equity: This draft seeks to expand upon the risk management content of previous revisions and specifically mandates that agencies account for impacts to individuals and communities in addition to impacts to the organization. It also elevates risks to mission delivery – including challenges to providing services to all people who are eligible for and entitled to them – within the risk management process and when implementing digital identity systems. Additionally, the guidance now mandates continuous evaluation of potential impacts across demographics, provides biometric performance requirements, and additional parameters for the responsible use of biometric-based technologies, such as those that utilize face recognition.

1. 消費者の選択性と選択肢の強調: 顔認識技術を利用するものや利用しないものを含む，追加のスケーラブルで公平で便利な身元確認オプションを促進および調査するために，このドラフトは，さまざまな手段，動機，および背景を持つ個人にサービスを安全に提供するための新しいメカニズムを提供するための身元確認の代替手段として許容可能なリストを拡大する．この改訂では，多様な消費者のニーズに対応し，アカウントを安全に復元するために，デジタルアイデンティティサービスが複数の認証オプションをサポートする必要性も強調している．

1. Emphasize Optionality and Choice for Consumers: In the interest of promoting and investigating additional scalable, equitable, and convenient identify verification options, including those that do and do not leverage face recognition technologies, this draft expands the list of acceptable identity proofing alternatives to provide new mechanisms to securely deliver services to individuals with differing means, motivations, and backgrounds. The revision also emphasizes the need for digital identity services to support multiple authenticator options to address diverse consumer needs and secure account recovery.

1. 詐欺と高度な脅威の抑止: このドラフトは，新しい攻撃に対応するためにリスクと脅威のモデルを更新し，フィッシング耐性のある認証のための新しいオプションを提供し，登録プロセスに対する自動化された攻撃を防止するための要件を導入することにより，第3版の詐欺防止対策を強化する．また，モバイル運転免許証(mDL)や verifiable credentials などの新しいテクノロジーへの扉も開く．

1. Deter Fraud and Advanced Threats: This draft enhances fraud prevention measures from the third revision by updating risk and threat models to account for new attacks, providing new options for phishing resistant authentication, and introducing requirements to prevent automated attacks against enrollment processes. It also opens the door to new technology such as mobile driver’s licenses and verifiable credentials.

1. 実装で学んだ教訓への対処: このドラフトでは，実装の経験から，ガイドラインを効果的に運用するために追加の明確さや詳細が必要であることが示された領域に対処している．これには，フェデレーションの保証レベルの見直し，Trusted Referee に関する詳細の提供，属性の検証ソースに関するガイドラインの明確化，アドレス確認要件の改善が含まれる．

   1. Address Implementation Lessons Learned: This draft addresses areas where implementation experience has indicated that additional clarity or detail was required to effectively operationalize the guidelines. This includes re-working the federation assurance levels, providing greater detail on Trusted Referees, clarifying guidelines on identity attribute validation sources, and improving address confirmation requirements.

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

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

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

• これまでガイドラインで議論されていなかったアイデンティティおよびプロビジョニングAPI の使用を説明するために，どのような追加のプライバシーの考慮事項 (同意の取り消し，使用の制限など) が必要になる可能性があるか?
• 更新されたテキストと「bound authenticators」の導入は、フェデレーション保証レベル (FAL) 3 のトランザクションの実用的な実装を可能にするのに十分明確か? 更新されたガイダンスに基づいて，どのような混乱や課題が予想されるか?

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

• このガイダンスに欠けている，または拡張できると思われる要素はあるか?
• ガイダンスに分かりにくい，または理解しにくい文言はあるか? 任意の言語に，定義または追加のコンテキストを追加する必要があるか?
• ガイダンスはプライバシーに十分に対処しているか?
• ガイダンスは公平性に十分に対応しているか?
  • 身元確認技術またはプロセスの結果として生じる可能性のあるさまざまな影響を防止または検出する際に組織をより適切にサポートするために，どのような公平性評価方法，影響評価モデル，または指標を参照できるか?
• どの特定の実装ガイダンス，リファレンスアーキテクチャ，メトリック，またはその他のサポートリソースが，デジタルアイデンティティガイドラインの今回および将来の反復においてより迅速な採用と実装を可能にするか?
• アイデンティティ市場とこれらのガイドラインの進歩に最大の影響を与える応用研究と測定の取り組みは何か?

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

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

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

Purpose

This section is informative.

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

This document, SP 800-63C, provides requirements to identity providers (IdPs) and relying parties (RPs) of federated identity systems. Federation allows a given IdP to provide authentication attributes and (optionally) subscriber attributes to a number of separately-administered RPs through the use of federation protocols and assertions. Similarly, RPs can use more than one IdP as sources of identities.

はじめに (Introduction)

This section is informative.

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

Federation is a process that allows for the conveyance of authentication attributes and subscriber attributes across networked systems. In a federation scenario, the CSP provides a service known as an identity provider, or IdP. The IdP acts as a verifier for authenticators issued by the CSP. The IdP sends a message, called an assertion, about this authentication event to the RP. The RP receives the assertion provided by the IdP and uses it for authentication and authorization decisions, but the RP does not verify the authenticator directly.

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

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

フェデレーションアイデンティティシナリオでは，加入者(subscriber)は RP に対して直接認証されない． 代わりに，フェデレーションプロトコルは，通常，RP からの明示的な要求に応答して，IdP が加入者(subscriber)に関連付けられたアサーションを生成するメカニズムを定義する．IdP は加入者(subscriber)の認証を担当する([SP800-63B]の7章 で説明されているように，セッション管理を使用する場合がある)．フェデレーションプロセスにより，加入者(subscriber)は，各 RP で個別のオーセンティケータを保持または維持する必要なく，複数の RP のサービスを利用できる．このプロセスは「シングル サインオン」と呼ばれることもある．

In a federated identity scenario, the subscriber does not authenticate directly to the RP. Instead, the federation protocol defines a mechanism for an IdP to generate an assertion associated with a subscriber, generally in response to an explicit request from the RP. The IdP is responsible for authenticating the subscriber (though it may use session management as described in [SP800-63B], Sec. 7). The federation process allows the subscriber to obtain services from multiple RPs without the need to hold or maintain separate authenticators at each RP, a process sometimes known as single sign-on.

加入者(subscriber)は，フェデレーション識別子によって RP に対して一意に識別される．これは，IdP によってアサートされる サブジェクト識別子 と IdP 自体の一意の識別子の論理的な組み合わせである．異なる IdP がそれぞれのサブジェクト識別子を個別に管理し，異なるサブジェクトに対するサブジェクト識別子の選択で衝突する可能性があるため，このマルチパート識別子パターンは必要である．したがって，どの IdP がそのサブジェクト識別子 を発行したかを考慮せずに，RP がサブジェクト識別子を処理しないことが不可欠である．

The subscriber is uniquely identified to the RP by a federated identifier, which is a logical combination of the subject identifier as asserted by the IdP as well as a unique identifier for the IdP itself. This multi-part identifier pattern is required because different IdPs manage their subject identifiers independently, and could therefore potentially collide in their choices of subject identifiers for different subjects. Therefore, it is imperative that an RP never process the subject identifier without taking into account which IdP issued that subject identifier.

アサーションには加入者(subscriber)のフェデレーション識別子が含まれており，加入者(subscriber)と，複数の認証済みセッションを介した RP との対話との関連付けを可能にする．アサーションには，加入者(subscriber)をさらに特徴付けてRP での承認決定をサポートする，属性値または派生属性値も含まれる場合がある．追加の属性は，より大きなフェデレーションプロトコルの一部として，アサーションの外部でも使用できる場合がある．これらの属性値と派生属性値は，属性ベースのアクセス制御 (ABAC) のアクセス権限を決定したり，トランザクションを促進したり (配送先住所の提供など) する際によく使用される．

An assertion includes a federated identifier for the subscriber, allowing association of the subscriber with their interactions with the RP over multiple authenticated sessions. Assertions may also include attribute values or derived attribute values that further characterize the subscriber and support authorization decisions at the RP. Additional attributes may also be available outside of the assertion as part of the larger federation protocol. These attribute values and derived attribute values are often used in determining access privileges for attribute-based access control (ABAC) or facilitating a transaction (e.g., providing a shipping address).

フェデレーションには，緻密なセキュリティとプライバシーの要件を持つ比較的複雑なマルチパーティプロトコルが必要である．特定のフェデレーション構造を評価するときは，それを構成要素の相互作用 (IdP への加入者(subscriber)，RP への IdP，RP への加入者(subscriber)) に分割することが有益な場合がある．フェデレーションプロトコルの各当事者は，フェデレーションシステムが意図したとおりに機能するために満たされなければならない特定の責任と期待を負う．

Federation requires relatively complex multiparty protocols that have subtle security and privacy requirements. When evaluating a particular federation structure, it may be instructive to break it down into its component interactions: the subscriber to the IdP, the IdP to the RP, and the subscriber to the RP. Each party in a federation protocol bears specific responsibilities and expectations that must be fulfilled in order for the federated system to function as intended.

IdP は，[SP800-63A] で定義された 加入者(subscriber)アカウント をフェデレーション固有のアイテムのセットで補強する加入者(subscriber)のレコードを維持する．以下を含むがこれらに限定されない:

• フェデレーションプロトコルで使用するための1つまたは複数の外部サブジェクト識別子
• アクセス権のセット．どの RP が加入者(subscriber)アカウントのどの属性にアクセスできるか，詳細を記す(加入者(subscriber)による実行時の決定など)．
• フェデレーションアカウントの使い方の情報
• IdP によって加入者(subscriber)に収集または割り当てられる追加の属性

The IdP maintains a record for the subscriber that augments the subscriber account defined in [SP800-63A] with a set of federation-specific items, including but not limited to the following:

• One or more external subject identifiers, for use with a federation protocol
• A set of access rights, detailing which RPs can access which attributes of the subscriber account (such as runtime decisions by the subscriber)
• Federated account usage information
• Additional attributes collected or assigned by the IdP to the subscriber

RP は多くの場合，加入者(subscriber)の RP 加入者(subscriber)アカウント を維持する．これは，IdP によって RP に開示され拡張された加入者(subscriber)アカウント情報から派生する．Sec. 5.4 で説明されているように，RP 加入者(subscriber)アカウントには，RP 自体にローカルな情報も含まれている．

The RP often maintains an RP subscriber account for the subscriber, which is derived from the augmented subscriber account information disclosed to the RP by the IdP. The RP subscriber account also contains information local to the RP itself, as described in Sec. 5.4.

本書の要件は，これらのガイドラインの他のボリュームの要件に基づいている．加入者(subscriber)と IdP の間の認証は，[SP800-63B] に示されている認証メカニズムに基づいており，フェデレーションプロトコルは[SP800-63A] の手順を使用して IdP で確立された属性を RP に伝達する．

The requirements in this document build on the requirements in the other volumes of these guidelines. Authentication between the subscriber and the IdP will be based on the authentication mechanisms presented in [SP800-63B], while the federation protocol will convey attributes to the RP established at the IdP using procedures in [SP800-63A] (along with other attributes).

次の表は，本書のどの章が normative で，どの章が informative であるかを示す．

• 1 目的 Informative
• 2 はじめに Informative
• 3 定義と略語 Informative
• 4 フェデレーション保証レベル (FAL) Normative
• 5 フェデレーション Normative
• 6 アサーション Normative
• 7 アサーションの提示 Normative
• 8 セキュリティ Informative
• 9 プライバシーに関する考慮事項 Informative
• 10 ユーザビリティに関する考慮事項 Informative
• 11 公平性に関する考慮事項 Informative
• 12 例 Informative
• 参考文献 Informative

The following table states which sections of the document are normative and which are informative:

• 1 Purpose Informative
• 2 Introduction Informative
• 3 Definitions and Abbreviations Informative
• 4 Federation Assurance Level (FAL) Normative
• 5 Federation Normative
• 6 Assertion Normative
• 7 Assertion Presentation Normative
• 8 Security Informative
• 9 Privacy Considerations Informative
• 10 Usability Considerations Informative
• 11 Equity Considerations Informative
• 12 Examples Informative
• References Informative

定義と略語 (Definitions and Abbreviations)

See [SP800-63], Appendix A for a complete set of definitions and abbreviations.

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

This section is normative.

この章では，フェデレーション保証レベル (FAL) を定義する．FAL は，IdP と RP の間の関係を確立する方法や，アサーションを提示・保護する方法など，フェデレーショントランザクションを保護するための要件を示している．これらのレベルは，実行時に RP によって要求されるか，特定のトランザクションにおける RP と IdP の両方の configuration によって要求される． FAL は，アサーションを受け取る RP に対する保証と，RP が利用するアサーションを作成する IdP に対する保証を提供する．

This section defines allowable federation assurance levels (FALs). The FAL describes requirements for securing federation transactions, including requirements on how relationships between IdPs and RPs are established and how assertions are presented and protected. These levels can be requested by an RP at runtime or required by the configuration of both the RP and the IdP for a given transaction. The FAL provides assurances for the RP receiving the assertion as well as assurances for the IdP creating the assertion to be used by an RP.

多くの異なるフェデレーション実装オプションが可能である中，FAL は，より安全な展開オプションを表す明確なガイダンスを提供することを目的としている．最も適切な FAL を選択する方法の詳細については、[SP800-63] を参照．

While many different federation implementation options are possible, the FAL is intended to provide clear guidance representing increasingly secure deployment options. See [SP800-63] for details on how to choose the most appropriate FAL.

各 FAL は，FAL が増加するにつれてセキュリティと複雑さが増す一連の要件によって特徴付けられる．これらの要件は以下にリストされており，本書の他のセクションで展開される．

Each FAL is characterized by a set of requirements that increase the security and complexity as the FAL increases. These requirements are listed here and expanded in other sections of this document:

暗号の検証可能性

フェデレーションプロトコルで提示されたアサーションは，それを発行した特定の IdP まで追跡可能であり，その接続はデジタル署名や MAC などの暗号化メカニズムで検証可能である．これにより，RP は，アサーションが変更または偽造されていないことを確認することも可能である．本項目は，すべての FAL で必須である．

Cryptographic Verifiability

The assertion presented in the federation protocol is traceable back to a specific IdP that issued it, and that connection can be verified with a cryptographic mechanism such as a digital signature or MAC. This also allows the RP to verify that the assertion was not modified or forged. This is required at all FALs.

対象者（Autience） の制約

フェデレーションプロトコルで提示されるアサーションは特定の RP を対象としており，RP はアサーションの対象者であることを確認することができる．本項目は，すべての FAL で必須である．

Audience Restriction

The assertion presented in the federation protocol is targeted to a specific RP and the RP can verify that it is the intended audience of the assertion. This is required at all FALs.

インジェクション保護

RP は，現在のフェデレーショントランザクションリクエスト以外の状況でアサーションを提示する攻撃者から強力に保護される．

Injection Protection

The RP is strongly protected from an attacker presenting an assertion in circumstances outside a current federation transaction request.

信頼の合意(Trust Agreement)

IdP と RP は，加入者（subscriber）が RP にログインする目的で，相互にフェデレーショントランザクションに参加することに同意する．これは，当事者間の静的な合意にまでさかのぼる，あるいは，接続自体から暗黙的に発生する可能性がある．

Trust Agreement

The IdP and RP have agreed to participate in a federation transaction with each other for the purposes of logging in the subscriber to the RP. This can be traced back to a static agreement between the parties or occur implicitly from the connection itself.

登録

IdP と RP は，将来のフェデレーショントランザクション中にアサーションやその他のアーティファクトを検証できるように，識別子とキー マテリアルを交換する．

Registration

The IdP and RP have exchanged identifiers and key material to allow for the verification of assertions and other artifacts during future federation transactions.

提示

アサーションは，単独で（ベアラ アサーションとして）RP に提示することも，加入者（subscriber）によって提示された bound authenticator と連携して提示することもできる．

Presentation

The assertion can be presented to the RP either on its own (as a bearer assertion) or in concert with a bound authenticator presented by the subscriber.

表1 は，各 FAL の非規範的な側面の要約を示す．連続する各レベルは，下位レベルのすべての要件を包含し，満たす (たとえば，FAL3 でのフェデレーションプロセスは，FAL2 や FAL1 で受け入れられる．これは，FAL3 がこれらの下位レベルの要件をすべて満たしているからである)． 表1 にない組み合わせも可能だが，ここでは範囲外としている．

表1 フェデレーションアサーション レベル

Table 1 provides a non-normative summary of aspects for each FAL. Each successive level subsumes and fulfills all requirements of lower levels (e.g., a federation process at FAL3 can be accepted at FAL2 or FAL1 since FAL3 satisfies all the requirements of these lower levels). Combinations not found in the Table 1 are possible but outside the scope of this volume.

Table 1 Federation Assertion Levels

FAL	Injection Protection	Trust Agreement	Registration	Presentation
1	Recommended	Dynamic or Static	Dynamic or Static	Bearer Assertion
2	Required	Static	Dynamic or Static	Bearer Assertion
3	Required	Static	Static	Assertion and Bound Authenticator

すべての FAL で，すべてのアサーションは，Sec. 5で説明されているようにフェデレーションプロトコルと共に使用しなければならない(SHALL)．すべてのアサーションは，Sec. 6で説明されているように，詳細な要件に準拠しなければならない(SHALL)．すべてのアサーションは，Sec. 7で説明されている方法のいずれかを使用して提示しなければならない(SHALL)．フェデレーテッドプロトコルで使用されるアサーションの例には，OpenID Connect の ID トークン [OIDC] や Security Assertion Markup Language [SAML] で記述されたアサーションが含まれる．

At all FALs, all assertions SHALL be used with a federation protocol as described in Sec. 5. All assertions SHALL comply with the detailed requirements in Sec. 6. All assertions SHALL be presented using one of the methods described in Sec. 7. Examples of assertions used in federated protocols include the ID Token in OpenID Connect [OIDC] and assertions written in the Security Assertion Markup Language [SAML].

すべての FAL で，IdP は，[SP800-53]や，同等の連邦の標準(例: [FEDRAMP])，業界標準で定義された中程度または高いセキュリティ制御のベースラインから，適切に調整されたセキュリティ制御（制御の強化を含む）を採用する必要がある．

At all FALs, the IdP SHALL employ appropriately tailored security controls (to include control enhancements) from the moderate or high baseline of security controls defined in [SP800-53] or equivalent federal (e.g., [FEDRAMP]) or industry standard.

Federation Assurance Level 1 (FAL1)

FAL1 では，IdP によって生成されるアサーションは，Sec. 6で定義されている主要な要件をひととおり満たさなければならない(SHALL)（承認された暗号化を使用して IdP によって署名されたアサーションコンテンツを取得することによる，攻撃者による変更や構築から保護を含む）．RP は，Sec. 6で説明されているように，受信時にアサーションの発信元と整合性を検証し，アサーションが期待されるソースから発信されていることを確認しなければならない(SHALL)．

At FAL1, the assertion being generated by the IdP SHALL meet a core set of requirements defined in Sec. 6, including protection against modification or construction by an attacker by having the assertion contents signed by the IdP using approved cryptography. An RP SHALL verify the origin and integrity of the assertion upon receipt, as discussed in Sec. 6, ensuring that the assertion has originated from the expected source.

FAL1 でのすべてのアサーションは，特定の RP または RPのセットに対象者を制限しなければならず(SHALL)，RP はアサーションの対象となる RP の 1 つであることを検証しなければならない(SHALL)．IdP は，承認された暗号化を使用した鍵と署名でアサーションを保護することにより，RP を含むアサーションを保持する当事者が，非対象のRPでIdPになりすますことができないようにしなければならない(SHALL)．アサーションが非対称鍵を使用したデジタル署名によって保護されている場合，IdP は同じ公開鍵と秘密鍵のペアを使用して複数の RP へのアサーションに署名してもよい(MAY)．IdP は，既知の場所にある HTTPS で保護された URL など，検証可能な方法で公開鍵を公開してもよい(MAY)．アサーションが共有鍵を使用する鍵付きメッセージ認証コード(MAC) によって保護されている場合，IdP は RP ごとに異なる共有キーを使用しなければならない(SHALL)．

All assertions at FAL1 SHALL be audience-restricted to a specific RP or set of RPs, and the RP SHALL validate that it is one of the targeted RPs for the given assertion. The IdP SHALL ensure that any party holding the assertion, including the RP, is unable to impersonate the IdP at a non-targeted RP by protecting the assertion with a signature and key using approved cryptography. If the assertion is protected by a digital signature using an asymmetric key, the IdP MAY use the same public and private key pair to sign assertions to multiple RPs. The IdP MAY publish its public key in a verifiable fashion, such as at an HTTPS-protected URL at a well-known location. If the assertion is protected by a keyed message authentication code (MAC) using a shared key, the IdP SHALL use a different shared key for each RP.

FAL1 では，IdP と RP の間の信頼の合意を完全に動的に確立してもよい(MAY)．例えば，加入者(subscriber)が使用できるように RP が IdP のパラメーターを検出して自身を登録することを許容することで，加入者(subscriber)が実行時に選択した RP を IdP に対して識別させることができる．加入者(subscriber)は RP に提供する属性と提供目的を決定するようIdP から求められる．この例では，IdP と RP の間の信頼は，加入者(subscriber)の要望と行動によって完全に決定される．注記：FAL1 では，信頼の合意と登録が静的に行われることもある．

At FAL1, the trust agreement between the IdP and RP MAY be established entirely dynamically. For instance, the subscriber can identify their chosen IdP to the RP at runtime, allowing the RP to discover the IdP’s parameters and register itself for use by the subscriber. The subscriber is prompted by the IdP to determine which attributes are released to the RP, and for what purposes. In this example, the trust between the IdP and RP is driven entirely by the desires and actions of the subscriber. Note that at FAL1, it is still possible for the trust agreement and registration to happen statically.

既存のフェデレーションプロトコルで FAL1 に該当するのは， OpenID Connectの Implicitクライアントプロファイル [OIDC-Implicit]、[OIDC]，OpenID Connectのハイブリッドクライアントプロファイル [OIDC], 追加機能のない SAML Web SSO [SAML-WebSSO] プロファイルであるがあげられる．これらのプロファイルのそれぞれで，アサーションは IdP によって署名され，署名によってカバーされるアサーションの一部で RP が識別される．

In existing federation protocols, FAL1 can be implemented with the OpenID Connect Implicit Client profile [OIDC-Implicit], the OpenID Connect Hybrid Client profile in [OIDC], or the SAML Web SSO [SAML-WebSSO] profile with no additional features. In each of these profiles, the assertion is signed by the IdP and the RP is identified in a portion of the assertion covered by the signature.

Federation Assurance Level 2 (FAL2)

本章でより具体的または厳格な要件によって上書きされる場合を除き，FAL1 のすべての要件は FAL2 にも適用される．

All the requirements for FAL1 apply at FAL2 except where overridden by more specific or stringent requirements here.

FAL2 では，アサーションは，攻撃者によるインジェクションからも強力に保護されなければならない(SHALL)．これを達成するため，アサーション は， OpenID Connect Basic Client プロファイル [OIDC-Basic] のようにSec. 7.1で説明されているバックチャネルで提示する必要がある(SHOULD)．この提示方法では，RP は使い捨てのアサーションリファレンスを使用して IdP からアサーションを直接取得するため，攻撃者が外部アクセスポイントを介してアサーションを挿入することを防ぐ．Sec. 7.2で説明されているフロントチャネルで提示する必要がある場合は，RP によって追加のインジェクション保護が実装されなければならない(SHALL)．

At FAL2, the assertion SHALL also be strongly protected from being injected by an attacker. To accomplish this, the assertion SHOULD be presented using back channel presentation as discussed in Sec. 7.1, as in the OpenID Connect Basic Client profile [OIDC-Basic]. In this presentation method, the RP fetches the assertion directly from the IdP by using a single-use assertion reference, thereby preventing an attacker from injecting the assertions through an external access point. If front channel presentation is used as discussed in Sec. 7.2, additional injection protections SHALL be implemented by the RP.

どちらの提示方法が使われるかによらず，フェデレーショントランザクションが IdP によって開始されるのではなく，RP で開始されることを常に要求することによって，インジェクション攻撃をさらに軽減することができる．これによりRP は，受取ったアサーションを，加入者(subscriber)が連続セッション内で開始した特定の要求と関連付けることができる．

Regardless of the presentation method used, injection attacks can be further mitigated by always requiring that the federation transaction start at the RP instead of being initiated by the IdP, thereby allowing the RP to associate an incoming assertion with a specific request that the subscriber initiated within a continuous session.

FAL2 では，IdP と RP の間の信頼の合意を静的に確立しなければならない(SHALL)．これには，RP で使用できる属性とその目的の制限を設定することも含まれる．この信頼の合意は，IdP と RP の間の二者間でも良く(MAY)，多者間のフェデレーションパートナーシップを使用して管理されても良い(MAY)． RP と IdP が実行時にそれらの間で確立された信頼の合意への接続を証明できる場合，登録は動的に行われても良い(MAY)．このような証明の方法は，フェデレーションプロトコルによって異なるが，ソフトウェアアテステーションの提示や，信頼されたドメインの URL に対する制御の証明を含めることができる．

At FAL2, the trust agreement between the IdP and RP SHALL be established statically, including establishing limits of which attributes are made available to the RP and for what purpose. This trust agreement MAY be bilateral between the IdP and RP or MAY be managed through the use of a multilateral federation partnership. The registration MAY be dynamic, provided that the RP and IdP can prove their connection at runtime to the established trust agreement between them. Such methods for this proof vary by federation protocol, but can include presentation of software attestations and proof of control over URLs at trusted domains.

FAL2 で認証アサーションを発行する(asserting authentication) 政府運営の IdP は，[FIPS140] のレベル 1 以上で検証されたメカニズムを使用して，アサーションの署名や暗号化に使用する鍵を保護しなければならない(SHALL)．

Government-operated IdPs asserting authentication at FAL2 SHALL protect keys used for signing or encrypting those assertions with mechanisms validated at [FIPS140] Level 1 or higher.

Federation Assurance Level 3 (FAL3)

本章でより具体的または厳格な要件によって上書きされる場合を除き，FAL1 並びに FAL2 のすべての要件は FAL3 にも適用される．

All the requirements at FAL1 and FAL2 apply at FAL3 except where overridden by more specific or stringent requirements here.

FAL3 では，加入者(subscriber)は，アサーションの提示に加えて，オーセンティケーターを RP に直接提示することにより RP に対して認証しなければならない(SHALL)．提示されるオーセンティケータは，Sec. 6.1.2で説明されている　bound authenticator　として知られている． 例えば，加入者(subscriber)は IdP と RP でフェデレートされたログインプロセスを実行し，RP は，加入者(subscriber)に，その RPの加入者(subscriber)のアカウントに関連付けられている bound authenticator を要求する．FAL3 で提示される bound authenticator は，加入者(subscriber)が IdP に対して認証するために使用するオーセンティケーターと同じである必要はない．アサーションは RP の加入者(subscriber)を識別するために使用されるが，bound authenticator は，ログインしようとしている当事者がアサーションで識別された加入者(subscriber)であることを非常に高く保証する． 加入者(subscriber)が bound authenticator で認証され，提示されたオーセンティケーターがアサーションによって識別された RP の加入者(subscriber)アカウントに正しくバインドされていることを RP が確認するまで，RP では FAL3 には到達しない．

At FAL3, the subscriber SHALL authenticate to the RP by presenting an authenticator directly to the RP in addition to presenting an assertion. The authenticator presented is known as a bound authenticator, described in Sec. 6.1.2. For example, the subscriber goes through a federated login process at the IdP and RP, and the RP then prompts the subscriber for a bound authenticator that is associated with that RP subscriber account. The bound authenticator presented at FAL3 need not be the same authenticator used by the subscriber to authenticate to the IdP. The assertion is used to identify the subscriber to the RP while the bound authenticator gives very high assurance that the party attempting to log in is the subscriber identified in the assertion. FAL3 is not reached at the RP until the subscriber authenticates with the bound authenticator and the RP verifies that the authenticator presented is correctly bound to the RP subscriber account identified by the assertion.

FAL3 では，IdP と RP の間の信頼の合意と登録を静的に確立しなければならない(SHALL)．すべての当事者 (RP に送信される属性のリストを含む) の，すべての識別キー マテリアルおよびフェデレーションパラメータは，フェデレーション認証プロセスが実行される前に，事前に修正されなければならない(SHALL)． 実行時の決定は，フェデレーション認証プロセスの当事者間で送信されるものをさらに制限するために使用されても良い(MAY)．例えば，実行時の決定では，メールアドレスの属性が信頼の合意のパラメーターに含まれていたとしても，メールアドレスを開示しないことを選択できる．

At FAL3, the trust agreement and registration between the IdP and RP SHALL be established statically. All identifying key material and federation parameters for all parties (including the list of attributes sent to the RP) SHALL be fixed ahead of time, before the federated authentication process can take place. Runtime decisions MAY be used to further limit what is sent between parties in the federated authentication process (e.g., a runtime decision could opt to not disclose an email address even though this attribute was included in the parameters of the trust agreement).

FAL3 で認証アサーションを発行する(asserting authentication) IdP は，[FIPS140] のレベル 1 以上で検証されたメカニズムを使用して，アサーションの署名や暗号化に使用する鍵を保護しなければならない(SHALL)．

IdPs asserting authentication at FAL3 SHALL protect keys used for signing or encrypting those assertions with mechanisms validated at [FIPS140] Level 1 or higher.

xALのリクエストと処理 (Requesting and Processing xALs)

IdP は，さまざまなフェデレーションパラメータを使用して，さまざまなオーセンティケータで，多くの異なる加入者(subscriber)のアイデンティティを示すことができるため，IAL，AAL，FAL は，同じ RP であっても，さまざまなフェデレーションログイン間で異なる可能性がある．

Since an IdP is capable of asserting the identities of many different subscribers with a variety of authenticators using a variety of federation parameters, the IAL, AAL, and FAL could vary across different federated logins, even to the same RP.

RP は，フェデレーショントランザクションごとに次の情報を通知されなければならない(SHALL)．

• RP に提示している加入者(subscriber)アカウントの IAL，または 身元確認(IAL) が行われていないことの表示
• IdP での加入者(subscriber)の現在アクティブなセッションの AAL，または 当人認証(AAL) が行われていないことの表示
• フェデレーショントランザクションの FAL

The RP SHALL be informed of the following information for each federated transaction:

• The IAL of the subscriber account being presented to the RP, or an indication that no IAL claim is being made
• The AAL of the currently active session of the subscriber at the IdP, or an indication that no AAL claim is being made
• The FAL of the federated transaction

RP は，Sec. 5.1で説明されている信頼の合意のパラメーターと、Sec. 6で説明されているアサーションに含まれる情報との組み合わせから，この xAL 情報を取得する．IdP と RP の間のすべてのメッセージで xAL が不変の場合，xAL の情報は IdP と RP の間の信頼の合意のパラメータに含まれなければならない(SHALL)．xAL が異なる場合，Sec. 6 で説明されているように，アサーションの一部として情報を含めなければならない(SHALL)．

The RP gets this xAL information from a combination of parameters in the trust agreement as described in Sec. 5.1 and information included in the assertion as described in Sec. 6. If the xAL is unchanging for all messages between the IdP and RP, the xAL information SHALL be included in the parameters of the trust agreement between the IdP and RP. If the xAL varies, the information SHALL be included as part of the assertion as discussed in Sec. 6.

IdP は，特定のフェデレーショントランザクションについて，身元確認(IAL) または 当人認証(AAL) が行われていないことを示しても良い(MAY)． このような場合，結果の xAL にデフォルト値は割り当てられない．つまり，信頼の合意またはアサーションのいずれかで IAL 宣言のないフェデレーショントランザクションは，機能的には“IALなし“と見なされ，RP は，アカウントがこのスイートで説明されている最小の IAL である“IAL1”を満たしているとみなすことはできない．

The IdP MAY indicate that no claim is made to the IAL or AAL for a given federation transaction. In such cases, no default value is assigned to the resulting xAL. That is to say, a federation transaction without an IAL declaration in either the trust agreement or the assertion is functionally considered to have “no IAL” and the RP cannot assume the account meets “IAL1”, the lowest numbered IAL described in this suite.

RP は，提供された機能へのアクセスのために受け入れても構わないと思っている最小の IAL，AAL，FAL を決定しなければならない(SHALL)．RP は，特定のフェデレーション認証の IAL，AAL，FAL に基づいて，その機能を変更しても良い(MAY)．例えば，RP は一般的な機能 (ダムシステムの状態の表示など) には AAL2 でのログインを許可するが，よりリスクの高い機能 (ダムシステムの流量の変更など) には AAL3 を要求する．同様に，RP は，管理機能を IAL2 で 身元確認された特定の加入者(subscriber)アカウントのみに制限しつつ，IAL に関係なくすべての加入者(subscriber)アカウントからのログインを許可することができる．

The RP SHALL determine the minimum IAL, AAL, and FAL it is willing to accept for access to any offered functionality. An RP MAY vary its functionality based on the IAL, AAL, and FAL of a specific federated authentication. For example, an RP can allow login at AAL2 for common functionality (e.g., viewing the status of a dam system) but require AAL3 be used for higher risk functionality (e.g., changing the flow rates of a dam system). Similarly, an RP could restrict management functionality to only certain subscriber accounts which have been identity proofed at IAL2, while allowing logins from all subscriber accounts regardless of IAL.

フェデレーションプロセスでは，適用可能な IAL を決定する加入者(subscriber)アカウントの詳細，並びに，適用可能な AAL を決定する IdP での認証イベントに直接アクセスできるのは IdP だけである．したがって，RP は IdP の IAL および AAL の宣言を，特定のフェデレーショントランザクションのこれらのレベルの唯一のソースと見なさなければならない(SHALL)．

In a federation process, only the IdP has direct access to the details of the subscriber account, which determines the applicable IAL, and the authentication event at the IdP, which determines the applicable AAL. Consequently, the RP SHALL consider the IdP’s declaration of the IAL and AAL as the sole source of these levels for a given federated transaction.

RP は，フェデレーショントランザクションがアサーションで宣言された FAL の要件を満たしていることを保証しなければならない(SHALL)．たとえば，RP は，提示方法が FAL2 以上のインジェクション保護要件を満たしていること，および適切な bound authenticator が FAL3 で提示されていることを確認しなければならない．

The RP SHALL ensure that the federation transaction meets the requirements of the FAL declared in the assertion. For example, the RP needs to ensure the presentation method meets the injection protection requirements at FAL2 and above, and that the appropriate bound authenticator is presented at FAL3.

IdP は，RP が信頼の合意の一部として許容可能な最小 xAL のセットを指定するメカニズムをサポートしなければならず(SHALL)，フェデレーショントランザクションの一部として実行時により厳密な最小セットを指定する RP をサポートする必要がある(SHOULD)．RP が特定の xAL を要求する場合，可能であれば，IdP はその要求を満たす必要があり(SHOULD)，アサーションで結果の xAL を示さなければならない(SHALL)．たとえば，加入者(subscriber)が AAL1 で認証されたアクティブなセッションを持っているが RP が AAL2 を要求した場合，可能であれば，IdP は加入者(subscriber)に AAL2 認証を要求して，加入者(subscriber)が IdP での対話中に IdP でセッションのセキュリティを強化する必要がある．IdP は，返却するアサーションの一部として結果の AAL（AAL1 （元のセッション）または AAL2（強化された認証）を送信する．

IdPs SHALL support a mechanism for RPs to specify a set of minimum acceptable xALs as part of the trust agreement and SHOULD support the RP specifying a more strict minimum set at runtime as part of the federation transaction. When an RP requests a particular xAL, the IdP SHOULD fulfill that request, if possible, and SHALL indicate the resulting xAL in the assertion. For example, if the subscriber has an active session that was authenticated at AAL1, but the RP has requested AAL2, the IdP needs to prompt the subscriber for AAL2 authentication to step up the security of the session at the IdP during the subscriber’s interaction at the IdP, if possible. The IdP sends the resulting AAL as part of the returned assertion, whether it is AAL1 (the original session) or AAL2 (a stepped-up authentication).

フェデレーション (Federation)

This section is normative.

フェデレーションプロトコルでは，図1に示すように，加入者(subscriber)，IdP，RP の間で三者関係が形成される．

In a federation protocol, a three-party relationship is formed between the subscriber, the IdP, and the RP, as shown in Figure 1.

図1. Federation Overview

IdP と RP 間のフェデレーション関係は，多段階プロセスで確立される.

1. まず，IdP と RP が信頼の合意(trust agreement)を形成する．この合意は，当事者間の二者間，当局の要請による多者間，または信頼できる当事者を通じてプロキシされる場合がある．この手順は，件の2つのシステムが接続するための最初の許可を表す．要求および提示できるもののパラメーターはこのステップで確立されるが，特定の加入者(subscriber)の特定の RP に提示される属性の詳細は，後の段階まで延期できる．

2. 次に，IdP と RP は登録を実行してプロトコルレベルで信頼を確立し，関係者間で情報を安全に交換できるようにする．最初のステップでは，接続の許可を表すポリシー決定が必要だが，このステップでは，フェデレーションプロトコルを介した通信を許可するために，IdP と RP を表すクレデンシャルと識別子を確立する．この段階は,加入者(subscriber)が RP にログインしようとする前に，または，加入者(subscriber)が RP で IdP を使用しようとする試行への応答として発生する．

3. 続いて，IdP と RP は，加入者(subscriber)を認証するためにフェデレーション認証トランザクションに関連することを決定する．その一環として，このトランザクション中に IdP から RP に加入者(subscriber)に関するどの属性を渡すかを決定する．このステップで行われる決定は，最初のステップで形成された信頼の合意(trust agreement)と，2番目のステップで確立された RP および IdP の アイデンティティ に基づいている．

4. 最後に，加入者(subscriber)が IdP に対して認証を行い，その認証イベントの結果がネットワークを介して RP に提示される．RP は IdP から提示されたアサーションを処理し，加入者(subscriber)との認証済みセッションを確立する．

A federation relationship between an IdP and RP is established in a multi-stage process:

1. First, the IdP and RP agree to enter into a trust agreement. This agreement can be bilateral between the parties, multilateral at the behest of an authority, or proxied through a trusted party. This step represents initial permission for the two systems in question to connect. Parameters of what can be requested and released are established in this step, though the details of which attributes are released to a given RP for a given subscriber can be deferred until a later stage.

2. Next, the IdP and RP perform registration to establish their trust at a protocol level, allowing for information to be securely exchanged between the parties. While the first step entails a policy decision representing a permission to connect, this step entails establishment of credentials and identifiers representing the IdP and RP to allow communication through the federation protocol. This stage can occur before any subscriber tries to log in to the RP or as a response to a subscriber’s attempt to use an IdP at an RP.

3. Next, the IdP and RP determine that they want to engage in a federated authentication transaction to authenticate the subscriber. As part of this, they determine which attributes about the subscriber are to be passed from the IdP to the RP during this transaction. The decision made in this step builds on the trust agreement established in the first step and the identities of the RP and IdP established in the second step.

4. Finally, the subscriber authenticates to the IdP and the result of that authentication event is asserted to the RP across the network. The RP processes this assertion from the IdP and establishes an authenticated session with the subscriber.

このトランザクションでは，[SP800-63B]で説明されているように，IdP は加入者(subscriber)のオーセンティケーターの検証者として機能する．認証イベント情報は，Sec. 6で説明されているアサーションを使用して IdP から RP に運ばれる． IdP は，このアサーションの一部として，または承認されたクレデンシャルによって保護された派生のアイデンティティプロトコルを介して，加入者(subscriber)の属性情報に関するステートメントを作成することもできる．

In this transaction, the IdP acts as the verifier of the subscriber’s authenticators, as described in [SP800-63B]. The authentication event information is carried from the IdP to the RP through the use of an assertion, described in Sec. 6. The IdP can also make statements about identity attributes of the subscriber as part of this assertion or through a secondary identity protocol protected by an authorized credential.

信頼の合意(Trust Agreements)

認証サービスを提供する IdP と，それらのサービスを使用する RP は，フェデレーションのメンバーとして知られている．IdP から見ると，フェデレーションは，サービスを提供する RP で構成される．RP から見ると，フェデレーションは，使用する IdP で構成される．本節では，現在使用されている一般的なアイデンティティフェデレーションモデルの概要と要件について説明する．各モデルでは，フェデレーションのメンバー間に関係が確立される．これらの関係は，次節で説明するように，二者間または多者間で確立される．

IdPs that provide authentication services and RPs that consume those services are known as members of a federation. From an IdP’s perspective, the federation consists of the RPs that it serves. From an RP’s perspective, the federation consists of the IdPs that it uses. This section provides an overview of and requirements for common identity federation models currently in use. In each model, relationships are established between members of the federation. These relationships are established in either a bilateral or multilateral fashion, as described in the following sections.

信頼の合意(trust agreement)では，次のパラメータを確立しなければならない(SHALL)．

• IdP が RP へ提示できる属性のセット
• IdP がアサーションを作成できる加入者(subscriber)アカウントの集合
• RP が要求する属性のセット (利用可能な属性のサブセット)
• RP によって要求された各属性の利用目的
• 加入者(subscriber)の属性の提供に関する決定に責任を負う authorized party
• RP への属性提供について加入者(subscriber)に通知する手段
• IdP が提供可能な xAL
• RP が必要とする xAL

Trust agreements SHALL establish the following parameters:

• The set of attributes the IdP can make available to the RP
• The population of subscriber accounts the IdP can create assertions for
• The set of attributes the RP will request (a subset of the attributes made available)
• The purpose for each attribute requested by the RP
• The authorized party responsible for decisions regarding the release of subscriber attributes
• The means of informing subscribers about attribute release to the RP
• The xALs available from the IdP
• The xALs required by the RP

信頼の合意(trust agreement)は，静的あるいは動的に形成できる．静的に形成する場合，多くの場合において，当事者を一連の期待される行動，権利，および要件に拘束する法的または契約上の合意がある．静的に信頼の合意(trust agreement)を行う際のパラメーターは，IdP のオペレーター，RP のオペレーター，および影響を受ける加入者(subscriber)を含む，合意に関わるのすべての関係者が利用できなければならない(SHALL)．

Trust agreements are able to be established either statically or dynamically. In a static establishment, there is often a legal or contractual agreement binding the parties to a set of expected behaviors, rights, and requirements. The parameters of static trust agreements SHALL be available to all parties in the agreement, including the operator of the IdP, the operator of the RP, and affected subscribers.

対照的に，動的に信頼を形成する場合では，加入者(subscriber)のログインのために RP と IdP が最初に相互に連絡するときに，信頼の合意(trust agreement)が暗黙的に定義される．動的に信頼の合意(trust agreement)を行う際のパラメータの表現は，適切なフェデレーションプロトコルによって駆動され，通常，フェデレーションパーティ間の契約上の合意に結び付けられることはない．動的に信頼の合意(trust agreement)を行う際のパラメータは，フェデレーショントランザクション中に RP および IdP によって加入者(subscriber)に開示されなければならない(SHALL)．

In dynamic trust establishment, in contrast, the trust agreement is implicitly defined when the RP and IdP first contact each other for the purposes of a subscriber’s login. The expression of the parameters of a dynamic trust agreement is driven by the federation protocol in place, and are not usually tied to a contractual agreement between the federating parties. The parameters of a dynamic trust agreement SHALL be disclosed to the subscriber by the RP and the IdP during the federation transaction.

信頼の合意(trust agreement)における authorized party とは，加入者(subscriber)属性のリリースを含む，信頼の合意(trust agreement)の対象となる特定の提示の決定に責任を負う組織，人，またはエンティティである．静的な信頼の合意(trust agreement)の場合，authorized party は IdP を担当する組織でもよい(MAY)．この場合，属性提示への同意は，すべての加入者(subscriber)に対して決定され，Sec. 5.3.1 で説明されているようにホワイトリストによって確立される．これにより，加入者(subscriber)による直接の決定や関与なしに属性情報の開示が可能になる．静的な信頼の合意(trust agreement)は，Sec. 5.3.3 で説明されているように，加入者(subscriber)などの個人が属性を開示することに同意するよう実行時に求められることを規定してもよい(MAY)． 動的な信頼の合意(trust agreement)は加入者(subscriber)のアクションによって形成されるため，動的な信頼の合意(trust agreement)の authorized party は常に加入者(subscriber)である．動的な信頼の合意(trust agreement)における属性の開示は，加入者(subscriber)からの実行時の決定に従わなければならず(SHALL)，IdP のホワイトリストに従っては**ならない(SHALL NOT)．

The authorized party in a trust agreement is the organization, person, or entity that is responsible for the specific release decisions covered by the trust agreement, including the release of subscriber attributes. For a static trust agreement, the authorized party MAY be the organization responsible for the IdP. In this case, consent to release attributes is decided for all subscribers and established by an allowlist as described in Sec. 5.3.1, allowing for the disclosure of attribute information without direct decisions and involvement by the subscriber. A static trust agreement MAY stipulate that an individual, such as the subscriber, is to be prompted at runtime for consent to disclose attributes as discussed in Sec. 5.3.3. Since dynamic trust agreements are established by subscriber actions, the authorized party in a dynamic trust agreement is always the subscriber. Disclosure of attributes in dynamic trust agreements SHALL be subject to a runtime decision from the subscriber and SHALL NOT be subject to an allowlist at the IdP.

たとえば, エンタープライズサービス (RP) に接続する組織 (IdP) に対して静的な信頼の合意(trust agreement)が形成され，ホワイトリストにある組織のすべての加入者(subscriber)が利用できるようになる場合，この信頼の合意(trust agreement)の authorized party は組織である．加入者(subscriber)がエンタープライズサービスにログインする際に，サービスに関する実行時の決定は要求されない．これは，静的な信頼の合意(trust agreement)によってアプリオリに確立されているためである．別のシナリオでは，同じ組織のすべての加入者(subscriber)が別のサービスを利用できるようになるが，静的な信頼協定では，加入者(subscriber)が authorized party であることが規定されている．サービスに初めてログインする際に各加入者(subscriber)は，属性を RP に提示することに同意するよう求められる．別のシナリオでは，加入者(subscriber)が RP（動的な信頼の合意(trust agreement)をしなければIdPに知られていないRP） にアクセスしようとすると，動的な信頼の合意(trust agreement)が暗黙的に形成される．RP は IdP から要求されているすべての属性の使用について加入者(subscriber)に通知し，IdP は加入者(subscriber)に RP に属性を提示することに同意するように求める．

For example, a static trust agreement is established for an organization (the IdP) connecting to an enterprise service (the RP) to be made available to all subscribers at the organization on an allowlist. The authorized party for this trust agreement is the organization. When a subscriber logs in to the enterprise service, they are not prompted with any runtime decisions regarding the service since the static trust agreement establishes this a priori. In a different scenario, another service is made available to all subscribers at the same organization, but the static trust agreement stipulates that the subscriber is the authorized party. When logging in to the service for the first time, each subscriber is prompted for their consent to release their attributes to the RP. In another scenario, a dynamic trust agreement is established implicitly when a subscriber goes to access an RP that is otherwise unknown by their IdP. The RP informs the subscriber about the uses of all attributes being requested from the IdP, and the IdP prompts the subscriber for consent to release their attributes to the RP.

IdP と RP が共有のセキュリティドメインまたは共有の法的所有権を持っている場合でも，すべてのフェデレーショントランザクションには信頼の合意(trust agreement)の形成が必要である．そのような場合，信頼の合意(trust agreement)の形成は，迅速に完了することができる内部プロセスである．

Establishment of a trust agreement is required for all federation transactions, even those in which the IdP and RP have a shared security domain or shared legal ownership. In such cases, the establishment of the trust agreement is an internal process that can be completed quickly.

単一のフェデレーショントランザクションの過程で，IdP と RP のポリシーと期待が，すべての関係者にとって明確であることが重要である．したがって，特定のトランザクションに対して有効な信頼の合意(trust agreement)のセットは 1 つだけである必要がある(SHOUD)．これは通常，単一の IdP と単一の RP で構成される一意のペアによって決定される．ただし，これらの合意は，IdP と RP が異なる加入者(subscriber)集団に対して異なる合意を形成しているなど，別の部分で異なる場合がある．

During the course of a single federation transaction, it is important for the policies and expectations of the IdP and RP to be unambiguous for all parties involved. Therefore, there SHOULD be only one set of trust agreements in effect for a given transaction. This will usually be determined by the unique pair consisting of a single IdP and a single RP. However, these agreements could vary in other ways, such as an IdP and RP having different agreements for different populations of subscribers.

2つの当事者間の信頼の合意(trust agreement)の存在は，合意の各当事者が他の当事者と形成する他の合意の存在を排除するものではない．つまり，IdP は同時に複数の RP と独立した合意を形成することができ (そして一般的にはそうしている)，RP は同様に複数の IdP と独立した合意を同時に形成することができる．

The existence of a trust agreement between two parties does not preclude the existence of other agreements for each party in the agreement to have with other parties. That is to say, an IdP can have (and generally does have) independent agreements with multiple RPs simultaneously, and an RP can likewise have independent agreements with multiple IdPs simultaneously.

二者間の信頼の合意 (Bilateral Trust Agreements)

二者間の信頼の合意(trust agreement)では，IdP と RP の潜在的なペアリングが相互に信頼関係を形成する．このモデルでは，IdP と RP がそれぞれ自身の authority として機能し，フェデレーション内でその役割を実行できる相手を確立する．

In a bilateral trust agreement, each potential pairing of an IdP and RP form a trust relationship with each other. In this model, the IdP and RP each act as their own authority and establish the other party as capable of performing its role within the federation.

IdP は，サポートされている IAL，AAL，FAL のレベルを RP に開示しなければならない(SHALL)．IdP は，アプリケーションのニーズに応じて，その機能のサブセットを特定の RP に開示してもよい(MAY)．たとえば，アカウントが IAL1 以上で証明されていることをリスクの低い RP にのみ開示するなど．

The IdP SHALL disclose its supported IAL, AAL, and FAL levels to the RP. The IdP MAY disclose a subset of its capabilities to a given RP depending on the needs of the application, for example only disclosing to a low-risk RP that accounts are proofed at IAL1 or better.

RP は，要求された各属性の使用目的を含め，必要な属性のリストを IdP に開示しなければならない(SHALL)．RP は，必要な IAL，AAL，FAL を IdP に通知しなければならない(SHALL)．これには、IAL または AAL は必要ないかどうかも含む．

The RP SHALL disclose its list of required attributes to the IdP, including its purpose for use of each requested attribute. The RP SHALL communicate its required IAL, AAL, and FAL to the IdP, including whether no claim is required for IAL or AAL.

IdP は，RP によって明示的に要求された属性のみを送信しなければならない(SHALL)．RP は，要求した属性をプライバシーリスク評価に含めるなければならない(SHALL)．

The IdP SHALL transmit only those attributes that were explicitly requested by the RP. RPs SHALL include their requested attributes in their privacy risk assessment.

多者間の信頼の合意 (Multilateral Trust Agreements)

多者間の信頼の合意(trust agreement)では，フェデレーションの当事者は，フェデレーションの信頼に関する決定を支援し，当事者間の協力関係を確立するために，federation authority に従う．このモデルでは，federation authority がフェデレーション合意の IdP と RP のメンバーシップを管理する．federation authority は，フェデレーション内の各当事者に対してある程度の審査を行い，信頼の合意(trust agreement)を定義する所定の基準に準拠していることを確認する．審査のレベルは，フェデレーション内で採用されているユースケースとモデルに固有のものである．この審査は，[図2] (sec5_federation.ja.md#fig-2) の左側に示されている．

In a multilateral trust agreement, the federated parties defer to a federation authority to assist in making federation trust decisions and to establish the working relationship between parties. In this model, the federation authority manages the membership of IdPs and RPs in the federation agreement. The federation authority conducts some level of vetting on each party in the federation to verify compliance with predetermined standards that define the trust agreement. The level of vetting is unique to the use cases and models employed within the federation. This vetting is depicted in the left side of Figure 2.

federation authority は，IdP が特定の IAL，AAL，FAL で動作することを承認する．この情報は，図2 の右側に示すように，RP が要件を満たす IdP を決定するために使われる．

Federation authorities approve IdPs to operate at certain IALs, AALs, and FALs. This information is used by relying parties, as shown in the right side of Figure 2, to determine which identity providers meet their requirements.

federation authority は，それらが可能にするフェデレーションリレーションシップに関連して，期待される受入れ可能な IAL，AAL，FAL に関するパラメータを確立しなければならない(SHALL)．federation authority は，フェデレーションの各関係者を個別に精査して，期待される基準を遵守しているかどうかを判断しなければならない(SHALL)．

Federation authorities SHALL establish parameters regarding expected and acceptable IALs, AALs, and FALs in connection with the federated relationships they enable. Federation authorities SHALL individually vet each participant in the federation to determine whether they adhere to their expected standards.

図2. Federation Authority

IdP と RP の審査では，少なくとも次のことを確立しなければならない(SHALL):

• IdP によって生成されたアサーションは，Sec. 6でしめされた要件を遵守する．
• RP は，保持，集約，および第三者への開示など，加入者(subscriber)属性データを処理するための要件を遵守する．
• RP および IdP システムは，フェデレーションプロトコルの承認済みプロファイルを利用する．

Vetting of IdPs and RPs SHALL establish, as a minimum, that:

• Assertions generated by IdPs adhere to the requirements in Sec. 6.
• RPs adhere to requirements for handling subscriber attribute data, such as retention, aggregation, and disclosure to third parties.
• RP and IdP systems use approved profiles of federation protocols.

federation authority は，IdP の構成データの公開や RP のソフトウェアステートメントの発行などによって，メンバー間の技術的な接続と構成プロセスを支援してもよい(MAY)．

Federation authorities MAY assist the technical connection and configuration process between members, such as by publishing configuration data for IdPs or by issuing software statements for RPs.

authorities を通じて管理されるほとんどの federation には，単純なメンバーシップモデルがある．たとえば，当事者は federation に属しているか，そうでないかのいずれかといったものである．より洗練された federation は，federation の他の当事者がより徹底的に審査されているかどうかを判断するために，フェデレーションの当事者が使用できる複数のメンバーシップ層を持ってもよい(MAY)．IdP は，特定の加入者(subscriber)属性が上位層の RP にのみ提示可能であると決定してもよく(MAY)，RP は上位層の IdP からのみ特定の情報を受け入れることを決定してもよい(MAY)．

Most federations managed through authorities have a simple membership model: parties are either in the federation or they are not. More sophisticated federations MAY have multiple membership tiers that federated parties can use to tell whether other parties in the federation have been more thoroughly vetted. IdPs MAY decide that certain subscriber attributes are only releasable to RPs in higher tiers and RPs MAY decide to accept certain information only from IdPs in higher tiers.

Proxied Federation

proxied federation では，IdP と RP の間のすべての通信は，2 つの当事者間の直接通信を防止する方法で仲介者を通過する．この効果を得るには複数の方法がある．一般的な構成は次のとおり．

• フェデレーションプロキシ (または ブローカー) として機能するサードパーティ
• 通信を分散し，エンドポイント間のプロキシとして機能するノードのネットワーク

In a proxied federation, all communication between the IdP and the RP is passed through an intermediary party in a way that prevents direct communication between the two parties. There are multiple methods to achieve this effect. Common configurations include:

• A third party that acts as a federation proxy (or broker)
• A network of nodes that distributes the communications and functions as a proxy between the endpoints

プロキシが使用されている場合，一方は IdP として機能し，もう一方は RP として機能する．したがって，IdP および RP に適用されるすべての規範的要件は，それぞれの役割のプロキシに適用されなければならない(SHALL)．

Where proxies are used, they function as an IdP on one side and an RP on the other. Therefore, all normative requirements that apply to IdPs and RPs SHALL apply to proxies in their respective roles.

図3. Federation Proxy

proxied federation モデルには，いくつかの利点がある．フェデレーションプロキシは，統合用の共通インターフェイスを提供することで，RP と IdP 間の技術的統合を簡素化できる．さらに，プロキシが RP と IdP を効果的に相互にブラインドすることで，加入者(subscriber)リストを相互に保護したい組織にある程度のビジネス機密性を提供できる．プロキシは，Sec. 5.5 以降で説明されているプライバシーリスクの一部を軽減することもできる．

A proxied federation model can provide several benefits. Federation proxies can simplify technical integration between the RP and IdP by providing a common interface for integration. Additionally, to the extent a proxy effectively blinds the RP and IdP from each other, it can provide some business confidentiality for organizations that want to guard their subscriber lists from each other. Proxies can also mitigate some of the privacy risks described in Sec. 5.5 below.

ブラインドの技術，その使用法，および制限の詳細については， Sec. 9.5を参照．

See Sec. 9.5 for further information on blinding techniques, their uses, and limitations.

プロキシを介して提示されるフェデレーションは，プロキシされたトランザクション中に使用される最小の FAL によって表されなければならない(SHALL)．たとえば，プロキシが FAL2 で IdP からアサーションを受け取ったものの，FAL1 で RP にアサーションを提示する場合，トランザクション全体が FAL1 とみなされる．同様に，federation が FAL1 でアサーションを受け取り，FAL3 で RP にアサーションを提示する場合，トランザクション全体は依然として FAL1 とみなされる．プロキシは，実行時または信頼の合意(trust agreement)の一部としての事前構成を通じて，この側面を RP に伝達しなければならない(SHALL)．

Federations presented through a proxy SHALL be represented by the lowest FAL used during the proxied transaction. For example, if a proxy takes in an assertion from the IdP at FAL2 but presents a downstream assertion to the RP at FAL1, the entire transaction is considered FAL1. Likewise if a federation takes in an assertion at FAL1 but presents a downstream assertion to the RP at FAL3, the entire transaction is still considered FAL1. The proxy SHALL communicate this aspect to the RP either at runtime or through pre-configuration as part of the trust agreement.

登録(Registration)

フェデレーションプロトコル内では，暗号化鍵，システム識別子，サービスエンドポイントURL，および必要なアクセス権などのプロトコル固有の情報を IdP と RP の間で確立する必要があり，それらによって相互に安全に通信できるようになる．さらに，システムの信頼性と使いやすさを向上させるために，システムの表示名やホームページなどの加入者(subscriber)向けの情報を確立することができる． この情報はすべて，フェデレーションプロトコルの範囲内で IdP と RP の間の信頼をデジタル的かつプログラム的に確立するために使用される．

Within federation protocols, protocol-specific information such as cryptographic keys, system identifiers, service endpoint URLs, and required access rights need to be established between the IdPs and RPs, allowing them to communicate securely with each other. Furthermore, subscriber-facing information such as system display names and home pages can be established to facilitate trust in and usability of the system. All of this information is used to digitally and programmatically establish trust between the IdP and RP within the scope of the federation protocol.

これらの情報交換は，フェデレーショントランザクション内で通信する IdP と RP ごとに，そのトランザクションの基礎となる信頼の合意(trust agreement)に関係なく，ペアで行われる．このプロセスの 2 つのフェーズは，一般に，RP による IdP の　検出(discovery)　および IdP での RP の 登録(registration) として知られている．これらのプロセスは，システム管理者または開発者がターゲットシステムに情報を入力する手動の静的な方法で行うことも，人間が直接関与せずにシステム自体が情報を交換する自動化された動的な方法で行うこともできる．

These exchanges of information happen in a pairwise fashion for each IdP and RP communicating within a federation transaction, regardless of the trust agreement underlying that transaction. The two phases of this process are commonly known as discovery of the IdP by the RP and registration of the RP at the IdP. These processes can happen in a manual, static fashion, where system administrators or developers enter the information into the target systems, or in an automated, dynamic fashion, where the systems themselves exchange information without direct human involvement.

\clearpage

手動登録 (Manual Registration)

手動登録モデルでは，IdP および RP のオペレーターは，加入者(subscriber)が関与する前に，相互運用を期待する関係者に関する構成情報を手動でプロビジョニングする．

In the manual registration model, the operators of the IdP and RP manually provision configuration information about parties with which they expect to interoperate, prior to involvement of the subscriber.

図4. Manual Registration

図4 に示すように，手動登録には次の3つの手順がある．

1. RP のシステム管理者は，RP の属性を IdP のシステム管理者と共有する．IdP のシステム管理者は，それらの属性を RP に関連付ける．

2. IdP のシステム管理者は，IdP の属性を RP のシステム管理者と共有する．RP のシステム管理者は，それらの属性を IdP に関連付ける．

3. IdP と RP は，標準のフェデレーション プロトコルを使用して通信する．

As shown in Figure 4, manual registration involves three steps:

1. The RP’s system administrator shares the RP’s attributes with the IdP’s system administrator, who associates those attributes with the RP.

2. The IdP’s system administrator shares the IdP’s attributes with the RP’s system administrator, who associates those attributes with the IdP.

3. The IdP and RP then communicate using a standard federation protocol.

IdP と RP は，Sec. 5.1.1 にあるように誰とフェデレートするかについて独自の authority として機能してもよい(MAY)，またはSec. 5.1.2のようにそれらの authority の決定を外部に外出ししてもよい(MAY)．

IdPs and RPs MAY act as their own authorities on who to federate with as in Sec. 5.1.1 or MAY externalize those authority decisions to an external party as in Sec. 5.1.2.

鍵情報の転送を必要とするプロトコルは，登録プロセス中に安全な方法を使用して，共有鍵または公開鍵を含んだフェデレーションリレーションシップを操作するために必要な鍵情報を交換しなければならない(SHALL)．この関係で使用される対称鍵は，フェデレーション参加者のペアに固有のものでなければならない(SHALL)．

Protocols requiring the transfer of keying information SHALL use a secure method during the registration process to exchange keying information needed to operate the federated relationship, including any shared secrets or public keys. Any symmetric keys used in this relationship SHALL be unique to a pair of federation participants.

フェデレーションリレーションシップは，フェデレーションリレーションシップに関連して，期待される受け入れ可能な IAL および AAL に関するパラメータを確立なければならない(SHALL)．

Federation relationships SHALL establish parameters regarding expected and acceptable IALs and AALs in connection with the federated relationship.

動的登録 (Dynamic Registration)

フェデレーションの動的登録モデルでは，トランザクション時にフェデレーションのメンバー間の関係をネゴシエートできる．このプロセスにより，手動登録を使用して IdP と RP 間の接続を手動で確立することなく，IdP と RP を相互に接続できる (Sec. 5.2.1を参照)．動的登録をサポートする IdP は，システム管理者の関与を最小限に抑えるような方法で，構成情報 (動的登録エンドポイントなど) を利用できるようにしなければならない(SHALL)．

In the dynamic registration model of federation, it is possible for relationships between members of the federation to be negotiated at the time of a transaction. This process allows IdPs and RPs to be connected together without manually establishing a connection between them using manual registration (See Sec. 5.2.1). IdPs that support dynamic registration SHALL make their configuration information (such as dynamic registration endpoints) available in such a way as to minimize system administrator involvement.

図5. Dynamic Registration

図5 に示すように，動的登録には次の 4 つの手順がある．

1. 検出(Discover)．RP は，IdP の既知の場所に移動して，IdP のメタデータを見つける．

2. 検証(Validate)．RP と IdP は，互いの有効性を決定する．これは，鍵情報，メタデータ，ソフトウェアステートメント，またはその他の手段によって実現される．

3. RP 属性を登録する．RP はその属性を IdP に送信し，IdP はそれらの属性を RP に関連付ける．

4. フェデレーションプロトコル．IdP と RP は，標準のフェデレーションプロトコルを使用して通信する．

As shown in Figure 5, dynamic registration involves four steps:

1. Discover. The RP goes to a well-known location at the IdP to find the IdP’s metadata.

2. Validate. The RP and IdP determine each other’s validity. This can be accomplished through keying information, metadata, software statements, or other means.

3. Register RP attributes. The RP sends its attributes to the IdP, and the IdP associates those attributes with the RP.

4. Federation Protocol. The IdP and RP then communicate using a standard federation protocol.

鍵情報の転送を必要とするプロトコルは，登録プロセス中に安全な方法を使用して，共有鍵または公開鍵を含んだフェデレーションリレーションシップを操作するために必要な鍵情報を確立しなければならない(SHALL)．この関係で使用される対称鍵は，フェデレーション参加者のペアに固有のものでなければならない(SHALL)．

Protocols requiring the transfer of keying information SHALL use a secure method during the registration process to establish such keying information needed to operate the federated relationship, including any shared secrets or public keys. Any symmetric keys used in this relationship SHALL be unique to a pair of federation participants.

IdP は，Sec. 6.2.5で説明されているように，動的に登録された RP にペアワイズ仮名識別子を発行する必要がある(SHOULD)．

IdPs SHOULD issue pairwise pseudonymous subject identifiers to dynamically registered RPs, as discussed in Sec. 6.2.5.

可能な場合，動的登録は，信頼の合意(trust agreement)に固定された ソフトウェアステートメント によって強化する必要がある(SHOULD)．ソフトウェアステートメントは，authority（IdP自身，Sec. 5.1.2にあるような federation authority，または別の信頼できる当事者) によって暗号的に署名された，RP ソフトウェアを説明する属性のリストである．ソフトウェアステートメントを使用すると，フェデレーテッドパーティは，RP のすべての識別情報を事前に入手することなく，動的に登録されている RP の一部の属性を暗号で検証できる．この暗号的に検証可能なステートメントにより，self-assert　された属性のみに依存することなく，フェデレーションパーティ間で接続を確立または昇格させることができる．(プロトコルのソフトウェアステートメントの実装の詳細については，[RFC7591]の 2.3 を参照のこと．)

Where possible, dynamic registration SHOULD be augmented by software statements anchored in their trust agreement. Software statements are lists of attributes describing the RP software, cryptographically signed by an authority (either the IdP itself, a federation authority as in Sec. 5.1.2, or another trusted party). Software statements allow federated parties to cryptographically verify some attributes of an RP being dynamically registered without necessarily having all of the identifying information for that RP ahead of time. This cryptographically verifiable statement allows the connection to be established or elevated between the federating parties without relying solely on self-asserted attributes. (See [RFC7591] Sec. 2.3 for more information on one protocol’s implementation of software statements.)

認証と属性開示 (Authentication and Attribute Disclosure)

IdP と RP が信頼の合意(trust agreement)を形成し，登録を完了すると，フェデレーションプロトコルを使用して IdP から RP に加入者(subscriber)属性を渡すことができる．認証を行うことができるかどうか，または属性を渡すことができるかどうかの決定は，ホワイトリスト，ブラックリスト，または実行時の決定を使用して，信頼の合意(trust agreement)形成時に規定された authorized party によって決定されなければならない(SHALL)．

Once the IdP and RP have entered into a trust agreement and have completed registration, the federation protocol can be used to pass subscriber attributes from the IdP to the RP. The decision of whether an authentication can occur or attributes may be passed SHALL be determined by the authorized party stipulated by the trust agreement, through use of an allowlist, a blocklist, or a runtime decision.

加入者(subscriber)の属性は，IdP と RP の間で，アイデンティティフェデレーショントランザクション，またはSec. 5.5で説明されている侵害された加入者(subscriber)アカウントの識別などのサポート機能のためにのみ送信されなければならない(SHALL)．ホワイトリストに登録されている場合でも，加入者(subscriber)の属性を他の目的で送信してはならない．

A subscriber’s attributes SHALL be transmitted between IdP and RP only for identity federation transactions or support functions such as identification of compromised subscriber accounts as discussed in Sec. 5.5. A subscriber’s attributes are not to be transmitted for any other purposes, even when parties are allowlisted.

加入者(subscriber)の属性は，信頼の合意(trust agreement)形成時に規定された目的以外で RP が使用してはならない(SHALL NOT)．

A subscriber’s attributes SHALL NOT be used by the RP for purposes other than those stipulated in the trust agreement.

RP へ属性が送信する際には，加入者(subscriber)に通知しなければならない(SHALL)．authorized party が組織である場合，組織は，承認された RP のリストと，それらの RP に送信された関連する属性のセットを加入者(subscriber)が利用できるようにしなければならない(SHALL)．authorized party が加入者(subscriber)である場合，加入者(subscriber)は，Sec. 5.3.3 で説明されているように，IdP での実行時の決定を使用して，属性を提示する前にプロンプトを表示されなければならない(SHALL)．

The subscriber SHALL be informed of the transmission of attributes to an RP. In the case where the authorized party is the organization, the organization SHALL make available to the subscriber the list of approved RPs and the associated sets of attributes sent to those RPs. In the case where the authorized party is the subscriber, the subscriber SHALL be prompted prior to release of attributes using a runtime decision at the IdP as described in Sec. 5.3.3.

IdP は，加入者(subscriber)の苦情や問題 (たとえば，加入者(subscriber)が不正確な属性値を発見するなど) を是正するための効果的なメカニズムを提供しなければならない(SHALL)．救済のためのユーザビリティに関する考慮事項については，Sec. 10参照．

The IdP SHALL provide effective mechanisms for redress of subscriber complaints or problems (e.g., subscriber identifies an inaccurate attribute value). See Sec. 10 on usability considerations for redress.

IdPにおけるRPのホワイトリスト (IdP Allowlists of RPs)

静的な信頼の合意(trust agreement)では，IdP は，加入者(subscriber)に実行時に確認することなしに，IdP から認証と属性を受け取ることを許可された RP のホワイトリストを確立してもよい(MAY)．RP をそのホワイトリストに登録する場合，IdP は，RP が SP 800-63 ガイドラインの該当するすべての規定と要件を遵守していることを保証なければならない(SHALL)．IdP は，認証時にホワイトリストに登録された RP に渡される 属性を決定しなければならない(SHALL)．IdP は，Sec. 9.2 で説明されているように，加入者(subscriber)がホワイトリストを利用できるようにしなければならない(SHALL)．

In a static trust agreement, IdPs MAY establish allowlists of RPs authorized to receive authentication and attributes from the IdP without a runtime decision from the subscriber. When placing an RP on its allowlist, the IdP SHALL ensure that the RP abides by all applicable provisions and requirements in the SP 800-63 guidelines. The IdP SHALL determine which identity attributes are passed to the allowlisted RP upon authentication. IdPs SHALL make allowlists available to subscribers as described in Sec. 9.2.

IdP におけるホワイトリストは，使用中のフェデレーションプロトコルに適用可能なドメイン名，暗号鍵，またはその他の識別子を使用して，RP を一意に識別しなければならない(SHALL)．識別子を共有するすべてのエンティティは，ホワイトリストの目的で同等と見なさしなければならない(SHALL)．たとえば，ワイルドカードドメイン識別子「*.example.com」は，「www.example.com」「service.example.com」「unknown.example.com」に等しく一致する． これら 3 つのサイトはすべて，ホワイトリストを使用した開示を決定する際に同じ RP として扱われる． ホワイトリストは，RP の意図しないなりすましを避けるため，できるだけ具体的にする必要がある(SHOULD)．

IdP allowlists SHALL uniquely identify RPs through the means of domain names, cryptographic keys, or other identifiers applicable to the federation protocol in use. Any entities that share an identifier SHALL be considered equivalent for the purposes of the allowlist. For example, a wildcard domain identifier of “*.example.com” would match the domains “www.example.com”, “service.example.com”, and “unknown.example.com” equally. All three of these sites would be treated as the same RP for disclosure decisions using the allowlist. Allowlists SHOULD be as specific as possible to avoid unintentional impersonation of an RP.

IdPにおけるRPのブラックリスト (IdP Blocklists of RPs)

IdP は，加入者(subscriber)によって要求された場合でも，IdP から認証アサーションまたは属性を受信することを許可されていない RP のブラックリストを確立してもよい(MAY)．RP が IdP のブラックリストにある場合，IdP は，いかなる状況においても，その RP をターゲットとするアサーションを生成してはならない(SHALL NOT)．

IdPs MAY establish blocklists of RPs not authorized to receive authentication assertions or attributes from the IdP, even if requested to do so by the subscriber. If an RP is on an IdP’s blocklist, the IdP SHALL NOT produce an assertion targeting the RP in question under any circumstances.

IdP におけるブラックリストは，使用中のフェデレーションプロトコルに適用可能なドメイン名，暗号鍵，またはその他の識別子を使用して，RP を一意に識別しなければならない(SHALL)．識別子を共有するすべてのエンティティは，ブラックリストの目的で同等と見なさしなければならない(SHALL)．たとえば，ワイルドカードドメイン識別子「*.example.com」は，「www.example.com」「service.example.com」「unknown.example.com」に等しく一致する． これら 3 つのサイトはすべて，ブラックリストを使用する際に同じ RP として扱われる．

IdP blocklists SHALL uniquely identify RPs through the means of domain names, cryptographic keys, or other identifiers applicable to the federation protocol in use. Any entities that share an identifier SHALL be considered equivalent for the purposes of the blocklist. For example, a wildcard domain identifier of “*.example.com” would match the domains “www.example.com”, “service.example.com”, and “unknown.example.com” equally. All three of these sites would be treated as the same RP for decisions using the blocklist.

IdPにおける実行時の決定 (IdP Runtime Decisions)

IdP と信頼の合意(trust agreement)を形成しているが，その IdP とのホワイトリストまたはブラックリストには含まれていないすべての RP は，IdPのデフォルトポリシーによって判断されなければならない(SHALL)．このポリシーでは，実行時の承認の決定は，信頼の合意(trust agreement)時に規定された authorized party によって行われる．ほとんどの場合，実用上，authorized party は加入者(subscriber)である． ただし，加入者(subscriber)に代わって，管理者またはその他の関係者に確認される場合もある．動的な信頼の合意(trust agreement)では，注記：属性の提示を承認できるのは実行時の決定のみである．

Every RP that is in a trust agreement with an IdP but not on an allowlist or a blocklist with that IdP SHALL be governed by a default policy in which runtime authorization decisions will be made by an authorized party identified by the trust agreement. In most circumstances, and for practical purposes, the authorized party is the subscriber; however, it is possible for an administrator or other party to be prompted on behalf of the subscriber. Note that in a dynamic trust agreement, only a runtime decision can be used to authorize the release of attributes.

この操作モードでは，認証アサーションを提供し，加入者(subscriber)に代わって RP に特定の属性を提示することに同意するために，フェデレーショントランザクション中に authorized party が IdP によって確認を求められる．IdP は，加入者(subscriber)に関する属性が RP に送信される前に，authorized party に明示的な通知を出し，肯定的な確認をしなければならない(SHALL)．少なくとも，通知は，Sec. 9.2 に記載されている通り，最も効果的な通知を提供し，確認結果を得る立場にある当事者によって提供される必要がある(SHOULD)．IdP は，トランザクションが承認された場合に RP に提示される属性を開示しなければならない(SHALL)．使用中のフェデレーションプロトコルが実行時にオプションの属性開示を許可する場合，authorized party には，フェデレーショントランザクションを完全に終了することなく，特定の属性を RP に送信するかどうかを決定するオプションが与えられなければならない(SHALL)．

In this mode of operation, the authorized party is prompted by the IdP during the federation transaction for their consent to provide an authentication assertion and release specific attributes to the RP on behalf of the subscriber. The IdP SHALL provide the authorized party with explicit notice and prompt them for positive confirmation before any attributes about the subscriber are transmitted to the RP. At a minimum, the notice SHOULD be provided by the party in the position to provide the most effective notice and obtain confirmation, consistent with Sec. 9.2. The IdP SHALL disclose which attributes will be released to the RP if the transaction is approved. If the federation protocol in use allows for optional attribute disclosure at runtime, the authorized party SHALL be given the option to decide whether to transmit specific attributes to the RP without terminating the federation transaction entirely.

機密情報が許可なく公開される (ショルダーサーフィンなど) リスクを軽減するために，IdP はデフォルトで，authorized party に表示される機密情報をマスクしなければならない(SHALL)．authorized party が加入者(subscriber)である場合，IdP は，加入者(subscriber)が送信前に完全な値を表示できるように，加入者(subscriber)が一時的にマスク解除するメカニズムを提供しなければならない(SHALL)．マスキングの詳細については，ユーザビリティの考慮事項に関するSec. 10を参照．

To mitigate the risk of unauthorized exposure of sensitive information (e.g., shoulder surfing), the IdP SHALL, by default, mask sensitive information displayed to the authorized party. If the authorized party is the subscriber, the IdP SHALL provide mechanisms for the subscriber to temporarily unmask such information in order for the subscriber to view full values before transmission. For more details on masking, see Sec. 10 on usability considerations.

IdP は，authorized party の決定を記録しておき，同じ属性のセットを同じ RP に再送信するメカニズムを採用してもよい(MAY)．このメカニズムは，IdP によって管理される加入者(subscriber)アカウントに関連付けられる．そのようなメカニズムが提供される場合，IdP は，authorized partyが将来そのような記録されたアクセスを取り消すことを許可しなければならない(SHALL)．

An IdP MAY employ mechanisms to remember and re-transmit the exact attribute bundle to the same RP, remembering the authorized party’s decision. This mechanism is associated with the subscriber account as managed by the IdP. If such a mechanism is provided, the IdP SHALL allow the authorized party to revoke such remembered access at a future time.

RPにおけるIdPのホワイトリスト (RP Allowlists of IdPs)

RP は，実行時に加入者(subscriber)に確認することなしに，RP が認証と属性を受け入れる IdP のホワイトリストを確立してもよい(MAY)．IdP をホワイトリストに登録する場合，RP は，IdP がガイドラインの規定と要件を遵守していることを確認しなければならない(SHALL)．

RPs MAY establish allowlists of IdPs from which the RP will accept authentication and attributes without a runtime decision from the subscriber. When placing an IdP in its allowlist, the RP SHALL ensure that the IdP abides by the provisions and requirements in these guidelines.

RP におけるホワイトリストは，使用中のフェデレーションプロトコルに適用可能なドメイン名，暗号鍵，またはその他の識別子を使用して IdP を一意に識別しなければならない(SHALL)．

RP allowlists SHALL uniquely identify IdPs through the means of domain names, cryptographic keys, or other identifiers applicable to the federation protocol in use.

RPにおけるIdPのブラックリスト (RP Blocklists of IdPs)

RP は，加入者(subscriber)によって要求された場合でも，RP が認証または属性を受け入れない IdP のブロックリストを確立してもよい(MAY)．ブロックリストに登録された IdP は，RP との有効な信頼の合意(trust agreement)を形成している場合もある．たとえば，両方が同じ federation authority の下にある場合など．

RPs MAY also establish blocklists of IdPs that the RP will not accept authentication or attributes from, even when requested by the subscriber. A blocklisted IdP can be otherwise in a valid trust agreement with the RP, for example if both are under the same federation authority.

RP におけるブロックリストは，使用中のフェデレーションプロトコルに適用可能なドメイン名，暗号化鍵，またはその他の識別子を使用して IdP を一意に識別しなければならない(SHALL)．

RP blocklists SHALL uniquely identify IdPs through the means of domain names, cryptographic keys, or other identifiers applicable to the federation protocol in use.

RPにおける実行時の決定 (RP Runtime Decisions)

RP と信頼の合意(trust agreement)を形成しているが，RP のホワイトリストまたはブロックリストには含まれていないすべての IdP は，デフォルトポリシーによって管理されなければならない(SHALL)．この場合RPは，authorized partyに，加入者(subscriber)に代わって認証のためにどの IdP に接続するか，選択または入力するよう要求する．このプロセスは，加入者(subscriber)が電子メールアドレスなどのhuman-facing な識別子を入力できるようにする discovery のメカニズムを使用することで容易に行うことができる．このプロセスにより，RP はその識別子に適した IdP をプログラムで選択できるようになる．

Every IdP that is in a trust agreement with an RP but not on an allowlist or a blocklist with that RP SHALL be governed by a default policy in which runtime authorization decisions will be made by the authorized party indicated in the trust agreement. In this mode, the authorized party is prompted by the RP to select or enter which IdP to contact for authentication on behalf of the subscriber. This process can be facilitated through use of a discovery mechanism allowing the subscriber to enter a human-facing identifier such as an email address. This process allows the RP to programmatically select the appropriate IdP for that identifier.

RP は，authorized party が特定の IdP を使用することを決定したことを記録するメカニズムを採用してもよい(MAY)．このメカニズムは RP での認証の前に使用されるため，RP がこのメカニズムを提供する方法（たとえば，認証されたセッション外のブラウザー Cookieなど）は，Sec. 5.4 で説明されている RPの加入者(subscriber)アカウントとは別のものである．そのようなメカニズムが提供される場合，RP は，authorized party が将来そのような記録されたオプションを取り消すことを許可しなければならない(SHALL)．

The RP MAY employ mechanisms to remember the authorized party’s decision to use a given IdP. Since this mechanism is employed prior to authentication at the RP, the manner in which the RP provides this mechanism (e.g., a browser cookie outside the authenticated session) is separate from the RP subscriber account described in Sec. 5.4. If such a mechanism is provided, the RP SHALL allow the authorized party to revoke such remembered options at a future time.

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

RP が RP 加入者(subscriber)アカウント と呼ばれる，RP 自体に対してローカルな加入者(subscriber)を表すレコードを保持することは一般的である．RP 加入者(subscriber)アカウントには，RP でのアクセス権や，加入者(subscriber)の属性のキャッシュなどを含めることができる．アクティブな RP 加入者(subscriber)アカウントは，RP の信頼する IdP からの 1 つ以上のフェデレーション識別子にバインドされる．フェデレーションプロトコルを介してフェデレーション識別子の 1 つの認証が成功すると，加入者(subscriber)は RP 加入者(subscriber)アカウントによって保護された情報と機能にアクセスできるようになる．

It is common for an RP to keep a record representing a subscriber local to the RP itself, known as the RP subscriber account. The RP subscriber account can contain things like access rights at the RP as well as a cache of identity attributes for the subscriber. An active RP subscriber account is bound to one or more federated identifiers from the RP’s trusted IdPs. Successful authentication of one of these federated identifiers through a federation protocol allows the subscriber to access the information and functionality protected by the RP subscriber account.

RP 加入者(subscriber)アカウントは，RP が加入者(subscriber)に関する一連の属性を RP の加入者(subscriber)アカウントを表すデータレコードに関連付けたときに プロビジョニング される．RP 加入者(subscriber) アカウントは，少なくとも 1 つのフェデレーション識別子にバインドされなければならなず(SHALL)，特定のフェデレーション識別子は，特定の RP で 1 つの RP 加入者(subscriber) アカウントにのみバインドされる．プロビジョニングは， Sec. 5.4.1 で説明されている展開パターンに応じて，認証の前に，またはフェデレーション認証プロセスの結果として発生する． プロビジョニングされる前は，RP 加入者(subscriber)アカウントは存在せず，RP に関連するデータレコードも存在しない．

An RP subscriber account is provisioned when the RP has associated a set of attributes about the subscriber with a data record representing the subscriber account at the RP. The RP subscriber account SHALL be bound to at least one federated identifier, and a given federated identifier is bound to only one RP subscriber account at a given RP. The provisioning can happen prior to authentication or as a result of the federated authentication process, depending on the deployment patterns as discussed in Sec. 5.4.1. Prior to being provisioned, the RP subscriber account does not exist and has no associated data record at the RP.

RP 加入者(subscriber)アカウントは，RP が RP でのアカウントへのすべてのアクセスを削除すると 終了 します． 終了には，フェデレーション識別子と bound authenticators の解除，監査とセキュリティ目的で必要なものを除くアカウントに関連付けられた属性と情報の削除が含まれなければならない(SHALL)．RP は，フェデレーション元の加入者(subscriber)アカウントの現在の有効性に関係なく，さまざまな理由で IdP とは独立して RP 加入者(subscriber)アカウントを終了してもよい(MAY)．

An RP subscriber account is terminated when the RP removes all access to the account at the RP. Termination SHALL include unbinding any federated identifiers and bound authenticators as well as removing attributes and information associated with the account except what is required for auditing and security purposes. An RP MAY terminate an RP subscriber account independently from the IdP for a variety of reasons, regardless of the current validity of the subscriber account from which it is derived.

認証されたセッションは，RP 加入者(subscriber)アカウントに関連付けられたフェデレーション識別子の発行者である IdP からの有効なアサーションを，RP が 処理および検証した場合にのみ，RP によって作成されなければならない(SHALL)．アサーションが FAL3 で bound authenticator の提示も必要とする場合は，Sec. 6.1.2 で説明されているように，RP 加入者(subscriber)アカウントが認証されたセッションに関連付けられる前に，bound authenticator が提示および処理されなければならない(SHALL)．アサーションが処理される前，および認証されたセッションが終了した後は，RP 加入者(subscriber)アカウントは認証されていないものの，プロビジョニングは可能である．

An authenticated session SHALL be created by the RP only when the RP has processed and verified a valid assertion from the IdP that is the issuer of the federated identifier associated with the RP subscriber account. If the assertion also requires presentation of a bound authenticator at FAL3, the bound authenticator SHALL also be presented and processed before the RP subscriber account is associated with an authenticated session, as discussed in Sec. 6.1.2. Before the federated assertion is processed and after termination of the authenticated session, the RP subscriber account is unauthenticated though it could still be provisioned.

プロビジョニングモデル (Provisioning Models)

RP 加入者(subscriber)アカウントのプロビジョニングプロセスのライフサイクルは，Sec. 5.1 で説明した信頼の合意(trust agreement)や IdP と RP の展開パターンなどの要因によって異なる．ただし，すべての場合において，RP 加入者(subscriber)アカウントは，RP で認証されたセッションを確立する前に，次のいずれかの方法で RP にプロビジョニングされなければならない(SHALL)．

The lifecycle of the provisioning process for an RP subscriber account varies depending on factors including the trust agreement discussed in Sec. 5.1 and the deployment pattern of the IdP and RP. However, in all cases, the RP subscriber account SHALL be provisioned at the RP prior to the establishment of an authenticated session at the RP in one of the following ways:

即時プロビジョニング

RP 加入者(subscriber)アカウントは，RP が IdP からフェデレーション識別子が不明なアサーションを初めて受信したときに自動的に作成される．アサーション内または Sec. 6.3 で説明されているアイデンティティAPI を介してフェデレーションプロセス中に取得した属性は，RP 加入者(subscriber)アカウントに関連付けてもよい(MAY)．この方法でプロビジョニングされたアカウントは，アカウントのプロビジョニングに使用されたアサーションでフェデレーション識別子にバインドされる．これは，RP と IdP 間の調整が最小限で済むため，フェデレーションシステムでの最も一般的なプロビジョニング方法である． ただし，そのようなシステムでは，RP は，キャッシュされた属性を管理する責任を負わなければならない(SHALL)．

Just-In-Time Provisioning

An RP subscriber account is created automatically the first time the RP receives an assertion with an unknown federated identifier from an IdP. Any identity attributes learned during the federation process, either within the assertion or through an identity API as discussed in Sec. 6.3, MAY be associated with the RP subscriber account. Accounts provisioned in this way are bound to the federated identifier in the assertion used to provision them. This is the most common form of provisioning in federation systems, as it requires the least coordination between the RP and IdP. However, in such systems, the RP SHALL be responsible for managing any cached attributes it might have.

図6. Just-In-Time Provisioning

\clearpage

事前プロビジョニング

RP 加入者(subscriber)アカウントは，IdP が属性を RP にプッシュするか，RP が IdP から属性をプルすることによって作成される．アカウントの事前プロビジョニングは，通常，Sec. 5.4.3 で説明されているように，プロビジョニング API を介して一括で行われる．プロビジョニングは，代表される加入者(subscriber)がフェデレーショントランザクションを介して認証する前に行われるためである．事前にプロビジョニングされたアカウントは，プロビジョニング時にフェデレーション識別子にバインドされなければならない(SHALL)．RP が特定のフェデレーション識別子を検出すると，関連付けられたアカウントがログインできる． この形式のプロビジョニングには，IdP と RP のインフラストラクチャと計画が必要であるが，これらのプロセスは自動化されたプロトコルによって容易に行われる．RP は，まだ RP システムと対話していないユーザーに関する属性も収集する．これは，プライバシーの問題を引き起こす可能性がある．さらに，IdP と RP は，Sec. 5.4.2 で説明したように，プロビジョニングされたアカウントのセットを時間の経過とともに同期させておく必要がある．

Pre-provisioning

An RP subscriber account is created by the IdP pushing the attributes to the RP or the RP pulling attributes from the IdP. Pre-provisioning of accounts generally occurs in bulk through a provisioning API as discussed in Sec. 5.4.3, as the provisioning occurs prior to the represented subscribers authenticating through a federated transaction. Pre-provisioned accounts SHALL be bound to a federated identifier at the time of provisioning. Any time a particular federated identifier is seen by the RP, the associated account can be logged in as a result. This form of provisioning requires infrastructure and planning on the part of the IdP and RP, but these processes can be facilitated by automated protocols. The RP also collects attributes about users who have not interacted with the RP system yet, which can cause privacy issues. Additionally, the IdP and RP must keep the set of provisioned accounts synchronized over time as discussed in Sec. 5.4.2.

図7. Pre-Provisioning

\clearpage

一時的なプロビジョニング (Ephemeral)

アサーションの処理時に RP 加入者(subscriber)アカウントが作成されるが，認証されたセッションが終了すると，RP 加入者(subscriber)アカウントは終了する．このプロセスは即時プロビジョニングに似ているが，RP は，監査およびセキュリティ目的で必要なもの (アクセスログなど) を除いて，セッションの完了時にアカウントの長期的な記録を保持しない． この形式のプロビジョニングは，アクセス権を完全に IdP に外部化する RP にとって役立ち，RP をより簡素化して内部状態を少なくすることができる．ただし，このパターンは一般的ではない．最も単純な RP であっても，アプリケーション内の状態を追跡する必要があるか，少なくともフェデレーション識別子に関連付けられたアクションの記録を保持する必要がある傾向があるためである．

Ephemeral

An RP subscriber account is created when processing the assertion, but then the RP subscriber account is terminated when the authenticated session ends. This process is similar to a just-in-time provisioning, but the RP keeps no long-term record of the account when the session is complete, except what is required for audit and security purposes (such as access logs). This form of provisioning is useful for RPs that fully externalize access rights to the IdP, allowing the RP to be more simplified with less internal state. However, this pattern is not common because even the simplest RPs tend to have a need to track state within the application or at least keep a record of actions associated with the federated identifier.

図8. Ephemeral Provisioning

その他

他の RP 加入者(subscriber)アカウントプロビジョニングモデルも可能だが，そのようなモデルの詳細は，これらのガイドラインの範囲外である．代替プロビジョニングモデルの詳細は，IdP および RP のプライバシーリスク評価に含めなければならない(SHALL)．

Other

Other RP subscriber account provisioning models are possible but the details of such models are outside the scope of these guidelines. The details of any alternative provisioning model SHALL be included in the privacy risk assessments of the IdP and RP.

すべての組織は，信頼の合意(trust agreement)の一部としてプロビジョニングモデルを文書化しなければならない(SHALL)．

All organizations SHALL document their provisioning model as part of their trust agreement.

属性情報の同期 (Attribute Synchronization)

フェデレーションプロセスでは，IdP と RP はそれぞれ，加入者(subscriber)アカウントに関連付けられた属性の独自のストアを持っている．IdP は加入者(subscriber)アカウントに直接確認しているが，RP 加入者(subscriber)アカウントは，フェデレーショントランザクション中に提示される加入者(subscriber)アカウントの属性のサブセットからのものである．したがって，IdP と RP の属性ストアは，時間の経過とともに互いに乖離する可能性がある．

In a federated process, the IdP and RP each have their own stores of identity attributes associated with the subscriber account. The IdP has a direct view of the subscriber account, but the RP subscriber account is derived from a subset of attributes from the subscriber account that are presented during the federation transaction. Therefore, it is possible for the IdP’s and RP’s attribute stores to diverge from with each other over time.

RP の観点からは，IdP は，IdP の加入者(subscriber)アカウントに関連付けられていると IdP が提示する属性の authoritative source である．ただし，RP は，RP 加入者(subscriber)アカウントに関連付ける他の属性を追加で収集し，オプションで検証してもよい(MAY)．場合によっては，これらの属性が IdP によって提示されるものを上書きすることもある．たとえば，IdP が加入者(subscriber)の完全な表示名を提示する場合，RP は，加入者(subscriber)が RP で使用する代替の名前を提供できるようにしてもよい．

From the RP’s perspective, the IdP is the authoritative source for any attributes that the IdP asserts as being associated with the subscriber account at the IdP. However, the RP MAY additionally collect, and optionally verify, other attributes to associate with the RP subscriber account. Sometimes, these attributes can even override what’s asserted by the IdP. For example, if an IdP asserts a full display name for the subscriber, the RP can allow the subscriber to provide an alternative preferred name for use at the RP.

IdP は，RP で利用可能な加入者(subscriber)アカウントの属性が更新されたときに，それを利用しているRP に通知する必要がある(SHOULD)．これは，Sec. 5.7 で説明されているように共有信号(shared signaling)を使用するか，Sec. 5.4.3 で説明されているようにプロビジョニング API を介すか，アサーションでシグナルを提供することによって実現する (たとえば，関連する属性の最終更新時を示すタイムスタンプで RP がキャッシュの期限切れを確認するなど）．

The IdP SHOULD signal downstream RPs when the attributes of a subscriber account available to the RP have been updated. This can be accomplished using shared signaling as described in Sec. 5.7, through a provisioning API as described in Sec. 5.4.3, or by providing a signal in the assertion (e.g., a timestamp indicating when relevant attributes were last updated, allowing the RP to determine that its cache is out of date).

IdP は，加入者(subscriber)アカウントが終了したとき，または加入者(subscriber)アカウントの RP へのアクセスが取り消されたときに，それを利用しているRP に通知する必要がある(SHOULD)．これは，Sec. 5.7 で説明されている共有信号(shared signaling)を使用するか，Sec. 5.4.3 で説明されているプロビジョニングAPI を使用して実現される．このような信号を受信すると，RP は RP 加入者(subscriber)アカウントを終了し，RP 加入者(subscriber)アカウントに関連付けられているすべての個人情報を，監査およびセキュリティ目的で必要なものは除いて，削除しなければならない(SHALL)．

The IdP SHOULD signal downstream RPs when a subscriber account is terminated, or when the subscriber account’s access to an RP is revoked. This can be accomplished using shared signaling as described in Sec. 5.7 or through a provisioning API as described in Sec. 5.4.3. Upon receiving such a signal, the RP SHALL terminate the RP subscriber account and remove all personal information associated with the RP subscriber account, except what is required for audit and security purposes.

プロビジョニングAPI (Provisioning APIs)

プロアクティブなプロビジョニングの一部として，プロビジョニングAPI と呼ばれる汎用的な属性API を介して，RP に加入者(subscriber)属性へのアクセスを与えることができる．このタイプの API により，IdP は一定範囲の加入者(subscriber)アカウントの属性をプッシュでき，場合によっては RP がこれらの加入者(subscriber)アカウントの属性を直接クエリできるようになる．API へのアクセスはフェデレーショントランザクションのコンテキスト外で許可されるため，特定の加入者(subscriber)のプロビジョニングAPI へのアクセスは，特定の加入者(subscriber)が認証されたことを RP に示さない．アサーションを使用してフェデレーション認証プロセスを実行する方法の詳細については，Sec. 6, Assertions 参照．

As part of some proactive forms of provisioning, the RP can be given access to subscriber attributes through a general-purpose attribute API known as a provisioning API. This type of API allows an IdP to push attributes for a range of subscriber accounts, and sometimes allows an RP to query the attributes of these subscriber accounts directly. Since access to the API is granted outside the context of a federated transaction, access to the provisioning API for a given subscriber does not indicate to the RP that a given subscriber has been authenticated. See Sec. 6, Assertions for more information on how the federated authentication process is accomplished using assertions.

特定の RP で利用可能なプロビジョニングAPI の属性は，RP がその機能を実行するために必要なものだけに制限されなければならない(SHALL)．信頼の合意(trust agreement)形成の一環としてプロビジョニングAPI へのアクセス権が RP に与えられた場合，IdP は文書化しなければならない(SHALL)．文書には少なくとも以下の全てを含む．

• プロビジョニングモデルを使用したアクセスの目的．
• RP で利用できる属性のセット．
• API が RP へのプッシュとして機能するか，RP からのプルとして機能するか，またはその両方として機能するか．
• 属性が RP で利用可能になっている加入者(subscriber)集団．

The attributes in the provisioning API available to a given RP SHALL be limited to only those necessary for the RP to perform its functions. As part of establishing the trust agreement, the IdP SHALL document when an RP is given access to a provisioning API including at least the following:

• the purpose for the access using the provisioning model;
• the set of attributes made available to the RP;
• whether the API functions as a push to the RP, a pull from the RP, or both; and
• the population of subscribers whose attributes are made available to the RP.

IdP は，プロビジョニングAPI へのプルベースのアクセスに対して，RP からの認証を要求しなければならない(SHALL)．RP は，プロビジョニングAPI へのプッシュベースのアクセスに対して，IdP からの認証を要求しなければならない(SHALL)．

The IdP SHALL require authentication from the RP for any pull-based access to a provisioning API. The RP SHALL require authentication from the IdP for any push-based access to a provisioning API.

プロビジョニングAPI は，動的または暗黙な信頼の合意(trust agreement)の下で利用可能にしてはならない(SHALL NOT)．IdP は，信頼の合意(trust agreement)を形成していない RP がプロビジョニングAPI を使用できるようにしてはならない(SHALL NOT)．IdP は，RPとのフェデレーショントランザクションや加入者(subscriber) アカウントの取り消しの通知などの関連機能を容易に行うことができるよう，RP とのフェデレーションリレーションシップの一部としてのみ，プロビジョニングAPI へのアクセスを提供しなければならない(SHALL)．IdP は，RP がその機能目的でアクセスする必要がなくなった場合，または信頼の合意(trust agreement)が終了した場合に，RP のプロビジョニングAPI へのアクセスを無効にしなければならない(SHALL)．

A provisioning API SHALL NOT be made available under a dynamic or implicit trust agreement. The IdP SHALL NOT make a provisioning API available to any RP outside of an established trust agreement. The IdP SHALL provide access to a provisioning API only as part of a federated identity relationship with an RP to facilitate federated transactions with that RP and related functions such as signaling revocation of the subscriber account. The IdP SHALL revoke an RP’s access to the provisioning API once access is no longer required by the RP for its functioning purposes or when the trust agreement is terminated.

RP に提供されるすべてのプロビジョニングAPI は，IdP の管理および管轄下になければならない(SHALL)．IdP は，このプロビジョニングAPI を介して属性を提供するために，外部属性プロバイダーを情報源として使用してもよい(MAY) が，IdP は，参照する属性属性プロバイダーによって提供される情報の内容と正確性について責任を負う．

Any provisioning API provided to the RP SHALL be under the control and jurisdiction of the IdP. External attribute providers MAY be used as information sources by the IdP to provide attributes through this provisioning API, but the IdP is responsible for the content and accuracy of the information provided by the referenced attribute providers.

プロビジョニングAPI が使用されている場合，IdP は，加入者(subscriber)アカウントが終了したときに RP に通知しなければならない(SHALL)．このような通知を受信すると，RP は関連する RP 加入者(subscriber)アカウントを終了しなければならない(SHALL)．

When a provisioning API is in use, the IdP SHALL signal to the RP when a subscriber account has been terminated. When receiving such a signal, the RP SHALL terminate the associated RP subscriber account.

属性の収集 (Attribute Collection)

RP は，IdP によって提供されるもの以外にも，加入者(subscriber)から追加の属性を収集して維持管理してもよい(MAY)．これらの属性は，RP によって直接収集されるため，フェデレーションの同意とは別に管理される．取得元に関係なく，RP 加入者(subscriber)アカウントに関連付けられているすべての属性は，RP 加入者(subscriber)アカウントが終了したときに削除しなければならない(SHALL)．

The RP MAY collect and maintain additional attributes from the subscriber beyond those provided by the IdP. These attributes are governed separately from any federation agreement since they are collected directly by the RP. All attributes associated with an RP subscriber account, regardless of their source, SHALL be removed when the RP subscriber account is terminated.

RP は，追加の属性を収集する目的を加入者(subscriber)に開示しなければならない(SHALL)．これらの属性は，RP の機能の明示された目的のためにのみ使用されなければならなず(SHALL)，前述の属性の他の関係者への通信を含む二次的な使用を行ってはならない(SHALL NOT)．

The RP SHALL disclose to the subscriber the purpose for collection of any additional attributes. These attributes SHALL be used solely for the stated purposes of the RP’s functionality and SHALL NOT have any secondary use, including communication of said attributes to other parties.

RP は，収集された追加の属性とその使用を，その System of Records Notice (SORN) の一部として開示しなければならない(SHALL)．RP は，加入者(subscriber)がこれらの追加で収集された属性を RP 加入者(subscriber)アカウントから更新および削除するための効果的な修正手段を提供しなければならない(SHALL)．修正のためのユーザビリティに関する考慮事項については，Sec. 10 を参照．

An RP SHALL disclose any additional attributes collected, and their use, as part of its System of Records Notice (SORN). The RP SHALL provide an effective means of redress for the subscriber to update and remove these additionally-collected attributes from the RP subscriber account. See Sec. 10 on usability considerations for redress.

タイムベースのRP加入者アカウントの削除 (Time-based Removal of RP Subscriber Accounts)

時間の経過とともに，RP には IdP からアクセスできなくなった RP 加入者(subscriber)アカウントを蓄積される．これは，特に即時プロビジョニングモデルが使用されており，Sec. 5.7 で説明されているような IdP から加入者(subscriber)アカウントの終了を通知するための共有信号(shared signaling)が利用できない場合に，RP 加入者(subscriber)アカウントに個人情報を保持するリスクを RP にもたらす．このような状況では，RP はタイムベースのメカニズムを使用して，一定の期間アクセスがない（たとえば最終アクセスから120日経過など） RP 加入者(subscriber)アカウントを特定し，終了する必要がある(SHOULD)．

Over time, an RP could accumulate RP subscriber accounts that are no longer accessible from the IdP. This poses a risk to the RP for holding personal information in the RP subscriber accounts, especially when a just-in-time provisioning model is in use and no shared signaling is available from the IdP to signal subscriber account termination as discussed in Sec. 5.7. In such circumstances, the RP SHOULD employ a time-based mechanism to identify RP subscriber accounts for termination that have not been accessed after a period of time, for example, 120 days since last access.

そのような非アクティブなアカウントを処理する場合，RP は，可能であれば，保留しているアカウントの終了について加入者(subscriber)に十分に通知し，予定された終了の前にアカウントを再アクティブ化するオプションを加入者(subscriber)に提供しなければならない(SHALL)．終了時に，RP は，監査およびセキュリティ目的で必要なものを除き，RP 加入者(subscriber)アカウントに関連付けられたすべての個人情報を削除しなければならない(SHALL)．

When processing such an inactive account, the RP SHALL provide sufficient notice to the subscriber, if possible, about the pending termination of the account and provide the subscriber with an option to re-activate the account prior to its scheduled termination. Upon termination, the RP SHALL remove all personal information associated with the RP subscriber account, except what is required for audit and security purposes.

プライバシー要件 (Privacy Requirements)

加入者(subscriber)の最終的な目標は，RP と対話して使用することである．フェデレーションには，トランザクションに関与していないサードパーティ — IdP からの個人属性の転送が含まれる．また，フェデレーションにより，IdP は加入者(subscriber)のアクティビティと状態を幅広く可視化できる可能性がある．したがって，フェデレーションに関連する特定のプライバシー要件が生じる．

The ultimate goal of a subscriber is to interact with and use the RP. Federation involves the transfer of personal attributes from a third party that is not otherwise involved in a transaction — the IdP. Federation also potentially gives the IdP broad visibility into subscriber activities and status. Accordingly, there are specific privacy requirements associated with federation.

RP と IdP 間の通信により，加入者(subscriber)がトランザクションを実行している場所が IdP に明らかになる．複数の RP との通信により，IdP はフェデレーションなしでは存在しなかった加入者(subscriber)トランザクションのプロファイルを構築できてしまう．この集約により，加入者(subscriber)の追跡と，プロファイル情報の使用（加入者(subscriber)のプライバシーの利益と必ずしも一致しない）の新しい機会を与えてしまう．

Communication between the RP and the IdP could reveal to the IdP where the subscriber is conducting a transaction. Communication with multiple RPs allows the IdP to build a profile of subscriber transactions that would not have existed without federation. This aggregation could enable new opportunities for subscriber tracking and use of profile information that do not always align with subscribers’ privacy interests.

IdP が RP での加入者(subscriber)のアクティビティに関する情報を任意の関係者に開示する場合，または 身元確認(identity proofing)，認証(authentication)，属性アサーション (総称して「アイデンティティサービス」) 以外の目的で加入者(subscriber)の属性を処理する場合，IdP は，追加の処理から生じるプライバシーリスクに見合った予測可能性と管理可能性を維持するための手段を実装しなければならない(SHALL)．これは，詐欺の軽減に関連して，法律または法的手続きを遵守するため，または特定のユーザーからの要求の場合に情報を送信するためである．措置には，明確な通知の提供，加入者(subscriber)の同意の取得，または属性の選択的な使用または開示の有効化が含まれてもよい(MAY)．IdP が同意手段を使用する場合，IdP は追加処理の同意をアイデンティティサービスの条件にしてはならない(SHALL NOT)．

If an IdP discloses information on subscriber activities at an RP to any party, or processes the subscriber’s attributes for any purpose other than identity proofing, authentication, or attribute assertions (collectively “identity service”), related fraud mitigation, to comply with law or legal process, or, in the case of a specific user request, to transmit the information, the IdP SHALL implement measures to maintain predictability and manageability commensurate with the privacy risk arising from the additional processing. Measures MAY include providing clear notice, obtaining subscriber consent, or enabling selective use or disclosure of attributes. When an IdP uses consent measures, the IdP SHALL NOT make consent for the additional processing a condition of the identity service.

同じ加入者(subscriber) アカウントが複数の RP に提示され，それらの RP が相互に通信する場合，共謀している RP は，複数のアプリケーションとセキュリティドメインにわたって加入者(subscriber)のアクティビティを追跡できてしまう．IdP は，分離可能性を提供して RP 間の加入者(subscriber)アクティビティの追跡とプロファイリングを思いとどまらせるために，Sec. 6.2.5 で説明されているペアワイズ仮名識別子またはプライバシー強化された暗号プロトコルの使用などの技術的手段を採用する必要がある(SHOULD)．

If the same subscriber account is asserted to multiple RPs, and those RPs communicate with each other, the colluding RPs could track a subscriber’s activity across multiple applications and security domains. The IdP SHOULD employ technical measures, such as the use of pairwise pseudonymous identifiers described in Sec. 6.2.5 or privacy-enhancing cryptographic protocols, to provide disassociability and discourage subscriber activity tracking and profiling between RPs.

IdP は，信頼の合意(trust agreement)形成時に規定されている場合，Sec. 5.7 で説明されているように，疑わしいアクティビティの通信や加入者(subscriber)アカウントの侵害など，セキュリティ上の目的で加入者(subscriber)アクティビティに関する情報を RP に開示するしてもよい(MAY)．信頼の合意(trust agreement)形成時に規定されている場合，RP は，疑わしいアクティビティの通信や RP 加入者(subscriber)アカウントの侵害など，セキュリティ上の目的で加入者(subscriber)アクティビティに関する情報を IdP に開示してもよい(MAY)．

An IdP MAY disclose information on subscriber activities to RPs for security purposes, such as communication of suspicious activity or a compromised subscriber account as described in Sec. 5.7, if stated within the trust agreement. An RP MAY disclose information on subscriber activities to IdPs for security purposes, such as communication of suspicious activity or a compromised RP subscriber account, if stated within the trust agreement.

IdP は， Sec. 5.7 で説明されている共有信号(shared signaling)を使用して，その加入者(subscriber)アカウントにバインドされたフェデレーション識別子でプロビジョニングされた RP に，加入者(subscriber)アカウントの終了を通知する必要がある(SHOULD)．IdP からそのようなシグナルを受信した RP は，RP 加入者(subscriber)アカウントを終了し，RP 加入者(subscriber)アカウントに関連付けられているすべての個人情報を，監査およびセキュリティ目的で必要なものは除いて，削除しなければならない(SHALL)．

An IdP SHOULD signal subscriber account termination to RPs that have been provisioned with federated identifiers bound to that subscriber account using shared signaling as discussed in Sec. 5.7. RPs that receive such a signal from the IdP SHALL terminate the RP subscriber account and remove all personal information associated with the RP subscriber account, except what is required for audit and security purposes.

次の要件は，特に federal agencies に適用される．

1. 機関は，プライバシーに関する Senior Agency Official for Privacy (SAOP) と相談して，プライバシー法(Privacy Act) の要件が，IdP として機能している機関，RP として機能している機関，またはその両方によって引き起こされているか（Sec. 9.4 を参照）を判断する分析を実施しなければならない(SHALL)．

2. 機関は，該当する場合，System of Records Notice (SORN) によってカバレッジを公開または特定しなければならない(SHALL)．

3. 機関は，SAOP と相談して，電子政府法(E-Government Act) の要件が IdP として機能している機関，RP として機能している機関，またはその両方によって引き起こされているかどうかを判断する分析を実施しなければならない(SHALL)．

4. 機関は，該当する場合，Privacy Impact Assessment (PIA) によって適用範囲を公開または特定しなければならない(SHALL)．

The following requirements apply specifically to federal agencies:

1. The agency SHALL consult with their Senior Agency Official for Privacy (SAOP) to conduct an analysis determining whether the requirements of the Privacy Act are triggered by the agency that is acting as an IdP, by the agency that is acting as an RP, or both (see Sec. 9.4).

2. The agency SHALL publish or identify coverage by a System of Records Notice (SORN) as applicable.

3. The agency SHALL consult with their SAOP to conduct an analysis determining whether the requirements of the E-Government Act are triggered by the agency that is acting as an IdP, the agency that is acting as an RP, or both.

4. The agency SHALL publish or identify coverage by a Privacy Impact Assessment (PIA) as applicable.

Sec. 5.4.3 で説明されているように，RP 加入者(subscriber)アカウントのライフサイクルプロセスがプロビジョニングAPI を介して属性へのアクセスを RP に与える場合，情報アクセスの幅広い性質を考慮して，追加のプライバシー対策を実装しなければならない(SHALL)．具体的には，加入者(subscriber)がその RP と対話することなく，加入者(subscriber)の属性を RP に提供することが可能である．結果として，プロビジョニングAPI が使用される場合，IdP は RP で利用できる属性を最小限に抑えなければならない(SHALL)．RP を全く使用しないユーザーの属性の送信を防ぐために，IdP は，プロビジョニングAPI を介して利用可能な加入者(subscriber)アカウントの集団を，信頼の合意(trust agreement)時に RP の使用を許可された加入者(subscriber)の集団に制限しなければならない(SHALL)．

If the RP subscriber account lifecycle process gives the RP access to attributes through a provisioning API as discussed in Sec. 5.4.3, additional privacy measures SHALL be implemented given the wide nature of information access. Specifically, it is possible for the attributes of a subscriber to be provided to an RP without the subscriber ever interacting with the RP in question. As a consequence, when a provisioning API is used, the IdP SHALL minimize the attributes made available to the RP. To prevent the transmission of attributes for users that will never use an RP, the IdP SHALL limit the population of subscriber accounts available via the provisioning API to the population of subscribers authorized to use the RP by the trust agreement.

フェデレーション環境での再認証とセッションの要件 (Reauthentication and Session Requirements in Federated Environments)

フェデレーション環境では，RP は IdP のセッションとは別にそのセッションを管理する．アサーションは両方のセッションに関連しているが，その有効期間は最終的にそれらから独立している．IdP が加入者(subscriber)のアサーションを作成するには，加入者(subscriber)は IdP との認証済みセッションを確立する必要がある．RP で認証されたセッションを作成するには，RP は IdP からの有効なアサーションを処理する必要がある．

In a federated environment, the RP manages its sessions separately from any sessions at the IdP. The assertion is related to both sessions but its validity period is ultimately independent of them. In order for the IdP to create an assertion for the subscriber, the subscriber needs to establish an authenticated session with the IdP. To create an authenticated session at the RP, the RP needs to process a valid assertion from the IdP.

フェデレーションシステムの分散性により，IdP および RP との加入者(subscriber)のセッションは，互いに独立して終了する．RP は，加入者(subscriber)がアサーションの発行時刻を過ぎて IdP でアクティブなセッションを持っていると想定してはならない(SHALL NOT)．IdP は，IdP での加入者(subscriber)のセッションの終了が加入者(subscriber)が　RP で持つセッションに伝播すると想定してはならない(SHALL NOT)．RP と IdP は，フェデレーションプロトコルでサポートされている場合，セッション終了要求をフェデレーションネットワーク内の他の関係者に伝達してもよい(MAY)．

Due to the distributed nature of a federated system, the subscriber’s sessions with the IdP and with the RP terminate independently of each other. The RP SHALL NOT assume that the subscriber has an active session at the IdP past the issuance time of the assertion. The IdP SHALL NOT assume that termination of the subscriber’s session at the IdP will propagate to any sessions that subscriber would have at downstream RPs. The RP and IdP MAY communicate session termination requests to other parties in the federation network, if supported by the federation protocol.

フェデレーションログイン要求の時点で，加入者(subscriber)は，IdP で既存のセッションを持っていてもよく(MAY)，RP へのアサーションを生成するために使用されてもよい(MAY)．IdP は，IdP での加入者(subscriber)の最新の認証イベントの時間に関する情報を伝達しなければならず(SHALL)，RP は，承認とアクセスの決定を行う際にこの情報を使用してもよい(MAY)．使用中のフェデレーションプロトコルの機能に応じて，IdP は，加入者(subscriber)がフェデレーションリクエストの一部として IdP で認証を繰り返すことを RP が要求できるようにする必要がある(SHOULD)．

At the time of a federated login request, the subscriber MAY have a pre-existing session at the IdP which MAY be used to generate an assertion to the RP. The IdP SHALL communicate any information it has regarding the time of the subscriber’s latest authentication event at the IdP, and the RP MAY use this information in making authorization and access decisions. Depending on the capabilities of the federation protocol in use, the IdP SHOULD allow the RP to request that the subscriber repeat authentication at the IdP as part of a federation request.

フェデレーションプロトコルによる認証を必要とする RP は，フェデレーションプロトコル (可能な場合) または信頼の同意(trust agreement)のパラメーターを介して，IdP に許容する最大の認証期間を指定しなければならない(SHALL)．認証期間は，IdP での加入者(subscriber)のセッションにおける最後の認証イベントからの時間を表し，その期間内に加入者(subscriber)が認証されていない場合，IdP は加入者(subscriber)を再認証しなければならない(SHALL)．RP での認証にアサーションが十分かどうかを RP が判断できるようにし，次の再認証イベントの時間を決定できるようにするために，IdP は認証イベントの時間を RP に伝達しなければならない(SHALL)．

An RP requiring authentication through a federation protocol SHALL specify the maximum acceptable authentication age to the IdP, either through the federation protocol (if possible) or through the parameters of the trust agreement. The authentication age represents the time since the last authentication event in the subscriber’s session at the IdP, and the IdP SHALL reauthenticate the subscriber if they have not been authenticated within that time period. The IdP SHALL communicate the authentication event time to the RP to allow the RP to decide if the assertion is sufficient for authentication at the RP and to determine the time for the next reauthentication event.

RP がアサーションと共に アイデンティティAPI へのアクセスを許可されている場合，アイデンティティAPI へのアクセスの有効期間は，アサーション自体の有効期間とは無関係である．アイデンティティAPI へのアクセスは追加の API へのアクセスと組み合わされることが多いため，アサーションの有効期限が切れた後も，おそらく RP とのセッションが終了した後も，このアクセスが有効であることが一般的であり，そのおかげで加入者(subscriber)がそこに存在しなくなっている間にも，RP が加入者(subscriber)の代わりに API にアクセスできるようになっている．結果として，アイデンティティAPI を介して追加の属性を正常にフェッチする RP の機能は，RP でセッションを確立するために使用されてはならない(SHALL NOT)．同様に，アイデンティティAPI にアクセスできないことを，RP でセッションを終了するために使用してはならない(SHALL NOT)．

IdP と RP の両方のセッション管理要件の詳細については，[SP800-63B]，の7章参照．

If an RP is granted access to an identity API along with the assertion, the lifetime of the access to the identity API is independent from the lifetime of the assertion itself. Since access to the identity API is often combined with access to additional APIs, it is common for this access to be valid long after the assertion has expired and possibly after the session with the RP has ended, allowing the RP to access APIs on the subscriber’s behalf while the subscriber is no longer present. As a consequence, the RP’s ability to successfully fetch additional attributes through an identity API SHALL NOT be used to establish a session at the RP. Likewise, inability to access an identity API SHOULD NOT be used to end the session at the RP.

See [SP800-63B], Sec. 7 for more information about session management requirements for both IdPs and RPs.

共有信号 (Shared Signaling)

一部の環境では，IdP と RP がフェデレーショントランザクションの外部で相互に情報を送信すると便利である．これらの信号は，他の方法では認識されない当事者間で状態の重要な変化を伝える．共有信号(shared signaling)の使用は，IdP と RP の間の信頼の合意（trust agreement)で文書化しなければならない(SHALL)．IdP から RP への信号は，静的な信頼の合意(trust agreement)形成を行わなければならない(SHALL)．RP から IdP への信号は，静的または動的な信頼の合意(trust agreement)形成で使用されてもよい(MAY)．

In some environments, it is useful for the IdP and RP to send information to each other outside of the federation transaction. These signals can communicate important changes in state between parties that would not be otherwise known. The use of any shared signaling SHALL be documented in the trust agreement between the IdP and RP. Signaling from the IdP to the RP SHALL require a static trust agreement. Signaling from the RP to the IdP MAY be used in a static or dynamic trust agreement.

共有信号(shared signaling)の使用は，文書化され，信頼の合意(trust agreement)で規定されたauthorized party が利用できるようにしなければならない(SHALL)．この文書には，信号が送信されるイベント，そのような信号に含まれる情報 (属性情報を含む)，および信号とともに送信される追加のパラメーターを含めなければならない(SHALL)．共有信号(shared signaling)の使用は，信頼の合意(trust agreement)に基づくプライバシー ビューの対象とそなければならない(SHALL)．

Any use of shared signaling SHALL be documented and made available to the authorized party stipulated by the trust agreement. This documentation SHALL include the events under which a signal is sent, the information included in such a signal (including any attribute information), and any additional parameters sent with the signal. The use of shared signaling SHALL be subject to privacy review under the trust agreement.

IdP は，次の変更に関する信号を加入者(subscriber)アカウントに送信してもよい(MAY)．

• アカウントが停止された．
• アカウントが侵害された疑いがある．
• フェデレーション識別子以外の識別子 (電子メールアドレスや証明書 CN など) を含むアカウントの属性が変更された．
• アカウントで可能な IAL，AAL，FAL の範囲が変更された．

The IdP MAY send a signal regarding the following changes to the subscriber account:

• The account has been terminated.
• The account is suspected of being compromised.
• Attributes of the account, including identifiers other than the federated identifier (such as email address or certificate CN), have changed.
• The possible range of IAL, AAL, or FAL for the account has changed.

RP は，次の変更に関する信号を RP 加入者(subscriber) アカウントに送信てもよい(MAY)．

• アカウントが停止された．
• アカウントが侵害された疑いがある．
• RP 管理の bound authenticator が追加された．
• RP 管理の bound authenticator が削除された．

IdP と RP の両方からの追加の信号は，信頼の合意(trust agreement)の一部として，プライバシーとセキュリティのレビューを条件として許可されてもよい(MAY)．

The RP MAY send a signal regarding the following changes to the RP subscriber account:

• The account has been terminated.
• The account is suspected of being compromised.
• An RP-managed bound authenticator is added.
• An RP-managed bound authenticator is removed.

Additional signals from both the IdP and RP MAY be allowed subject to privacy and security review as part of the trust agreement.

アサーション (Assertions)

This section is normative.

認証に使用されるアサーションは，フェデレーションアイデンティティシステムで IdP から RP に渡される認証済み加入者(subscriber)に関する（またはそれに関連付けられた）属性値や派生属性値のパッケージ化されたセットである．アサーションにはさまざまな情報が含まれる．アサーションメタデータ，加入者(subscriber)に関する属性値と派生属性値，IdP での加入者(subscriber)の認証に関する情報，RP が活用できるその他の情報 (制限や有効期間など) などである．アサーションの主な機能は RP に対してユーザーを認証することであるが，アサーションで伝達される情報は，多くのユースケースで RP によって使用できる．たとえば，Web サイトの承認やパーソナライズなど．これらのガイドラインは，選択されたソリューションがここに含まれるすべての必須要件を満たしている限り，RP のユースケース，使用されるプロトコルやフェデレーションに使うデータペイロードの種類を制限しない．

An assertion used for authentication is a packaged set of attribute values or derived attribute values about or associated with an authenticated subscriber that is passed from the IdP to the RP in a federated identity system. Assertions contain a variety of information, including: assertion metadata, attribute values and derived attribute values about the subscriber, information about the subscriber’s authentication at the IdP, and other information that the RP can leverage (e.g., restrictions and validity time window). While the assertion’s primary function is to authenticate the user to an RP, the information conveyed in the assertion can be used by the RP for a number of use cases — for example, authorization or personalization of a website. These guidelines do not restrict RP use cases nor the type of protocol or data payload used to federate an identity, provided the chosen solution meets all mandatory requirements contained herein.

アサーションは，IdP で加入者(subscriber)の個別の認証イベントを表さなければならなず(SHALL)，RP で個別の認証イベントとして処理されなければならない(SHALL)．

Assertions SHALL represent a discrete authentication event of the subscriber at the IdP and SHALL be processed as a discrete authentication event at the RP.

すべてのアサーションには，次の属性が含まれていなければならない(SHALL)．

1. 主体識別子(subject identifier): アサーションが適用される当事者（つまり，加入者(subscriber)）の識別子．
2. 発行者識別子(issuer identifier): アサーションの発行者（つまり，IdP）の識別子．
3. 対象者識別子(audience identifier): アサーションを消費することを意図した当事者（つまり，RP）の識別子．
4. 発行時刻(issuance time): IdP がアサーションを発行した時刻を示すタイムスタンプ．
5. 有効期間(validity time window): ここで示される期間以外では，加入者(subscriber)を認証し，RP で認証されたセッションを開始する目的で，アサーションを RP が有効として受け入れては ならない(SHALL NOT) ．これは通常，発行タイムスタンプに加えて，アサーションの有効期限タイムスタンプによって通知される．
6. アサーション識別子(assertion identifier): このアサーションを一意に識別する値で，攻撃者が以前のアサーションをリプレイすることを防ぐために使用される．
7. 署名(signature): アサーション全体をカバーする，IdP に関連付けられた鍵識別子または公開鍵を含む，デジタル署名またはメッセージ認証コード(MAC)．
8. 認証時間(authentication time): IdP が主要な認証イベント（利用可能な場合）を通じて IdP で加入者(subscriber)の存在を最後に確認した日時を示すタイムスタンプ．
9. IAL: アサーションで表されている加入者(subscriber)アカウントの IAL のインジケーター，または IAL が提示されていないことのしるし．
10. AAL: 加入者(subscriber)が IdP に対して認証されたときに使用された AAL のインジケーター，または AAL が提示されていないことのしるし．
11. FAL: アサーションによって表されるフェデレーションプロセスの IdP の意図した FAL のインジケーター．

All assertions SHALL include the following attributes:

1. Subject identifier: An identifier for the party to which the assertion applies (i.e., the subscriber).
2. Issuer identifier: An identifier for the issuer of the assertion (i.e., the IdP).
3. Audience identifier: An identifier for the party intended to consume the assertion (i.e., the RP).
4. Issuance time: A timestamp indicating when the IdP issued the assertion.
5. Validity time window: A period of time outside of which the assertion SHALL NOT be accepted as valid by the RP for the purposes of authenticating the subscriber and starting an authenticated session at the RP. This is usually communicated by means of an expiration timestamp for the assertion in addition to the issuance timestamp.
6. Assertion identifier: A value uniquely identifying this assertion, used to prevent attackers from replaying prior assertions.
7. Signature: Digital signature or message authentication code (MAC), including key identifier or public key associated with the IdP, covering the entire assertion.
8. Authentication time: A timestamp indicating when the IdP last verified the presence of the subscriber at the IdP through a primary authentication event (if available).
9. IAL: Indicator of the IAL of the subscriber account being represented in the assertion, or an indication that no IAL is asserted.
10. AAL: Indicator of the AAL used when the subscriber authenticated to the IdP, or an indication that no AAL is asserted.
11. FAL: An indicator of the IdP’s intended FAL of the federation process represented by the assertion.

Sec. 6.1.2 で説明されているように，FAL3 でアサーションが bound authenticator と共に使用される場合，アサーションは以下を含まなければならない(SHALL)．

1. Authenticator binding: 公開鍵，鍵識別子，その他の加入者(subscriber)が保持する bound authenticator の識別子（IdP 管理の bound authenticator の場合) ，RP 管理の bound authenticator が 個のアサーションの検証に必要であることを示すインジケーター．

If the assertion is used at FAL3 with a bound authenticator as described in Sec. 6.1.2, the assertion SHALL include the following:

1. Authenticator binding: The public key, key identifier, or other identifier of subscriber-held bound authenticator (for IdP-managed bound authenticators) or indicator that an RP-managed bound authenticator is required for verification of this assertion.

アサーションには，次の情報を含む追加の項目が含まれてもよい(MAY)．

1. 属性値と派生属性値: 加入者(subscriber)に関する情報．
2. 属性メタデータ: NIST Internal Report 8112 [NISTIR8112] で説明されているような，1 つまたは複数の加入者(subscriber)属性に関する追加情報．

Assertions MAY also include additional items, including the following information:

1. Attribute values and derived attribute values: Information about the subscriber.
2. Attribute metadata: Additional information about one or more subscriber attributes, such as those described in NIST Internal Report 8112 [NISTIR8112].

アサーションは，認証イベントが提示されている場合は AAL を指定し，身元証明(identity proofing)された属性 (またはそれらの属性から派生した値) が提示されている場合は IAL を指定する必要がある(SHOULD)．

Assertions SHOULD specify the AAL when an authentication event is being asserted and IAL when identity proofed attributes (or values derived from those attributes) are being asserted.

アサーション内のすべてのメタデータは，受信時に RP によって検証されなければならない(SHALL)．

• 発行者の検証: アサーションが，RP が期待する IdP によって発行されたことを確認する．
• 署名の検証: アサーションの署名が有効であり，アサーションを送信する IdP に属する鍵に対応していることを確認する．
• 時間の検証: 有効期限と発行時間が現在のタイムスタンプの許容範囲内であることを確認する．
• 対象者の制限: この RP がアサーションの意図された受信者であることを確認する．

All metadata within the assertion SHALL be validated by the RP upon receipt:

• Issuer verification: ensuring the assertion was issued by the IdP the RP expects it to be from.
• Signature validation: ensuring the signature of the assertion is valid and corresponds to a key belonging to the IdP sending the assertion.
• Time validation: ensuring the expiration and issue times are within acceptable limits of the current timestamp.
• Audience restriction: ensuring this RP is the intended recipient of the assertion.

RP は，主体識別子を本質的にグローバルに一意ではないものとして扱わなければならない(SHALL)．代わりに，アサーションの主体識別子の値は通常，アサーション発行者の制御下にある名前空間にある．これにより，RP は，異なる IdP からの主体を誤って混同することなく，複数の IdP と通信することができる．

An RP SHALL treat subject identifiers as not inherently globally unique. Instead, the value of the assertion’s subject identifier is usually in a namespace under the assertion issuer’s control. This allows an RP to talk to multiple IdPs without incorrectly conflating subjects from different IdPs.

アサーションには，加入者(subscriber)に関する追加の属性を含めてもよい(MAY)．Section 6.2.3 には，アサーションで属性を提示するためのプライバシー要件が含まれている．RP は，加入者(subscriber)の追加の属性を取得するために RP が使用できるアサーションと共に，Sec. 6.3 で説明されているように，アイデンティティAPI への制限付きアクセスを与えられてもよい(MAY)．

Assertions MAY include additional attributes about the subscriber. Section 6.2.3 contains privacy requirements for presenting attributes in assertions. The RP MAY be given limited access to an identity API as discussed in Sec. 6.3 along with the assertion, which the RP can use to fetch additional identity attributes for the subscriber.

詳細は使用しているフェデレーションプロトコルによって異なるが，アサーションは RP への個別のログインイベントを表す．アサーションの有効期間は，IdP または RP でのセッション管理に関連しているが，それとは別のものである．具体的には，IdP での認証済みセッションの中でアサーションが作成され，アサーションを処理すると RP で認証済みセッションが作成される．IdP がアサーションを作成した後，IdP のセッションの有効性はアサーションの有効性とは無関係である．IdP でセッションがまだ有効な間に，認証を繰り返す要求が IdP に送信されると，それ用の有効期間で作成される新しい別のアサーションが発生する．同様に，RP がアサーションを消費した後，RP のセッションの有効性はアサーションの有効性とは無関係である．また同様に，アイデンティティAPI に付与されたアクセスは，アサーションの有効性や RP での認証済みセッションの有効期間とは無関係である．セッション管理の詳細については，Sec. 5.3 を参照．

Although details vary based on the exact federation protocol in use, an assertion represents a discrete login event to the RP. The validity time window of an assertion is related to but separate from any session management at the IdP or RP. Specifically, an assertion is created during an authenticated session at the IdP, and processing an assertion creates an authenticated session at the RP. After the IdP creates the assertion, the validity of the IdP’s session is independent of the validity of the assertion. If a request comes to the IdP for a repeated authentication while the session is still valid at the IdP, this results in a new and separate assertion being created with its own validity time window. Similarly, after the RP consumes the assertion, the validity of the RP’s session is independent of the validity of the assertion. Access granted to an identity API is likewise independent of the validity of the assertion or the lifetime of the authenticated session at the RP. See Sec. 5.3 for more information on session management.

アサーションの有効期間は，発行から有効期限までの時間である．この期間は，RP がアサーションを処理し，加入者(subscriber)のローカルアプリケーションセッションを作成できるように十分な長ささである必要があるが，そのような処理に必要な時間を超えて長くすべきではない．有効期間の長いアサーションは，盗まれたりリプレイされたりするリスクが高くなる．アサーションの有効期間を短くすると，このリスクが軽減される．アサーションの有効期間は，RP でのセッションを制限するために使用してはならない(SHALL NOT)．詳細は Sec. 5.3 を参照．

The assertion’s validity time window is the time between its issuance and its expiration. This window needs to be large enough to allow the RP to process the assertion and create a local application session for the subscriber, but should not be longer than necessary for such establishment. Long-lived assertions have a greater risk of being stolen or replayed; a short assertion validity time window mitigates this risk. Assertion validity time windows SHALL NOT be used to limit the session at the RP. See Sec. 5.3 for more information.

Assertion Binding

アサーションバインディングは，主張者(claimant)によるアサーションの提示が，加入者(subscriber)として RP と現在セッション中の当事者にバインディングするのに十分かどうか，または加入者(subscriber)にバインドされたオーセンティケーターが提示されたことを通して RP が追加の証明を必要とするかどうかに基づいて分類できる．

Assertion binding can be classified based on whether presentation by a claimant of an assertion is sufficient for binding to the party currently in session with the RP as the subscriber, or if the RP requires additional proof through the successful presentation of an authenticator bound to the subscriber.

Bearer Assertions

ベアラーアサーションは，ベアラーのアイデンティティの証明として，どの当事者でも提示できる．同様に，ベアラアサーション参照は，任意の当事者によってRPに提示され，RP がアサーションを取得するために使用できる（この場合のアサーションもベアラアサーションとみなされる）．加入者(subscriber)を表す有効なアサーションまたはアサーション参照を，攻撃者がキャプチャまたは作成でき，そのアサーションまたは参照をRPに正常に提示できる場合，攻撃者はその RP で加入者(subscriber)になりすますことができる．

A bearer assertion can be presented by any party as proof of the bearer’s identity. Similarly, a bearer assertion reference can be presented by any party to the RP and used by the RP to fetch an assertion; the assertion in this instance is also considered a bearer assertion. If an attacker can capture or manufacture a valid assertion or assertion reference representing a subscriber and can successfully present that assertion or reference to the RP, then the attacker could be able to impersonate the subscriber at that RP.

注記：ベアラーアサーションまたは参照を単に所有するだけでは，加入者(subscriber)になりすますのに十分ではない．たとえば，アサーションがバックチャネルフェデレーションモデル (Sec. 7.1 で説明) で提示される場合，RP を不正行為からさらに保護するのに役立つ追加の制御 (RP の識別やアサーションインジェクション保護など) をトランザクションに配置してもよい(MAY)．

Note that mere possession of a bearer assertion or reference is not always enough to impersonate a subscriber. For example, if an assertion is presented in the back-channel federation model (described in Sec. 7.1), additional controls MAY be placed on the transaction (such as identification of the RP and assertion injection protections) that help further protect the RP from fraudulent activity.

Bound Authenticators

bound authenticator は，加入者(subscriber)によってアサーションと共に RP に提示されるオーセンティケーターである．RP に bound authenticator を所有していることを証明する際に，加入者(subscriber)は，自分がアサーションの正当な主体であることをある程度保証して証明する．加入者(subscriber)に発行されたアサーションを攻撃者が盗んで使用することは，攻撃者がアサーションだけでなく bound authenticator も盗み，それらを一緒に提示できなけれならないため，より困難である．さらに，bound authenticator を使用すると，独立した認証により，悪意のあるまたは侵害された IdP から RP を保護する．

A bound authenticator is an authenticator presented to the RP by the subscriber alongside the assertion. In proving possession of the bound authenticator to the RP, the subscriber also proves with a certain degree of assurance that they are the rightful subject of the assertion. It is more difficult for an attacker to use a stolen assertion issued to a subscriber since the attacker would need to steal the bound authenticator as well as the assertion and be able to present them together. Furthermore, use of a bound authenticator protects the RP against malicious or compromised IdPs through the use of independent authentication.

bound authenticator は，RP の加入者(subscriber)ごとに一意でなければならない(SHALL) ため，2つの加入者(subscriber)が別々の RP 加入者(subscriber)アカウントに対して同じオーセンティケーターを提示することはできない．すべての bound authenticator は，フィッシング耐性がなければならない(SHALL)．したがって，記憶されたシークレットなどの加入者(subscriber)が選択した値は，bound authenticator として使用できない． RP は，アサーションを処理するコンテキストでのみ，bound authenticator からの認証を受け入れなければならない(SHALL)．したがって，加入者(subscriber)は bound authenticator を使用して RP に直接ログインできず，IdP をバイパスする．

A bound authenticator SHALL be unique per subscriber at the RP such that two subscribers cannot present the same authenticator for their separate RP subscriber accounts. All bound authenticators SHALL be phishing resistant. Consequently, subscriber-chosen values such as a memorized secret cannot be used as bound authenticators. The RP SHALL accept authentication from a bound authenticator only in the context of processing an assertion. Consequently, the subscriber can not use a bound authenticator to log into the RP directly, bypassing the IdP in the process.

以下のセクションで詳しく説明するように，bound authenticator は，さまざまな状況下で IdP または RP のいずれかによって管理される． FAL3 アサーションには，加入者(subscriber)が FAL3 に到達するために RP にて特定の IdP 管理の bound authenticator または RP 管理の bound authenticator を提示することを IdP が期待するかどうかの指示が含まれる．

A bound authenticator can be managed by either the IdP or the RP under different circumstances, as detailed in the sections below. An FAL3 assertion contains an indication of whether the IdP expects the subscriber to present a specific IdP-managed bound authenticator or an RP-managed bound authenticator at the RP to reach FAL3.

IdP 管理の bound authenticator (IdP-Managed Bound Authenticators)

図9のように bound authenticator が IdP によって管理されている場合 ，オーセンティケータの一意の識別子（その公開鍵など）は，RP に提示されるアサーションに含まれなければならない(SHALL)．RP は，加入者(subscriber)に，識別された bound authenticator の所有を証明するように促さなければならない(SHALL)．

When the bound authenticator is managed by the IdP as in Fig. 9, a unique identifier for the authenticator (such as its public key) SHALL be included in the assertion presented to the RP. The RP SHALL prompt the subscriber to prove possession of the identified bound authenticator.

図9. IdP-Managed Bound Authenticators

IdP 管理の bound authenticator は，加入者(subscriber)が IdP への認証に使用する主要なオーセンティケータとは異ってもよい(MAY)．IdP で管理される bound authenticator は，フィッシング耐性がなければならず(SHALL)，公開鍵インフラストラクチャなどの相互に信頼できるセキュリティフレームワークに基づいて RP によって個別に逆参照可能でなければならない(SHALL)．IdP 管理の bound authenticator を初めて処理するとき，RP は，オーセンティケーターが提示する情報の属性からのアカウント解決などを通じて，提示されているオーセンティケーターが加入者(subscriber)アカウントに関連付けられるのに適切であるかどうかを検証する必要がある(SHOULD)．

An IdP-managed bound authenticator MAY be distinct from the primary authenticator the subscriber uses to authenticate to the IdP. Bound authenticators managed at the IdP SHALL be phishing resistant and SHALL be independently dereferenceable by the RP based on a mutually-trusted security framework, such as a public-key infrastructure. When processing an IdP-managed bound authenticator for the first time, the RP SHOULD verify whether the authenticator being presented is appropriate to be associated with the subscriber account, such as through account resolution from the attributes in the authenticator’s presented information.

たとえば，加入者(subscriber)は，多要素暗号化デバイスである，証明書が読み込まれたスマートカードを持つことができる．証明書は IdP と RP の両方に提示できるため，IdP は RP へ送る FAL3 アサーションに証明書の識別子を含めることができる．RP は加入者(subscriber)に，FAL3 に到達するためにスマートカードから証明書を提示するように要求する．

For example, a subscriber could have a smart card loaded with a certificate, which is a multi-factor cryptographic device. Since the certificate can be presented to both the IdP and the RP, the IdP can include an identifier for the certificate in the FAL3 assertion to the RP. The RP would then prompt the subscriber to present the certificate from their smart card in order to reach FAL3.

「Holder of Key」(HoK) アサーションは，IdP 管理の bound authenticatorsの一例である．これは，IdP が RP で使用される加入者(subscriber)の鍵を認識しており，RP に提示されるアサーションに鍵情報が含まれているためである．

“Holder of Key” (HoK) assertions are one example of IdP-managed bound authenticators, since the IdP knows the subscriber’s key to be used at the RP and includes the key information in the assertion presented to the RP.

\clearpage

RP 管理の bound authenticator (RP-Managed Bound Authenticators)

bound authenticator が　図10 のようにRP によって管理される場合，IdP は，アサーションが FAL3 でバインドされたオーセンティケータとともに使用されるというインジケータをアサーションに含めなければならない(SHALL)．オーセンティケータの一意の識別子 （その公開鍵など）は，RP 加入者(subscriber)アカウントに格納しなければならない(SHALL)．

When the bound authenticator is managed by the RP as in Fig. 10, the IdP SHALL include an indicator in the assertion that the assertion is to be used with a bound authenticator at FAL3. The unique identifier for the authenticator (such as its public key) SHALL be stored in the RP subscriber account.

図10. RP-Managed Bound Authenticators

RP が FAL3 アサーションを正常に受け入れる前に，RP 加入者(subscriber)アカウントに bound authenticator が含まれていなければならない．これらのオーセンティケータは，RP または加入者(subscriber)のいずれかによって提供できる．それぞれの場合で，オーセンティケータの RP 加入者(subscriber)アカウントへの初期バインディングに適用される要件はわずかに異なる．

Before an RP can successfully accept an FAL3 assertion, the RP subscriber account must include a bound authenticator. These authenticators can be provided by either the RP or the subscriber, with slightly different requirements applying to the initial binding of the authenticator to the RP subscriber account in each case.

RP 提供のオーセンティケーターの場合，RP の管理者は，FAL3 ログインで使用するために，加入者(subscriber)にオーセンティケーターを直接発行しなければならない(SHALL)．RP の管理者は， bound authenticator の一意の識別子を RP 加入者(subscriber) アカウントに格納しなければならない(SHALL)．RP の管理者は，オーセンティケータが発行される当事者が RP 加入者(subscriber)アカウントの識別された主体であることを，独立した手段を通じて決定しなければならない(SHALL)．

For RP-provided authenticators, the administrator of the RP SHALL issue the authenticator to the subscriber directly for use with an FAL3 login. The administrator of the RP SHALL store a unique identifier for the bound authenticator in the RP subscriber account. The administrator of the RP SHALL determine through independent means that the party to which the authenticator is issued is the identified subject of the RP subscriber account.

加入者(subscriber)提供のオーセンティケーターで，RP 加入者(subscriber) アカウントに関連付けられている bound authenticator がない場合，RP は 図11に示すように，オーセンティケーター，加入者(subscriber)，および RP 加入者(subscriber)アカウント間の接続を確立するためにバインディング儀式を実行しなければならない(SHALL)．RP は，最初に FAL3 の他のすべての要件を満たすアサーションでフェデレーションを使用して，認証されたセッションを確立しなければならない(SHALL)．これには，アサーションが RP 管理の bound authenticator を使用して FAL3 で使用するためのものであるという指示が含まれる．加入者(subscriber)は，提案されたオーセンティケーターを提示して認証するようにすぐに求められなければならない(SHALL)．オーセンティケータの提示が成功すると，RP はオーセンティケータの一意の識別子 (公開鍵など) を格納しなければならず(SHALL)，これをフェデレーション識別子に関連付けられた RP 加入者(subscriber)アカウントに関連付ける．加入者(subscriber)が適切なオーセンティケーターを正常に提示できなかった場合，バインディング儀式は失敗する．バインディング儀式のセッションは，5分以内にタイムアウトしなければならない(SHALL)．儀式中に使用されるセッションは，ログインのための認証済みセッションではない．バインディング儀式が正常に完了したら，RP はすぐに IdP から FAL3 の新しいアサーションを要求しなければならない(SHALL) （新しくバインドされたオーセンティケーター加入者(subscriber)に要求することを含む）．

For subscriber-provided authenticators, if no bound authenticators are associated with the RP subscriber account, the RP SHALL perform a binding ceremony to establish the connection between the authenticator, the subscriber, and the RP subscriber account as shown in Fig. 11. The RP SHALL first establish an authenticated session using federation with an assertion that meets all the other requirements of FAL3, including an indication that the assertion is intended for use at FAL3 with an RP-managed bound authenticator. The subscriber SHALL immediately be prompted to present and authenticate with the proposed authenticator. Upon successful presentation of the authenticator, the RP SHALL store a unique identifier for the authenticator (such as its public key) and associate this with the RP subscriber account associated with the federated identifier. If the subscriber fails to successfully present an appropriate authenticator, the binding ceremony fails. The binding ceremony session SHALL have a timeout of five minutes or less. The session used during the ceremony is not an authenticated session for the purposes of logging in. Upon successful completion of the binding ceremony, the RP SHALL immediately request a new assertion from the IdP at FAL3, including prompting the subscriber for the newly-bound authenticator.

図11. Binding Ceremony

RP は，加入者(subscriber)が FAL3 で複数の加入者(subscriber)提供のオーセンティケーターをバインドできるようにしてもよい(MAY)．これが当てはまり，RP 加入者アカウントに 1 つ以上の既存の bound authenticator がある場合，バインディング儀式は FAL3 に到達する既存の機能を利用する．加入者(subscriber)は，最初に FAL3 に到達するために既存の bound authenticator を提示するように求めらなければならない(SHALL)．認証が成功すると，RP は直ちに加入者(subscriber)に新しく bound authenticator を要求しなければならない(SHALL)．

An RP MAY allow a subscriber to bind multiple subscriber-provided authenticators at FAL3. If this is the case, and the RP subscriber account has one or more existing bound authenticators, the binding ceremony makes use of the existing ability to reach FAL3. The subscriber SHALL first be prompted to present an existing bound authenticator to reach FAL3. Upon successful authentication, the RP SHALL immediately prompt the subscriber for the newly-bound authenticator.

RP は，加入者(subscriber)がバインドされた加入者(subscriber)提供のオーセンティケーターを RP 加入者(subscriber)アカウントからバインド解除することを許可してもよい(MAY)．これにより，そのオーセンティケーターを FAL3 に使用する機能が削除される．bound authenticator がバインド解除された場合，RP は加入者(subscriber)の現在のすべての FAL3 セッションを終了しなければならず(SHALL)，IdP からの加入者(subscriber)の再認証を要求しなければならない(SHALL)．注記：多くの場合，加入者(subscriber)は，オーセンティケーターの紛失または侵害を考慮して，bound authenticator のバインドを解除する必要がある．したがって，加入者(subscriber)は，バインド解除プロセス中にオーセンティケーターにアクセスできない．

An RP MAY allow a subscriber to unbind a bound subscriber-provided authenticator from their RP subscriber account, thereby removing the ability to use that authenticator for FAL3. When a bound authenticator is unbound, the RP SHALL terminate all current FAL3 sessions for the subscriber and SHALL require reauthentication of the subscriber from the IdP. Note that in many cases, a subscriber will need to unbind a bound authenticator to account for a lost or compromised authenticator, and the subscriber will therefore not have access to the authenticator during the unbinding process.

\clearpage

次のイベントのいずれかが発生した場合，RP は out-of-band のメカニズムを通じて加入者(subscriber)に通知しなければならず(SHALL)，共有信号システム（Sec. 5.7 参照）を使用して IdP に通知する必要がある(SHOULD)．

• 新しいオーセンティケータが RP 加入者(subscriber)アカウントにバインドされた．
• 既存の bound authenticator が RP 加入者(subscriber)アカウントからバインド解除された．

The RP SHALL notify the subscriber through an out-of-band mechanism, and SHOULD notify the IdP using a shared signaling system (see Sec. 5.7), if any of the following events occur:

• A new authenticator is bound to the RP subscriber account.
• An existing bound authenticator is unbound from the RP subscriber account.

たとえば，加入者(subscriber)は，オーセンティケーターとして単一要素暗号化デバイスを持つことができる．このオーセンティケーターは，名前ベースのフィッシング耐性を使用するため，IdP と RP は，それぞれの場所で使用されたときに異なる鍵を認識する．ここで説明したバインディング儀式を使用して，RP は，加入者(subscriber)がこのデバイスを FAL3 で bound authenticator として使用できるようにする．RP は，IdP から この加入者(subscriber)の FAL3 のアサーションを確認するたびに，加入者(subscriber)にこのオーセンティケーターを要求する．

For example, a subscriber could have a single factor cryptographic device as an authenticator. This authenticator uses name-based phishing resistance so the IdP and RP would see different keys when used in each location. The RP can use a binding ceremony as described here to allow the subscriber to use this device as a bound authenticator at FAL3. The RP will prompt the subscriber for this authenticator whenever it sees an assertion for this subscriber at FAL3 from the IdP.

bound authenticator の処理 (Processing Bound Authenticators)

RP が bound authenticator に関連付けられたアサーションを受信すると，加入者(subscriber)は bound authenticator を所有していることを RP に直接証明する． IdP での主要な認証と RP でのフェデレーション認証は別々に処理される．加入者(subscriber)は，IdP での主要な認証に同じオーセンティケーターを使用でき，RP で bound authenticator として使用できるが，これらが同じであるという前提はない．

When the RP receives an assertion associated with a bound authenticator, the subscriber proves possession of the bound authenticator directly to the RP. The primary authentication at the IdP and the federated authentication at the RP are processed separately. While the subscriber could use the same authenticator during the primary authentication at the IdP and as the bound authenticator at the RP, there is no assumption that these will be the same.

次の要件は，bound authenticator に関連付けられたすべてのアサーションに適用される．

1. 加入者(subscriber)は，アサーション自体の提示に加えて，bound authenticator の所有を RP に証明しなければならない(SHALL)．
2. オーセンティケーターが IdP で管理されている場合，アサーション内の特定のオーセンティケータへの参照は，アサーション内の他のすべての情報と同じレベルで信頼されなければならない(SHALL)．
3. オーセンティケーターが IdP で管理されている場合，アサーションを提示する際に，オーセンティケータとして使用される暗号化していない秘密鍵または対称鍵を含めてはならない(SHALL NOT)．
4. RP は，bound authenticator に加えて，アサーションを処理および検証しなければならない(SHALL)．
5. bound authenticator で認証に失敗した場合，RP でエラーにしなければならない(SHALL)．

The following requirements apply to all assertions associated with a bound authenticator:

1. The subscriber SHALL prove possession of the bound authenticator to the RP, in addition to presentation of the assertion itself.
2. If the authenticator is managed at the IdP, reference to a given authenticator found within an assertion SHALL be trusted at the same level as all other information within the assertion.
3. If the authenticator is managed at the IdP, the assertion SHALL NOT include an unencrypted private or symmetric key to be used as an authenticator with the presentation.
4. The RP SHALL process and validate the assertion in addition to the bound authenticator.
5. Failure to authenticate with the bound authenticator SHALL result in an error at the RP.

アサーションの保護 (Assertion Protection)

バインディングメカニズム（Sec. 6.1 で説明）またはそれらを取得するために使用されるフェデレーションモデル（Sec. 5.1 で説明）とは無関係に，アサーションには，攻撃者が有効なアサーションを作成したり，キャプチャしたアサーションを異なる RP で再利用したりするのを防ぐための一連の保護を含めなければならない(SHALL)．必要な保護は，検討中のユースケースの詳細によって異なる．具体的な保護を示す．

Independent of the binding mechanism (discussed in Sec. 6.1) or the federation model used to obtain them (described in Sec. 5.1), assertions SHALL include a set of protections to prevent attackers from manufacturing valid assertions or reusing captured assertions at disparate RPs. The protections required are dependent on the details of the use case being considered, and specific protections are listed here.

アサーション識別子 (Assertion Identifier)

アサーションは，ターゲットの RP が一意に識別することを許可するのに十分に一意でなければならない(SHALL)．アサーションは，埋め込まれたナンス，発行タイムスタンプ，アサーション識別子，またはこれらまたは他の手法の組み合わせを使用して，これを達成してもよい(MAY)．

Assertions SHALL be sufficiently unique to permit unique identification by the target RP. Assertions MAY accomplish this by use of an embedded nonce, issuance timestamp, assertion identifier, or a combination of these or other techniques.

署名付きアサーション (Signed Assertion)

アサーションは，発行者 (IdP) によって暗号署名されなければならない(SHALL)．RP は，発行者の鍵に基づいて，アサーションのデジタル署名または MAC を検証しなければならない(SHALL)．この署名は，アサーション識別子，発行者，対象者，主体，および有効期限を含むアサーション全体をカバーしなければならない(SHALL)．

Assertions SHALL be cryptographically signed by the issuer (IdP). The RP SHALL validate the digital signature or MAC of each such assertion based on the issuer’s key. This signature SHALL cover the entire assertion, including its identifier, issuer, audience, subject, and expiration.

アサーション署名は，非対称鍵を使用するデジタル署名か，RP と発行者の間で共有される対称鍵を使用する MAC のいずれかでなければならない(SHALL)．IdP がこの目的で使用する共有対称鍵は，アサーションを送信する RP ごとに独立していなければならず(SHALL)，通常は RP の登録中に確立される．デジタル署名を検証するための公開鍵は，安全な方法で RP に転送しなければならず(SHALL)，実行時に安全な方法 (IdP によってホストされる HTTPS URL など) で RP によって取得されてもよい(MAY)．承認された暗号化を使しなければならない(SHALL)．

The assertion signature SHALL either be a digital signature using asymmetric keys or a MAC using a symmetric key shared between the RP and issuer. Shared symmetric keys used for this purpose by the IdP SHALL be independent for each RP to which they send assertions, and are normally established during registration of the RP. Public keys for verifying digital signatures SHALL be transferred to the RP in a secure manner, and MAY be fetched by the RP in a secure fashion at runtime, such as through an HTTPS URL hosted by the IdP. Approved cryptography SHALL be used.

暗号化されたアサーション (Encrypted Assertion)

暗号化されたアサーションは，アサーションのコンテンツが意図しない第三者によって読み取られることを防ぎ，対象の RP のみがアサーションを読み取ることができるようにする．アサーションの暗号化には，主に2つの利点がある．目的の RP 以外はアサーションの内容を見ることができない点と，対象の RP 以外はアサーションを使用できない点である．

Encrypted assertions protect the contents of the assertion from being read by unintended parties, ensuring that only the targeted RP is able to read the assertion. Encrypting assertions provides two primary benefits: the assertion contents cannot be seen by any party other than the intended RP, and the assertion cannot be used by any RP other than the targeted one.

アサーションを暗号化する場合，IdP は RP の公開鍵または共有対称鍵のいずれかを使用してアサーションの内容を暗号化しなければならない(SHALL)．IdP がこの目的で使用する共有対称鍵は，アサーションを送信する RP ごとに独立していなければならず(SHALL)，通常は RP の登録中に確立される．暗号化のための公開鍵は，IdP に安全に転送されなければならず(SHALL)，RP によってホストされる HTTPS URL などを通じて，実行時に安全な方法で IdP によって取得されてもよい(MAY)．

When encrypting assertions, the IdP SHALL encrypt the contents of the assertion using either the RP’s public key or a shared symmetric key. Shared symmetric keys used for this purpose by the IdP SHALL be independent for each RP to which they send assertions, and are normally established during registration of the RP. Public keys for encryption SHALL be securely transferred to the IdP and MAY be fetched by the IdP in a secure fashion at runtime, such as through an HTTPS URL hosted by the RP.

アサーションのすべての暗号化は，承認された暗号化を使用しなければならない(SHALL)．

All encryption of assertions SHALL use approved cryptography.

個人を特定できる情報がアサーションに含まれ，アサーションがブラウザなどの仲介者によって処理される場合，フェデレーションプロトコルはアサーションを暗号化して，アサーション内の機密情報が意図しない関係者に漏洩するのを防がなければならない(SHALL)．たとえば，SAML のアサーションは XML暗号化を使用して暗号化でき，OpenID Connect の IDトークンは JSON Web 暗号化 (JWE) を使用して暗号化できる．

When personally-identifiable information is included in the assertion and the assertion is handled by intermediaries such as a browser, the federation protocol SHALL encrypt assertions to protect the sensitive information in the assertion from leaking to unintended parties. For example, a SAML assertion can be encrypted using XML-Encryption, or an OpenID Connect ID Token can be encrypted using JSON Web Encryption (JWE).

対象者の制限 (Audience Restriction)

アサーションは，それが発行されたアサーションの意図された対象者であるかどうかを RP が認識できるようにするために，対象者制限技術を使用しなければならない(SHALL)．すべての RP は，ある RP に対して生成されたアサーションを，別の RP でインジェクションやリプレイで利用されることを防ぐために，アサーションの対象者に RP の識別子が含まれていることを確認しなければならない(SHALL)．

Assertions SHALL use audience restriction techniques to allow an RP to recognize whether or not it is the intended target of an issued assertion. All RPs SHALL check that the audience of an assertion contains an identifier for their RP to prevent the injection and replay of an assertion generated for one RP at another RP.

ペアワイズ仮名識別子 (Pairwise Pseudonymous Identifiers)

状況によっては，共通の識別子を使用して加入者アカウントが複数の RP で簡単にリンクされるのを防ぐことが望ましい場合がある．ペアワイズ仮名識別子 (PPI) を使用すると，IdP は単一の加入者(subscriber)アカウントでも，異なる RP には複数の異なるフェデレーション識別子を提供することができる．これにより，さまざまな RP が共謀して，フェデレーション識別子を使用して加入者(subscriber)を追跡することが防止される．

In some circumstances, it is desirable to prevent the subscriber account from being easily linked at multiple RPs through use of a common identifier. A pairwise pseudonymous identifier (PPI) allows an IdP to provide multiple distinct federated identifiers to different RPs for a single subscriber account. This prevents different RPs from colluding together to track the subscriber using the federated identifier.

一般的な要件 (General Requirements)

RP 向けに，IdP によって生成されたアサーション内でペアワイズ仮名識別子を使用する場合，IdP は以下の Sec. 6.2.5.2 で説明されているように，RP ごとに異なるフェデレーション識別子を生成する必要がある．

When using pairwise pseudonymous identifiers within the assertions generated by the IdP for the RP, the IdP SHALL generate a different federated identifier for each RP as described in Sec. 6.2.5.2 below.

PPI が属性と一緒に RP と共に使用される場合，依然として，複数の共謀 RP が，これらの属性を使用するシステム間の相互関係によって加入者(subscriber)を再識別できる可能性がある．たとえば，2つの独立した RP がそれぞれ，異なるペアワイズ仮名識別子で識別された同じ加入者(subscriber)を確認した場合でも，名前，メールアドレス，住所，それぞれのアサーション内でペアワイズ仮名識別子と共に提示されるその他の識別属性を比較することにより，加入者(subscriber)が同一人物であると判断することができる．プライバシーポリシーは，そのような相関を禁止する必要があり(SHOULD)，ペアワイズ仮名識別子は，属性相関を管理する作業を増やすことで，これらのポリシーの有効性を高めることができる．

When PPIs are used with RPs alongside attributes, it may still be possible for multiple colluding RPs to re-identify a subscriber by correlation across systems using these identity attributes. For example, if two independent RPs each see the same subscriber identified with different pairwise pseudonymous identifiers, they could still determine that the subscriber is the same person by comparing the name, email address, physical address, or other identifying attributes carried alongside the pairwise pseudonymous identifier in the respective assertions. Privacy policies SHOULD prohibit such correlation, and pairwise pseudonymous identifiers can increase effectiveness of these policies by increasing the administrative effort in managing the attribute correlation.

注記：プロキシは，加入者(subscriber)がアクセスしている RP を IdP が認識できないようにする可能性があるため，プロキシされたフェデレーションモデルでは，最初の IdP は最終的な RP のペアワイズ仮名識別子を生成できない可能性がある．このような状況では，通常，IdP とフェデレーションプロキシ自体の間でペアワイズ仮名識別子が確立される．IdP として機能するプロキシ自体が，ペアワイズ仮名識別子を RP に提供できる．プロトコルによっては，フェデレーションプロキシは，アイデンティティプロトコルを機能させるために，ペアワイズ仮名識別子を IdP からの関連付けられた識別子にマッピングし直す必要がある場合がある．そのような場合，プロキシは，どのペアワイズ仮名識別子が異なる RP で同じ加入者(subscriber)を表しているかを追跡および判断することができる．プロキシは，ペアワイズ仮名識別子とその他の識別子との間のマッピングを第三者に開示してはならない(SHALL NOT)．また，フェデレーション認証，関連する詐欺の軽減，法律または法的手続きの遵守，特定のユーザーからの情報の要求以外の目的で情報を使用してはならない(SHALL NOT)．

Note that in a proxied federation model, the initial IdP may be unable to generate a pairwise pseudonymous identifier for the ultimate RP, since the proxy could blind the IdP from knowing which RP is being accessed by the subscriber. In such situations, the pairwise pseudonymous identifier is generally established between the IdP and the federation proxy itself. The proxy, acting as an IdP, can itself provide pairwise pseudonymous identifiers to downstream RPs. Depending on the protocol, the federation proxy may need to map the pairwise pseudonymous identifiers back to the associated identifiers from upstream IdPs in order to allow the identity protocol to function. In such cases, the proxy will be able to track and determine which pairwise pseudonymous identifiers represent the same subscriber at different RPs. The proxy SHALL NOT disclose the mapping between the pairwise pseudonymous identifier and any other identifiers to a third party or use the information for any purpose other than federated authentication, related fraud mitigation, to comply with law or legal process, or in the case of a specific user request for the information.

ペアワイズ仮名識別子の生成 (Pairwise Pseudonymous Identifier Generation)

ペアワイズ仮名識別子は，加入者(subscriber)に関する識別情報を含まないようにしなければならない(SHALL)．また，加入者(subscriber)を特定する情報にアクセスできる当事者が推測できないものにしなければならない(SHALL)．ペアワイズ仮名識別子は，ランダムに生成され，IdP によって加入者(subscriber)に割り当てられてもよい(MAY)．あるいは，不可逆な方法で生成され,推測不可能な方法である場合 (たとえば，秘密鍵でハッシュ関数を使用するなど)，他の加入者(subscriber)情報から生成してもよい(MAY)．

Pairwise pseudonymous identifiers SHALL contain no identifying information about the subscriber. They SHALL also be unguessable by a party having access to some information identifying the subscriber. Pairwise pseudonymous identifiers MAY be generated randomly and assigned to subscribers by the IdP or MAY be derived from other subscriber information if the derivation is done in an irreversible, unguessable manner (e.g., using a keyed hash function with a secret key).

通常，識別子は1つのエンドポイントのペア (例: IdP-RP) によってのみ認識され，使用されなければならない(SHALL)．IdP は，複数の RP の要求に応じて，複数の RP で加入者(subscriber)に同じ識別子を生成してもよい(MAY)．下記のような場合である．

• 信頼の合意(trust agreement)は，RP の特定のファミリーの共有仮名識別子を規定している．
• authorized party は，共有仮名識別子の使用に同意し，その使用について通知されている．
• RP に，共有のセキュリティドメインや共有の法的所有権など，運用上の必要性を正当化する実証可能な関係がある．
• 識別子を共有するすべての RP は，そのような方法で関連付けられることに同意する (つまり，ある RP は，他の RP の同意なしに，別の RP の PPI を要求することはできない)．

Normally, the identifiers SHALL only be known by and used by one pair of endpoints (e.g., IdP-RP). An IdP MAY generate the same identifier for a subscriber at multiple RPs at the request of those RPs, provided:

• The trust agreement stipulates a shared pseudonymous identifier for a specific family of RPs;
• The authorized party consents to and is notified of the use of a shared pseudonymous identifier;
• Those RPs have a demonstrable relationship that justifies an operational need for the correlation, such as a shared security domain or shared legal ownership; and
• All RPs sharing an identifier consent to being correlated in such a manner (i.e., one RP cannot request to have another RP’s PPI without that other RP’s knowledge and consent).

RP は，共通識別子の要求に関連するプライバシーリスクを考慮するために，プライバシーリスク評価を実施しなければならない(SHALL)．プライバシーに関するその他の考慮事項は，Sec. 9.2 を参照．

The RPs SHALL conduct a privacy risk assessment to consider the privacy risks associated with requesting a common identifier. See Sec. 9.2 for further privacy considerations.

IdP は，意図した RP のみが関連付けられるようにしなければならない(SHALL)．そうしない場合，不正な RP が相関する RP の一部として装うことで，相関する RP の仮名識別子を知ることができてしまう．

The IdP SHALL ensure that only intended RPs are correlated; otherwise, a rogue RP could learn of the pseudonymous identifier for a set of correlated RPs by fraudulently posing as part of that set.

アイデンティティAPI (Identity APIs)

プロファイル情報を含む加入者(subscriber)に関する属性は，アイデンティティAPI として知られる保護された 属性API を通じて RP に提供されてもよい(MAY)．RP は，アサーションと連携して，フェデレーショントランザクション中に アイデンティティAPI への制限付きアクセスを許可される． たとえば，OpenID Connect では，UserInfo エンドポイントは，加入者(subscriber)に関する属性を取得するための標準化された アイデンティティAPI を提供する．この API は，OpenID Connect のアサーションである ID トークンとともに RP に発行される OAuth 2.0 アクセス トークンによって保護される．フェデレーションアサーションと共に アイデンティティAPI を使用すると，フェデレーションシステムの全体的なセキュリティ，プライバシー，および効率性にいくつかの利点がある．

Attributes about the subscriber, including profile information, MAY be provided to the RP through a protected attribute API known as the identity API. The RP is granted limited access to the identity API during the federation transaction, in concert with the assertion. For example, in OpenID Connect, the UserInfo Endpoint provides a standardized identity API for fetching attributes about the subscriber. This API is protected by an OAuth 2.0 Access Token, which is issued to the RP along with OpenID Connect’s assertion, the ID Token. The use of identity APIs along with federation assertions has several advantages for the overall security, privacy, and efficiency of the federation system.

アイデンティティAPI で属性を使用できるようにすることで，IdP はアサーションを使用して多くの情報を RP に伝える必要がなくなる．これは，機密属性をアサーション自体で保持する必要がないことを意味するだけでなく，アサーションを小さくし，RP による処理を容易にする．アサーションの内容は，必須フィールド (例えば，一意の主体識別子) と，提示される即時認証イベントに関する情報に限定することができる．

By making attributes available at an identity API, the IdP no longer has to use the assertion to convey as much information to the RP. This not only means that sensitive attributes do not have to be carried in the assertion itself, it also makes the assertion smaller and easier to process by the RP. The contents of the assertion can then be limited to essential fields (e.g., unique subject identifiers) and information about the immediate authentication event being asserted.

RP は，Sec. 5.4で説明されているように，RP 加入者(subscriber)アカウントで IdP によって提供される属性をキャッシュすることがよくある．アサーションで提供される属性はログインごとに渡される．RP は属性が要求される前に加入者(subscriber)の アイデンティティ を知らないため，IdP はアサーション自体にできるだけ多くの情報を含めるようにしようとする．ただし，加入者(subscriber)の属性のほとんどはその後のログイン間で変更されないため，この情報は冗長になる．結果として，これらの変更される頻度の低い属性のほとんどは，代わりに，必要な場合にのみ RP によって呼び出される アイデンティティAPI を介して使用できるようになる．IdP は，加入者(subscriber)の属性が加入者(subscriber)アカウントで最後に更新された時期をアサーションで示すことができる．これにより，RP は属性を新たにフェッチする必要があるかどうか，または それらの RP 加入者(subscriber)アカウントの属性は十分であるかどうかを判断できまる．

The RP often caches attributes provided by the IdP in an RP subscriber account, discussed in Sec. 5.4. Attributes provided in the assertion are passed on every login, and since the RP does not know the identity of the subscriber before the attribute is requested, the IdP is incentivized to include as much information as possible in the assertion itself. However, most of a subscriber’s attributes will not change in between subsequent logins, making this information redundant. As a consequence, most of these more-stable attributes can instead be made available through an identity API that is called by the RP only when necessary. The IdP can indicate in the assertion when the last time the subscriber’s attributes have been updated in the subscriber account, allowing the RP to decide if it needs to fetch the attributes anew or if those in the RP subscriber account are sufficient.

アイデンティティAPI へのアクセスは時間が制限されなければならない(SHALL)．制限される時間は，アサーションの有効期間および RP での認証済みセッションの有効期間とは別のものである．関連付けられた有効なアサーションのない RP による アイデンティティAPI へのアクセスでは，RP で認証されたセッションを確立ために十分であってはならない(SHALL NOT)．．

Access to the identity API SHALL be time limited. The time limitation is separate from the validity time window of the assertion and the lifetime of the authenticated session at the RP. Access to an identity API by the RP without an associated valid assertion SHALL NOT be sufficient for the establishment of an authenticated session at the RP.

特定の アイデンティティAPI を用意することで，IdP がアサーションを作成できるすべての加入者(subscriber)に属性を提供できることが期待されている．ただし，アイデンティティAPI へのアクセスがフェデレーショントランザクションのコンテキスト内で許可される場合，アイデンティティAPI によって提供される属性は，関連付けられたアサーションで識別される単一の加入者(subscriber)のみに関連付けられなければならない(SHALL)．アイデンティティAPI が IdP によってホストされている場合，返される属性には加入者(subscriber)の主体識別子が含まれなければならない(SHALL)．これにより，RP はアサーションの主体を返された属性に積極的に関連付けることができる．注記：Sec. 5.4.1 で説明されているように，属性 API へのアクセスが RP 加入者(subscriber)アカウントの事前プロビジョニングの一部として提供される場合，RP は通常，フェデレーショントランザクションのコンテキスト外でアイデンティティAPI への制限のないアクセスが許可され，これらの要件は適用されない．

A given identity API deployment is expected to be capable of providing attributes for all subscribers for whom the IdP can create assertions. However, when access to the identity API is granted within the context of a federation transaction, the attributes provided by an identity API SHALL be associated with only the single subscriber identified in the associated assertion. If the identity API is hosted by the IdP, the returned attributes SHALL include the subject identifier for the subscriber. This allows the RP to positively correlate the assertion’s subject to the returned attributes. Note that when access to an attribute API is provided as part of pre-provisioning of RP subscriber accounts as discussed in Sec. 5.4.1, the RP is usually granted blanket access to the identity API outside the context of the federated transaction and these requirements do not apply.

属性プロバイダー(Attribute Providers)

フェデレーションで使用されるほとんどの属性 API は IdP の一部としてホストされるが，IdP が外部属性プロバイダーによってホストされる アイデンティティAPI へのアクセスを許可することも可能である．これらのサービスは，IdP から直接利用できる属性に加えて，更なる加入者(subscriber)に関する属性を提供する．

While most attribute APIs used in federation are hosted as part of the IdP, it is also possible for the IdP to grant access to identity APIs hosted by external attribute providers. These services provide attributes about the subscriber in addition to those made available directly from the IdP.

IdP が属性プロバイダーへのアクセスを許可するとき，IdP は，属性プロバイダーから返された情報が，関連付けられたアサーションで識別された加入者(subscriber)に関連付けられていることを明示的に宣言する．信頼の合意(trust agreement)の目的上，IdP は属性 API の正確さと内容について責任を負う．

When the IdP grants access to an attribute provider, the IdP is making an explicit statement that the information returned from the attribute provider is associated with the subscriber identified in the associated assertion. For the purposes of the trust agreement, the IdP is the responsible party for the accuracy and content of the attribute API.

属性プロバイダーによって返される属性は，IdP から直接返される属性とは無関係であると想定されるため，異なる識別子，形式，またはスキーマを使用してもよい(MAY)．RP は，識別された属性プロバイダーが，該当する信頼の合意(trest agreement)の下で，存在する種類の属性について提供することを許容されているか確認しなければならない(SHALL)．

The attributes returned by the attribute provider are assumed to be independent of those returned directly from the IdP, and as such MAY use different identifiers, formats, or schemas. The RP SHALL verify that the identified attribute provider is capable of providing the kinds of attributes that are present, under the auspices of the applicable trust agreement.

たとえば，IdP が，フェデレーションプロセスの一部として加入者(subscriber)の医師免許情報へのアクセスを提供している場合，IdP が免許の状態を直接提示する代わりに，IdP は，医師免許機関の加入者(subscriber)のレコードへの RP からのアクセスを提供する．この場合，免許情報は IdP が使用する主体識別子と同じものを使用しない可能性があるが，RP は現在の加入者(subscriber)と免許情報との間に強力な関連付けを作成できる．

For example, an IdP could provide access to a subscriber’s medical license information as part of the federation process. Instead of the IdP asserting the license status directly, the IdP provides the RP access to a record for the subscriber at a medical licensure agency. The RP can make a strong association between the current subscriber and the license record, even though the license record will not likely use the same subject identifier that the IdP does in this case.

アサーションの提示 (Assertion Presentation)

This section is normative.

プロトコルの詳細に応じて，RP と IdP は 2つの方法で相互に通信する．これにより，IdP から RP にアサーションを渡すことができる 2つの異なる方法が可能になる．

• 加入者(subscriber)と加入者(subscriber)のブラウザーを含むリダイレクトによる フロントチャネル．
• 加入者(subscriber)を直接含まない，RP と IdP 間の直接接続を介した バックチャネル．

Depending on the specifics of the protocol, the RP and the IdP communicate with each other in two ways, which lends to two different ways in which an assertion can be passed from the IdP to the RP:

• The front channel, through redirects involving the subscriber and the subscriber’s browser; or
• The back channel, through a direct connection between the RP and IdP, not involving the subscriber directly.

各モデルにはトレードオフがあるが，それぞれにアサーションの適切な検証が必要である．Sec. 5.1.3 で詳細に説明されているように，アサーションは，異なる提示方法を使用して IdP と RP 間のフェデレーションを促進するためにプロキシされてもよい(MAY)．

There are tradeoffs with each model, but each requires the proper validation of the assertion. Assertions MAY also be proxied to facilitate federation between IdPs and RPs using different presentation methods, as discussed in detail in Sec. 5.1.3.

バックチャネル (Back-Channel Presentation)

バックチャネルの提示モデルでは，加入者(subscriber)は，通常はフロントチャネルを通じて，RP に提示するためのアサーション参照を与えられる．アサーション参照自体には加入者(subscriber)に関する情報は含まれておらず，攻撃者による改ざんや偽造に対して耐性がなければならない(SHALL)．RP は，アサーションを取得するために，通常は RP 自体の認証とともに，アサーション参照を IdP に提示する．

In the back-channel presentation model, the subscriber is given an assertion reference to present to the RP, generally through the front channel. The assertion reference itself contains no information about the subscriber and SHALL be resistant to tampering and fabrication by an attacker. The RP presents the assertion reference to the IdP, usually along with authentication of the RP itself, to fetch the assertion.

図12. Back-channel Presentation

図12 に示すように，バックチャネルの提示モデルは次の3つのステップで構成される．

1. IdP は，フロントチャネルを介して加入者(subscriber)にアサーション参照を送信する．
2. 加入者(subscriber)は，フロントチャネルを介して RP にアサーション参照を送信する．
3. RP は，バックチャネルを介して，アサーション参照と RP クレデンシャルを IdP に提示する．IdP は資格情報を検証し，アサーションを返す．

As shown in Figure 12, the back-channel presentation model consists of three steps:

1. The IdP sends an assertion reference to the subscriber through the front channel.
2. The subscriber sends the assertion reference to the RP through the front channel.
3. The RP presents the assertion reference and its RP credentials to the IdP through the back channel. The IdP validates the credentials and returns the assertion.

アサーション参照:

1. 単一の RP による使用に制限されなければならない(SHALL)．
2. 使い捨てでなければならない(SHALL)．
3. 時間制限がなければならなず(SHALL)，有効期間が数分以内である必要がある(SHOULD)．
4. RP の認証とともに IdP に提示しなければならない(SHALL)．
5. 少なくとも 128 ビットのエントロピーを含まなければならない(SHALL)．

The assertion reference:

1. SHALL be limited to use by a single RP.
2. SHALL be single-use.
3. SHALL be time limited, and SHOULD have a lifetime of no more than a small number of minutes in length.
4. SHALL be presented along with authentication of the RP to the IdP.
5. SHALL contain at least 128 bits of entropy.

\clearpage

このモデルでは，RP は IdP からのアサーションを直接要求し，第三者 (加入者(subscriber)自身を含む) による傍受と操作の可能性を最小限に抑える．

In this model, the RP directly requests the assertion from the IdP, minimizing chances of interception and manipulation by a third party (including the subscriber themselves).

この方法は，RP が IdP にアサーション自体に含まれていない加入者(subscriber)に関する追加の属性を照会することも容易にする．これは，最初の認証トランザクションが完了した後，ユーザーを IdP に送り返すことなく，バックチャネル通信が引き続き発生する可能性があるためである．Sec. 6.3 で説明されている通り，この照会は，アイデンティティAPIを使う際に発生する．

This method also facilitates the RP querying the IdP for additional attributes about the subscriber not included in the assertion itself, since back-channel communication can continue to occur after the initial authentication transaction has been completed without sending the user back to the IdP. This query occurs using an identity API, as described in Sec. 6.3.

バックチャネル方式では，より多くのネットワークトランザクションが必要になるが，情報はそれを必要とする関係者のみに限定される．RP は IdP からのみ直接アサーションを取得することを期待しているため，攻撃に面する機会が減少する．したがって，アサーションを RP に直接インジェクションすることはより困難であり，この表示方法は FAL2 以降に推奨される．

More network transactions are required in the back-channel method, but the information is limited to only those parties that need it. Since an RP is expecting to get an assertion only from the IdP directly, the attack surface is reduced. Consequently, it is more difficult to inject assertions directly into the RP and this presentation method is recommended for FAL2 and above.

RP は，クロスサイトスクリプティングに対する保護またはその他の承認された技術を使用して，製造またはキャプチャされたアサーション参照のインジェクションから自身を保護しなければならない(SHALL)．

The RP SHALL protect itself against injection of manufactured or captured assertion references by use of cross-site scripting protection or other accepted techniques.

IdP から加入者(subscriber)へのアサーション参照の伝達，および加入者(subscriber)から RP へのアサーション参照の伝達は，認証され保護されたチャネルを介して行われなければならない(SHALL)．RP から IdP へのアサーション参照の伝達，および IdP から RP へのアサーションは，認証され保護されたチャネルを介して行われなければならない(SHALL)．

Conveyance of the assertion reference from the IdP to the subscriber, as well as from the subscriber to the RP, SHALL be made over an authenticated protected channel. Conveyance of the assertion reference from the RP to the IdP, as well as the assertion from the IdP to the RP, SHALL be made over an authenticated protected channel.

アサーション参照が提示される場合，IdP は，アサーション参照を提示する当事者が認証を要求した当事者と同じであることを検証しなければならない(SHALL)．IdP は，アサーション参照を IdP に提示する際に RP が自身を認証することを要求するか，他の同様の手段を使用してこれを行うことができる．(プロトコルの動的な RP の検証方法については，[RFC7636] を参照)．

When assertion references are presented, the IdP SHALL verify that the party presenting the assertion reference is the same party that requested the authentication. The IdP can do this by requiring the RP to authenticate itself when presenting the assertion reference to the IdP or through other similar means (see [RFC7636] for one protocol’s method of dynamic RP verification).

注記：Sec. 5.1.3 で説明されているフェデレーションプロキシでは，IdP はアサーション参照とアサーションの対象者をプロキシに制限し，プロキシは新しく作成されたアサーション参照またはアサーションの送付先を RP に制限する．

Note that in a federation proxy described in Sec. 5.1.3, the IdP audience restricts the assertion reference and assertion to the proxy, and the proxy restricts any newly-created assertion references or assertions to the downstream RP.

\clearpage

フロントチャネル (Front-Channel Presentation)

フロントチャネルの提示モデルでは，IdP はアサーションを作成し，認証の成功後に加入者(subscriber)に送信する．アサーションは加入者(subscriber)によって提示され，RP に対して認証される．通常は，リダイレクトなどの加入者(subscriber)のブラウザー内のメカニズムを介して行われる．

In the front-channel presentation model, the IdP creates an assertion and sends it to the subscriber after successful authentication. The assertion is presented by the subscriber to authenticate to the RP, usually through mechanisms within the subscriber’s browser such as redirects.

図13. Front-channel Presentation

アサーションは，フロントチャネル方式で加入者(subscriber)に表示される．これにより，アサーションに含まれるシステム情報が漏えいする可能性がある．さらに，Sec. 6.3 で説明されているように，アイデンティティAPI を使用してアサーションを提示した後，RP が IdP に追加の属性を照会することは可能なものの，このモデルではより対応が難しい．

An assertion is visible to the subscriber in the front-channel method, which could potentially cause leakage of system information included in the assertion. Further, it is possible but more awkward in this model for the RP to query the IdP for additional attributes after the presentation of the assertion using an identity API, as described in Sec. 6.3.

アサーションは加入者(subscriber)の制御下にあるため，フロントチャネル方式を使用すると，加入者(subscriber)は，複数の RP でアサーションをリプレイするブラウザーなどによって，意図しない関係者に単一のアサーションを送信することもできてしまう．アサーションの対象者が制限されていて意図しない RP によって拒否されたとしても，意図しない RP への提示は，加入者(subscriber)の情報や加入者(subscriber)のオンラインでの活動に関する情報の漏えいにつながる可能性がある．複数の RP に提示されるように設計されたアサーションを意図的に作成することは可能だが，この方法では，アサーション自体の対象者の制限が緩くなり，これらの RP 全体で加入者(subscriber)のプライバシーとセキュリティが侵害される可能性がある．このような複数の RP の使用は推奨されない．代わりに，RP は独自のアサーションを取得することが推奨される．

Since the assertion is under the subscriber’s control, the front-channel presentation method also allows the subscriber to submit a single assertion to unintended parties, perhaps by a browser replaying an assertion at multiple RPs. Even if the assertion is audience-restricted and rejected by unintended RPs, its presentation at unintended RPs could lead to leaking information about the subscriber and their online activities. Though it is possible to intentionally create an assertion designed to be presented to multiple RPs, this method can lead to lax audience restriction of the assertion itself, which in turn could lead to privacy and security breaches for the subscriber across these RPs. Such multi-RP use is not recommended. Instead, RPs are encouraged to fetch their own individual assertions.

RP は，クロスサイトスクリプティングに対する保護やその他の利用可能な技術を使用して，製造またはキャプチャされたアサーションのインジェクションから自身を保護しなければならない(SHALL)．

IdP から加入者(subscriber)へのアサーションの伝達，および加入者(subscriber)から RP へのアサーションの伝達は，認証された保護されたチャネルを介して行われなければならない(SHALL)．

The RP SHALL protect itself against injection of manufactured or captured assertions by use of cross-site scripting protection and other accepted techniques.

Conveyance of the assertion from the IdP to the subscriber, as well as from the subscriber to the RP, SHALL be made over an authenticated protected channel.

注記：Sec. 5.1.3 で説明されているフェデレーションプロキシでは，IdPのアサーションの対象者はプロキシに制限し，プロキシは新しく作成されたアサーションの送り先を RP に制限する．

Note that in a federation proxy described in Sec. 5.1.3, the IdP audience restricts the assertion to the proxy, and the proxy restricts any newly-created assertions to the downstream RP.

情報の保護 (Protecting Information)

IdP と RP の間の通信は，認証され保護されたチャネルを使用して転送中に保護されなければならない(SHALL)．加入者(subscriber)と IdP または RP (通常はブラウザーを介して) との間の通信は，認証され保護されたチャネルを使用して行われなければならない(SHALL)．

Communications between the IdP and the RP SHALL be protected in transit using an authenticated protected channel. Communications between the subscriber and either the IdP or the RP (usually through a browser) SHALL be made using an authenticated protected channel.

注記：IdP は，デバイス識別子，場所，システムのヘルスチェック，構成管理などのセキュリティポリシーを適用する際に RP にとって役立つ情報にアクセスできる場合がある．その場合，Sec. 9.2 で説明されている加入者(subscriber)のプライバシー設定の範囲内で，この情報を RP に渡すことをお勧めする．

Note that the IdP may have access to information that may be useful to the RP in enforcing security policies, such as device identity, location, system health checks, and configuration management. If so, it may be a good idea to pass this information along to the RP within the bounds of the subscriber’s privacy preferences described in Sec. 9.2.

ユーザーに関する追加の属性は，Sec. 6.3 で説明されているように，アイデンティティAPI への承認されたアクセスを使用して，アサーション自体の外部に含めてもよい(MAY)． この方法でユーザー情報を分割すると，ユーザーのプライバシーを保護するのに役立ち，認証アサーション自体の重要な情報に加えて，識別属性の限定的な開示が可能になる．

Additional attributes about the user MAY be included outside of the assertion itself by use of authorized access to an identity API as discussed in Sec. 6.3. Splitting user information in this manner can aid in protecting user privacy and allow for limited disclosure of identifying attributes on top of the essential information in the authentication assertion itself.

可能な場合，RP は，Sec. 9.3 で説明されているように，完全な属性値ではなく，派生属性値を要求しなければならない(SHALL)．IdP は，派生属性値を可能な限りサポートしなければならない(SHALL)．

The RP SHALL, where feasible, request derived attribute values rather than full attribute values as described in Sec. 9.3. The IdP SHALL support derived attribute values to the extent possible.

Security

This section is informative.

Since the federated authentication process involves coordination between multiple components, including the CSP which now acts as an IdP, there are additional opportunities for attackers to compromise federated identity transactions. This section summarizes many of the attacks and mitigations applicable to federation.

Federation Threats

As in non-federated authentication, attackers’ motivations are typically to gain access (or a greater level of access) to a resource or service provided by an RP. Attackers may also attempt to impersonate a subscriber. Rogue or compromised IdPs, RPs, user agents (e.g., browsers), and parties outside of a typical federation transaction are potential attackers. To accomplish their attack, they might intercept or modify assertions and assertion references. Further, two or more entities may attempt to subvert federation protocols by directly compromising the integrity or confidentiality of the assertion data. For the purpose of these types of threats, any authorized parties who attempt to exceed their privileges are considered attackers.

Table 2 Federation Threats

Federation Threat Mitigation Strategies

Mechanisms that assist in mitigating the above threats are identified in Table 3.

Table 3 Mitigating Federation Threats

Privacy Considerations

This section is informative.

Minimizing Tracking and Profiling

Federation offers numerous benefits to RPs and subscribers, but requires subscribers to have trust in the federation participants. Sec. 5 and Sec. 6.2.5 cover a number of technical requirements, the objective of which is to minimize privacy risks arising from increased capabilities to track and profile subscribers. For example, a subscriber using the same IdP to authenticate to multiple RPs allows the IdP to build a profile of subscriber transactions that would not have existed absent federation. The availability of such data makes it vulnerable to uses that may not be anticipated or desired by the subscriber and may inhibit subscriber adoption of federated services.

Sec. 5.5 requires IdPs to use measures to maintain the objectives of predictability (enabling reliable assumptions by individuals, owners, and operators about PII and its processing by an information system) and manageability (providing the capability for granular administration of PII, including alteration, deletion, and selective disclosure) commensurate with privacy risks that can arise from the processing of attributes for purposes other than identity proofing, authentication, authorization, or attribute assertions, related fraud mitigation, or to comply with law or legal process [NISTIR8062].

IdPs may have various business purposes for processing attributes, including providing non-identity services to subscribers. However, processing attributes for different purposes from the original collection purpose can create privacy risks when individuals are not expecting or comfortable with the additional processing. IdPs can determine appropriate measures commensurate with the privacy risk arising from the additional processing. For example, absent applicable law, regulation or policy, it may not be necessary to get consent when processing attributes to provide non-identity services requested by subscribers, although notices may help subscribers maintain reliable assumptions about the processing (predictability). Other processing of attributes may carry different privacy risks that call for obtaining consent or allowing subscribers more control over the use or disclosure of specific attributes (manageability). Subscriber consent needs to be meaningful; therefore, when IdPs do use consent measures, they cannot make acceptance by the subscriber of additional uses a condition of providing the identity service.

Consult the SAOP if there are questions about whether the proposed processing falls outside the scope of the permitted processing or the appropriate privacy risk mitigation measures.

Sec. 5.5 also encourages the use of technical measures to provide disassociability (enabling the processing of PII or events without association to individuals or devices beyond the operational requirements of the system) and prevent subscriber activity tracking and profiling [NISTIR8062]. Technical measures, such as those outlined in Sec. 5.1.3 for proxied federation and Sec. 6.2.5 for pairwise pseudonymous identifiers, can increase the effectiveness of policies by making it more difficult to track or profile subscribers beyond operational requirements.

Notice and Consent

To build subscriber trust in federation, subscribers need to be able to develop reliable assumptions about how their information is being processed. For instance, it can be helpful for subscribers to understand what information will be transmitted, which attributes for the transaction are required versus optional, and to have the ability to decide whether to transmit optional attributes to the RP. Accordingly, Sec. 5.1 requires that positive confirmation be obtained from the authorized party before any attributes about the subscriber are transmitted to any RP. In determining when a set of RPs should share a common pairwise pseudonymous identifier as in Sec. 6.2.5.2, the IdP considers the subscriber’s understanding of such a grouping of RPs and the role of notice in assisting such understanding. An effective notice will take into account user experience design standards and research, as well as an assessment of privacy risks that may arise from the information processing. There are various factors to be considered, including the reliability of the assumptions subscribers may have about the processing and the role of different entities involved in federation. However, a link to a complex, legalistic privacy policy or general terms and conditions that a substantial number of subscribers do not read or understand is never an effective notice.

Sec. 5.1 does not specify which party should provide the notice. In some cases, a party in a federation may not have a direct connection to the subscriber in order to provide notice and obtain consent. Although multiple parties may elect to provide notice, it is permissible for parties to determine in advance, either contractually or through trust framework policies, which party will provide the notice and obtain confirmation, as long as the determination is being based upon factors that center on enabling the subscriber to pay attention to the notice and make an informed choice.

If an IdP is using an allowlist of RPs as described in Sec. 5.3, any RPs on that list are not presented to the subscriber during an authentication transaction. Since the IdP does not provide notice to the subscriber at runtime, the IdP makes its list of allowlisted RPs available to the subscriber so that the subscriber can see which RPs on the allowlist have access to which of the subscriber’s attributes in an authentication transaction. Since IdPs can not share a subscriber’s authentication information or attributes with an allowlisted RP outside of an authentication transaction involving the subscriber (see Sec. 5.5), the existence of an RP on a list of IdPs does not indicate that the subscriber’s information will be shared. However, if the subscriber logs into any of the allowlisted RPs using the IdP, the attributes indicated will be shared as part of the authentication transaction.

If a subscriber’s runtime decisions at the IdP were stored in the subscriber account by the IdP to facilitate future transactions, the IdP also needs to allow the subscriber to view and revoke any RPs that were previously approved during a runtime decision. This list includes information on which attributes were approved. Similarly, if a subscriber’s runtime decisions at the RP are stored in some fashion, the RP also needs to allow the subscriber to view and revoke any IdPs that were approved during a runtime decision.

Data Minimization

Federation enables the data exposed to an RP to be minimized, which can yield privacy protections for subscribers. Although an IdP may collect additional attributes beyond what the RP requires for its use case, only those attributes that were explicitly requested by the RP are to be transmitted by the IdP. In some instances, an RP does not require a full value of an attribute. For example, an RP may need to know whether the subscriber is over 13 years old, but has no need for the full date of birth. To minimize collection of potentially sensitive PII, the RP may request a derived attribute value (e.g., Question: Is the subscriber over 13 years old? Response: Y/N or Pass/Fail). This minimizes the RP’s collection of potentially sensitive and unnecessary PII. Accordingly, Sec. 7.3 requires the RP to, where feasible, request derived attribute values rather than full attribute values. To support this RP requirement IdPs are, in turn, required to support a derived attribute value.

Agency-Specific Privacy Compliance

Section 5.5 identifies agency requirements to consult their SAOP to determine privacy compliance requirements. It is critical to involve the agency’s SAOP in the earliest stages of digital authentication system development to assess and mitigate privacy risks and advise the agency on compliance obligations such as whether the federation triggers the Privacy Act of 1974 or the E-Government Act of 2002 requirement to conduct a PIA. For example, if the agency is serving as an IdP in a federation, it is likely that the Privacy Act requirements will be triggered and require coverage by either a new or existing Privacy Act system of records since credentials would be maintained at the IdP on behalf of any RP it federates with. If, however, the agency is an RP and using a third-party IdP, digital authentication may not trigger the requirements of the Privacy Act, depending on what data passed from the RP is maintained by the agency at the RP (in such instances the agency may have a broader programmatic SORN that covers such data).

The SAOP can similarly assist the agency in determining whether a PIA is required. These considerations should not be read as a requirement to develop a Privacy Act SORN or PIA for use of a federated credential alone. In many cases it will make the most sense to draft a PIA and SORN that encompasses the entire digital authentication process or includes the digital authentication process as part of a larger programmatic PIA that discusses the program or benefit the agency is establishing online access.

Due to the many components of digital authentication, it is important for the SAOP to have an awareness and understanding of each individual component. For example, other privacy artifacts may be applicable to an agency offering or using federated IdP or RP services, such as Data Use Agreements, Computer Matching Agreements, etc. The SAOP can assist the agency in determining what additional requirements apply. Moreover, a thorough understanding of the individual components of digital authentication will enable the SAOP to thoroughly assess and mitigate privacy risks either through compliance processes or by other means.

Blinding in Proxied Federation

While some proxy structures — typically those that exist primarily to simplify integration — may not offer additional subscriber privacy protection, others offer varying levels of privacy to the subscriber through a range of blinding technologies. Privacy policies may dictate appropriate use of the subscriber attributes and authentication transaction data (e.g., identities of the ultimate IdP and RP) by the IdP, RP, and the federation proxy.

Technical means such as blinding can increase effectiveness of these policies by making the data more difficult to obtain. A proxy-based system has three parties, and the proxy can be used to hide information from one or more of the parties, including itself. In a double-blind proxy, the IdP and RP do not know each other’s identities, and their relationship is only with the proxy. In a triple-blind proxy, the proxy additionally does not have insight into the data being passed through it. As the level of blinding increases, the technical and operational implementation complexity may increase. Since proxies need to map transactions to the appropriate parties on either side as well as manage the keys for all parties in the transaction, fully triple-blind proxies are very difficult to implement in practice.

Even with the use of blinding technologies, a blinded party may still infer protected subscriber information through released attribute data or metadata, such as by analysis of timestamps, attribute bundle sizes, or attribute signer information. The IdP could consider additional privacy-enhancing approaches to reduce the risk of revealing identifying information of the entities participating in the federation.

The following table illustrates a spectrum of blinding implementations used in proxied federation. This table is intended to be illustrative, and is neither comprehensive nor technology-specific.

Table 4 Federation Proxies

Usability Considerations

This section is informative.

Ergonomic of Human-System Interaction — Part 11: Usability: Definitions and Concepts [ISO/IEC9241-11] defines usability as the “extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” This definition focuses on users, goals, and context of use as key elements necessary for achieving effectiveness, efficiency and satisfaction. A holistic approach considering these key elements is necessary to achieve usability.

From the usability perspective, one of the major potential benefits of federated identity systems is to address the problem of user fatigue associated with managing multiple authenticators. While this has historically been a problem with usernames and passwords, the increasing need for users to manage many authenticators — whether physical or digital — presents a usability challenge.

While many other approaches to authentication have been researched extensively and have well-established usability guidelines, federated identity is more nascent and, therefore, lacks the depth and conclusiveness of research findings. As ongoing usability research matures, usability guidelines for federated identity systems will have stronger supporting data. For example, additional data is needed to support guidance on the translation of technical attribute names and values into user-friendly language.

As stated in the usability sections in 800-63A and 800-63B, overall user experience is critical to the success of any authentication method. This is especially true for federated identity systems as federation is a less familiar user interaction paradigm for many users. Users’ prior authentication experiences may influence their expectations.

The overall user experience with federated identity systems should be as smooth and easy as possible. This can be accomplished by following usability standards (such as the ISO 25060 series of standards) and established best practices for user interaction design.

Note: In this section, the term “users” means “claimants” or “subscribers.” The terms “entity” and “entities” refer to the parties of federated systems.

Guidelines and considerations are described from the users’ perspective.

Accessibility differs from usability and is out of scope for this volume. [Section508] was enacted to eliminate barriers in information technology and requires federal agencies to make their electronic and information technology public content accessible to people with disabilities. Refer to Section 508 law and standards for accessibility guidance.

General Usability Considerations

Federated identity systems should:

• Minimize user burden (e.g., frustration, learning curve)
  • Minimize the number of user actions required.
  • Allow users to quickly and easily select among multiple subscriber accounts with a single IdP. For example, approaches such as Account Chooser allow users to select from a list of subscriber accounts they have accessed in the recent past, rather than start the federation process by selecting their IdP from a list of potential IdPs.
  • Balance minimizing user burden with the need to provide sufficient information to enable users to make informed decisions.

• Minimize the use of unfamiliar technical jargon and details (e.g., users do not need to know the terms IdP and RP if the basic concepts are clearly explained).

• Strive for a consistent and integrated user experience across the IdP and RP.

• Help users establish an understanding of identity by providing resources to users such as graphics, illustrations, FAQs, tutorials and examples. Resources should explain how users’ information is treated and how transacting parties (e.g., RPs, IdPs, and brokers) relate to each other.

• Provide clear, honest, and meaningful communications to users (i.e., communications should be explicit and easy to understand).

• Provide users online services independent of location and device.

• Make trust relationships explicit to users to facilitate informed trust decisions. Trust relationships are often dynamic and context dependent. Users may be more likely to trust some IdPs and RPs with certain attributes or transactions more than others. For example, users may be more hesitant to use federated identity systems on websites that contain valuable personal information (such as financial or health). Depending on the perceived sensitivity of users’ personal data, users may be less comfortable with social network providers as IdPs since people are often concerned with the broadcasting nature of social networking implementations.

• Follow the usability considerations specified in [SP800-63A], Sec. 9 for any user-facing information.

• Clearly communicate how and where to acquire technical assistance. For example, provide users with information such as a link to an online self-service feature, chat sessions or a phone number for help desk support. Avoid redirecting users back and forth among transacting parties (e.g., RPs, IdPs, and brokers) to receive technical assistance.

• Perform integrative and continuous usability evaluations with representative users and realistic tasks in an appropriate context to ensure success of federated identity systems from the users’ perspectives.

Specific Usability Considerations

This section addresses the specific usability considerations that have been identified with federated identity systems. This section does not attempt to present exhaustive coverage of all usability factors related to federated identity systems. Rather it is focused on the larger, more pervasive themes in the usability literature, primarily users’ perspectives on identity, user adoption, trust, and perceptions of federated identity space. In some cases, implementation examples are provided. However, specific solutions are not prescribed. The implementations mentioned are examples to encourage innovative technological approaches to address specific usability needs. See standards for system design and coding, specifications, APIs, and current best practices (such as OpenID and OAuth) for additional examples. Implementations are sensitive to many factors that prevent a one-size-fits-all solution.

User Perspectives on Online Identity

Even when users are familiar with federated identity systems, there are different approaches to federated identity (especially in terms of privacy and the sharing of information) that make it necessary to establish reliable expectations for how users’ data are treated. Users and implementers have different concepts of identity. Users think of identity as logging in and gaining access to their own private space. Implementers think of identity in terms of authenticators and assertions, assurance levels, and the necessary set of identity attributes to provide a service. Given this disconnect between users’ and implementers’ concepts of identity, it is essential to help users form an accurate concept of identity as it applies to federated identity systems. A good model of identity provides users a foundation for understanding the benefits and risks of federated systems and encourage user adoption and trust of these systems.

Many properties of identity have implications for how users manage identities, both within and among federations. Just as users manage multiple identities based on context outside of cyberspace, users must learn to manage their identity in a federated environment. Therefore, it must be clear to users how identity and context are used. The following factors should be considered:

• Provide users the requisite context and scope in order to distinguish among different user roles. For example, whether the user is acting on their own behalf or on behalf of another, such as their employer.

• Provide users unique, meaningful, and descriptive identifiers to distinguish among entities such as IdPs, RPs, and accounts. Any such user-facing identifiers are likely to be in addition to identifiers used by the underlying protocols, which are not normally exposed to the user.

• Provide users with information on data ownership and those authorized to make changes. Identities, and the data associated with them, can sometimes be updated and changed by multiple actors. For example, some healthcare data is updated and owned by the patient, while some data is only updated by a hospital or doctor’s practice.

• Provide users with the ability to easily verify, view, and update attributes. Identities and user roles are dynamic and not static; they change over time (e.g., age, health, and financial data). The ability to update attributes or make attribute release decisions may or may not be offered at the same time. Ensure the process for how users can change attributes is well known, documented, and easy to perform.

• Provide users means for updating data, even if the associated entity no longer exists.

• Provide users means to delete their identities completely, removing all information about themselves, including transaction history. Consider applicable audit, legal, or policy constraints that may preclude such action. In certain cases, full deactivation is more appropriate than deletion.

• Provide users with clear, easy-to-find, site/application data retention policy information.

• Provide users with appropriate anonymity and pseudonymity options, and the ability to switch among such identity options as desired, in accordance with an organization’s data access policies.

• Provide means for users to manage each IdP to RP connection, including complete separation as well as the removal of RP access to one or more attributes.

User Perspectives of Trust and Benefits

Many factors can influence user adoption of federated identity systems. As with any technology, users may value some factors more than others. Users often weigh perceived benefits versus risks before making technology adoption decisions. It is critical that IdPs and RPs provide users with sufficient information to enable them to make informed decisions. The concepts of trust and tiers of trust — fundamental principles in federated identity systems — can drive user adoption. Finally, a positive user experience may also result in increased user demand for federation, triggering increased adoption by RPs.

This sub-section is focused primarily on user trust and user perceptions of benefits versus risks.

To encourage user adoption, IdPs and RPs need to establish and build trust with users and provide them with an understanding of the benefits and risks of adoption. The following factors should be considered:

• Allow users to control their information disclosure and provide explicit consent through the appropriate use of notifications (see Sec. 9.2). Balancing the content, size, and frequency of notifications is necessary to avoid thoughtless user click-through.

• For attribute sharing, consider the following:
  • Provide a means for users to verify those attributes and attribute values that will be shared. Follow good security practices (see Sec. 7.3 and Sec. 8).
  • Enable users to consent to a partial list of attributes, rather than an all-or-nothing approach. Allow users some degree of online access, even if the user does not consent to share all information.
  • Allow users to update their consent to their list of shared attributes.
  • Minimize unnecessary information presented to users. For example, do not display system generated attributes (such as pairwise pseudonymous identifiers) even if they are shared with the RP as part of the authentication response.
  • Minimize user steps and navigation. For example, build attribute consent into the protocols so they’re not a feature external to the federated transaction. Examples can be found in standards such as OAuth or OpenID Connect.
  • Provide effective and efficient redress methods such that a user can recover from invalid attribute information claimed by the IdP or collected by the RP.
  • Minimize the number of times a user is required to consent to attribute sharing. Limiting the frequency of consent requests avoids user frustration from multiple requests to share the same attribute.

• Collect information for constrained usage only, and minimize information disclosure (see Sec. 9.3). User trust is eroded by unnecessary and superfluous information collection and disclosure or user tracking without explicit user consent. For example, only request attributes from the user that are relevant to the current transaction, not for all possible transactions a user may or may not access at the RP.

• Clearly and honestly communicate potential benefits and risks of using federated identity to users. Benefits that users value include time savings, ease of use, reduced number of passwords to manage, and increased convenience.

User concern over risk can negatively influence willingness to adopt federated identity systems. Users may have trust concerns, privacy concerns, security concerns, and single-point-of-failure concerns. For example, users may be fearful of losing access to multiple RPs if a single IdP is unavailable, either temporarily or permanently. Additionally, users may be concerned or confused about learning a new authentication process. In order to foster the adoption of federated identity systems, the perceived benefits must outweigh the perceived risks.

User Mental Models and Beliefs

Users’ beliefs and perceptions predispose them to expect certain results and to behave in certain ways. Such beliefs, perceptions, and predispositions are referred to in the social sciences as mental models. For example, people have a mental model of dining out which guides their behavior and expectations at each establishment, such as fast food restaurants, cafeterias, and more formal restaurants. Thus, it is not necessary to be familiar with every establishment to understand how to interact appropriately at each one.

Assisting users in establishing good and complete mental models of federation allows users to generalize beyond a single specific implementation. If federated identity systems are not designed from users’ perspectives, users may form incorrect or incomplete mental models that impact their willingness to adopt these systems. The following factors should be considered:

• Clearly explain the working relationship and information flow among the transacting parties (e.g., RPs, IdPs, and brokers) to avoid user misconceptions. Use the actual names of the entities in the explanation rather than using the generic terms IdPs and RPs.
  • Provide prominent visual cues and information so that users understand why seemingly unrelated entities have a working relationship. For example, users may be concerned with mixing online personal activities with government services due to a lack of understanding of the information flow in federated identity systems.
  • Provide prominent visual cues and information to users about redirection when an RP needs to redirect control from their site to an IdP. For example, display RP branding within the IdP user interface to inform users when they are logging in with their IdP for access to the destination RP.

• Provide users with clear and usable ways (e.g., visual assurance) to determine the authenticity of the transacting parties (e.g., RPs, IdPs, and brokers). This will also help to alleviate user concern over leaving one domain for another, especially if the root domain changes (e.g., .gov to .com). For example, display the URL of the IdP so that the user can verify that they are not being phished by a malicious site.

• Provide users with clear information, including visual cues, regarding implicit logins and explicit logouts. Depending on the implementation, logging into an RP with a federated account may authenticate users to both the IdP and RP. Users may not realize that ending their session with the RP will not necessarily end their session with the IdP; users will need to explicitly “log out” of the IdP. Users require clear information to remind them if explicit logouts are required to end their IdP sessions.

公平性の考慮事項 (Equity Considerations)

This section is informative.

IdP および RP の機能への公平なアクセスは，フェデレーションアイデンティティシステムの不可欠な要素である．行政命令 13985 Advancing Racial Equity and Support for Underserved Communities Through the Federal Government [EO13985] で指定されているように，フェデレーション技術を使用している場合でも，政府サービスへの公平なアクセスを提供するには，すべての加入者(subscriber)が確実に認証できることが必要である．公平性リスクを評価する際，IdP と RP は，フェデレーションアイデンティティサービスが提供する全体的なユーザー数を考慮する必要がありる．さらに，IdP と RP は，そのサービスを使用する際に，共有された特性が，不公平なアクセス，処理，または結果の対象となる可能性がある集団内のユーザーのグループをさらに識別する． Sec. 10 で提供されるユーザビリティに関する考慮事項も，フェデレーションアイデンティティサービスを使用するすべての人にとっての全体的な使いやすさと公平性を確保するためにも考慮されるべきである．

Equitable access to the functions of IdPs and RPs is an essential element of a federated identity system. The ability for all subscribers to authenticate reliably is required to provide equitable access to government services, even when using federation technology, as specified in Executive Order 13985, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government [EO13985]. In assessing equity risks, IdPs and RPs should consider the overall user population served by their federated identity service. Additionally, IdPs and RPs further identify groups of users within the population whose shared characteristics can cause them to be subject to inequitable access, treatment, or outcomes when using that service. The Usability Considerations provided in Sec. 10 should also be considered to help ensure the overall usability and equity for all persons using federated identity services.

検証者としての役割において，IdP は，[SP800-63A] の11章に挙げられているような，身元確認(identity proofing)，属性の検証，および登録に関連する公平性，ならびに，[SP800-63B]の11章に挙げられているような，れたオーセンティケーターに関連する公平性，に関する考慮事項を認識する必要がある．FAL3 を提供する RP は，オーセンティケーターが IdP または RP で管理されているかどうかにかかわらず，バインドされたオーセンティケーターを処理する際，同様のオーセンティケーターの考慮事項を認識する必要がある．

In its role as the verifier, the IdP needs to be aware of equity considerations related to identity proofing, attribute validation, and enrollment as enumerated in [SP800-63A] Sec. 11 and equity considerations concerning authenticators as enumerated in [SP800-63B] Sec. 11. An RP offering FAL3 will also need to be aware of these same authenticator considerations when processing bound authenticators, whether the authenticators are managed at the IdP or RP.

フェデレーションプロセスは複数のアクティブパーティ間でネットワークプロトコルを介して行われるため，フェデレーションシステムを使用して認証を行うと，次の例のような公平性の問題が生じる可能性がある．

Since the federation process takes place over a network protocol between multiple active parties, the experience of authenticating using the federation system may present equity problems, such as the following examples:

• タイムアウトすることなくフェデレーショントランザクション全体を完了することは，信頼できるネットワーク接続を持たない加入者(subscriber) (農村地域など) にとっては難しい場合がある．
• 知的障害，発達障害，学習障害，または神経認知障害のある加入者(subscriber)の属性の提供に関する実行時の決定について，インフォームドコンセントを提供することは困難な場合がある．
• IdP と RP の両方と同時に対話するために必要な十分な処理能力，ネットワークアクセス，およびその他の機能を備えたシステムは，一部の加入者(subscriber)にとっては購入しにくい場合がある．
• デバイスを共有する加入者(subscriber)は，ホワイトリストベースのシステムを安全に管理するのが難しいと感じる場合がある．これは，デバイスの他のユーザーが，IdP でまだアクティブなセッションを介して RP への意図しないアクセスを黙って取得する可能性があるためである．
• さまざまな理由で IdP へのアクセスを失った加入者(subscriber)のために，RP でアカウントを再確立することは非常に困難になる可能性がある．

• Completing the entire federated transaction without timing out may be difficult for subscribers without a reliable network connection, such as those in rural areas.
• It may be difficult to provide informed consent for a runtime decision regarding the release of attributes for subscribers with intellectual, developmental, learning, or neurocognitive difficulties.
• Systems with sufficient processing power, network access, and other features required to interact with both the IdP and the RP simultaneously may be difficult to afford for some subscribers.
• Subscribers that share devices may find allowlist-based systems difficult to manage securely, as other users of the device could silently gain unintended access to an RP through a session still active at the IdP.
• It could be prohibitively difficult to re-establish an account at the RP for subscribers who lose access to their IdP for any of a variety of reasons.

最も一般的であると予想されるこの分野の問題を軽減するため IdP と RP に要求する規範的な要件が確立されている．しかし，規範的(Normative)要件がすべての潜在的な公平性の問題を予期している可能性は低い．潜在的な公平性の問題も，アプリケーションによって異なる．したがって，IdP と RP は，加入者(subscriber)が不公平な認証要件を報告し，潜在的な代替認証戦略についてアドバイスするメカニズムを提供する必要がある．

Normative requirements have been established requiring IdPs and RPs to mitigate the problems in this area that are expected to be most common. However, normative requirements are unlikely to have anticipated all potential equity problems. Potential equity problems also will vary for different applications. Accordingly, IdPs and RPs need to provide mechanisms for subscribers to report inequitable authentication requirements and to advise them on potential alternative authentication strategies.

本ガイドラインにより，追加のフェデレーション識別子を RP 加入者(subscriber)アカウントにバインドすることで，IdP アクセス損失のリスクを最小限に抑えることができる (Sec 5.4 参照)．ただし，加入者(subscriber)は，RP に受け入れられる複数の IdP アカウントを同時に持つことが難しい場合がある．この不公平性は，RP 加入者(subscriber)アカウントからの複数のフェデレーション識別子の安全なバインドおよびバインド解除を可能にする独自のアカウント回復プロセスを RP に持たせることで対処できる．

This guideline allows the binding of additional federated identifiers to an RP subscriber account to minimize the risk of IdP access loss (see Sec. 5.4). However, a subscriber might find it difficult to have multiple IdP accounts that are acceptable to the RP at the same time. This inequity can be addressed by having the RP having its own account recovery process that allows for the secure binding and unbinding of multiple federated identifiers from the RP subscriber account.

RP は，すべての加入者(subscriber)が必ずしも同じ IdP にアクセスできるとは限らないことに注意する必要がある．RP は，そのような加入者(subscriber)に対してローカルで認証されたアカウントを作成し，後でそれらのアカウントをフェデレーション識別子にバインドできるようにする．

RPs need to be aware that not all subscribers will necessarily have access to the same IdPs. The RPs can institute locally authenticated accounts for such subscribers, and later allow binding of those accounts to federated identifiers.

Examples

This section is informative.

Three types of assertion technologies are discussed below: SAML assertions, Kerberos tickets, and OpenID Connect tokens. This list is not inclusive of all possible assertion technologies, but does represent those commonly used in federated identity systems.

Security Assertion Markup Language (SAML)

SAML is an XML-based framework for creating and exchanging authentication and attribute information between trusted entities over the internet. As of this writing, the latest specification for SAML is SAML v2.0, issued 15 March 2005.

The building blocks of SAML include:

• The Assertions XML schema, which defines the structure of the assertion.
• The SAML Protocols, which are used to request assertions and artifacts (the assertion references used in the indirect model described in Sec. 7.1).
• The Bindings, which define the underlying communication protocols (such as HTTP or SOAP), and can be used to transport the SAML assertions.

The three components above define a SAML profile that corresponds to a particular use case such as “Web Browser SSO”.

SAML Assertions are encoded in an XML schema and can carry up to three types of statements:

• Authentication statements include information about the assertion issuer, the authenticated subscriber, validity period, and other authentication information. For example, an Authentication Assertion would state the subscriber “John” was authenticated using a password at 10:32pm on 06-06-2004.

• Attribute statements contain specific additional characteristics related to the subscriber. For example, subject “John” is associated with attribute “Role” with value “Manager”.

• Authorization statements identify the resources the subscriber has permission to access. These resources may include specific devices, files, and information on specific web servers. For example, subject “John” for action “Read” on “Webserver1002” given evidence “Role”.

Authorization statements are beyond the scope of this document and will not be discussed.

Kerberos Tickets

The Kerberos Network Authentication Service [RFC4120] was designed to provide strong authentication for client/server applications using symmetric-key cryptography on a local, shared network. Extensions to Kerberos can support the use of public key cryptography for selected steps of the protocol. Kerberos also supports confidentiality and integrity protection of session data between the subscriber and the RP. Even though Kerberos uses assertions, it was designed for use on shared networks and, therefore, is not truly a federation protocol.

Kerberos supports authentication of a subscriber over a network using one or more IdPs. The subscriber implicitly authenticates to the IdP by demonstrating the ability to decrypt a random session key encrypted for the subscriber by the IdP. (Some Kerberos variants also require the subscriber to explicitly authenticate to the IdP, but this is not universal.) In addition to the encrypted session key, the IdP also generates another encrypted object called a Kerberos ticket. The ticket contains the same session key, the identity of the subscriber to whom the session key was issued, and an expiration time after which the session key is no longer valid. The ticket is confidentiality and integrity protected by a pre-established key that is shared between the IdP and the RP during an explicit setup phase.

To authenticate using the session key, the subscriber sends the ticket to the RP along with encrypted data that proves that the subscriber possesses the session key embedded within the Kerberos ticket. Session keys are either used to generate new tickets or to encrypt and authenticate communications between the subscriber and the RP.

To begin the process, the subscriber sends an authentication request to the Authentication Server (AS). The AS encrypts a session key for the subscriber using the subscriber’s long-term credential. The long-term credential may either be a secret key shared between the AS and the subscriber, or in the PKINIT variant of Kerberos, a public key certificate. Most variants of Kerberos based on a shared secret key between the subscriber and IdP derive this key from a user-generated password. As such, they are vulnerable to offline dictionary attacks by passive eavesdroppers, unless Flexible Authentication Secure Tunneling (FAST) [RFC6113] or some other tunneling and armoring mechanism is used.

In addition to delivering the session key to the subscriber, the AS also issues a ticket using a key it shares with the Ticket Granting Server (TGS). This ticket is referred to as a Ticket Granting Ticket (TGT), since the verifier uses the session key in the TGT to issue tickets rather than to explicitly authenticate the verifier. The TGS uses the session key in the TGT to encrypt a new session key for the subscriber and uses a key it shares with the RP to generate a ticket corresponding to the new session key. The subscriber decrypts the session key and uses the ticket and the new session key together to authenticate to the RP.

When Kerberos authentication is based on passwords, the protocol is known to be vulnerable to offline dictionary attacks by eavesdroppers who capture the initial user-to-KDC exchange. Longer password length and complexity provide some mitigation to this vulnerability, although sufficiently long passwords tend to be cumbersome for users. However, when Kerberos password-based authentication is used in a FAST (or similar) tunnel, a successful attacker-in-the-middle attack is additionally required in order to perform the dictionary attack.

OpenID Connect

OpenID Connect [OIDC] is an internet-scale federated identity and authentication protocol built on top of the OAuth 2.0 authorization framework and the JSON Object Signing and Encryption (JOSE) cryptographic system.

OpenID Connect builds on top of the OAuth 2.0 authorization protocol to enable the subscriber to authorize the RP to access the subscriber’s identity and authentication information. The RP in both OpenID Connect and OAuth 2.0 is known as the client.

In a successful OpenID Connect transaction, the IdP issues an ID Token, which is a signed assertion in JSON Web Token (JWT) format. The client parses the ID Token to learn about the subscriber and primary authentication event at the IdP. This token contains at minimum the following information about the subscriber and authentication event:

• iss - An HTTPS URL identifying the IdP that issued the assertion.
• sub - An IdP-specific subject identifier representing the subscriber.
• aud - An IdP-specific audience identifier, equal to the OAuth 2.0 client identifier of the client at the IdP.
• exp - The timestamp at which the ID Token expires and after which SHALL NOT be accepted the client.
• iat - The timestamp at which the ID Token was issued and before which SHALL NOT be accepted by the client.

In addition to the ID Token, the IdP also issues the client an OAuth 2.0 access token which can be used to access the UserInfo Endpoint at the IdP. This endpoint returns a JSON object representing a set of attributes about the subscriber, including but not limited to their name, email address, physical address, phone number, and other profile information. While the information inside the ID Token is reflective of the authentication event, the information in the UserInfo Endpoint is generally more stable and could be more general purpose. Access to different attributes from the UserInfo Endpoint is governed by the use of a specially-defined set of OAuth scopes, openid, profile, email, phone, and address. An additional scope, offline_access, is used to govern the issuance of refresh tokens, which allow the RP to access the UserInfo Endpoint when the subscriber is not present. Access to the UserInfo Endpoint is structured as an API and may be available when the subscriber is not present. Therefore, access to the UserInfo Endpoint is not sufficient for proving a subscriber’s presence and establishing an authenticated session at the RP.

References

This section is informative.

General References

[EO13985] Executive Order 13985, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government, January 25, 2021, available at: https://www.federalregister.gov/d/2021-01753.

[FEDRAMP] General Services Administration, Federal Risk and Authorization Management Program, available at: https://www.fedramp.gov/.

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

[NISTIR8112] NIST Internal Report 8112 (Draft), Attribute Metadata, available at: https://pages.nist.gov/NISTIR-8112/NISTIR-8112.html.

[Section508] Section 508 Law and Related Laws and Policies (January 30, 2017), available at: https://www.section508.gov/manage/laws-and-policies/.

Standards

[ISO/IEC9241-11] International Standards Organization, ISO/IEC 9241-11 Ergonomic of Human-System Interaction — Part 11: Usability: Definitions and Concepts. ISO, Geneva, Switzerland, 2018, available at: https://www.iso.org/standard/63500.html.

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

[OIDC-Basic] N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, C. Mortimore, OpenID Connect Basic Client Implementer’s Guide 1.0, April 18, 2022. Available at: https://openid.net/specs/openid-connect-basic-1_0.html

[OIDC-Implicit] N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, and C. Mortimore, OpenID Connect Implicit Client Implementer’s Guide 1.0, September 14, 2022. Available at: https://openid.net/specs/openid-connect-implicit-1_0.html

[RFC4120] IETF, The Kerberos Network Authentication Service (V5), RFC 4120, DOI 10.17487/RFC4120, July 2005, https://doi.org/10.17487/RFC4120.

[RFC6113] IETF, A Generalized Framework for Kerberos Pre-Authentication, RFC 6113, DOI 10.17487/RFC6113, April 2011, https://doi.org/10.17487/RFC6113.

[RFC7591] IETF, OAuth 2.0 Dynamic Client Registration Protocol, RFC 7591, DOI 10.17487/RFC7591, July 2015, https://doi.org/10.17487/RFC7591.

[RFC7636] IETF, Proof Key For Code Exchange, RFC 7636, DOI 10.17487/RFC7636, September 2015, https://doi.org/10.17487/RFC7636.

[SAML] OASIS, Security Assertion Markup Language (SAML) V2.0 Technical Overview, March 2008, available at: https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html.

[SAML-WebSSO] OASIS, Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, 15 March 2005. Available at: https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

NIST Special Publications

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

[SP800-53] NIST Special Publication 800-53 Revision 4, Recommended Security and Privacy Controls for Federal Information Systems and Organizations, April 2013 (updated January 22, 2015), https://dx.doi.org/10.6028/NIST.SP.800-53r4.

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

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

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

Federal Information Processing Standards

[FIPS140] Federal Information Processing Standard Publication 140-3, Security Requirements for Cryptographic Modules, March 22, 2019, https://doi.org/10.6028/NIST.FIPS.140-3.

Changelog

This appendix is informative. It provides an overview of the changes to SP 800-63C since its initial release.

• 公平性(equity)に関する考慮事項と要件の追加．

• フェデレーションプロセスの個別のステップとして信頼の合意(trust agreement)と登録を確立．

• すべての FAL に信頼の合意(trust agreement)の形成と登録に関する要件を設定．

• FAL の定義から暗号化要件を撤廃．暗号化は FAL に関係なく，信頼できない当事者を介してアサーションで PII を渡す際に必要となる．

• FAL2 にはインジェクション保護が必要．

• FAL3 では，従来の holder-of-key に加えて，より一般的な bound authenticator（RP 管理の authenticatorなど）が許容された．

• IAL/AAL/FALの伝達が必須．

• より包括的になるように language を更新．

• RP 加入者(subscriber)アカウントの定義と説明を追加．

• 属性プロビジョニングモデルと説明を追加．

• Added discussion of equity considerations and requirements.

• Established trust agreements and registration as discrete steps in the federation process.

• All FALs have requirements around establishment of trust agreements and registration.

• FAL definitions no longer have encryption requirements; encryption is triggered by passing PII in an assertion through an untrusted party regardless of FAL.

• FAL2 requires injection protection.

• FAL3 allows more general bound authenticators including RP-managed authenticators, in addition to classical holder-of-key.

• Communication of IAL/AAL/FAL required.

• Updated language to be more inclusive.

• Added definition and discussion of RP subscriber accounts.

• Added attribute provisioning models and discussion.