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

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 の源泉として用いることも可能となる.

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

Definitions and Abbreviations

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

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

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

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 とライセンスレコードとの間に強力な関連付けを行うことができる.

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

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

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

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 を終了するために明示的なログアウトが必要かどうか確認するための明確な情報を必要とする.

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 に紐づけることを可能にすることもできる.

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 の確立には不十分である.

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.