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

ABSTRACT

本ガイドライン群は, Digital Identity サービスを実装する連邦機関に対する技術的要件を提供するものであり, それ以外の条件下での標準仕様の開発・利用に対する制約を意図したものではない. 本ガイドラインは, Identity Federation の実装に際した Federated Identity および Assertion の利用にフォーカスしている. Federation は, ある Credential Service Provider が, 多数の異なる管理下にある Relying Party に対して, Authentication Attribute および (オプションで) Subscriber Attribute を提示する手段となる. 同様に, Relying Party は一つ以上の Credential Service Provider を利用可能となる. 本ドキュメントの発行をもって, 本ドキュメントは既存の NIST Special Publication (SP) 800-63C を置き換えるものとなる.

Keywords

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

翻訳者

• Nov Matake
  • OpenID Foundation Japan エバンジェリスト 兼 翻訳WGリーダー
  • MoneyForward inc.
  • YAuth.jp LLC

ABSTRACT

本ガイドライン群は, Digital Identity サービスを実装する連邦機関に対する技術的要件を提供するものであり, それ以外の条件下での標準仕様の開発・利用に対する制約を意図したものではない. 本ガイドラインは, Identity Federation の実装に際した Federated Identity および Assertion の利用にフォーカスしている. Federation は, ある Credential Service Provider が, 多数の異なる管理下にある Relying Party に対して, Authentication Attribute および (オプションで) Subscriber Attribute を提示する手段となる. 同様に, Relying Party は一つ以上の Credential Service Provider を利用可能となる. 本ドキュメントの発行をもって, 本ドキュメントは既存の 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.

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

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

1. Advance Equity: This draft seeks to expand upon the risk management content of previous revisions and specifically mandates that agencies account for impacts to individuals and communities in addition to impacts to the organization. It also elevates risks to mission delivery – including challenges to providing services to all people who are eligible for and entitled to them – within the risk management process and when implementing digital identity systems. Additionally, the guidance now mandates continuous evaluation of potential impacts across demographics, provides biometric performance requirements, and additional parameters for the responsible use of biometric-based technologies, such as those that utilize face recognition.
2. Emphasize Optionality and Choice for Consumers: In the interest of promoting and investigating additional scalable, equitable, and convenient identify verification options, including those that do and do not leverage face recognition technologies, this draft expands the list of acceptable identity proofing alternatives to provide new mechanisms to securely deliver services to individuals with differing means, motivations, and backgrounds. The revision also emphasizes the need for digital identity services to support multiple authenticator options to address diverse consumer needs and secure account recovery.
3. Deter Fraud and Advanced Threats: This draft enhances fraud prevention measures from the third revision by updating risk and threat models to account for new attacks, providing new options for phishing resistant authentication, and introducing requirements to prevent automated attacks against enrollment processes. It also opens the door to new technology such as mobile driver’s licenses and verifiable credentials.
4. Address Implementation Lessons Learned: This draft addresses areas where implementation experience has indicated that additional clarity or detail was required to effectively operationalize the guidelines. This includes re-working the federation assurance levels, providing greater detail on Trusted Referees, clarifying guidelines on identity attribute validation sources, and improving address confirmation requirements.

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

Federation and Assertions

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

General

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

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

Note to Reviewers

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

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

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

1. Advance Equity: This draft seeks to expand upon the risk management content of previous revisions and specifically mandates that agencies account for impacts to individuals and communities in addition to impacts to the organization. It also elevates risks to mission delivery – including challenges to providing services to all people who are eligible for and entitled to them – within the risk management process and when implementing digital identity systems. Additionally, the guidance now mandates continuous evaluation of potential impacts across demographics, provides biometric performance requirements, and additional parameters for the responsible use of biometric-based technologies, such as those that utilize face recognition.
2. Emphasize Optionality and Choice for Consumers: In the interest of promoting and investigating additional scalable, equitable, and convenient identify verification options, including those that do and do not leverage face recognition technologies, this draft expands the list of acceptable identity proofing alternatives to provide new mechanisms to securely deliver services to individuals with differing means, motivations, and backgrounds. The revision also emphasizes the need for digital identity services to support multiple authenticator options to address diverse consumer needs and secure account recovery.
3. Deter Fraud and Advanced Threats: This draft enhances fraud prevention measures from the third revision by updating risk and threat models to account for new attacks, providing new options for phishing resistant authentication, and introducing requirements to prevent automated attacks against enrollment processes. It also opens the door to new technology such as mobile driver’s licenses and verifiable credentials.
4. Address Implementation Lessons Learned: This draft addresses areas where implementation experience has indicated that additional clarity or detail was required to effectively operationalize the guidelines. This includes re-working the federation assurance levels, providing greater detail on Trusted Referees, clarifying guidelines on identity attribute validation sources, and improving address confirmation requirements.

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

Federation and Assertions

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

General

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

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

Purpose

This section is informative.

本ドキュメントとそれと対をなす各ドキュメント [SP800-63], [SP800-63A], and [SP800-63B] は, Digital Identity Service を実装する組織に向けた技術的ガイドラインを提供するものである.

本ドキュメント SP 800-63C は Federated Identity System における Identity Provider (IdP) および Relying Party (RP) に対する要件を定める. Federation を行うことで, IdP は個々に独立した多数の RP に対して, Federation Protocol および Assertion を介して, Authentication イベントに関する Attribute および (オプションで) Subscriber に関する Attribute を提供することができる. 同様に, RP は1つ以上の IdP を Identity の源泉として用いることも可能となる.

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.

Federation とは, Authentication イベントに関する Attribute および Subscriber に関する Attribute を Network 化されたシステム間で伝播することを可能とするプロセスである. Federation シナリオでは, CSP は Identity Provider (IdP) と呼ばれるサービスを提供する. IdP は CSP が発行する Authenticator に対する Verifier となる. IdP は Assertion と呼ばれる Authentication イベントに関するメッセージを RP に送信する. RP は IdP に提示された Assertion を受け取り自身の Authentication および Authorization の決定に用いるが, RP 自身が Authenticator を直接 Verify することはない.

Assertion は IdP から RP に対して提示される Verify 可能なステートメントであり, Subscriber に対する Authentication イベントを表現している. 一般的に Federation は RP と IdP が単一主体ではなく, 共通の主体の管理下にあるものでもない場合に用いられるが, さまざまな理由により同一セキュリティドメイン下のサービスに対して適用されることもある. RP は Assertion に含まれる情報を用いて Subscriber を識別し, RP の管理下にあるリソースへの当該 Subscriber の Access に対する Authorization 判断を下す.

Federated Identity シナリオにおいて, Subscriber は直接 RP に対して Authenticate を行うことはない. Federated Protocol が提供するメカニズムによって, IdP は Subscriber に関する Assertion を生成する. これは一般的には RP からの明示的なリクエストに応答する形で行われる. IdP は Subscriber を Authenticate する責務を担う. (ただし [SP800-63B], Sec. 7 にあるように Session Management を用いることもある) Federation プロセスによって, Subscriber は複数の RP に対してそれぞれ独立した Authenticator を管理することなく各 RP のサービスを享受することができる. このプロセスは Single Sign-on と呼ばれることもある.

Subscriber は Federated Identifier により RP に対して一意に識別される. Federated Identifier とは, IdP によって提示される Subject Identifier と, IdP 自身を一意に識別する識別子の論理的組み合わせとして表現される. この複数要素からなる識別子の表現方法により, 異なる IdP 間において各 IdP が各々の Subject Identifier を独立して管理可能となる. このような条件下では異なる Subject に対して Subject Identifier が衝突するリスクが存在するため, このような識別子表現が必要不可欠となる. RP は Subject Identifier を発行した IdP を考慮することなく Subject Identifier に対して処理を行ってはならない.

Assertion とは, Subscriber の Federated Identifier を含み, 複数の Authenticated Session にまたがって RP とインタラクションを行った Subscriber を紐づけることを可能とするものである. Assertion には Attribute Value や Derived Attribute Value が含まれることもあり, それらは Subscriber の更なる特徴を示して RP による Authorization 判断の材料となる. 追加の Attribute はより大きな Federation Protocol の一部として Assertion 外で提供されることもある. これらの Attribute Value や Derived Attribute Value はしばしば Attribute-based Access Control (ABAC) における Access 権限の決定や Transaction の促進 (e.g., 配送先住所の提供) に用いられる.

Federation は比較的複雑なマルチパーティープロトコルが必要となり, それには繊細なセキュリティおよびプライバシー要件が求められる. ある特定の Federation 構造を評価する際には, それを個々のインタラクション (Subscriber->IdP, IdP->RP, Subscriber->RP etc.) に分解するとよい. Federation Protocol における各々のパーティーは特定の責任と期待を負い, それらを満たすことで Federated System が期待通りに機能することとなる.

IdP は [SP800-63A] に定義された Subscriber Account を補強する形で Federation 特有の項目をセットにして Subscriber に関するレコードを管理する. この Federation 特有の項目には以下のようなものが含まれるがこの限りではない.

• Federation Protocol で用いられる1つ以上の External Subject Identifier
• Access 権限のセット. (Subscriber の決定などにより) どの RP が当該 Subscriber Account のどの Attribute に Access できるかを示す.
• Federated アカウントの利用情報
• IdP が Subscriber に対して収集及び付与した追加の Attribute

RP はしばしば RP Subscriber Account を管理する. これは IdP から RP に対して提示された Subscriber Account 情報から導出されたものである. RP Subscriber Account は RP 自身に閉じた情報も含む. (Sec. 5.4 参照)

本ドキュメントに記載された要件は, 本ガイドラインの他のドキュメントに述べられた要件に基づいたものである. Subscriber と IdP の間の Authentication は [SP800-63B] に記載された Authentication メカニズムに基づいて実施され, Federation Protocol によって RP に伝達される Attribute そのものは (その他の Attribute と共に) [SP800-63A] に記載された手続きを用いて IdP によって確立される.

本ドキュメンントの各セクションのいずれが normative でありいずれが 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

Introduction

This section is informative.

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.

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.

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.

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.

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

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.

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

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.

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

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

用語定義および略語については [SP800-63], Appendix A を参照のこと.

Definitions and Abbreviations

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

Federation Assurance Level (FAL)

This section is normative.

本セクションでは, Federation Assurance Level (FAL) を規定する. FAL は Federation Transaction に関するセキュリティ要件を定める. これには IdP と RP の関係確立方法や Assertion の提示・保護方法に関する要件を含む. このレベルは RP がランタイム毎に要求することもあり, RP と IdP が所与の Transaction に対して事前に設定することもある. FAL は, RP が Assertion を受け取る際の確度を示すとともに, IdP が RP に利用される Assertion を生成する際の確度を示す.

Federation 実装時の選択肢は幅広いが, FAL はよりセキュアなデプロイメントに関する明示的なガイダンスを提供することを意図している. 最適な FAL の選択方法についての詳細は [SP800-63] を参照のこと.

FAL は, レベルが上がるごとにセキュリティと複雑性が増すという特徴を持つ, 一連の要件の集合として表現される. これらの要件については, 本セクションでリスト化したのち, 本ドキュメント各セクションで詳細化する.

Cryptographic Verifiability

Federation Protocol において提示された Assertion が, それを発行した特定の IdP を追跡可能であり, その関係性を Digital Signature や MAC などの暗号論的メカニズムにより検証可能であること. また RP によって当該 Assertion が改変されたり偽造されていないことを検証できること. これは全ての FAL において求められる要件である.

Audience Restriction

Federation Protocol において提示された Assertion が, 特定の RP に向けたものであり, 当該 RP が当該 Assertion の Audience を検証可能であること. これは全ての FAL において求められる要件である.

Injection Protection

Attacker が当該 Federation Transaction リクエスト外で得た Assertion を提示してくるような Attack に対して, RP が強固な保護策を持つこと.

Trust Agreement

IdP と RP が, 双方ともに, 当該 Subscriber を当該 RP にログインさせるために当該 Federation Transaction に参加することに合意すること. これは両パーティー間の事前の静的な合意によることもあるし, 当該接続を持って暗黙的に合意したとみなされることもある.

Registration

IdP と RP が相互に自身の識別子とキーマテリアルを交換し, それ以降の Federation Transaction 内で Assertion や Artifact の Verification に用いることができるようにすること.

Presentation

Assertion がそれ単体で RP に (Bearer Assertion として) 提示されたり, Subscriber が提示する Authenticator と紐づけた形で提示されたりすること.

Table 1 は各 FAL を要約したものである (non-normative). 各レベルは, それ以下のレベルの全要件を内包および満たす. (e.g., FAL3 は下位レベルの要件をすべて満たしているため, FAL3 を満たしていれば, FAL2 や FAL1 の全ての要件を満たしている.) Table 1 に存在しない組み合わせも可能であるが, そういった組み合わせに関しては本ドキュメントのスコープ外とする.

Table 1 Federation Assertion Levels

いかなる FAL においても, 全ての Assertion は Sec. 5 にあるように Federation Protocol とともに利用せねばならない (SHALL). 全ての Assertion は Sec. 6 に述べる要件を満たさねばならない (SHALL). 全ての Assertion は Sec. 7 に述べるいずれかの方法で提示されなければならない (SHALL). Federation Protocol で利用される Assertion の例としては, OpenID Connect [OIDC] における ID Token や Security Assertion Markup Language [SAML] に従って記述された Assertion などが挙げられる.

いかなる FAL においても, IdP は, [SP800-53] や同等の連邦標準 (e.g., [FEDRAMP]) および業界標準において定義された中程度ないしは高度なベースラインを構成するセキュリティコントロールの中から, 適切に調整されたセキュリティコントロールを採用しなければならない (SHALL).

Federation Assurance Level 1 (FAL1)

FAL1 では, IdP が生成する Assertion は Sec. 6 のコアとなる要件を満たさねばならない (SHALL). これらの要件には, IdP が Approved Cryptography を用いて Assertion の内容に署名を施すことによる, Attacker からの Assertion 改変および偽造に対する保護策が含まれる. RP は, Sec. 6 にあるように, Assertion を受け取った際はその起源や Integrity (完全性) を検証し, それが期待した出所を起源としたものであることを保証せねばならない (SHALL).

FAL1 における Assertion は全て, 特定の RP (群) に対する Audience Restriction が施されなければならず (SHALL), RP が当該 Assertion の Audience に自身が含まれていることを確認せねばならない (SHALL). IdP は, Approved Cryptography による署名及び鍵を用いて当該 Assertion を保護し, 当該 RP を含む全ての Assertion 所有者が IdP になりすますことができないようにせねばならない (SHALL). Assertion が Asymmetric Key を用いた Digital Signature により保護されている場合は, IdP は同じ Public & Private Key ペアを用いて複数の RP に向けて Assertion に署名を行っても良い (MAY). IdP は, HTTPS で保護された well-known location を用いるなど, 検証可能な形で自身の Public Key を公開してもよい (MAY). Assertion が Shared Secret を用いた鍵付き Message Authentication Code (MAC) により保護されている場合は, IdP は RP 毎に異なる Shared Secret を用いなければならない (SHALL).

FAL1 では IdP-RP 間の Trust Agreement は完全に Dynamic に確立しうる (MAY). 例えば, Subscriber が RP に対して動的に IdP を選択・指定し, RP は IdP のパラメータを Discovery により取得し自身を IdP に登録することも可能である. IdP は Subscriber に対してどの Attributre を何の目的で RP に提示するかを選択させる. こういった例では, IdP-RP 間の信頼関係は完全に Subscriber の要求および行動により主導される. なお FAL1 でも Static な Trust Agreement および Registration が可能であることは留意.

既存の Federation Protocol では, FAL1 は OpenID Connect Implicit Client プロファイル [OIDC-Implicit], OpenID Connect Hybrid Client プロファイル [OIDC], 追加機能なしの SAML Web SSO プロファイル [SAML-WebSSO] などにより実装可能である. これらのプロファイルでは, Assertion は IdP により署名され, RP は署名された Assertion の内容により指定される.

Federation Assurance Level 2 (FAL2)

FAL1 に対する要件は, ここでより明確ないし厳密にオーバーライトされない限り全て FAL2 でも求められる.

FAL2 では Assertion は Attacker による Injection Attack から強固に保護される必要がある (SHALL). この要件を満たすためには, Assertion は Sec. 7.1 にあるように, OpenID Connect Basic Client プロファイル [OIDC-Basic] などを用いて, Back-Channel で提示されるべきである (SHOULD). この提示方法では, RP はワンタイムな Assertion Reference を用いて IdP から直接 Assertion を取得する. 従って Attacker は外部アクセスポイントを通じて Assertion を Inject することはできない. Sec. 7.2 のような Front-Channel による提示では, RP は追加の Injection Protection を実装しなければならない (SHALL).

Assertion の提示方法の如何を問わず, Injection Attack は Federation Transaction を常に IdP からではなく RP から開始することで防ぐこともできる. これにより, RP は取得される Assertion をある Session 内において Subscriber が開始した特定のリクエストと紐づけることができる.

FAL2 では, IdP-RP 間の Trust Agreement は Static に確立されなければならない (SHALL). これには RP に提示可能な Attribute 及びその利用目的の制限の確立も含む. Trust Agreement は IdP-RP の二者間 (Bilateral) で確立することもできるし (MAY), 多者間 (Multilateral) での Federation パートナーシップを介して確立することもできる (MAY). RPと IdP が実行時に確立済の Trust Agreement を証明可能であれば, Registration は Dynamic でもよい (MAY). そのような証明方法は Federation Protocol により多様であるが, Software Attestation の提示や Trusted Domain 上の URL の管理権限を証明することなどが例として挙げられる.

政府が運営する IdP のうち FAL2 での Authentication を提供する IdP は, Assertion の署名及び暗号化に用いる鍵を [FIPS140] Level 1 およびそれ以上の手法により保護しなければならない (SHALL).

Federation Assurance Level 3 (FAL3)

FAL1 および FAL2 に対する要件は, ここでより明確ないし厳密にオーバーライトされない限り全て FAL3 でも求められる.

FAL3 では Subscriber は Assertion に加えて Authenticator を Direct に RP に提示することで Authenticate せねばならない (SHALL). ここで用いられる Authenticator は Bound Authenticator とも呼ばれ, Sec. 6.1.2 に後述される. 例えば Subscriber が IdP と RP の間で Federation によるログインプロセスを実施する場合, RP は Subscriber に RP Subscriber Account に紐づく Bound Authenticator の提示を促す. FAL3 で提示される Bound Authenticator は Subscriber が IdP に Authenticate する際に用いられる Authenticator と同一である必要はない. Assertion は RP が Subscriber を識別する際に用いられるが, その際に Bound Authenticator はログインしようとしている当事者が Assertion により識別される Subscriber であるという高い確度を与える. なお, Subscriber が Bound Authenticator を用いて Authenticate し, RP が当該 Authenticator が正しく当該 Assertion が示す RP Subscriber Account に紐づいていることを検証するまで, FAL3 が達成されることはない.

FAL3 では, IdP-RP 間の Trust Agreement および Registration は Static に確立されなければならない (SHALL). 全当事者にとって, 識別に用いられるキーマテリアルおよび Federation パラメータ (RP に送信される Attribute リストを含む) は, Federation による Authentication プロセス実施前に固定されていなければならない (SHALL). Federation による Authentication プロセスの中で送信する項目をさらに制限する場合には, 動的に決定がなされてもよい (MAY). (e.g., Trust Agreement で合意されたパラメータには含まれているものの Email Address を開示したくない場合など)

FAL3 での Authentication を提供する IdP は, Assertion の署名及び暗号化に用いる鍵を [FIPS140] Level 1 およびそれ以上の手法により保護しなければならない (SHALL).

Requesting and Processing xALs

IdP は, 多様な Federation パラメータおよび Authenticator を用いて, 多数の Subscriber の Identity を主張することができる. 従って同一の RP に対しても異なる Federation ログイン毎に IAL, AAL および FAL は変わりうる.

RP は各 Federation Transaction 毎に以下の情報を知らされなければならない (SHALL).

• RP に提示される Subscriber Account の IAL. これがない場合は IAL に関する主張がないことを示唆するものとする.
• IdP における当該 Subscriber の当該アクティブ Session の AAL. これがない場合は AAL に関する主張がないことを示唆するものとする.
• 当該 Federation Transaction の FAL.

RP は上記 xAL 情報を Sec. 5.1 に述べる Trust Agreement のパラメータおよび Sec. 6 に述べる Assertion に含まれる情報の組み合わせにより取得する. IdP-RP 間の全メッセージで xAL が不変な場合は, xAL 情報は IdP-RP 間の Trust Agreement のパラメータに含まれることとする (SHALL). xAL が可変の場合は, Sec. 6 に述べる Assertion の一部として xAL 情報を含むものとする (SHALL).

IdP は所与の Federation Transaction に対していかなる IAL ないし AAL に関する主張もないことを示唆しても良い (MAY). この場合, 当該 Transaction の結果としての xAL には何のデフォルト値も割り当てられることはない. つまり, Trust Agreement にも Assertion にも IAL に関する宣言のない Federation Transaction は “IAL を持たない” ものとし, RP は当該アカウントが本ガイドライン群に規定する最低の IAL である “IAL1” を満たすものと仮定してはならない.

RP は, 提供する機能に対する Access を受け入れるための最低限の IAL, AAL および FAL を規定しなければならない (SHALL). RP は, 特定の Federated Authentication における IAL, AAL および FAL に基づいて, 提供する機能を変更しても良い (MAY). 例えば, AAL2 でのログインでは共通機能 (e.g., ダムシステムのステータス閲覧) へのアクセスのみとし, AAL3 ではよりハイリスクな機能 (e.g., ダムシステムの流量変更) へのアクセスを許可するなどが考えられる. 同様に, RP は, IAL の如何を問わず全 Subscriber Account によるログインを許可しつつも, 管理機能を IAL2 による Identity Proofing を経た特定の Subscriber Account のみに制限する, といったことも可能である.

Federation プロセスにおいては, IdP のみが Subscriber Account に対して適切な IAL を決定するための詳細情報への直接の Access を持つ. また適切な AAL を決定するための IdP における Authentication イベントに関しても同様である. 従って, RP は所与の Federation Transaction における IdP による IAL および AAL の宣言を, それらのレベルの単一の情報源としなければならない (SHALL).

RP は Federation Transaction が Assertion に示される FAL 要件を満たすことを保証しなければならない (SHALL). 例えば, RP は Presentation 方法が FAL2 以上で求められる Injection Protection を満たし, FAL3 を満たす適切な Bound Authenticator が提示されたことを保証する必要がある, といったことが考えられる.

IdP は RP が Trust Agreement において許容可能な最低限の xAL を指定する仕組みをサポートせねばならず (SHALL), Federation Transaction においてより厳格な最低限の xAL を指定する仕組みもサポートすべきである (SHOULD). RP が特定の xAL をリクエストした場合, IdP はそのリクエストを満たすべきであり (SHOULD), 可能であれば Assertion においてその結果の xAL を示すものとする (SHALL). 例えば, Subscriber が AAL1 で Authenticate されたアクティブな Session を持つ一方で RP が AAL2 を要求している場合, IdP は可能であれば Subscriber に AAL2 での Authentication を促し, IdP とのインタラクションを通じて当該 Session のセキュリティを高める必要がある. IdP は, 結果として得られた AAL を, 返却する Assertion に含める. これは AAL1 (元の Session の AAL) ないし AAL2 (より強固な Authentication で得られた AAL) となるであろう.

Federation Assurance Level (FAL)

This section is normative.

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.

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.

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:

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.

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.

Injection Protection

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

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.

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.

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.

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

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

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)

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.

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.

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.

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)

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

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.

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.

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.

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)

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

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.

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

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

Requesting and Processing xALs

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.

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

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.

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.

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.

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.

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.

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.

Federation Protocol においては, Figure 1 に示されるように, Subscriber, IdP および RP の三者間の関係性が形成される.

Figure 1. Federation Overview

IdP-RP 間の Federation の関係性は多段階のプロセスにより確立される.

1. まず, IdP と RP が Trust Agreement の締結に合意する. これは二者間合意でも良いし, オーソリティの要請による多者間合意や信頼できる当事者を通じた委任によるものでもよい. このステップは2つのシステムが接続するための最初の許可となる. リクエストおよび開示できるパラメータはこのステップで確立される. どの Attribute が所与の RP および Subscriber について開示されるかの詳細についての決定は, 以降のステージに遅延されることもある.

2. 次に, IdP と RP はプロトコルレベルで信頼関係を確立するため Registration を行う. これにより当事者間で情報がセキュアに交換可能となる. 最初のステップでは接続許可を示すポリシー決定が行われるが, このステップでは IdP と RP を示す Credential および識別子の確立が行われる. これにより Federation Protocol を通じてコミュニケーションが可能となる. このステージは Subscriber が RP にログインしようとする前に実施することもあるし, Subscriber が RP に対して IdP を利用するよう試行した結果として実施されることもある.

3. 次に, IdP と RP は Subscriber を Authenticate するため Federation Transaction を実施することを決定する. この一環として, IdP と RP は当該 Transaction において Subscriber に関するどの Attribute が IdP から RP に渡されるかを決定する. このステップにおける決定は, 最初のステップで確立された Trust Agreement と, 2つめのステップで確立された RP および IdP の Identity に基づいて行われる.

4. 最後に, Subscriber は IdP に対して Authenticate し, その Authentication イベントの結果がネットワークを介して RP に Assertion として提示される. RP は IdP から提示されたこの Assertion を処理し, Subscriber との間に Authenticated Session を確立する.

この Transaction において, IdP は [SP800-63B] に述べるように Subscriber の Authenticator の Verifier として動作する. Authentication イベントの情報は Sec. 6 に述べるように IdP から RP に Assertion を介して伝搬される. IdP は, Assertion の一部として, ないしは Authorize された Credential で保護されたセカンダリな Identity プロトコルを通じて, Subscriber の Identity Attribute についてのステートメントを生成することができる.

Trust Agreements

Authentication サービスを提供する IdP とそのサービスを利用する RP は Federation のメンバーとなる. IdP から見ると, Federation とは IdP がサービスを提供する相手である RP 群からなる. RP から見ると, Federation とは RP が利用する IdP 群からなる. 本セクションでは, 現在利用されている Identity Federation モデルの概観について述べる. 各モデルで Federation メンバー間の関係性が構築される. この関係性は後述のように二者間で確立されることもあるし多者間で確立されることもある.

Trust Agreement では, 以下のパラメータを確立することとする (SHALL).

• IdP が RP に対して開示できる Attribute のリスト
• IdP が Assertion を生成できる Subscriber Account の母集団
• RP がリクエストする Attribute のリスト (IdP が RP に対して開示できるリストのサブセット)
• RP がリクエストする各 Attribute についてその利用目的
• Subscriber Attribute の開示にかかる意思決定の責務を負う Authorized Party
• Subscriber が RP に開示される Attribute について知る手段
• IdP が提供しうる xAL
• RP が必要とする xAL

Trust Agreement は Static に確立されることもあれば Dynamic に確立されることもある. Static Trust Agreement の確立においては, 双方に期待される挙動, 権利および要件について, 法的ないしは契約に基づいた合意がなされる. Static Trust Agreement のパラメータは, 当該合意に参加する全当事者 (IdP や RP のオペレーターや影響する Subscriber を含む) に開示されなければならない (SHALL).

Dynamic Trust Agreement 確立においては, Static な場合とは裏腹に, Trust Agreement は RP と IdP が Subscriber をログインさせる目的でやり取りをする初回に暗黙的に確立される. Dynamic Trust Agreement のパラメータ表現は Federation Protocol によって定められ, 通常は Federation に参加する当事者間の契約等には紐づかない. Dynamic Trust Agreement のパラメータは, Federation Transaction 中に IdP および RP から Subscriber に開示されなければならない.

Trust Agreemeent における Authorized Party は, Subscriber Attribute の開示を含む Trust Agreement がカバーする特定の開示決定に責務を負う組織, 個人ないしはなんらかの主体である. Static Trust Agreement では Authorized Party は IdP を管理する組織でありえる (MAY). そのようなケースでは, Attribute 開示の同意は全ての Subscriber に対して決定され, Sec. 5.3.1 に述べるように Allowlist 形式で確立された上で, Subscriber の直接の意思決定や関与を必要としない. Static Trust Agreement では, Sec. 5.3.3 に述べるように, Subscriber をはじめとする個人が Attribute 開示への同意を実行時に促されるように規定することもある (MAY). Dynamic Trust Agreement は Subscriber のアクションを起点に確立されるため, Dynamic Trust Agreement における Authorized Party は常に Subscriber である. Dynamic Trust Agreement における Attribute の開示は Subscriber による実行時の決定の対象とせねばならず (SHALL), IdP の Allowlist の対象としてはならない (SHALL NOT).

例えば Static Trust Agreement は, エンタープライズサービス (RP) を Allowlist に基づき組織 (IdP) の全 Subscriber に提供するために確立されることもある. この場合 Trust Agreement の Authorized Party は組織である. Subscriber がエンタープライズサービスにログインする際は, 当該サービスに関してはなんら実行時決定は要求されない. これは Static Trust Agreement がそのように事前に確立されているからである. 別の例として, 同じ組織において別のサービスが全 Subscriber に提供されているが, 当該 Static Trust Agreement においては Subscriber が Authorized Party となっていることもある. この場合, 当該サービスへの初回ログイン時には各 Subscriber が自身の Attribute を RP に開示する旨の同意を促される. また別の例としては, Subscriber が IdP にとって未知な RP にアクセスした時点で Dynamic Trust Agreement が暗黙的に確立されることもある. この場合, RP は IdP に対して当該 RP が要求する全 Attribute の利用について Subscriber に通知し, IdP はそれらの Attribute の開示について Subscriber に同意を促す.

Trust Agreement の確立は全ての Federation Transaction において必要となる. IdP と RP が同一セキュリティドメインにあったり同じ法的所有権のもとにあってもそれは同様である. そのような場合においては, Trust Agreement の確立は内部プロセスにより迅速に完了できるであろう.

単一の Federation Transaction の間, IdP と RP のポリシーおよび期待値が Transaction 参加者全員に対して明白であることが重要である. 従って, ある Transaction に対しては単一セットの Trust Agreement のみが有効とされるべきである (SHOULD). これは通常単一の IdP および RP のペア毎に決定される. しかしながら, Trust Agreement の有り様は多様であり, 単一の IdP および RP のペアが異なる Subscriber の集団毎に対して異なる Agreement を持つこともありえる.

2当事者間の Trust Agreement が存在したからといって, 当該 Agreement の各当事者が他の当事者と別の Agreement を持つことは排除されない. つまり, IdP は同時に複数の RP に対してそれぞれ独立した Agreement を持つことができる (また, 一般的にはそうなっている). また RP も同様に, 同時に複数の RP に対してそれぞれ独立した Agreement を持つことができる.

Bilateral Trust Agreements

二者間 (Bilateral) Trust Agreement においては, 組み合わせうる各 IdP-RP ペアが相互に信頼関係を構築する. このモデルでは, IdP と RP がそれぞれ自ら Authority となり, 相手を Federation において役割を担えるものとして認める.

IdP は自信がサポートする IAL, AAL および FAL を RP に開示せねばならない (SHALL). IdP はアプリケーションのニーズに応じて RP に自身の機能のサブセットを開示してもよい (MAY). 例えば, 低リスクな RP にのみアカウントが IAL1 以上で確認されていることを開示するなど.

RP は自信が必要とする Attribute をその利用目的を含めて IdP に開示せねばならない (SHALL). RP は必要とする IAL, AAL および FAL を IdP に伝えねばならない (SHALL). これにはいかなる IAL や AAL も必要としないということも含まれる.

IdP は RP が明示的にリクエストした Attribute のみを伝達すること (SHALL). RP はリクエストした Attribute を Privacy Risk Assessment の対象とすること (SHALL).

Multilateral Trust Agreements

多者間 (Multilateral) Trust Agreement においては, Federation 当事者は Federation の信頼に関する決定を支援し当事者間での関係確立を行うため, Federation Authority に従う. このモデルでは, Federation Authority は Federation Agreement に参加する IdP および RP を管理する. Federation Authority は Federation に参加する各当事者に対して何らかの審査を行い, Trust Agreement を定義する事前に決定された標準に準拠しているか検証する. 審査のレベルは Federation のユースケースやそこで採用されるモデル毎に異なる. Figure 2 の左サイドはこの審査を表現している.

Federation Authority は IdP が所定の IAL, AAL および FAL で動作することを承認する. この情報は, RP がどの IdP であれば自身の要件を満たすかを決定するために用いられる. Figure 2 の右サイドがこれを表現している.

Federation Authority は, 自身が有効にする Federation 関係に対して, 期待される許容可能な IAL, AAL および FAL に関するパラメータを確立しなければならない (SHALL). Federation Authority は Federation 参加者を個々に審査し, 彼らが期待される標準を遵守しているかどうか判断せねばならない (SHALL).

Figure 2. Federation Authority

IdP と RP の審査結果は最低限以下のようなものとなる (SHALL).

• IdP が生成する Assertion は Sec. 6 の要件に従っている.
• RP は Subscriber Attribute の保持, 集約および第三者への開示といった取り扱いに関する要件に従っている.
• RP と IdP のシステムは許可された Federation Protocol のプロファイルを利用している.

Federation Authority はメンバー間の技術的な接続および設定プロセスを支援してもよい (MAY). IdP に対する設定データの発行や, RP に対する Software Statement の発行などが例として挙げられる.

Authority を介して管理されるほとんどの Federation は単純なメンバーシップモデルで構成され, 当事者は Federation に参加しているかいないかのどちらかである. より高度な Federation では, 複数のメンバーシップ層が存在することもあり (MAY), Federation 当事者はその情報を用いて Federation 内の他当事者がより徹底した審査を通過しているか判断する. IdP は特定の Subscriber Attribute をより高い層の RP にのみ開示するといった決定をすることもあり (MAY), RP は特定の情報をより高い層の IdP からのみ受け入れるといった決定をすることもある (MAY).

Proxied Federation

Proxied Federation においては, IdP-RP 間の全ての通信は中間者を介して行われ, 2者間の直接通信は防止される. これを実現するにはいくつかの方法がある. 一般的な構成には以下のようものが含まれる.

• Federation Proxy (Broker とも呼ばれる) として動作する第三者
• 通信を振り分けエンドポイント間で Proxy として機能するノードからなるネットワーク

Proxy を利用する場合, 当該 Proxy はある一方には IdP, またある一方には RP として動作する. 従って IdP と RP に適用される全 normative 要件が対応する役割を担う各 Proxy に適用されねばならない (SHALL).

Figure 3. Federation Proxy

Proxyed Federation モデルにはいくつかの利点がある. Federation Proxy は, インテグレーション用の共通インタフェースを提供することで, RP と IdP の間の技術的なインテグレーションを単純化することができる. さらに, Proxy が効果的に RP と IdP を相互にブラインドすることで, 自身の Subscriber リストを相互に保護したい組織に対してある種のビジネス上の Confidentiality (機密性) をもたらす. Proxy は Sec. 5.5 で後述するプライバシーリスクを低減することもできる.

ブラインドテクニックおよびその利用・限界に関する詳細情報は Sec. 9.5 を参照のこと.

Proxy を介した Federation は, Proxy Transaction 内の最低の FAL とみなすものとする (SHALL). 例えば, Proxy が IdP から FAL2 で Assertion を受け取り, それを RP には FAL1 の Assertion に変換して提示する場合, 全体の Transaction は FAL1 となる. 同様に, ある Federation において Assertion が FAL1 で発行され, それが RP には FAL3 の Assertion に変換して提示される場合, 全体の Transaction は依然として FAL1 となる. Proxy は, こういった側面を RP に伝えなければならない (SHALL). その伝達は実行時ないしは Trust Agreement の一部をなす事前設定を通じて行われる.

Registration

Federation Protocol においては, Protocol 特有の情報が IdP と RP の間で確立され, 相互にセキュア通信が可能となる必要がある. これらの情報としては, Cryptographic Key, システムの識別子, サービスエンドポイント URL, 必要な Access 権限などが挙げられる. さらに, Subscriber が目にするシステムの表示名やホームページなどの情報も, システムの信頼と Usability の向上のため確立されうる. これらの全ての情報は, Federation Protocol の範囲内で IdP と RP がデジタルかつプログラム的に信頼を確立するために用いられる.

こういった情報は, Transaction の根底にある Trust Agreement に関係なく, Federation Transaction 内で通信を行う各 IdP-RP が対となる形でやり取りされる. このプロセスは2つのフェーズからなり, 一般的には RP による IdP の Discovery と IdP における RP の Registration と呼ばれる. このプロセスは, システム管理者や開発者が情報を対象システムに入力するといった形で手動 (Manual) かつ Static に行われることもあるし, 人間の直接的関与なしにシステム自身が情報を交換する形で自動的かつ Dynamic に行われることもある.

\clearpage

Manual Registration

Manual Regisrtration モデルでは, Subscriber が関与する前に, IdP と RP のオペレータが手動で相互運用が期待される当事者に関する設定情報を Provisioning する.

Figure 4. Manual Registration

Figure 4 にあるように, Manual Registration は3つのステップからなる.

1. RP のシステム管理者が RP の Attribute を IdP のシステム管理者に共有し, IdP のシステム管理者はそれを RP に紐づける.

2. IdP のシステム管理者が IdP の Attributre を RP のシステム管理者に共有し, RP のシステム管理者はそれを IdP に紐づける.

3. IdP と RP は標準化された Federation Protocol を用いて通信する.

IdP と RP は Sec. 5.1.1 にあるように自ら Federation 相手に対する Authority となることもあれば (MAY), Sec. 5.1.2 にあるように外部の当事者を Authority とすることもある (MAY).

鍵情報の転送を必要とする Protocol では, Regisrtation プロセスにセキュアな手法を利用して Federation のために必要な鍵交換を行わねばならない (SHALL). これは Shared Secret の交換でも Public Key の交換でも同様である. ここで用いられる Symmetric Key は Federation 参加者のペアごとにユニークでなければならない (SHALL).

Federation 関係確立においては, 期待され許容可能な IAL, AAL に関するパラメータを確立しなければならない (SHALL).

Dynamic Registration

Federation の Dynamic Registration モデルでは, Transaction 実行時に Federation メンバー間の関係取り決めが行われることもある. このプロセスのおかげで, IdP と RP は Manual Registration (See Sec. 5.2.1) により手動で関係を構築することなく相互接続することも可能である. Dynamic Registration をサポートする IdP は自身の設定情報 (Dynamic Registration Endpoint 等) 可能な限りシステム管理者の関与を必要としない形で公開すること (SHALL).

Figure 5. Dynamic Registration

Figure 5 にあるように, Dynamic Registration は4つのステップからなる.

1. Discover. RP は IdP メタデータを見つけるため IdP の well-known location にアクセスする.

2. Validate. RP と IdP はお互いの正当性を確認する. これには鍵情報, メタデータ, Software Statement もしくはその他の方法がある.

3. Register RP Attribute. RP は自身の Attribute を IdP に送信し, IdP はそれを RP に紐づける.

4. Federation Protocol. IdP と RP は標準化された Federation Protocol を用いて通信する.

鍵情報の転送を必要とする Protocol では, Regisrtation プロセスにセキュアな手法を利用して Federation のために必要な鍵情報の確立を行わねばならない (SHALL). これは Shared Secret の交換でも Public Key の交換でも同様である. ここで用いられる Symmetric Key は Federation 参加者のペアごとにユニークでなければならない (SHALL).

IdP は, Sec. 6.2.5 にあるように, Dynamic Registration により登録された RP に対しては Pairwise Pseudonymous Subject Identifier を発行すべきである (SHOULD).

可能な限り, Dynamic Registration は Trust Agreement を基とする Software Statement により増強されるべきである (SHOULD). Software Statement とは RP ソフトウェアについて記述する Attribute のリストであり, Authority (IdP 自身, Sec. 5.1.2 で述べた Federation Authority ないしはその他の信頼できる当事者) により暗号論的に署名される. Software Statement により, Federation の当事者は暗号論的に Dynamic Registration を行う RP の Attribute を検証でき, 事前に全ての当該 RP の識別情報を入手しておく必要はなくなる. この暗号論的に検証可能な Statement により, Federation 当事者間の関係確立および構築において, 自己主張による Attribute にのみ依存せざるを得ない状況から脱することができる. ある Protocol における Software Statement の実装に関しては (See [RFC7591] Sec. 2.3 を参照のこと.

Authentication and Attribute Disclosure

IdP と RP が Trust Agreement を結び Registration を完了させると, Subscriber Attribute を IdP から RP に伝達するために Federation Protocol が利用可能となる. Authentication を要求するか Attribute を伝達可能とするかは, Allowlist や Blocklist, 実行時決定などにより, Trust Agreement に規定された Authorized Party によって決定されるものとする (SHALL).

Subscriber Attribute は, Identity Federation Transaction や Sec. 5.5 に後述する Subscriber Account 危殆化検知機能のサポートの目的でのみ, IdP と RP の間を伝達されるものとする (SHALL). Allowlist に当事者が記載されているからといって, その他の目的で Subscriber Attribute を伝達してはならない.

RP は Trust Agreement に規定される目的のほかには Subscriber Attribute を利用してはならない (SHALL NOT).

Subscriber は, RP への Attribute 送信について通知されるものとする (SHALL). Authorized Party が組織の場合, 当該組織は Subscriber に許可された RP のリストと各 RP に送信される Attribute のセットを開示するべきである (SHALL). Authorized Party が Subscriber 自身の場合, Subscriber は Sec. 5.3.3 の通り IdP における実行時決定において, Attribute 開示前にそれを知らされるべきである (SHALL).

IdP は Subscriber の苦情や問題 (Subscriber が誤った Attribute Value に気づいた, など) の是正のための効果的なメカニズムを提供すべきである (SHALL). 是正のための Usability 上の検討事項については Sec. 10 を参照のこと.

IdP Allowlists of RPs

Static Trust Agreement において, IdP は RP の Allowlist をもうけ, そこに含まれる RP については当該 IdP から Subscriber による実行時決定無しに Authentication および Attribute を受け取ることを認可されたものとすることができる (MAY). RP を Allowlist に追加するには, IdP は RP が SP 800-63 ガイドライン群に規定される適切な規定及び要件に従うことを保証しなければならない (SHALL). IdP は Authentication 時にどの Identity Attribute が Allowlist 内の RP に開示されるかを決定せねばならない (SHALL). IdP は Sec. 9.2 に後述の通り Allowlist を Subscriber に開示せねばならない (SHALL).

IdP の Allowlist は, ドメイン名や Cryptographic Key, 利用している Federation Protocol が提供するその他の識別子などを用いて, 一意に RP を識別せねばならない (SHALL). ある識別子が示す全ての主体は, Allowlist の目的のもとで同等とみなされるべきである (SHALL). 例えば “*.example.com” といったワイルドカードドメインは “www.example.com”, “service.example.com” および “unknown.example.com” に等しくマッチする. これら3つのサイトは Allowlist を用いた開示決定において全て同じ RP として扱われる. Allowlist は予期せぬ RP のなりすましを防止するためできる限り RP を特定できるようにすべきである (SHOULD).

IdP Blocklists of RPs

IdP は RP の Blocklist をもうけ, そこに含まれる RP については当該 IdP から Authentication Assertion や Attribute を受け取ることができないようにしても良い (MAY). この場合, Subscriber が当該 RP を利用するようリクエストしたとしても拒否される. RP が IdP の Blocklist に追加された場合, IdP はいかなる状況下でもその RP を対象とした Assertion を生成してはならない (SHALL NOT).

IdP の Blocklist は, ドメイン名や Cryptographic Key, 利用している Federation Protocol が提供するその他の識別子などを用いて, 一意に RP を識別せねばならない (SHALL). ある識別子が示す全ての主体は, Blocklist の目的のもとで同等とみなされるべきである (SHALL). 例えば “*.example.com” といったワイルドカードドメインは “www.example.com”, “service.example.com” および “unknown.example.com” に等しくマッチする. これら3つのサイトは Blocklist を用いた決定において全て同じ RP として扱われる.

IdP Runtime Decisions

Trust Agreement 内の RP のうち IdP の Allowlist にも Blocklist にも記載のない RP は, デフォルトのポリシーに従い Trust Agreement により定められる Authorized Party による実行時の Authorization 決定に従うものとする (SHALL). ほとんどの場合, 実用上, Authorized Party は Subscriber 自身である. しかしながら管理者やその他の当事者が Subscriber に代わって許可を求められることもある. Dynamic Trust Agreement においては, Attribute 開示の認可には実行時決定以外利用できないことに注意.

実行時決定モードでは, Authorized Party は IdP から Authentication Assertion と特定の Attribute を Subscriber に代わって RP に開示する旨の同意を Federation Transaction 中に求められる. IdP は, Subscriber に関する Attribute が RP に送信する前に, Authorized Party に明示的な通知を行い同意を求める必要がある (SHALL). 最低限, 通知は最も効果的に通知および同意取得を行える当事者から提供されるべきである (SHOULD). これについては Sec. 9.2 に後述する. IdP は Transaction が許可された場合にどの Attribute が送信されるかを開示しなければならない (SHALL). 利用する Federation Protocol により実行時にオプショナルな Attribute の開示が可能な場合, Authorized Party には Federation Transaction 自体を終了させることなく特定の Attribute を送信するか否か決定できるオプションが与えられねばならない (SHALL).

センシティブな情報の無認可での開示リスク (ショルダーサーフィン等) を低減するため, IdP はデフォルトでは Authorized Party に開示されるセンシティブ情報をマスクすべきである (SHALL). Authorized Party が Subscriber 自身の場合, IdP は Subscriber が伝送前にその値を確認できるよう, 当該情報を一時的に閲覧可能とする仕組みを提供すべきである (SHALL). マスキングに関しては, Usability の検討事項について Sec. 10 を参照のこと.

IdP は, Authorized Party の決定を記憶し, 同じ RP に対して同じ Attribute の組み合わせを再送できるようにしてもよい (MAY). このメカニズムは IdP に管理される Subscriber Account に関連付けられる. このようなメカニズムを提供する場合, IdP は Authorized Party が将来記憶された Access を無効化できるようにすること (SHALL).

RP Allowlists of IdPs

RP は IdP の Allowlist をもうけて, そこに含まれる IdP からは Subscriber の実行時決定無しに Authentication や Attribute を受け入れてもよい (MAY). IdP を Allowlist に追加する場合, RP は IdP が本ガイドラインの規定及び要件に従うことを保証しなければならない (SHALL).

RP の Allowlist は, ドメイン名や Cryptographic Key, 利用している Federation Protocol が提供するその他の識別子などを用いて, 一意に IdP を識別せねばならない (SHALL).

RP Blocklists of IdPs

RP は IdP の Blocklist をもうけて, そこに含まれる IdP からは Subscriber の要求があったとしても Authentication や Attribute を受け入れないようにしてもよい (MAY). Blocklist に追加された IdP は, Blocklist がない限り RP との間に有効な Trust Agreement を持つ可能性もある. 例えば両者が同じ Federation Authority のもとにある場合などが考えられる.

RP の Blocklist は, ドメイン名や Cryptographic Key, 利用している Federation Protocol が提供するその他の識別子などを用いて, 一意に IdP を識別せねばならない (SHALL).

RP Runtime Decisions

RP と Trust Agreement を結びながら, Allowlist や Blocklist に記載されていないすべての IdP は, デフォルトのポリシーに従い, Trust Agreement により定められる Authorized Party による実行時の Authorization 決定に従うものとする (SHALL). このモードでは, Authorized Party は RP から Subscriber に代わって Authentication に利用する IdP を選択/入力するよう促される. このプロセスは, Subscriber が Email アドレスなどの人が目にする識別子を入力できるような Discovery メカニズムを採用することにより, より使いやすくすることができる. このプロセスにより, RP は識別子が示す適切な IdP をプログラム的に選択できるようになる.

RP は利用する IdP に関する Authorized Party の決定を記憶する仕組みを採用してもよい (MAY). このメカニズムは RP における Authentication の前に用いられるため, RP がこのメカニズムを提供する方法 (Authenticated Session 外のブラウザクッキー等) は Sec. 5.4 に述べる RP Subscriber Account とは紐づかない. このようなメカニズムを提供する場合, RP は Authorized Party が将来記憶されたオプションを無効化できるようにすること (SHALL).

RP Subscriber Accounts

RP が Subscriber レコードを RP 自身のローカルに保存するのは一般的なことで, これは RP Subscriber Account と呼ばれる. RP Subscriber Account には, RP において Subscriber が持つ Access 権限や, Subscriber の Identity Attribute のキャッシュなどが含まれる. アクティブな RP Subscriber Account は, RP が信頼する IdP の1つ以上の Federated Identifier と紐づいている. Federation Protocol を通じてそれらの Federated Identifier のいずれかの Authentication が成功すると, Subscriber は RP Subscriber Account により保護されている情報や機能への Access を得る.

RP Subscriber Account は RP が Subscriber に関する Attribute のセットを RP における Subscriber Account を示すレコードに関連づけることで Provisioning される. RP Subscriber Account は最低限一つの Federated Identifier に紐づけられるものとし (SHALL), 当該 Federated Identifier は当該 RP において唯一の RP Subscriber Accout に紐づけられるものとする. Provisioning は Authentication の前に実行されることもあれば, Federated Authentication プロセスの結果として実行されることもある. どのような Provisioning が行われるかは, Sec. 5.4.1 に述べるように実装パターンに依存する. Provisioning が実行されるまでは, RP Subscriber Account は存在せず RP のいかなるデータレコードとも関連づけられていない.

RP Subscriber Account は RP が RP における当該アカウントの全ての Access を削除した際に Terminate される. Termination は Federated Identifier や紐づけられた Authennticator の紐付け解除を含み, 監査やセキュリティ目的で必要とされない限り当該 Account に紐づく Attribute および情報の削除も含むものとする (SHALL). RP は, さまざまな理由により, IdP とは独立して RP Subscriber Account を Terminate することができる (MAY). これは Subscriber Account がその源泉において現在も正当であったとしても関係がない.

Authenticated Session は, RP が RP Subscriber Account に関連づけられた Federated Identifier の発行元である IdP からの有効な Assertion を処理・検証して初めて生成されるものとする (SHALL). Assertion が Bound Authenticator の提示を要求するものの場合, Sec. 6.1.2 にあるように, RP Subscriber Account が Authenticated Session に関連づけられる前に当該 Bound Authenticator が提示・処理されねばならない (SHALL). Federated Assertion が処理される前, かつ Authenticated Session が終了した後は, RP Subscriber Account は Unauthenticated となる. ただし RP Subscriber Account は以前として Provisioning されうる.

Provisioning Models

RP Subscriber Account の Provisioning プロセスのライフサイクルは Sec. 5.1 の Trust Agreement や IdP & RP の実装パターンなどの要因により多様である. しかしながら, いかなるケースにおいても, RP Subscriber Account は Authenticated Session の確立前に以下のいずれかの方法により RP に Provisioning されていなければならない (SHALL).

Just-In-Time Provisioning

RP Subscriber Account は RP が IdP から未知の Federated Identifier を含む Assertion を初めて受け取った際に自動的に生成される. Assertion に含まるか Sec. 6.3 で述べる Identity API から取得するかのいずれかの方法で Federation Process 中に得られた Identity Attribute は, すべて RP Subscriber に関連づけることができる (MAY). この方法で Provisioning された Account は, Provisioning に用いられた Assertion に含まれる Federated Identifier に紐づけられる. これは Federation システムにおいて最も一般的な形であり, RP と IdP の間の協調動作が最も少なくて済む. しかしながらこのようなシステムでは RP は自身が持ちうる全ての Attribute のキャッシュ管理に責任を持たねばならない (SHALL).

Figure 6. Just-In-Time Provisioning

\clearpage

Pre-provisioning

RP Subscriber Account は IdP が Attribute を RP に Push するか RP が IdP から Attribute を Pull ことで生成される. Account の Pre-provisioning は, Sec. 5.4.3 にあるように一般的に Provisioning API を介して Bulk で行われる. これは Provisioning が Federated Transaction を通じて Subscriber を Authenticate する前に発生するからである. Pre-provisioning された Account は Provisioning 時に Federated Identifier と紐づけられるものとする (SHALL). これにより, RP が特定の Federated Identifier を受け取ると, その結果として関連づけられた Account がログインできるようになる. この形態の Provisioning は, IdP と RP にインフラストラクチャと計画を必要とするが, このプロセス自体は自動化されたプロトコルにより実現可能である. RP は RP システムとインタラクションを行ったことのないユーザーの Attribute を収集するため, プライバシー上の問題も発生しうる. さらに Sec. 5.4.2 で述べるように, IdP と RP は Provisioning された Account の集合を長期にわたって同期しなければならない.

Figure 7. Pre-Provisioning

\clearpage

Ephemeral

RP Subscriber Account は Assertion を処理する際に生成されるが, Authenticated Session が終了する際に Terminate される. このプロセスは Just-in-time Provisioning と似ているが, RP は Session が終了したらそれ以上 Account のレコードを保持しない. ただし監査やセキュリティ目的で必要とされる場合は別である (アクセスログ等). この形態の Provisioning は IdP に Access 権限を完全に外部依存する RP にとっては使いやすい. RP は内部的なステート管理を低減させ, よりシンプルになる. しかしながらこのパターンは一般的ではない. 最もシンプルな RP ですら, アプリケーション内でのステート追跡は必要としがちであり, 少なくとも Federated Identifier に関連したアクションのレコードは保持するからである.

Figure 8. Ephemeral Provisioning

Other

その他の RP Subscriber Account Provisioning モデルも可能であるが, その詳細は本ガイドライン群のスコープ外とする. いかなる代替の Provisioning モデルにおいても, IdP および RP において Privacy Risk Assessment を行うことが必要となる (SHALL).

全組織は自身の Provisioning モデルを Trust Agreement の一部としてドキュメント化するべきである (SHALL).

Attribute Synchronization

Federation プロセスにおいて, IdP と RP は各々 Subscriber Account に関連づけられた Identity Attribute を保持する. IdP は Subscriber Account を直接閲覧できるのに対し, RP Subscriber Account は Federation Transaction 時に提示された Subscriber Account の Attribute のサブセットから導出される. したがって時間の経過に伴い IdP と RP がそれぞれ保持する Attribute が乖離する可能性がある.

RP から見ると, IdP は IdP が当該 IdP において Subscriber Account と関連づけられていると主張する全ての Attribute の Authoritative Source である. しかしながら, RP は追加で RP Subscriber Accout に関連づけられるその他の Attribute を収集, および時には検証することもできる (MAY). ときにはこれらの Attribute は IdP が主張したものを上書くことすらありえる. 例えば IdP が Subscriber の完全なる Display Name を主張したとして, RP が Subscriber に RP において代替となる好きな名前を指定できるようにすることなどが考えられる.

IdP は RP に提供した Subscriber Account の Attribute に更新があった場合, RP にシグナルを送るべきである (SHOULD). これは, Sec. 5.7 の Shared Signaling や Sec. 5.4.3 の Provisioning API を利用したり, Assertion にシグナルを含めて提供する (関連する Attribute の最終更新日時を含めたり, RP に自身のキャッシュが期限切れだと判断する手段を提供したり) などの方法で実現可能である.

IdP は Subscriber Account が Terminate されたり Subscriber Account が持つ RP への Access が無効化された場合, RP にシグナルを送るべきである (SHOULD). これは, Sec. 5.7 の Shared Signaling や Sec. 5.4.3 の Provisioning API などの方法で実現可能である. このシグナルを受け取った場合, RP は RP Subscriber Account を Terminate させ, RP Subscriber Account に関連する全ての personal information を削除せねばならない (SHALL). ただし監査やセキュリティ目的で必要とされる場合を除く.

Provisioning APIs

プロアクティブな Provisioning の一環として, RP は Provisioning API と呼ばれる汎用 Attribute API を介して Subscriber Attribute への Access を与えられることもある. この種の API により, IdP は一定範囲の Subscriber Account の Attribute を Push できるようになり, ときには RP がこれら Subscriber Account の Attribute に直接クエリできるようにもなる. この API への Access は Federation Transaction のコンテキスト外で許可されるため, Provisioning API を介して Subscriber に Access できるからといって Subscriber が Authenticate されたとは言えない. Federated Authentication プロセスが Assertion を用いてどのように実現されるかは Sec. 6, Assertions を参照のこと.

Provisioning API によって RP に提供される Attribute は, RP がその機能の実現に必要なものに限定されなければならない (SHALL). Trust Agreement 確立の一環として, IdP は RP がいつ Provisioning API への Access を与えらえるかドキュメント化せねばならない (SHALL). これには最低限以下のような項目を含む.

• その Provisioning モデルを利用した Access の目的
• RP に開示される Attribute セット
• API が RP への Push を行うのか, RP からの Pull によるのか, 両方なのか
• RP に Attribute が開示される Subscriber の母集団

IdP は Pull ベースの Provisioning API への Access 全てについて RP に Authentication を要求せねばならない (SHALL). RP は Push ベースの Provisioning API への Access 全てについて IdP に Authentication を要求せねばならない (SHALL).

Dynamic ないし Implicit な Trust Agreement のもとでは Provisioning API は利用してはならない (SHALL NOT). IdP は Trust Agreement を確立していない RP に Provisioning API を提供してはならない (SHALL NOT). IdP は RP との Federated Identity 関係の一環でのみ Provisioning API への Access を提供し, 当該 RP との Federated Transaction や Subscriber Account 無効化の Signaling を含む関連する機能に役立てるものとする (SHALL). IdP は RP がもはやその機能を実現するのに必要としなくなった場合や Trust Agreement が Terminate した場合は, RP の Provisioning API への Access を無効化せねばならない (SHALL).

RP に提供される全ての Provisioning API は IdP の制御および管轄下にあるものとする (SHALL). IdP はこの Provisioning API を通じて Attribute を提供するために, 外部の Attribute Provider を情報ソースとして利用することもできる (MAY). ただし IdP は参照する Attribute Provider から提供された情報の内容および正確性について責任を持つこと.

Provisioning API を利用する場合, IdP は Subscriber Account が Terminate された時点で RP にシグナルを送らねばならない (SHALL). そのようなシグナルを受け取った際, RP は関連する RP Subscriber Account を Terminate せねばならない (SHALL).

Attribute Collection

RP は IdP から提供されたものの他に Subscriber から追加の Attribute を収集し管理してもよい (MAY). これらの Attribute は RP が直接収集したものであるため, いかなる Federation Agreement の支配も受けない. RP Subscriber Account に関連した全ての Attribute は, そのソースにかかわらず, RP Subscriber Account が Terminate された時点で削除されねばならない (SHALL).

RP はいかなる追加の Attribute に関しても収集の目的を Subscriber に開示しなければならない (SHALL). これらの Attribute は RP がその機能を達成する目的にのみ用いるものとし (SHALL), 第三者にその Attribute を伝えることを含むいかなる二次利用もしてはならない (SHALL NOT).

RP は収集した全ての追加の Attribute およびその利用を System of Records Notice (SORN) の一部として開示すること (SHALL). RP は RP Subscriber Account に対して追加収集された Attribute に関して Subscriber が更新および削除するための効果的な是正手段を提供すること (SHALL). 是正に関する Usability 上の考慮事項に関しては Sec. 10 を参照のこと.

Time-based Removal of RP Subscriber Accounts

時間が経過するにつれ, IdP からアクセスできなくなった RP Subscriber Account が蓄積されていく可能性がある. これは RP Subscriber Account に Personal Information を保持するリスクを RP にもたらす. 特に Just-in-time Provisioning モデルでは, Sec. 5.7 の Shared Signaling により IdP から Subscriber Account が Terminate されたというシグナルを送ることができない. このような条件下では, RP は時間ベースのメカニズムをもちいて一定時間アクセスのない (例えば, 最終アクセスから120日など) RP Subscriber Account を特定し Terminate させるべきである (SHOULD).

このようなインアクティブな Account を処理する際, RP は可能であれば保留中の Account の Terminate について Subscriber に十分な通知を行うこととし, スケジュールされた Terminate の前に Subscriber に Account を再アクティベートするオプションを提供することとする (SHALL). Terminate を行う際は, RP は RP Subscriber Account に関連する全ての Personal Information を削除することとする (SHALL). ただし監査やセキュリティ目的で必要とされる場合を除く.

Privacy Requirements

Subscriber の最終的な目的は RP とインタラクションしたり RP を利用することである. Federation は Transaction に関与しない 3rd party, つまり IdP, からの Personal Attribute の転送を伴う. Federation はさらに潜在的に IdP に Subscriber のアクティビティやステータスに関する広い可視性をもたらす. 従って, Federation には関連する特定のプライバシー要件がある.

RP と IdP のコミュニケーションは, IdP に Subscriber がどこと Transaction を進めようとしているかを暴露しうる. 複数の RP とのコミュニケーションを通じて, IdP は Subscriber の Transaction に関するプロファイルを生成しうる. これは Federation なしでは生成不可能であろう. このアグリゲーションは, Subscriber のトラッキングおよび Subscriber のプライバシーの利益に必ずしも一致しないプロファイル情報利用の機会をもたらす.

IdP が Subscriber の RP におけるアクティビティ情報を他社に開示したり, Subscriber Attribute を Identity Proofing, Authentication, Attribute Assertion (以上3つを総称して “Identity Service”), 関連する不正防止, 法律または法的手続きへの対応, 特定のユーザーからの要求以外の目的で処理する場合, 情報送信にあたって IdP は追加処理により生じるプライバシーリスクに見合った Predictability および Manageability を維持するための対策を施す必要がある (SHALL). この対策には, 明確な通知の提供, Subscriber からの同意取得, Attribute の選択的利用及び開示などが含まれうる (MAY). IdP が同意による対策を用いる場合, IdP は追加処理に対する同意を Identity Service の利用条件としてはならない (SHALL NOT).

同一の Subscriber Account が複数の RP に開示され, かつこれらの RP が相互にコミュニケーションを行う場合, 共謀した RP が Subscriber のアクティビティを複数のアプリケーションおよびセキュリティドメインに渡って追跡することが可能となる. IdP は Sec. 6.2.5 にある Pairwise Pseudonymous Identifier やプライバシーを向上させる暗号プロトコルなどの技術的対策を施し, Disassociability を提供して RP 間での Subscriber アクティビティのトラッキングやプロファイリングを抑止すべきである (SHOULD).

IdP は, Trust Agreement で定義されていれば, セキュリティ目的で不審なアクティビティや Sec. 5.7 にある侵害された Subscriber Account のアクティビティ情報を RP に開示してもよい (MAY). これには についての情報が含まれる. RP も同様に, Trust Agreement で定義されていれば, セキュリティ目的で不審なアクティビティや侵害された RP Subscriber Account のアクティビティ情報を IdP に開示してもよい (MAY).

IdP は, Sec. 5.7 にある Shared Signaling を用いて, Subscriber Account の Terminate シグナルを当該 Subscirber Account に紐づいた Federated Identifier の Provisioning を受けた RP に送るべきである (SHOULD). IdP からこのシグナルを受け取った RP は RP Subscriber Account を Terminate し, 当該 RP Subscriber Account に関連する全ての Personal Information を削除しなければならない (SHALL). ただし監査やセキュリティ目的で必要とされる場合を除く.

以下の要件は特に連邦機関に適用される.

1. 当該機関はそれぞれの Senior Agency Official for Privacy (SAOP) に助言を求め, IdP, RP もしくはその両方として動作する機関を起因として Privacy Act の要件が課せられることがないか判断するための分析を実施すること (SHALL). (Sec. 9.4 参照)

2. 該当する場合, 当該機関は System of Records Notice (SORN) によりその適用範囲を公開・特定すること (SHALL).

3. 当該機関はそれぞれの SAOP に助言を求め, IdP, RP もしくはその両方として動作する機関を起因として E-Government Act の要件が課せられることがないか判断するための分析を実施すること (SHALL).

4. 該当する場合, 当該機関は Privacy Impact Assessment (PIA) によりその適用範囲を公開・特定すること (SHALL).

RP Subscriber Account のライフサイクルプロセスにおいて RP が Sec. 5.4.3 で述べた Provisioning API を通じた Attribute への Access を得る場合, 広く情報アクセスの性質を考慮した追加のプライバシー対策を行うこと (SHALL). 具体的には, Subscriber の Attribute が, Subscriber が一度も RP と対話することなく, RP に提供されうる. 結果として, Provisioning API を利用する場合, IdP は RP に開示する Attribute を最小化しなければならない (SHALL). ユーザーが利用することのない RP への Attribute 転送を防止するため, IdP は Provisioning API を通じてやり取りされる Subscriber Account の母集団を Trust Agreement により当該 RP の利用を認可された Subscriber 群に制限しなければならない (SHALL).

Reauthentication and Session Requirements in Federated Environments

Federation 環境下では, RP は自身の Session を IdP の Session とは独立して管理する. Assertion は両者の Session に関係づけられるが, 根本的にその有効期間はこれらの Session とは独立している. IdP が Subscriber に関する Assertion を生成する際, Subscriber は IdP との間に Authenticated Session を確立する必要がある. RP において Authenticated Session を生成する際は, RP が IdP から有効な Assertion を受け取り処理する必要がある.

Federated System はその性質上分散しているので, IdP における Subscriber の Session と RP における Subscriber の Session は互いに独立に Terminate する. RP は Assertion 発行前に Subscriber が IdP にアクティブな Session を持っていると仮定してはならない (SHALL NOT). IdP は IdP において Subscriber の Session が Terminate したからと言って RP における Subscriber の Session にそれが伝播されると仮定してはならない (SHALL NOT). RP と RP は, Federation Protocol がそれをサポートしている場合は, Federation Network 内で相互に Session Termination リクエストをやりとりしてもよい (MAY).

Federation においてログインリクエストを送る際, Subscriber は IdP に既存の Session を持つこともあり (MAY), それを使って RP 向けの Assertion を生成することもできる (MAY). IdP は Subscriber の IdP における最終 Authentication イベント時刻に関する情報を伝えるものとし (SHALL), RP はその情報を利用して Authorization および Access の決定を行うことができる (MAY). Federation Protocol がサポートしている場合, IdP は Federation リクエストの一環として RP が IdP において Subscriber を再度 Authenticate するようリクエストできるようにすべきである (SHOULD).

Federation Protocol を通じて Authentication を要求する RP は, IdP に最大限許容できる Authentication 有効期間を指定すべきである (SHALL). これは可能であれば Federation Protocol を通じて指定してもよいし, Trust Agreement のパラメータとして指定してもよい. Authentication 有効期間は, IdP における Subscriber Session における最終 Authentication イベントからの経過時間を示し, その期間内に Authentication イベントが発生していない場合 IdP は Subscriber を Reauthenticate しなければならない (SHALL). IdP は Authentication イベント時刻を RP に伝えねばならず (SHALL), RP はそれにより Assertion が RP における Authentication に足りるかどうかを判断し, 次回の Reauthentication イベントのタイミングを決定することができる.

RP が Assertion に加えて Identity API への Access を許可されている場合, Identity API への Access の有効期間は Assertion 自体の有効期間とは独立している. Identity API への Access はしばしばその他の API への Access と統合されているため, Assertion が期限切れになった後も, そして場合によっては RP における Session が終了した後も, 長期間 Access が有効であることは一般的である. これにより RP は Subscriber がそこにいない時でも Subscriber の代理として API に Access することができる. 以上のことから, RP が Identity API を通じて追加の Attribute の取得に成功したからといって, RP において Session を確立することはできない (SHALL NOT). 同様に, Identity API に Access できないからと言って, RP の Session が終了されるべきではない (SHOULD NOT).

IdP および RP における Session Management 要件の詳細については [SP800-63B] Sec. 7 を参照のこと.

Shared Signaling

環境によっては, IdP と RP が Federation Transaction 外で情報をやりとりすることも有用である. こういったシグナルによって, それがなければお互い知り得なかった当事者間でのステート変更情報のやりとりが実現される. Shared Signaling は IdP-RP 間の Trust Agreement にドキュメント化されなければならない (SHALL). IdP から RP への Signaling には Static Trust Agreement が必要となる (SHALL). RP から IdP への Signaling には Static Trust Agreement ないしは Dynamic Trust Agreement が必要となる (MAY).

Shared Signaling はドキュメント化され Trust Agreement に規定された Authorized Party に開示されなければならない (SHALL). このドキュメントには, シグナルの送信につながるイベント, シグナルに含まれる情報 (Attribute 情報を含む), シグナルに追加のパラメータを含めること (SHALL). Shared Signaling は Trust Agreement のもとでプライバシーレビューの対象とすること (SHALL).

IdP は Subscriber Account に以下のような変更が生じた際, シグナルを送ることができる (MAY).

• Account が Terminate された.
• Account が侵害された恐れがある.
• Federated Identifier 以外の識別子 (Email Address, Certificate CN 等) をはじめとする Account の Attribute に変更が生じた.
• Account に適用されうる IAL, AAL ないしは FAL の範囲に変更が生じた.

RP は RP Subscriber Account に以下のような変更が生じた際, シグナルを送ることができる (MAY).

• Account が Terminate された.
• Account が侵害された恐れがある.
• RP が管理する Bound Authenticator が追加された.
• RP が管理する Bound Authenticator が削除された.

Trust Agreement の一環としてプライバシーレビューおよびセキュリティレビューを経ている場合は, IdP および RP どちらからも追加のシグナルを送ることができる (MAY).

Federation

This section is normative.

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

Figure 1. Federation Overview

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.

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

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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

Figure 2. Federation Authority

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

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

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

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.

Figure 3. Federation Proxy

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.

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

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

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.

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

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.

Figure 4. Manual Registration

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.

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.

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.

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

Dynamic Registration

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.

Figure 5. Dynamic Registration

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.

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.

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

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

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.

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.

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

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.

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 Allowlists of RPs

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 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 Blocklists of RPs

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 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 Runtime Decisions

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.

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.

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.

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 Allowlists of IdPs

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 allowlists SHALL uniquely identify IdPs through the means of domain names, cryptographic keys, or other identifiers applicable to the federation protocol in use.

RP Blocklists of IdPs

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 blocklists SHALL uniquely identify IdPs through the means of domain names, cryptographic keys, or other identifiers applicable to the federation protocol in use.

RP Runtime Decisions

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.

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 Accounts

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.

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.

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.

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

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:

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.

Figure 6. Just-In-Time Provisioning

\clearpage

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.

Figure 7. Pre-Provisioning

\clearpage

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.

Figure 8. Ephemeral Provisioning

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.

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

Attribute Synchronization

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.

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.

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

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.

Provisioning APIs

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.

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.

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.

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.

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.

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

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.

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.

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.

Time-based Removal of RP Subscriber Accounts

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

Authentication に用いられる Assertion は, Authentication 対象の Subscriber に関する Attribute Value ないしは Derived Attribute Value のパッケージ化されたセットであり, Federated Identity Systemにおいて IdP から RP に伝搬されるものである. Assertion Metadata, Subscriber の Attribute Value ないしは Derived Attribute Value, IdP における Subscriber の Authentication に関する情報, および RP が活用可能なその他の情報など, Assertion は多様な情報を含んでいる. Assertion の第一の機能は RP に対してユーザーを Authenticate することだが, Assertion によって伝達される情報は RP がもつ多くのユースケースにおいて利用可能である. 例としては, Authorization や Web サイトのパーソナライゼーションなどが挙げられる. 本ガイドライン群は, ここに指定する必須要件を全て満たしている限り, Identity Federation における RP のユースケースや Protocol やデータペイロードのタイプを制限しない.

Assertion は IdP における Subscriber の個別の Authentication イベントを表現するものとし (SHALL), RP はそれを個別の Authentication イベントとして処理するものとする (SHALL).

全ての Assertion には以下の Attribute を含めるものとする (SHALL).

1. Subject Identifier: Assertion が指し示す当事者 (i.e., Subscriber) の識別子
2. Issuer Identifier: Assertion 発行者 (i.e., IdP) の識別子
3. Audience Identifier: Assertion を利用することが想定された当事者 (i.e., RP) の識別子
4. Issuance Time: IdP が Assertion を発行した時刻を示すタイムスタンプ
5. Validity Time Window: その期間を超えて RP が Subscriber を Authentication する目的で Assertion を有効なものとして受け入れることのない (SHALL NOT) よう示す期間. これは通常 Assertion の有効期限タイムスタンプという形で Issuance タイムスタンプとともに伝えられる.
6. Assertion Identifier: 当該 Assertion を一意に識別する値で, 攻撃者が以前の Assertion を Replay することを防止する目的で利用される.
7. Signature: Digital Signature ないしは Message Authentication Code (MAC). IdP に紐づいた鍵の識別子や Public Key を含み, Assertion 全体をカバーするもの.
8. Authentication Time: IdP が最後に (可能であれば) 直接 Authentication イベントを通じて Subscriber の存在確認を行った時刻を示すタイムスタンプ.
9. IAL: Assertion が指し示す Subscriber Account の IAL を示す値, ないしはいかなる IAL も明言されないことを示す値.
10. AAL: IdP が Subscriber を Authenticate した際の AAL を示す値, ないしはいかなる AAL も明言されないことを示す値.
11. FAL: Assertion が指し示す Federation プロセスにおいて IdP が意図する FAL を示す値.

Sec. 6.1.2 に後述のように Assertion が FAL3 で Bound Authenticator とともに用いられる場合, Assertion は以下を含むものとする (SHALL).

1. Authenticator Binding: Public Key, 鍵の識別子, その他の Subscriber が保持する Bound Authenticator (IdP が管理するもの) の識別子, ないしは RP が管理する Bound Authenticator が Assertion 検証に要求されることを示す値.

Assertion は以下に示すような追加の項目を含んでもよい (MAY).

1. Attribute Value および Derived Attribute Value: Subscriber に関する情報.
2. Attribute Metadata: 1つ以上の Subscriber Attribute に関する追加情報. NIST Internal Report 8112 [NISTIR8112] 例示あり.

Assertion は, Authentication Event を示す場合は AAL を, Identity Proofing を経た Attribute を示す場合は IAL を指定すべきである (SHOULD).

RP は Assertion を受け取ったらそこに含まれる全てのメタデータを検証すること (SHALL).

• Issuer Verification: Assertion が RP の期待する IdP により発行されたものであることを保証すること.
• Signature Verification: Assertion の署名が有効かつ Assertion を送信した IdP の鍵によるものであることを保証すること.
• Time Validation: 現在時刻と照らし合わせて有効期限と発行日時が許容範囲に収まっていることを保証すること.
• Audience Restriction: Assertion の受け取り先として当該 RP が意図されていることを保証すること.

RP は Subject Identifier を本質的にグローバルにユニークではないものとして扱うこと (SHALL). Assertion 内の Subject Identifier は通常 Assertion 発行者の管理下にあるネームスペース内の値である. これにより, RP は異なる IdP から受け取った Subject を誤って混同することなく複数の IdP と対話可能になる.

Assertion は Subscriber のその他の Attribute を含んでもよい (MAY). Assertion に含めて Attribute を提示するためのプライバシー要件については Section 6.2.3 で述べる. RP には Assertion に加えて Sec. 6.3 で述べた Identity API への限定的 Access が与えられることもあり (MAY), RP はこの API を利用して Subscriber に関する追加の Identity Attribute を取得可能となる.

Federation Protocol によって詳細はさまざまであるが, Assertion は個々の RP へのログインイベントを表現する. Assertion の Validity Time Window は IdP ないし RP の Session 管理に関連はするが分離したものである. 特に Assertion は IdP における Authenticated Session 中に生成され, Assertion を処理することで RP における Authenticated Session が生成される. IdP が Assertion を生成した後は, IdP の Session の有効性と Assertion の有効性は独立したものとなる. IdP における Session が有効なうちに再度 IdP が Authentication 要求を受け取った場合, その結果として新たな独立した Assertion が独自の Validity Time Window のもと生成される. 同様に, RP が Assertion を消費した後は, RP の Session と Assertion の有効性は独立したものとなる. Identity API に対して付与された Access もまた, Assertion の有効性や RP の Authenticated Session の有効期間とは独立したものである. Session 管理についての詳細は Sec. 5.3 を参照のこと.

Assertion の Validity Time Window はその発行日時と有効期限の間の期間である. この値は RP が Assertion を処理して Subscriber に対して ローカルのアプリケーション Session を生成するに足りるものである必要がある一方, 必要以上に長くあるべきではない. 長期間有効な Assertion は詐取されたり Replay されるリスクを高め, Validity Time Window を短くするとそのリスクは低減される. Assertion の Validity Time Window は RP における Session を制限するために用いてはならない (SHALL NOT). 詳細は Sec. 5.3 を参照のこと.

Assertion Binding

Assertion Binding は, Claimant による Assertion の提示が Subscriber として RP に Session を保持している当事者と紐づけるに足りるかどうかや, RP が Subscriber に紐づけられた Authenticator の提示を通じた追加の証明を必要とするかどうかに基づいて分類できる.

Bearer Assertions

Bearer Assertion は, いかなる当事者であれ自身の Identity の証明として提示することが可能なものである. Bearer Assertion Reference も同様に, いかなる当事者でも RP に提示し RP に Assertion を取得させることができる. そうやって取得された Assertion も Bearer Assertion として扱われる. Attacker が Subscriber に関する有効な Assertion ないし Assertion Reference を詐取ないし偽造して成功裡に RP に提示できる場合, Attacker は RP に対して Subscriber になりすますことが可能となる.

Bearer Assertion ないしは Bearer Assertion Referende を保持するだけでは, 常に Subscriber になりすますのに十分であるとは限らないことに注意すること. 例えば, Assertion が Back-channel Federation Model (Sec. 7.1 に後述) によって提示される場合, Transaction に追加の統制が課されることもある (MAY). 例としては RP の識別や Assertion インジェクションに対する保護策などが考えられる. これらは RP を不正なアクティビティから保護する追加の対策となる.

Bound Authenticators

Bound Authenticator とは Subscriber が Assertion とともに RP に提示する Authenticator である. RP に Bound Authenticator を保持していることを証明するため, Subscriber は Assertion の正当な Subject であるということを一定の確度を持って証明する. これにより, Attacker は Assertion に加え Bound Authenticator も詐取・提示することが必要になるため, Attacker が Subscriber 向けに発行された Assertion を詐取して利用することはより困難になる. さらに Bound Authenticator は独立した Authentication により RP を不正もしくは侵害された IdP から保護する.

Bound Authenticator は RP において Subscriber 毎に一意であるものとし (SHALL), 異なる Subscriber は同じ Authenticator をそれぞれの RP Subscriber Account に対して提示することができないようにすること. 全ての Bound Authenticator は Phishing 耐性を持つこと (SHALL). 従って, Memorized Secret のような Subscriber が選択した値は Bound Authenticator としては利用できない. RP は Assertion を保持したコンテキストでのみ Bound Authenticator による Authentication を受け入れること (SHALL). 従って, Subscriber は Bound Authenticator を使って IdP におけるプロセスをバイパスして直接 RP にログインすることはできない.

次節で詳述の通り, Bound Authenticator はさまざまな条件のもと IdP ないし RP のいずれかによって管理されうる. FAL3 の Assertion は, IdP が Subscriber に特定の IdP 管理の Bound Authenticator を提示することを期待するか, RP において FAL3 に足りる RP 管理の Bound Authenticator を提示することを期待するかを指定する値を含む.

IdP-Managed Bound Authenticators

Fig. 9 のように Bound Authenticator が IdP によって管理されている場合, RP に提示される Assertion には Authenticator を一意に示す識別子 (Authenticator の Public Key など) を含めることとする (SHALL). また RP は Subscriber に指定された Bound Authenticator の保持証明を求めること (SHALL).

Figure 9. IdP-Managed Bound Authenticators

IdP が管理する Bound Authenticator は Subscriber が IdP に対して Authenticate する際に用いるプライマリな Authenticator とは異なるものでよい (MAY). IdP が管理する Bound Authenticator は Phishing 耐性を持ち (SHALL), Public Key Infrastructure などの相互信頼セキュリティフレームワークに基づいて RP により個別に参照解除可能でなければならない (SHALL). 初めて IdP 管理の Bound Authenticator を処理する際, RP は Authenticator が提示する情報に含まれる Attribute を用いて Account 解決を行うなどして, 提示された Authenticator が Subscriber Account に関連づけられるに適切かどうかを検証するべきである (SHOULD).

例えば, Subscriber が Certificate が読み込まれた Smart Card を持っているとする. この Smart Card は Multi-factor Cryptographic Device である. Certificate は IdP にも RP にも提示可能であるため, IdP は RP に向けた FAL3 の Assertion に Certificate の識別子を含めることができる. すると RP は Subscriber に Smart Card 内の Certificate の提示を求め, FAL3 を満たすことができる.

“Holder of Key” (HoK) Assertion は IdP 管理の Bound Authenticator の一例である. この例では IdP は RP で使用される Subscriber の鍵を知っており, RP に提示する Assertion に鍵情報を含める.

\clearpage

RP-Managed Bound Authenticators

Fig. 10 のように Bound Authenticator が RP によって管理されている場合, IdP は Assertion に当該 Assertion が FAL3 で Bound Authenticator とともに利用されることを示す値を含めることとする (SHALL). Authenticator を一意に示す識別子 (Authenticator の Public Key など) は RP Subscriber Account 内に保存すること (SHALL).

Figure 10. RP-Managed Bound Authenticators

RP は FAL3 Assertion を成功裡に受け入れるには, 事前に RP Subscriber Account に Bound Authenticator が保存されていなければならない. これらの Authenticator は RP ないしは Subscriber のどちらかにより提示されうる. どちらが提示するかによって, 初回の RP Subscriber Account への Authenticator 紐付け処理にかかる要件は微妙に異なる.

RP が提示する Authenticator に関しては, RP の管理者が FAL3 で Subscriber をログインさせた状態で Subscriber に直接 Authenticator を発行しなければならない (SHALL). RP の管理者は, RP Subscriber Account に Bound Authenticator の一意な識別子を保存しなければならない (SHALL). さらに, RP の管理者は, 独自に Authenticator を発行する相手が RP Subscriber Account の Subject であることを確認しなければならない (SHALL).

Subscriber が提示する Authenticator に関しては, RP Subscriber にひとつも Bound Authenticator が紐づいていない場合, RP は Fig. 11 のように Authenticator, Subscriber および RP Subscriber Account の間の紐付け確立のために Binding セレモニーを実施しなければならない (SHALL). RP はまず FAL3 の Bound Authenticator に関するもの以外の要件を満たす Assertion を用いた Federation により Authenticated Session を確立する. 当該 Assertion には RP 管理の Bound Authenticator により FAL3 で利用されることが期待されることを示す値が含まれる. 次に Subscriber はその直後に提案された Authenticator を提示し Authenticate する. Authenticator の提示が成功すると, RP は Authenticator の一意な識別子 (Public Key 等) を保存し, それを Federated Identifier が指し示す RP Subscriber Account に紐づける (SHALL). Subscriber が適切な Authenticator を提示することができない場合, Binding セレモニーは失敗する. Binding セレモニーの Session は5分以内にタイムアウトさせなければならない (SHALL). セレモニー中の Session はログイン目的の Authenticated Session とはならない. Binding セレモニーが成功すると, RP は直後に IdP に対して FAL3 の新たな Assertion を要求すること (SHALL). その際 Subscriber には新たに登録した Bound Authenticator の提示が求められる.

Figure 11. Binding Ceremony

RP は Subscriber に複数の FAL3 の Subscriber 提示の Authenticator 紐付けを許可してもよい (MAY). その場合、RP Subscriber Account は一つ以上の既存の Bound Authenticator を持ち, Binding セレモニーは既存のものを使い FAL3 で行うことができる. Subscriber はまず最初に既存の Bound Authenticator を提示して FAL3 に到達する. Authentication 成功直後に RP は Subscriber に新たな Bound Authenticator を要求する.

RP は Subscriber に RP Subscriber Account からの Subscriber 提示の Authenticator 紐付け解除を許可してもよい (MAY). 紐付けを解除すると当該 Authenticator を用いて FAL3 を達成することはできなくなる. Bound Authenticator の紐付けが解除された際, RP は Subscriber の全ての既存 FAL3 Session を Terminate し (SHALL), Subscriber に IdP での Reauthentication を要求すること (SHALL). 多くの場合, Subscriber は, Authenticator を紛失したり Authenticator が侵害された際に Bound Authenticator を Account から紐付け解除する必要があることに注意すること. 従って, Subscriber は紐付け解除プロセス中には当該 Authenticator への Access を持たないことにも注意.

\clearpage

RP は, 以下のようなイベントが発生した際は, Out-of-band な手段で Subscriber に通知し (SHALL), IdP にも Shared Signaling システム (Sec. 5.7 参照) を通じて通知を行うべきである (SHALL).

• 新たな Authenticator が RP Subscriber Account に紐づけられた.
• 既存の Bound Authenticator が RP Subscriber Account から紐付け解除された.

例えば, Subscriber は Single Factor Cryotographic Device を Authenticator として保持しうる. この Authenticator は名前ベースの Phishing 耐性を持ち, IdP と RP はそれぞれ異なる鍵を受け取る. RP は, ここで述べた Binding セレモニーを用いて, Subscriber がこのデバイスを FAL3 の Bound Authenticator として使うことを許可することができる. RP は IdP から Subscriber に関する FAL3 の Assertion を受け取るたびに, Subscriber にこの Authenticator の提示を求めることになろう.

Processing Bound Authenticators

RP が Bound Authenticator とともに Assertion を受け取る際, Subscriber は RP に直接 Bound Authenticator の保持証明を行う. IdP におけるプライマリ Authentication および RP における Federated Authentication は別々に処理される. Subscriber は IdP におけるプライマリ Authentication でも RP における Bound Authenticator と同じ Authenticator を使うことができるが, それぞれが同じものであるということはなんら想定されない.

以下の要件は Bound Authenticator と関連づけられた全ての Assertion に適用される.

1. Subscriber は RP に対して Assertion そのものの提示に加え Bound Authenticator の保持証明を行うこと (SHALL).
2. Authenticator が IdP で管理されている場合, Assertion 内に含まれる当該 Authenticator の参照は Assertion 内のその他の全ての情報を同じレベルで信頼すること (SHALL).
3. Authenticator が IdP で管理されている場合, Assertion は提示時に Authenticator として使われる Private Key ないし Symmetric Key を暗号化せずに含んではならない (SHALL NOT).
4. RP は Bound Authenticator に加えて Assertion も処理, 検証すること (SHALL).
5. Bound Authenticator を用いた Authentication が失敗した場合, RP 側でエラーになること (SHALL).

Assertion Protection

Binding メカニズム (Sec. 6.1) やその取得に用いる Federation モデル (Sec. 5.1) とは別に, Assertion は有効な Assertion を偽装したり取得した Assertion を他の RP に対して再利用する攻撃に対する保護策を持たねばならない (SHALL). 必要な保護策は考慮されるユースケースの詳細に依存する. 具体的な保護策を以下に示す.

Assertion Identifier

Assertion は対象の RP が一意に区別可能である必要がある (SHALL). これは Nonce, Issuance Timestamp, Assertion Identifier ないしこれらおよびその他のテクニックの組み合わせにより実現可能である (MAY).

Signed Assertion

Assertion は Issuer (IdP) に暗号論的に署名されなければならない (SHALL). RP は Issuer の鍵にもとづいて各 Assertion の Digital Signature ないし MAC を検証しなければならない. この署名は Assertion Identifier, Issuer, Audience, Subject および Expiration を含む Assertion 全体をカバーすること (SHALL).

Assertion の署名は Asymmetric Key を用いた Digital Signature か Symmetric Key を用いた MAC のどちらかでなければならない (SHALL). この目的のために IdP が用いる Shared Symmetric Key は, Assertion 送信先の RP 毎に固有でなければならなず (SHALL), 通常は RP の Registration 時に確立される. Digital Signature を検証するための Public Key はセキュアな手段により RP に送信されなければならず (SHALL), RP が実行時に IdP のホストする HTTPS URL を介するなどセキュアな方法で取得することも可能である (MAY). また Approved Cryptography を利用せねばならない (SHALL).

Encrypted Assertion

Encrypted Assertion は Assertion のコンテンツを想定外の当事者に閲覧されることを防止し, 対象の RP のみが Assertion を閲覧できることを保証する. Assertion の暗号化には, 主に2つの利点がある. 1つめは Assertion コンテンツが対象 RP 以外から閲覧できないということ, 2つめは対象の RP 以外の RP は当該 Assertion を利用できないということである.

Assertion を暗号化する際, IdP は RP の Public Key ないしは Shared Symmetric Key を用いて Assertion コンテンツを暗号化しなければならない (SHALL). この目的のために IdP が用いる Shared Symmetric Key は, Assertion 送信先の RP 毎に固有でなければならなず (SHALL), 通常は RP の Registration 時に確立される. 暗号化に用いる Public Key はセキュアな手段により IdP に送信されなければならず (SHALL), IdP が実行時に RP のホストする HTTPS URL を介するなどセキュアな方法で取得することも可能である (MAY).

全ての Assertion 暗号化には Approved Cryptography を利用すること (SHALL).

Assertion に Personally Identifiable Information が含まれかつ Assertion がブラウザなどの中間者に取り扱われる場合, Federation Protocol は Assertion を暗号化し Assertion に含まれるセンシティブな情報を予期せぬ当事者に漏洩しないよう保護しなければならない (SHALL). 例えば SAML Assertion は XML-Encryption を用いて暗号化することができるし, OpenID Connect ID Token は JSON Web Encryption (JWE) を用いて暗号化することができる.

Audience Restriction

Assertion には Audience Restriction 技術を適用し, RP に自信がその Assertion の発行対象として想定されているか認識できるようにしなければならない (SHALL). 全ての RP は, ある RP が別の RP に Assertion をインジェクトしたり Replay したりすることを防止するため, Assertion の Audience が自身の識別子を含んでいることをチェックしなければならない (SHALL).

Pairwise Pseudonymous Identifiers

状況によっては, 共通の識別子を用いて複数の RP にまたがって Subscriber Account をリンクすることを防ぎたい場合がある. Pairwise Pseudonymous Identifier (PPI) は, IdP が単一の Subscriber Account に関して異なる RP に異なる Federated Identifier を提供することを可能にする. これにより異なる RP が共謀して Federated Identifier を用いて Subscriber をトラックすることを防止できる.

General Requirements

IdP が RP に対して生成する Assertion 内で Pairwise Pseudonymous Identifier を用いる際, IdP は Sec. 6.2.5.2 に後述の通り各 RP に異なる Federated Identifier を生成しなければならない (SHALL).

RP に対して Attribute とともに PPI を用いる場合, 共謀する複数の RP が Identity Attribute に基づいて複数のシステムにまたがって名寄せを行うことで, Subscriber を再識別することは依然起こりうる. 例えば2つの独立した RP が各々異なる Pairwise Pseudonymous Identifier が指し示す同一の Subscriber を見ている場合, これらの RP は依然として, 各自の Assertion 内に Pairwise Pseudonymous Identifier と共に伝搬される Subscriber の氏名, Email Address, 住所やその他の識別可能な Attribute により, 当該 Subscriber が同一人物であると特定することもありうる. このような名寄せはプライバシーポリシーで禁止すべきであり (SHOULD), Pairwise Pseudonymous Identifier は Attribute の名寄せに関する管理作業を増大させることによってこういったポリシーの効果を高めることも可能である.

Proxied Federation モデルでは, 最初の IdP が末端の RP に対して Pairwise Pseudonymous Identifier を生成することは不可能な場合もあることに注意すること. Proxy は IdP に対して Subscriber が Access しようとしている RP を隠すこともある. このような状況下では, Pairwise Pseudonymous Identifier は通常 IdP と Federation Proxy 自身の間で確立される. Proxy は IdP として動作することで自身の Pairwise Pseudonymous Identifier を下流の RP に提供することができる. プロトコルによっては, Identity Protocol が機能するために, Federation Proxy が Pairwise Pseudonymous Identifier から上流の IdP が発行したそれに紐づく識別子を逆引きすることが必要な場合もある. そのような場合, Proxy はどの Pairwise Pseudonymous Identifier が異なる RP のどの同一の Subscriber を示しているか特定, 追跡が可能となる. Proxy は, Pairwise Pseudonymous Identifier とその他のいかなる識別子との間のマッピングについても 3rd-party に開示してはならず, 当該情報を Federated Authentication, それに関連する不正防止, 法律ないし法的プロセスへの準拠, 当該情報に対する特別なユーザー要求への応答を除き, その他の目的で利用してはならない (SHALL NOT).

Pairwise Pseudonymous Identifier Generation

Pairwise Pseudonymous Identifier にはいかなる Subscriber の識別情報をも含めないこと (SHALL). さらに Pairwise Pseudonymous Identifier はなんらかの Subscriber の識別情報を持つ当事者により推測可能でもないこと (SHALL). Pairwise Pseudonymous Identifier は IdP によってランダムに生成され Subscriber に割り当てることもできるし (MAY), 不可逆かつ推測不可能な方法で導出可能 (e.g., Secret Key を用いた鍵付きハッシュなど) であれば Subscriber に関するその他の情報から導出することもできる (MAY).

通常は, この識別子は1組のエンドポイントにのみ知られ, 使われうるものとする (SHALL). IdP は以下の条件を満たす複数の RP により要求された場合は, 同じ Subscriber に同じ識別子を生成してもよい (MAY).

• 特定の RP 群に対して Pseudonymous Identifier を共有可能であることが Trust Agreement に規定されている.
• Authorized Party が Pseudonymous Identifier の共有について同意し, かつその利用に関して通知されている.
• これらの RP 群が, 互いにセキュリティドメインを共有していたり同一の法的所有権のもとにあるなど, 運用上の名寄せの必要性を正当化するような関係性にある.
• 識別子を共有するすべての RP がこのような方法で名寄せ可能な関係性になることに同意する. (i.g., ある RP が他の RP の認知および同意なしに他の RP の PPI を要求することはできない.)

RP は Privacy Risk Assessment を行い共有識別子の要求に関するプライバシーリスクについて検討すること (SHALL). さらなるプライバシー上の考慮事項は Sec. 9.2 を参照.

IdP は意図した RP だけが名寄せ可能な状態になることを保証すること (SHALL). さもなくば, 不正な RP が, 名寄せ可能な状態にある RP 群に向けた Pseudonymous Identifier を, その RP 群の一員を装い知り得ることになる.

Identity APIs

プロフィール情報を含む Subscriber に関する Attribute は, Identity API とも呼ばれる保護された Attribute API から提供されうる (MAY). RP は Federation Transaction 中に Assertion と合わせて Identity API への限定 Access を許可される. 例えば OpenID Connect では UserInfo Endpoint が標準の Identity API として Subscriber Attribute の取得に用いられる. この API は OAuth 2.0 Access Token により保護され, この Access Token は OpenID Connect の Assertion である ID Token と共に RP に発行される. Federation Assertion に加えて Identity API の利用することには, 全体のセキュリティ, プライバシーおよび Federation システムの効率性において幾つかの利点がある.

Attribute を Identity API から取得可能とすることで, IdP は Assertion に大量の情報を含めて RP に送信する必要はなくなる. これはセンシティブな Attribute を Assertion 自身に含めなくてよくなるというだけでなく, Assertion をより小さく RP に処理しやすいものにするという意味もある. それにより, Assertion のコンテンツは, 必須項目 (e.g., Subject Identifier) と当該 Authentication イベントを示す情報に限定されうる.

Sec. 5.4 で述べたように, RP はしばしば RP Subscriber Account に IdP から提供された Attribute をキャッシュする. Assertion 内の Attribute は全てのログイン時に伝搬され, RP は Attribute を要求する前段階では Subscriber の Identity を知らないため, IdP は Assertion 自身に可能な限り多くの情報を含めるインセンティブを持つことになる. しかしながら大抵の Subscriber Attribute は連続するログイン間で不変であり, この情報は冗長となる. 結果として, これらの変化の少ない属性のほとんどは, Assertion に含める代わりに必要に応じて RP が Identity API を介して取得すれば十分となる. IdP は Assertion 内で当該 Subscriber Account に関する Subscriber Attribute の最終更新時間を示すことも可能で, そうすることで RP は Attribute を新たに取得する必要があるか RP Subscriber Account に保存されている情報で足りるかを判断することができる.

Identity API への Access には有効期限がある. この有効期限は Assertion の Validity Time Window とは独立しており, RP の Authenticated Session の有効期限からも独立している. RP が Identity API に Access できるからといって, 関連する有効な Assertion がない場合は, RP での Authenticated Session の確立に必要な条件を満たしたものとしてはならない (SHALL NOT).

Identity API 実装は, IdP が Assertion を生成できる全ての Subscriber に関する Attribute を提供できることが期待される. しかしながら, Federation Transaction のコンテキス内で Identity API への Access が許可された場合, その Identity API が提供する Attribute は当該 Assertion が指し示す Subscriber のもののみとすること (SHALL). IdP が Identity API をホストする場合, 返却される Attribute には Subscriber の Subject Identifier を含めること (SHALL). これにより RP は Assertion Subject を返却された Attribute に確実に紐づけることができる. なお, Sec. 5.4.1 で述べたように, Attribute API への Access が RP Subscriber Account の Pre-provisioning の一環として提供される場合, RP は通常 Federation Transaction コンテキスト外で Identity API への全面的な Access を許可され, 上記要件は適用されないことに注意.

Attribute Providers

Federation において, 大抵の Attribute API は IdP の一部としてホストされるが, IdP が外部の Attribute Provider にホストされる Identity API への Access を許可することも可能である. こういったサービスは, IdP が直接提供できるもの以外にも Subscriber に関する Attribute を提供することができる.

IdP が Attribute Provider への Access を許可する場合, IdP は Attribute Provider から返却された情報が, 関連づけられた Assertion により識別される Subscriber に紐づいたものであることを明示する. Trust Agreement においては, IdP が Attribute API から返却されるコンテンツの正確性に責任を負う当事者となる.

Attribute Provider に返却された Attribute は IdP が直接返却する Attribute とは独立したものと想定される. 従って異なる識別子, フォーマットおよびスキーマを利用することも可能である (MAY). RP は当該 Attribute Provider が適切な Trust Agreement の保護のもとでそういった類の実在する Attribute を提供するに足りることを検証すること (SHALL).

例えば, IdP が Federation プロセスの一環で Subscriber の医師免許情報への Access を提供しうるとする. この時 IdP は, 当該ライセンスのステータスを直接示す代わりに, RP に医師免許機関における Subscriber のレコードへの Access を許可するとする. この場合, ライセンスレコードは IdP が使用する Subject Identifier を使用していないこともあり得るが, RP は当該 Subscriber とライセンスレコードとの間に強力な関連付けを行うことができる.

Assertions

This section is normative.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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

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.

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

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.

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.

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-Managed Bound Authenticators

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.

Figure 9. IdP-Managed Bound Authenticators

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.

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) 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-Managed Bound Authenticators

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.

Figure 10. RP-Managed Bound Authenticators

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.

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.

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.

Figure 11. Binding Ceremony

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.

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

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.

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.

Processing Bound Authenticators

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.

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

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

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

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.

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

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.

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.

All encryption of assertions SHALL use approved cryptography.

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

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

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

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.

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.

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

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

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

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.

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.

Identity APIs

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.

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.

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.

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.

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

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.

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.

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.

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つの種類が存在する. それにより Assertion を IdP から RP に提示する方法も2つ存在することとなる.

• Front Channel という, Subscriber および Subscriber のブラウザのリダイレクトを介したもの
• Back Channel という, Subscriber が直接関与することのない RP と IdP の直接通信を介したもの

それぞれのモデルにはトレードオフがあるが, どちらも適切な Assertion の検証を必要とする. Assertion は, Sec. 5.1.3 で述べたように, IdP-RP 間の Federation 促進のため, 上記とはまた別の提示方法を用いて Proxy されることもある (MAY).

Back-Channel Presentation

Back Channel 提示モデルでは, Subscriber は Assertion Reference を提示され, それを RP に提示する. この際は通常 Front Channel を介して提示が行われる. Assertion Reference 自体は Subscriber に関する情報を持たず, Attacker による改変や偽造を防止するものでなければならない (SHALL). RP は Assertion Reference を IdP に提示し, 通常はその際同時に RP 自身の Authentication も行いつつ, Assertion を取得する.

Figure 12. Back-channel Presentation

Figure 12 に示す通り, Back Channel 提示モデルは3つのステップからなる.

1. IdP が Front Channel を介して Subscriber に Assertion Reference を送信する.
2. Subscriber が Front Channel を介して RP に Assertion Reference を送信する.
3. RP が Back Channel を介して Assertion Reference と RP 自身の Credential を IdP に提示する. IdP は当該 Credential を検証し Assertion を返却する.

Assertion Reference の要件を以下に示す.

1. 利用できる RP を単一に制限する (SHALL).
2. 利用できる回数を1度きりに制限する (SHALL).
3. 有効期限を定め (SHALL), そのライフタイムは数分以内にすべきである (SHOULD).
4. 提示の際には IdP に対する RP の Authentication を必要とする (SHALL).
5. 128 bit 以上の Entropy を持つ (SHALL).

\clearpage

このモデルでは, RP は IdP に直接 Assertion を要求する. 従って3rd-party (Subscriber 自身を含む) により傍受されたり改ざんされるリスクは最小化される.

この手法では, RP が IdP に対して Assertion 自体には含まれていない Subscriber の追加の Attribute を照会することを促進する. Back Channel 通信は, 最初の Authentication Transaction が完了した後も, ユーザーを IdP に送り返すことなく継続して実施可能であることがその要因である. この照会は Sec. 6.3 で述べた Identity API を介して行われる.

Back Channel 手法ではより多くの Network Transaction が必要になるが, 情報を受け取るのはそれを必要としている主体のみに限定される. RP は IdP から直接 Assertion を受け取ることとなるため, Attack の可能性がある箇所も削減される. したがって, Assertion を RP に対して直接インジェクトすることはより困難になるため, この提示方法は FAL2 以上で推奨される.

RP は, Cross-site Scripting 対策やその他の一般的防御策を用いて, Assertion Reference のインジェクションや偽造, 傍受からの防御策を施さねばならない (SHALL).

IdP から Subscriber への Assertion Reference の送信は, Subscriber から RP への Assertion Reference の送信と同様に, Authenticated Protected Channel を介して行わねばならない (SHALL). RP から IdP への Assertion Reference の送信も, IdP から RP への Assertion の送信と同様に, Authenticated Protected Channel を介して行わねばならない (SHALL).

Assertion Reference を提示する際, IdP は Assertion Reference を提示する相手が Authentication を要求している相手と同一であることを検証せねばならない (SHALL). IdP は, RP が IdP に Assertion Reference を提示する際に Authentication を要求したり, その他の類似手段 (あるプロトコルにおける動的 RP 検証方法については [RFC7636] を参照) によりこれを実現できる.

Sec. 5.1.3 の Federation Proxy においては, IdP は Assertion Reference および Assertion に関して Proxy を相手とした Audience Restriction を施し, Proxy が新たに生成した Assertion Reference および Assertion に関して下流の RP を相手とした Audience Restriction を施すことに注意.

\clearpage

Front-Channel Presentation

Front Channel 提示モデルでは, IdP は Subscriber の Authentication 成功後に Assertion を生成しそれを Subscriber に送信する. Subscriber は RP に対して Authentication を行うため当該 Assertion を提示する. これは通常 Subscriber のブラウザ内でリダイレクト等のメカニズムを介して行われる.

Figure 13. Front-channel Presentation

Front Channel 手法では, Assertion は Subscriber により閲覧可能である. よって Assertion に含まれるシステム情報は潜在的に漏洩しうる. さらにこのモデルでは, Sec. 6.3 で述べたように, RP が IdP に Assertion 提示後に Identity API を通じて追加の Attribute を照会することも, 可能ではあるがよりやりにくくなる.

Assertion は Subscriber の管理下に置かれるため, Front Channel 提示手法では Subscriber が単一の Assertion を期待されていない相手に送りつけることも可能となる. これはおそらくブラウザを介して複数の RP に当該 Assetion を Replay することで行われるであろう. たとえ Assertion が Audience Restriction により保護されており期待されない RP から拒絶されるとしても, 期待されない RP に提示されるということそのものが, Subscriber に関する情報および Subscriber のオンラインアクティビティの漏洩に繋がる可能性がある. 複数の RP に提示されることを意図して Assertion を生成することも可能であるが, この方法では Assertion 自体の Audience Restriction を緩めることにつながりかねず, 対象 RP 間で Subscriber のプライバシーおよびセキュリティ侵害に繋がる可能性もある. このような複数 RP での利用は推奨されず, 代わりに RP は個々に独自の Assertion を取得することが推奨される.

RP は, Cross-site Scripting 対策やその他の一般的防御策を用いて, Assertion のインジェクションや偽造, 傍受からの防御策を施さねばならない (SHALL).

IdP から Subscriber への Assertion の送信は, Subscriber から RP への Assertion の送信と同様に, Authenticated Protected Channel を介して行わねばならない (SHALL).

Sec. 5.1.3 の Federation Proxy においては, IdP は Assertion に関して Proxy を相手とした Audience Restriction を施し, Proxy が新たに生成した Assertion に関して下流の RP を相手とした Audience Restriction を施すことに注意.

Protecting Information

IdP と RP の間の通信は, Authenticated Protected Channel を使用して転送中に保護しなければならない (SHALL). Subscriber と IdP ないし RP の間の通信 (通常はブラウザを介して行われる) もまた, Authenticated Protected Channel を用いて実施せねばならない (SHALL).

IdP は RP がセキュリティポリシー適用に際して役立てることができる情報への Access を持っていることもありえる. これには Device Identity 情報, 位置情報, システムのヘルスチェック情報, 構成管理情報などが含まれる. こういう情報を持っている場合, Sec. 9.2 に述べるように, Subscriber のプライバシー設定の範囲内でそれらを RP に送信することは良いアイデアであろう.

Sec. 6.3 で述べたように, ユーザーに関する追加の Attribute を Assertion 外で Identity API への認可された Access を用いて提供することもできる (MAY). このようにユーザー情報を分離することで, ユーザーのプライバシーを保護し, Authentication Assertion 自体に必須情報を含めた上で, 識別可能な Attribute の開示を最小化することもできる.

RP は, Sec. 9.3 にあるように, 可能な限り完全な Attribute Value より Derived Attribute Value を要求しなければならない (SHALL). IdP は Derived Attribute Value を可能な限りサポートしなければならない (SHALL).

Assertion Presentation

This section is normative.

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.

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

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.

Figure 12. Back-channel Presentation

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.

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

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

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.

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.

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

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.

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

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

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.

Figure 13. Front-channel Presentation

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.

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.

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.

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

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.

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.

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.

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.

Federated Authentication プロセスでは, IdP として動作する CSP を含む複数のコンポーネント間の協調動作が行われるため, Attacker が Federated Identity Transaction を侵害する機会は増大する. 本セクションでは, Federation において起こりうる Attack およびその対応策についてまとめる.

Federation Threats

Federation を用いない Authentication と同様に, Attacker のモチベーションは通常リソースや RP が提供するサービスへの Access (またはより高レベルの Access) を得ることにある. また Attacker は Subscriber になりすまそうとする可能性もある. 不正または侵害された IdP, RP, ユーザーエージェント (e.g., ブラウザ) および典型的 Federation Transaction 外の関係者は, 潜在的に Attacker たりえる. こういった Attack を成功させるため, Attacker は Assertion や Assertion Rerefernce を傍受または改ざんする可能性もある. さらには, 2つ以上の主体が Federation Protocol 自体を転覆させるべく, Assertion データの Integrity (完全性) および Confidentiality (機密性) を侵害しようとすることもあろう. こういったタイプの脅威を目的とする場合, その権限を超えて行動しようと試みるいかなる Authorized Party もが Attacker とみなされる.

Table 2 Federation Threats

Federation Threat Mitigation Strategies

上記の脅威に対する対策を Table 3 にまとめる.

Table 3 Mitigating Federation Threats

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 は RP と Subscriber に多くの恩恵をもたらすが, Subscriber による Federation 参加者への信頼を必要とする. Sec. 5 および Sec. 6.2.5 は, Subscriber の追跡およびプロファイリング可能性の向上により増大するプライバシーリスクの最小化を目的とした, 多数の技術要件をカバーしている. 例えば同じ IdP を複数の RP に対する Authentication のために用いる Subscriber は, IdP によって Federation がなければ起こり得なかったであろう Subscriber Transaction のプロファイリングを行われる可能性がある. このようなデータが利用可能になると, Subscriber が予期または希望しない利用のされかたが行われる恐れにつながり, Subscriber が Federated サービスの採用を躊躇うことにもつながりうる.

Sec. 5.5 では, IdP に Predictability (PII および情報システムによる PII の処理に関して, 個人, 所有者およびオペレーターによる確実な予測可能性) および Manageability (変更, 削除および選択的開示を含む PII の細やかな管理機能の提供) を維持するための手段を要求している. この Predictability および Manageability は, Identity Proofing, Authentication, Authorization のほか, Attribute Assesion, 関連する不正防止ないしは法律や法的プロセスへの準拠以外の目的での Attribute の処理により生じるプライバシーリスクに相応するものである必要がある [NISTIR8062].

IdP は Attribute を処理する際に多様なビジネス上の目的を持ちうる. これには Subscriber への Identity Service 以外のサービス提供を含む. しかしながら, Attribute をその収集の本来の目的とは異なる目的で処理することは, 個人が追加処理に対して期待ないし満足していない場合にはプライバシーリスクにつながりうる. 例えば, 適用される法律, 規制ないしポリシーが存在しなければ, Identity Service 以外のサービスを提供する際に Subscriber の同意は不要かもしれないが, Subscriber が確実な予測を行えるようにする (Predictability) には, その処理に関する通知が役に立つこともある. また別の Attribute の処理により異なるプライバシーリスクが生じる可能性もあり, Subscriber による同意や Subscriber による特定の Attribute の利用ないし開示に関するより詳細なコントロール (Manageability) が求めれることもある. Subscriber の同意は意味のあるものでなければならず, IdP が同意による手段をとる場合は, Subscriber による追加利用に関する同意を Identity Servicee の提供条件にしてはならない.

検討中の処理が許可された処理や適切なプライバシーリスク軽減措置の範囲を超えるかどうかに疑念がある場合は SAOP に相談すること.

Sec. 5.5 では, Disassociability (システム運用上の要件を超えて個人またはデバイスに関連付けることなく, PII またはイベントの処理を可能にすること) を提供する技術的手段の採用も推奨しており, Subscriber のアクティビティがトラッキングされたりプロファイリングされることを防止している [NISTIR8062]. Sec. 6.2.5 で述べた Proxied Federation や Sec. 6.2.5 で述べた Pairwise Pseudonymous Identifier Sec. 5.1.3 のような技術的手段は, Subscriber を運用上の要件を超えてトラッキングないしプロファイリングすることをより困難にし, ポリシー適用の効率化に寄与しうる.

Notice and Consent

Federation において Subscriber の信頼を確立するには, Subscriber が自身の情報の処理に関して確実性のある予測可能性を保つことが必要である. 例えば Subscriber が, どのような情報が送信され, 当該 Transaction においてどの Attribute が必須でどれが任意かを理解し, 任意の Attribute を RP に送信するかどうか決定可能であることは, Subscriber にとって有用である. 従って Sec. 5.1 は Subscriber に関する Attribute が RP に送信される前に Authorized Party による明示的な確認を得ることを要求している. Sec. 6.2.5.2 にあるように, 一連の RP 群が共通の Pairwise Pseudonymous Identifier を共有すべきかどうかを決定する際, IdP は Subscriber が当該 RP 群のグルーピングを理解しているかを考慮し, その理解を促すための通知役を担うことを検討すべきである. 効果的な通知を行うには, 情報処理により生じる可能性のあるプライバシーリスクの評価にくわえ, ユーザーエクスペリエンスの設計基準および研究が重要となる. Subscriber による当該処理や Federation に関与するその他の主体に対する想定の確度など, 考慮する要素は多岐にわたる. しかしながら, 相当数の Subscriber が読みもせず理解もしない, 複雑かつ法律主義的なプライバシーポリシーや一般的な規約条件へのリンクは, 全く効果的な通知にはならない.

Sec. 5.1 はどの当事者が通知を提供すべきかは規定していない. 場合によっては, Federation 中のある当事者が Subscriber との間に通知および同意取得を行うための直接のつながりを持っていないこともある. 複数の当事者が通知を提供するとも可能だが, Subscriber が通知に注目して情報に基づいた選択を行えることに主眼を置いて決定がなされる限り, 契約上またはトラストフレームワークのポリシーを通じて事前に通知および同意取得を行う当事者を決定することも許容される.

IdP が Sec. 5.3 で述べた RP の Allowlist を採用している場合, Authentication Transaction 中 Subscriber に当該リスト上の RP が提示されることはない. IdP は実行時には Subscriber に通知を提供しないため, IdP は Allowlist 上の RP を Subscriber に開示して, Subscriber がどの RP が Allowlist に存在し Authentication Transaction 中にどの Subscriber Attribute にアクセスするのか確認できるようにすべきである. IdP は Subscriber が関与する Authentication Transaction の外では Allowlist 中の RP に Subscriber の Authentication 情報や Attribute を共有することはできない (Sec. 5.5 参照) ため, RP が当該リストに記載されているからといって IdP が Subscriber の情報を当該 RP に共有するとは限らない. しかしながら, Subscriber が IdP を利用して Allowlist に記載されたいずれかの RP にログインする際, 記載された Attribute が Authentication Transaction の一環として共有されることになる.

IdP が将来の Transaction を円滑にするため Subscriber の IdP における実行時決定を Subscriber Account に保存する場合, IdP は Subscriber が過去に実行時決定において許可した RP のリストを確認し, その許可を取り消すことができるようにする必要がある. このリストにはどの Attribute が許可されたかの情報も含む. 同様に, Subscriber の RP における実行時決定が何らかの形式で保存される場合, RP は Subscriber が過去の実行時決定において許可した IdP を確認し, その許可を取り消すことができるようにする必要がある.

Data Minimization

Federation は RP に開示されるデータを最小化することを可能にする. これは Subscriber のプライバシー保護につながる. IdP は RP がそのユースケースに応じて要求する範囲を超えて追加の Attribute を収集することもあるが, RP が明示的に要求した Attribute のみを送信する. 場合によっては RP が Attribute の完全な値を要求しないこともある. 例えば RP は Subscriber が13歳以上かどうかを知りたいが, 完全な生年月日を知る必要はないとする. 潜在的にセンシティブな PII の収集を最小化するため, RP は Derived Attribute Value (e.g., 質問: この Subscriber は13歳以上ですか? 回答: Y/N or Pass/Fail) を要求することもできる. これにより RP による潜在的にセンシティブかつ不必要な PII の収集を最小化できる. 従って Sec. 7.3 は RP に可能な限り完全な Attribute Value ではなく Derived Attribute Value を要求するよう求めている. この RP の要件をサポートするため, IdP は逆に Derived Attribute Value をサポートすることが要求される.

Agency-Specific Privacy Compliance

Section 5.5 は各機関がプライバシーコンプライアンス要件の決定のために SAOP に相談する際の要件を定めている. 当該機関の SAOP が Digital Authentication システムの開発の初期段階で関与し, プライバシーリスクを評価および軽減し, 当該 Federation に Privacy Act of 1974 や E-Government Act of 2002 による PIA 実施要件が適用されるかどうかなどのコンプライアンス上の義務についてアドバイスすることは, 非常に重要である. 例えば, 機関が Federation において IdP を提供している場合, Privacy Act の要件が適用されて新旧いずれかの Privacy Act の記録システムにカバーされる必要が生じるであろう. これは IdP が Federation をおこなう RP に代わって Credential を管理することになるからである. しかしながら, もし機関が 3rd-party の IdP を利用する RP の場合, RP が送信したデータが RP 機関でどのように監査されているかによっては, Digital Authentication に Privacy Act 要件は適用されないかもしれない. (この場合, 当該機関はそのようなデータをカバーするより広範な計画に沿った SORN を持っているかもしれない)

同様に, SAOP は機関による PIA が必要かどうかの判断を手助けすることもできる. こういった考慮事項は, Federated Credential の利用のみを目的とした Privacy Act SORN や PIA の実施要件として受け取るべきではない. 多くの場合, Digital Authentication プロセス全体を網羅した PIA および SORN を起草したり, Digital Authentication プロセスを当該機関がオンラインアクセスを確立するプログラムやメリットについて議論するためのより大きな計画に沿った PIA の一部として取り扱うことは理にかなっている.

Digital Authentication には多くのコンポーネントが存在するため, SAOP が個々のコンポーネントを認識して理解することは重要である. 例えば, IdP や RP のサービスを提供ないし利用している機関に適用されうる, Data Use Agreements や Computer Matching Agreements などのプライバシー要件が存在するかもしれない. SAOP はどのような追加要件が適用されうるかという当該機関の判断を手助けすうことができる. さらに, Digital Authentication の個々のコンポーネントの完全な理解を通じて, SAOP はコンプライアンスプロセスやその他の手段を通じてプライバシーリスクを徹底的に評価・軽減することができるようになる.

Blinding in Proxied Federation

Proxy 構造によっては (典型的にはインテグレーションを単純化することを主目的とするものなど) Subscriber に対する追加のプライバシー保護を提供しないこともあるが, 多くは Blinding テクノロジーにより Subscriber に多様なレベルでのプライバシーを提供する. IdP, RP および Federation Proxy は Privacy Policy によって Subscriber Attribute および Authentication Transaction データ (e.g., 末端の IdP および RP の識別子) の適切な利用を指示することもできる.

Blinding などの技術的対策はデータ取得をより困難にすることでこういったポリシーの効果を高めることができる. Proxy ベースのシステムは3つの当事者から成り, Proxy は自身を含む1つ以上の当事者から得られる情報を秘匿するために利用可能である. Double Blind Proxy では, IdP と RP はお互いの Identity を知ることがなく, その関係性は Proxy を介したもに限定される. Triple Blind Proxy では, Proxy は自身を通過するデータを見ることもできなくなる. Blinding のレベルが上がるにつれ, 技術的および運用上の実装複雑度も上昇しうる. Proxy は Transaction をいずれかの側の適切な当事者にマッピングし, Transaction 内の全ての当事者の鍵を管理する必要があるため, 完全な Triple Blind Proxy の実装は実際には非常に困難である.

Blinding 技術を採用しても, Blind された当事者は依然として保護された Subscriber 情報を開示された Attribute データやメタデータから推測しうる. 例としては, タイムスタンプや Attribute Bundle のサイズ, Attribute 署名者情報などの解析により, そのようなことが起こりうる. IdP は Federation に参加している主体の識別情報が暴露されるリスクを軽減するため, 追加のプライバシー強化アプローチを検討してもよい.

以下の表は Proxied Federation で利用される Blinding 実装の種類を示している. この表は説明目的で記載されたものであり, 包括的でもなく技術的に固有のものでもないことに注意.

Table 4 Federation Proxies

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] は Usability を “特定の利用コンテキストにおいて, 特定のユーザーが, あるシステム, プロダクトないしはサービスを利用して, 特定の目標を, どの程度有効的, 効率的かつ満足のいくレベルで達成できるかの度合い” と定義している. この定義はユーザー, 目標および利用コンテキストを, 有効性, 効率性および満足度の達成に必要な重要要素として捉えている. Usability を実現するには, これらの重要要素を考慮した総合的なアプローチが必要となる.

Usability の観点からは, Federated Identity Systemの主な潜在的利点の1つとして, 複数の Authenticator 管理に関するユーザーの苦役に対処できることが挙げられる. 歴史的にこれはユーザー名と Password に関して問題となってきたが, ユーザーが多くの Authenticator (物理的なものも Digital なものも) を管理するニーズが高まるについて, Usability の課題が生じている.

Authentication に対する多くの他のアプローチが広く研究されており, 十分に確立された Usability ガイドラインも存在するが, Federated Identity はまだ初期段階であり, 従って研究結果の深さや決定性に欠けている. Usability 研究が進展するにつれ, Federated Identity Systemに対する Usability ガイドラインを発展させるより強力なデータを得ることとなろう. 例えば, 技術的な Attribute 名およびその値をユーザーフレンドリーな言語に翻訳するためのガイドラインの発展には, 追加のデータが必要となる.

800-63A および 800-63B の Usability の章で述べたように, 全体的なユーザーエクスペリエンスはあらゆる Authentication 方法の成功に不可欠である. Federation は多くのユーザーにとってあまり馴染みのないユーザーインタラクションの形態であるため, これは特に Federated Identity System に当てはまることである. ユーザーが過去に経験した Authentication のエクスペリエンスは, 彼らの期待に影響を与える可能性もある.

Federated Identity System における全体のユーザーエクスペリエンスは可能な限りスムースかつ容易であるべきである. これは Usability 標準 (ISO 25060 シリーズの標準など) と確立されたユーザーインタラクションデザインのベストプラクティスに従うことで実現可能である.

Note: 本章では “ユーザー” という用語は “Claimant” ないし “Subscriber” を意味し, “主体” という用語は Federated System 内の当事者を表す.

ガイドラインと考慮事項はユーザーの観点から記述されている.

Usability とは異なり, アクセシビリティに関しては本書のスコープ外とする. [Section508] は情報技術の障壁を取り除くために制定され, 連邦政府機関に対して電子および情報技術の公開コンテンツを障害を持つ人にもアクセスできるように要求している. アクセシビリティガイドラインに関しては Section 508 の法律および標準を参照のこと.

General Usability Considerations

Federated Identity System は以下を満たすべきである.

• ユーザー障壁 (e.g., フラストレーションや学習カーブ) の最小化
  • 必要なユーザーアクションを最小化すること.
  • ユーザーが単一の IdP において複数の Subscriber Account のなかから素早く簡単に目的の Account を選択可能とすること. 例えば Account Chooser のようなアプローチは, ユーザーが直近にアクセスした Subscriber Account のリストから Account を選択することを可能にし, 利用可能な IdP のリストから目的の IdP を選ぶところから Federation プロセスをスタートさせる必要性をなくすことができる.
  • ユーザー障壁の最小化とユーザーが情報に基づいた決定を行うに足りる情報の提供のバランスを取ること.

• なじみのない専門用語や詳細の使用を最小限に抑えること. (e.g., 基本的な概念が明確に説明されている場合, ユーザーは IdP や RP という用語を知る必要はない)

• IdP, RP を通じて一貫性のある統合されたユーザーエクスペリエンスを目指すこと.

• 図表, イラスト, FAQ, チュートリアルや例示などを提供し, ユーザーが Identity に対する理解を確立できるよう手助けすること. こういったリソースは, ユーザーの情報がどのように取り扱われ, どのように当事者 (e.g., RP, IdP, Broker) が相互にやりとりを行うかを説明すべきである.

• ユーザーに対して, 明確, 正直かつ意味のあるコミュニケーションを行うこと. (i.e., コミュニケーションは明確で理解しやすいものであるべきである)

• 位置やデバイスに依存しないオンラインサービスをユーザーに提供すること.

• 信頼関係をユーザーに明示して, 情報に基づいた信頼の決定を容易にすること. 信頼関係はしばしば動的かつコンテキスト依存である. ユーザーは特定の Attribute ないし Transaction に関わる IdP および RP を他より信頼しやすくなることもある. 例えばユーザーは (財務や健康など) 価値の高い Personal Information を持つ Web サイトにおいて Federated Identity を使うことをより躊躇うかもしれない. ユーザーが Personal Data をセンシティブだと認識している度合いによっては, ユーザーはソーシャルネットワークプロバイダーを IdP として使用することを快適に思わないかもしれない. 人々はしばしばソーシャルネットワーク実装がもつブロードキャストの性質を気にしがちである.

• ユーザーの目に留まる情報に関して, [SP800-63A], Sec. 9 が規定する Usability の考慮事項に従うこと.

• 技術的な支援を受ける方法とその場所を明確に伝えること. 例えばオンラインのセルフサービス機能へのリンク, チャット, ヘルプデスクサポートの電話番号などを提供することなどが考えられる. ユーザーが技術的な支援を受けるために関与する当事者間 (e.g., RP, IdP および Broker) をたらい回しにされる事態は避けること.

• 適切なコンテキストにおける代表的なユーザーと現実的なタスクを前提に, 統合的かつ継続的な Usalibity 評価を実施し, ユーザーの観点から Federated Identity System の成功を保証すること.

Specific Usability Considerations

本セクションでは Federated Identity System 固有の Usalibity に関する考慮事項に述べる. 本セクションは Federated Identity System に関する全ての Usability 要素を網羅しようとしているわけではない. むしろ, Usablity 文献におけるより大きく普遍的なテーマである, Federated Identity System に関連する Identity, ユーザーによる採用, 信頼および理解に対する, 主としてユーザー視点のテーマに焦点を当てている. 場合によっては実装例が示されることもある. しかしながら, 具体的な解決策が規定されるわけではない. 言及される実装は, 特定の Usability ニーズに対応するための革新的技術アプローチを促すための例に過ぎない. その他の例については, システム設計とコーディングの標準, 標準仕様, API 標準および現在のベストプラクティス (OpenID や OAuth など) を参照のこと. 実装例は, 1つで全てを解決する万能なソリューションを妨げるような, 多くの要因を含みがちであることに注意.

User Perspectives on Online Identity

ユーザーが Federated Identity System に慣れている場合でも, Federated Identity に対するアプローチは (特にブライバシーや情報共有という面で) さまざまであり, ユーザーのデータがどのように取り扱われるかについての確度の高い期待を確立する必要がある. ユーザーと実装者では Identity についての概念が異なる. ユーザーは Identity をログインして自身のプライベートスペースへの Access を得るものだと考えている. 実装者は Identity を Authenticator と Assertion, Assurance Level, およびサービス提供のための必須な Identity Attribute のセットの観点から考える. このユーザーと実装者の間の Identity に関する概念の違いを考慮すると, Federated Identity System における Identity の正確な概念をユーザーが理解できるようにすることが不可欠である. 良い Identity モデルは Federated System の利点とリスクを理解するための基盤をユーザーに提供し, ユーザーがこういったシステムを採用し信頼することを促すであろう.

Identity の多くの特性は, ユーザーが1つの Federation 内および複数の Federation 間でどのように Identity を管理するかに影響を与える. ユーザーは, サイバースペース外のコンテキストに基づき複数の Identity を管理しているように, Federated 環境でも自身の Identity を管理する術を学ばなければならない. 従って, Identity とコンテキストがどのように使われるのかがユーザーにとって明確である必要がある. ここでは以下のような項目を考慮するべきである.

• ユーザーに, 異なるユーザーロールを区別するために不可欠なコンテキストとスコープを提供する. 例えばユーザーが自信を代表して行動しているのか, 雇用主など別の誰かのの代理として行動しているのかなど.

• ユーザーに, 一意で意味のあるわかりやすい識別子を提供し, IdP, RP, Account などの主体を区別できるようにする. ユーザーが目にする識別子は, その下で動くプロトコル内で使用される通常ユーザーの目に触れることのない識別子に加えて使用される可能性がある.

• ユーザーに, データの所有権および変更を行う権限のある人に関する情報を提供する. Identity およびそれに紐づくデータは, 時には複数の関係者に更新, 変更されることがある. 例えば, 医療データは患者によって更新・所有されるものもあれば, 病院または医者によってのみ更新されるものもある.

• ユーザーに, Attribute を簡単に検証, 閲覧, 更新するすべを提供する. Identity およびユーザーロールは静的ではなく動的であるため, 時間経過によって変化しうる (e.g., 年齢, 医療情報, 財務情報). Attribute を更新したりその公開を決定する機能は同時に提供されることもあればされないこともある. ユーザーが Attribute を変更可能なプロセスが, 既知でドキュメント化されており容易に実行可能であることを保証すること.

• 関連する主体がもはや存在しない場合においても, ユーザーにデータを更新するすべを提供する.

• ユーザーに, 自身の Identity を完全に削除したり, 自身に関する情報を全て削除したりするすべを提供する. これには Transaction 履歴も含む. なお, このようなアクションを妨げる可能性のある監査, 法律ないしポリシー上の制約がないか考慮すること. 場合によっては削除よりも完全な非アクティブ化が適切である.

• ユーザーに, 明確で容易に発見可能なサイトデータ/アプリケーションデータ保持ポリシーに関する情報を提供すること.

• ユーザーに, 組織のデータアクセスポリシーに従って, 適切な匿名性および Pseudonymity のオプション, および必要に応じてそのような Identity オプションを切り替えるすべを提供する.

• ユーザーに, IdP から RP への接続を管理するすべを提供する. これには完全な分離や1つ以上の Attribute への RP の Access の削除などが含まれる.

User Perspectives of Trust and Benefits

多くの要因が, ユーザーによる Federated Identity System の採用に影響を与える可能性がある. あらゆるテクノロジーに対する場合と同じように, ユーザーはある要素を他より重視する可能性がある. ユーザーはしばしばテクノロジーの採用を決定する前に, 目に見えるメリットとリスクを比較検討する. IdP と RP がユーザーに十分な情報提供を行い, ユーザーが情報に基づいた決定を行えるようにすることが重要である. 信頼および信頼の層 (Federated Identity System の基本原則) はユーザーによる採用を促進しうる. 最後に, ポジティブなユーザーエクスペリエンスは Federation に対するユーザーの要求を増大させ, RP による採用増加も引き起こす可能性がある.

本セクションでは主にユーザーの信頼およびユーザー視点でのメリットとリスクについて述べる.

ユーザーによる採用を促進するため, IdP と RP はユーザーとの間に信頼を確立し, ユーザーがその採用にかかるメリットとデメリットを理解するように促す必要がある. ここでは以下のような項目を考慮するべきである.

• 適切な情報利用通知により, ユーザーが自身の情報開示を制御し明示的な同意提供を行えるようにする (Sec. 9.2 参照). ユーザーが無意識にクリックしてしまうことを防ぐため, 通知の内容, サイズ, 頻度のバランスを取ること.

• Attribute 共有に関しては以下を考慮すること.
  • ユーザーに, 共有される自身の Attribute および Attribute Value を検証するすべを提供する. 優れたセキュリティプラクティスに従うこと (Sec. 7.3 および Sec. 8 参照).
  • ユーザーが All-or-nothing ではなく Attribute リストの一部分にのみ同意できるようにすること. ユーザーが全ての情報共有に同意できない場合でも, ある程度のオンラインアクセスを可能にすること.
  • ユーザーが共有されている Attribute リストへの同意を更新できるようにすること.
  • ユーザーに提示される不必要な情報を最小化する. 例えば, たとえそれが RP に Authentication レスポンスの一環として共有されるとしても, システムによって生成された Attribute (Pairwise Pseudonymous Identifier など) は提示しないなど.
  • ユーザーのステップとナビゲーションを最小化する. 例えば, Attribute への同意をプロトコルに組み込み, Federated Transaction の外で実現される機能とはしないなど. そういった例は OAuth や OpenID Connect などの標準の中で見られる.
  • 効果的かつ効率的な是正方法を提供し, IdP が提供したり RP が収集した誤った Attribute 情報を是正できるようにすること.
  • ユーザーが Attribute 共有の際に要求される同意回数を最小化する. 同意要求の頻度を制限することで, 同じ Attribute を共有するための複数の要求に対するユーザーのフラストレーションを避けることができる.

• 限定された用途にのみ情報を収集し, 情報開示を最小化する (Sec. 9.3 参照). ユーザーの信頼は, 不必要で余分な情報収集や開示, 明示的なユーザー同意なしに行われるトラッキングなどにより損なわれる. 例えば, 現在の Transaction に関連する Attribute のみをユーザーに要求し, ユーザーが RP で取るか取らないかわからないような全ての Transaction で必要な Attribute に関しては要求しないなど.

• Federated Identity を利用する際の潜在的なメリットおよびリスクについて, 明確かつ誠意を持ってユーザーに伝える. ユーザーが重視するメリットとしては, 時間の節約, 使いやすさ, 管理する Password の数の削減, 利便性の向上などがあろう.

リスクに対するユーザーの懸念は, Federated Identity System の採用に係る意欲に悪影響を与える可能性がある. ユーザーは, 信頼に関する懸念, プライバシーに関する懸念, セキュリティに関する懸念, および単一障害点に関する懸念を持つ可能性がある. 例えば, ある1つの IdP が一時的または永続的に利用できない場合, ユーザーは複数の RP への Access を失うことを恐れるかもしれない. さらに, ユーザーは新しい Authentication プロセスを学ぶことに懸念を感じたり混乱する可能性もある. Federated Identity System の採用を促進するには, ユーザーの目に見えるメリットがユーザーの目に見えるリスクを上回る必要がある.

User Mental Models and Beliefs

ユーザーの信念と認識により, ユーザーは特定の結果を期待し, 特定の方法で行動する傾向がある. このような信念, 認識, 傾向は, 社会科学ではメンタルモデルと呼ばれる. 例えば, ファーストフードレストラン, カフェテリア, よりフォーマルなレストランなど, 人々は施設によって異なる外食のメンタルモデルを持ち, それにより彼らのふるまいや期待が導かれる. 従って, ある施設で適切にやりとりする方法を理解するために, 全ての個別の施設に精通している必要はない.

ユーザーが Federation に関する優れた完全なメンタルモデルを確立することで, ユーザーは単一かつ特定の実装を超えて一般化することができる. Federated Identity System がユーザー視点で設計されていなければ, ユーザーは不正確かつ不完全なメンタルモデルを形成し, それがユーザーによるシステムの採用意欲に影響を与えるかもしれない. ここでは以下のような項目を考慮するべきである.

• ユーザーの誤解を避けるため, やり取りを行う当事者間 (e.g., RP, IdP および Broker) の関係性や情報の流れを明確に説明する. その際は IdP や RP という一般的な用語ではなく, 当該主体の実際の名称を使用すること.
  • 一見無関係に見える主体がなぜ関係性を持っているのかをユーザーが理解できるように, 明確かつ視覚的なヒントや情報を提供する. 例えば, ユーザーは Federated Identity System における情報の流れを理解していないがために, オンラインでの個人的活動と政府のサービスが混ざることに懸念を抱く可能性がある.
  • RP がユーザーを自身のサイトから IdP にリダイレクトさせる必要がある場合, リダイレクトに関する明確かつ視覚的なヒントや情報を提供する. 例えば, IdP ユーザーインターフェース内に RP ブランドを表示し, ユーザーに当該 RP への Access のため IdP にログインしようとしていることを伝えるなど.

• ユーザーに, やり取りを行う当事者 (e.g., RP, IdP および Broker) の Authenticity (真正性) を判断するための明確で利用しやすい手段 (e.g., 視覚的保証など) を提供する. これは, 特にルートドメインが変わる場合 (e.g., .gov から .com へ) など, あるドメインから別のドメインに移動する際のユーザーの懸念を軽減する際にも役に立つものであろう. 例えば, IdP の URL を表示して, ユーザーが悪意あるサイトに Phishing されていないことを検証できるようにするなど.

• ユーザーに, 暗黙的なログインと明示的なログアウトに関して, 視覚的なヒントを含む明確な情報を提供する. 実装によっては, Federated Account を用いて RP にログインすると, ユーザーは IdP と RP 双方に Authenticate される可能性がある. ユーザーは RP で Session を終了しても IdP の Session が終了するとは限らないことに気づいていない場合がある. この場合, ユーザーは IdP から明示的に “ログアウト” する必要がある. ユーザーは IdP Session を終了するために明示的なログアウトが必要かどうか確認するための明確な情報を必要とする.

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 の機能への公平な Access は, Federated Identity System において不可欠な要素である. Federation 技術を使用する際も, Executive Order 13985, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government [EO13985] に定められている通り, 政府サービスへの公平なアクセスを提供するには, 全ての Subscriber が確実に Authenticate できることが必要である. Equity に関するリスクを評価する際, IdP と RP は Federated Identity Service の対象となるユーザー母集団全体を考慮する必要がある. さらに, IdP と RP はそれらのサービスを使用する際に, 共有される特性により不公平な Access, 取り扱い, 結果の対象となりうる母集団中の特定のユーザーグループをより一層認識することとなる. Sec. 10 で述べた Usability 上の考慮事項は, Federated Identity Service を使用する全ての人の全体的な使いやすさと Equity を担保するためにも考慮されるべきである.

Verifier としての役割を果たす中で, IdP は Identity Proofing, Attribute Validation および Enrollment に対する Equity に関する考慮事項 ([SP800-63A] Sec. 11 参照) および Authenticator に対する Equity に関する考慮事項 ([SP800-63B] Sec. 11 参照) を認識する必要がある. FAL3 を提供する RP は, Authenticator が IdP に管理されているか RP に管理されているかに関わらず, Bound Authenticator を処理する際にはこれと同じ Authenticator に関する考慮事項を認識する必要がある.

Federation プロセスは複数のアクティブな当事者間で Network プロトコルを介して行われるため, Federation System を利用した Authentication のエクスペリエンスには Equity の問題が生じ得る. 以下に例を示す.

• 地方に住んでいるなど, 信頼できる Network 接続を持たない Subscriber にとっては, タイムアウトせずに全体の Federated Transaction を完了させるのは困難かもしれない.
• 知的障害, 発達障害, 学習障害または神経認知障害のある Subscriber は, Attribute 開示に関する実行時決定の際に情報に基づく同意を行うことが困難な可能性もある.
• 十分な処理能力, Network Access および IdP と RP の両方と同時に対話するために必要なその他の機能を備えたシステムは, 一部の Subscriber にとっては購入が難しいかもしれない.
• デバイスを共有している Subscriber は, Allowlist ベースのシステムをセキュアに管理するのが難しいと感じる可能性もある. これは当該デバイスの他のユーザーが IdP でまだアクティブな Session を用いて RP への意図しない Access を黙って取得する可能性があるためである.
• さまざまな理由により IdP への Access を失った Subscriber にとって, RP でアカウントを再確立することは非常に困難な場合がある.

最も一般的であると予想されるこの分野の問題を軽減するため, IdP と RP には normative な要件が確立されている. しかし normative な要件が全ての潜在的な Equity の問題を想定済であるとは言いづらい. 潜在的な Equity の問題は, アプリケーション毎にも異なる. 従って, IdP と RP は Subscriber が不公平な Authentication 要件を報告し, 潜在的な代替の Authentication 戦略についてアドバイスを行えるようなメカニズムを提供する必要がある.

本ガイドラインは、追加の Federated Identifier を RP Subscriber Account に紐づけることを可能とし, これにより IdP への Access を失った際のリスクが最小化される (Sec. 5.4 参照). しかしながら, Subscriber は RP が受け入れることのできる複数の IdP アカウントを同時に持つことが困難である可能性もある. この不公平性は, RP が独自の Account Recovery プロセスを持ち, RP Subscriber Account と複数の Federated Identifier の紐付けをセキュアに追加・削除可能にすることにより対処可能である.

RP は全ての Subscriber が必ずしも同じ IdP への Access を持つとは限らないことを認識する必要がある. RP はそのような Subscriber に対してローカルで Authenticate された Account を作成し, 後でそれらの Account を Federated Identifier に紐づけることを可能にすることもできる.

Equity Considerations

This section is informative.

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.

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:

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

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.

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.

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.

以下では, SAML Assertion, Kerberos Ticket, OpenID Connect Token という3種類の Assertion 技術について述べる. このリストは考えうる全ての Assertion 技術を含むものではないが, Federated Identity System において一般的に使用されているものを示している.

Security Assertion Markup Language (SAML)

SAML はインターネットを介して信頼された主体間で Authentication および Attribute 情報を生成・交換するための, XML ベースのフレームワークである. 本稿執筆段階での SAML の最新仕様は2005年3月15日に発行された SAML 2.0 である.

SAML の構成要素は以下の通りである.

• Assertion XML Schema: Assertion の構造を定義する.
• SAML Protocol: Assertion および Artifact (Sec. 7.1 で述べた間接モデルで用いる Assertion Reference) を要求するために用いる.
• Binding: その下で用いるコミュニケーションプロトコル (HTTP や SOAP など) を定義し, SAML Assertion の転送に用いる.

上記3つの構成要素により SAML プロファイルが定義され, これらのプロファイルが “Web Browser SSO” などの特定のユースケースに対応する.

SAML Assertion は XML Schema でエンコードされ, 最大3つの Statement を伝搬可能である.

• Authentication Statement: Asseriton Issuer, Authenticated Subscriber, 有効期間およびその他の Authentication に関する情報を含む. 例えば, ある Authentication Assertion は Subscriber “John” が 2024-06-06 10:32pm に Password を用いて Authenticate されたことを表現できる.

• Attribute Statement: Subscriber に関する追加の特徴を含む. 例えば, Subject “John” に “Manager” という “Role” Attribute が関連づけられているなど.

• Authorization Statement: Subscriber が Access する権限を持つリソースを識別する. こういったリソースには特定のデバイス, ファイル, 特定の Web サーバー上の情報などが含まれうる. 例えば, Subject “John” が “Role” を証拠として “Webserver1002” 上の “Read” というアクションに対して権限を持つなど.

Authorization Statement は本ドキュメントのスコープ外であり, ここでは議論しない.

Kerberos Tickets

Kerberos Network Authentication Service [RFC4120] は, ローカルの共有 Network 上で, Symmetric Key Cryptography を用いて, Client/Server 形アプリケーションに対して強固な Authentication を提供するために設計されている. 拡張機能によって, Kerberos はプロトコル上の指定されたステップで Public Key Cryptography をサポートすることもできる. Kerberos は Subscriber と RP の間の Session データに関して Confidentiality (機密性) 保護および Integrity (完全性) 保護をサポートすることもできる. Kerberos は Assertion を利用するが, これは共有 Network 上での利用を想定して設計されたものであり, 真の Federation Protocol ではない.

Kerberos は1つ以上の IdP を用いた Network 経由の Subscriber Authentication をサポートする. Subscriber は, IdP が Subscriber に対して暗号化したランダムな Session Key を復号できることを示すことで, 暗黙的に IdP に Authenticate される. (一部の Kerberos 派生系は Subscriber が IdP に対して明示的に Authenticate することを要求するが, これは一般的ではない) 暗号化された Session Key に加え, IdP はその他の暗号化されたオブジェクトも生成する. これは Kerberos Ticket と呼ばれる. この Ticket は同じ Session Key, Session Key を発行された Subscriber の Identity, Session Key の有効期限を含む. この Ticket は, 明示的なセットアップフェーズ中に IdP-RP 間で共有される事前確立鍵により Confidentiality (機密性) 保護および Integrity (完全性) 保護を施される.

Session Key を利用して Authenticate するには, Subscriber は Ticket を RP に送り, それに Subscriber が Kerberos Ticket 内に含まれた Session Key を保持することを証明する暗号化されたデータを添える. Session Key は新しい Ticket の生成に用いられることもあれば, Subscriber と RP の間の通信を暗号化および Authenticate するために用いられることもある.

このプロセスを開始するにあたり, Subscriber は Authentication リクエストを Authentication Server (AS) に送る. AS は Subscriber の長時間有効な Credential を用いて Subscriber の Session Key を暗号化する. この長期間有効な Credential は AS と Subscriber 間で共有された Secret Key であることもあれば, Kerberos の PKINIT 相当のものに含まれる Public Key Certificate であることもある. Subscriber と IdP の間の Shared Secret Key に基づいている大抵の Kerberos 派生系は, ユーザーが生成した Password からこの Key を導出する. そのため, Flexible Authentication Secure Tunneling (FAST) [RFC6113] やその他のトンネリングおよび防御メカニズムが採用されていない限り, パッシブな盗聴者によるオフライン辞書攻撃に対して脆弱である.

Session Key の Subscriber への配送に加え, AS は Ticket Granting Server (TGS) と共有する鍵を使って Ticket を発行する. この Ticket は Ticket Granting Ticket (TGT) と呼ばれる. これは, Verifier が TGT 内の Session Key を用いて Authenticate するかわりに Ticket を発行するからである. TGS は TGT 内の Session Key を用いて新たな Session Key を Subscriber に対して暗号化し, RP と共有する鍵を用いて新たな Session Key に対応する Ticket を生成する. Subscriber は Session Key を復号し, Ticket と新たな Session Key を使って RP に対して Authenticate を行う.

Kerberos Authentication が Password に基づいている場合, このプロトコルは最初のユーザーと KDC の交換を盗聴する盗聴者によるオフライン辞書 Attack に脆弱であることが知られている. この脆弱性は長く複雑な Password により軽減されるが, 十分に長い Password はユーザーにとって扱いにくい傾向がある. ただし, Password ベースの Kerberos Authentication が FAST (または類似の) トンネル内で用いられている場合, 辞書攻撃を実行するには中間者攻撃を成功させることも必要になる.

OpenID Connect

OpenID Connect は, OAuth 2.0 Authorization Framework および JSON Object Signing and Encryption (JOSE) Cryptographic System に基づいた, インターネットスケールの Federated Identity & Authentication Protocol である.

OpenID Connect は OAuth 2.0 Authorization Protocol の上に構築され, Subscriber が RP に対して Subscriber Identity および Authentication 情報に Access することを Authorize 可能にする. OpenID Connect および OAuth 2.0 における RP は Client とも呼ばれる.

OpenID Connect Transaction 成功時, IdP は ID Token を発行する. これは JSON Web Token (JWT) 形式の署名付き Assertion である. Client は ID Token をパースし, Subscriber および IdP におけるプライマリな Authentication Event についての情報を得る. このトークンは最低限以下のような Subscriber および Authentication Event に関する情報を含む.

• iss - Assertion を発行した IdP を識別する HTTPS URL.
• sub - Subscriber を示す, IdP 固有の Subject Identifier.
• aud - IdP 固有の Audience Identifier. 当該 Client の IdP における OAuth 2.0 Client Identifier と等しい.
• exp - ID Token が期限切れになるタイムスタンプ. Client はこれ以降にこの ID Token を受け入れてはならない (SHALL NOT).
• iat - ID Token が発行されたタイムスタンプ. Client はこれ以前にこの ID Token を受け入れてはならない (SHALL NOT).

ID Token に加え, IdP は Client に OAuth 2.0 Access Token を発行することもできる. これは IdP の UserInfo Endpoint への Access に利用できる. この Endpoint は Subscriber に関する Attribute セットを表現する JSON Object を返す. 返される Attribute には, 氏名, Email Address, 住所, 電話番号およびその他のプロフィール情報が含まれるが, それに限るものでもない. ID Token に含まれる情報は Authentication Event を反映している一方, UserInfo Endpoint から返される情報は一般的にはより永続的でより一般的な目的で利用される. UserInfo Endpoint から返される Attribute への Access は, Attribute 毎に特別に定義された openid, profile, email, phone および address といった OAuth Scope のセットにより決定される. offline_access という追加の Scope もあり, これは Refresh Token の発行を制御するために用いられる. RP は Subscriber が介在しない時でも Refresh Token を使って UserInfo Endpoint への Access を行うことができる. UserInfo Endpoint への API として実現されており, Subscriber が介在しない場合でも利用できる可能性がある. 従って UserInfo Endpoint への Access を持つからといって, Subscriber の存在証明や RP における Authenticated Session の確立には不十分である.

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.

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.

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

Changelog

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

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