NIST PIV and digital identity SP 800-63C-4

Controls in this version
Ref	Title	Text
1	Introduction	This section is informative. Federation is the process of authenticating a subscriber to a relying party (RP) without the RP directly verifying the subscriber’s authenticators. An identity provider (IdP) makes the subscriber account define	changed here
1.1 in 1	Notations	This guideline uses the following typographical conventions in text: • Specific terms in CAPITALS represent normative requirements. When these same terms are not in CAPITALS , the term does not represent a normative requirement. – The ter	changed here
1.1.1 in 1.1	Cryptographic Terminology	In these guidelines, assertions, attribute bundles, and other elements of the federation protocol are verified by an asymmetric digital signature or a symmetric message authentication code (MAC). When either asymmetric or symmetric cryptogr	changed here
1.2 in 1	Document Structure	This document is organized as follows. Each section is labeled as either normative (i.e., mandatory for compliance) or informative (i.e., not mandatory). • Section 1 introduces the document. This section is informative . • Section 2 descr	changed here
2	Federation Assurance Level (FAL)	This section is normative. This section defines federation assurance levels (FALs) and the requirements for securing federation transactions at each FAL. In order to fulfill the requirements for a given FAL, the federation transaction SHAL	changed here
2.1 in 2	Common FAL Requirements	If no FAL is specified by the trust agreement or federation transaction, the requirements of this section still apply. At all FALs, all federation transactions SHALL comply with the requirements in Sec. 3 to deliver an assertion to the RP	changed here
2.2 in 2	Federation Assurance Level 1 (FAL1)	FAL1 provides a basic level of protection for federation transactions and allows for a wide range of use cases and deployment decisions. At FAL1, the federation protocol SHOULD apply assertion injection protection, as discussed in Sec. 3.1	changed here
2.3 in 2	Federation Assurance Level 2 (FAL2)	FAL2 provides a high level of protection for federation transactions by requiring additional protections against a variety of attacks on federated systems, including attempts to inject assertions into a federated transaction. All of the req	changed here
2.4 in 2	Federation Assurance Level 3 (FAL3)	FAL3 provides a very high level of protection for federation transactions and establishes very high confidence that the information communicated in the federation transaction matches what was established by the CSP and IdP. FAL3 also protec	changed here
2.5 in 2	Requesting and Processing xALs	Since an IdP is capable of asserting the identities of many different subscribers with a variety of authenticators using a variety of federation parameters, the IAL, AAL, and FAL could vary across different federation transactions, even to	changed here
3	Common Federation Requirements	This section is normative. A federation transaction allows the subscriber to establish an authenticated session with the RP based on a subscriber account known to the IdP. The federation transaction can also provide the RP with a set of id	changed here
3.1 in 3	Federation Models	These guidelines provide requirements for two models of federation: general-purpose IdPs and subscriber-controlled wallets. Subscriber-controlled wallets can in turn be hosted on a device that is controlled by the subscriber or on a remote-	changed here
3.2 in 3	Roles		changed here
3.2.1 in 3.2	Credential Service Provider (CSP)	The CSP collects and verifies attributes from the subscriber and stores them in a subscriber account. The CSP also binds one or more authenticators to the subscriber account and allows the subscriber to directly authenticate to systems capa	changed here
3.2.2 in 3.2	Identity Provider (IdP)	The IdP provides a bridge between the subscriber account (as established by the CSP) and the RP that the subscriber is accessing. An IdP can be deployed as a service for multiple subscriber accounts or as a component controlled by a single	changed here
3.2.3 in 3.2	Relying Party (RP)	The RP processes assertions from the IdP and provides the service that the subscriber is trying to access. Unlike in a direct authentication model, the RP does not provide the verifier function to authenticators that are tied to the subscri	changed here
3.3 in 3	Functions		changed here
3.3.1 in 3.3	Trust Agreement Management	The trust agreement that defines the terms for a federated transaction (see Sec. 3.5 ) can be directly established and managed by the parties involved, such as an RP and IdP making a pairwise agreement to connect with each other or a subscr	changed here
3.3.2 in 3.3	Authorized Party	The authorized party in a trust agreement is the organization, person, or entity that is responsible for the specific release decisions covered by the trust agreement, including the release of subscriber attributes. The trust agreement stip	changed here
3.3.3 in 3.3	Proxied Federation	In some architectures, the IdP and RP do not communicate directly with each other. A federation proxy acts as an intermediary between the IdP and RP for all communication in the federation protocol. The proxy functions as an RP on the upstr	changed here
3.3.4 in 3.3	Fulfilling Roles and Functions of a Federation Model	The roles in a federation transaction can be connected in a variety of ways, but several common patterns are anticipated by these guidelines. The expected trust agreement structure and connection between components will vary based on which	changed here
3.4 in 3	Federated Identifiers	The subscriber is identified in the federation transaction by information in the assertion, which allows the RP to associate the assertion with an RP subscriber account. This identification can happen through an account resolution process (	changed here
3.4.1 in 3.4	Pairwise Pseudonymous Identifiers (PPI)	In some circumstances, it is desirable to prevent the subscriber account from being easily linked at multiple RPs through the use of a common subject identifier. A pairwise pseudonymous identifier (PPI) allows an IdP to provide multiple dis	changed here
3.4.1.1 in 3.4.1	General Requirements	When using pairwise pseudonymous identifiers within the assertions generated by the IdP for the RP, the IdP SHALL generate a different federated identifier for each RP (see Sec. 3.4.1.2 ) or set of RPs (see Sec. 3.4.1.3 ). Some identity at	changed here
3.4.1.2 in 3.4.1	Pairwise Pseudonymous Identifier Generation	The PPI SHALL contain no identifying information about the subscriber (e.g., username, email address, employee number). The PPI SHALL be difficult to guess by a party with access to information about the subscriber and SHALL provide suffici	changed here
3.4.1.3 in 3.4.1	Shared Pairwise Pseudonymous Identifiers	The same shared PPI SHALL be used for a specific set of RPs if all of the following criteria are met: • The trust agreement stipulates a shared PPI for a specific set of RPs. • The authorized party consents to and is notified of the use o	changed here
3.5 in 3	Trust Agreements	Trust agreements are a construct that represent the set of trust relationships established to support parties in a federation transaction. A trust agreement SHALL address one or more of the following relationships: IdP to CSP: The IdP trust	changed here
3.5.1 in 3.5	Bilateral Trust Agreements	In a bilateral trust agreement, the establishment of the trust agreement occurs directly between the federated parties, and the trust agreement is not managed or facilitated by a separate party. Bilateral trust agreements allow for a point-	changed here
3.5.2 in 3.5	Multilateral Trust Agreements	In a multilateral trust agreement, the federated parties look to a federation authority to assist in establishing the trust agreement between parties. In this model, the federation authority facilitates the inclusion of CSPs, IdPs, and RPs	changed here
3.5.3 in 3.5	Redress Requirements	Federation transactions occur between multiple parties that are often controlled by multiple entities, and different stages of the federation transaction can lead to situations in which a subscriber would need to seek redress from the other	changed here
3.6 in 3	Identifiers and Cryptographic Key Management for CSPs, IdPs, and RPs	While a trust agreement establishes permission to federate, it does not facilitate the secure connection of parties in the federation. In order to communicate over a federation protocol, the CSP, IdP, and RP need to be able to identify each	changed here
3.6.1 in 3.6	Cryptographic Key Rotation	Over time, it can be desirable or necessary to update the cryptographic key associated with a CSP, IdP, or RP. The allowable update process for any identifiers and cryptographic keys SHALL be defined by the trust agreement and SHALL be exec	changed here
3.6.2 in 3.6	Cryptographic Key Storage	CSPs, IdPs (including subscriber-controlled wallets), and RPs SHALL store all signing keys, decryption keys, and symmetric keys in a secure fashion. Cryptographic key storage is subject to applicable [FIPS140] requirements, including applic	changed here
3.6.3 in 3.6	Software Attestations	Software and device attestations can augment the establishment of identifiers and cryptographic keys, especially in dynamic and distributed systems. Attestations in this usage are cryptographically bound statements that a particular piece o	changed here
3.7 in 3	Authentication and Attribute Disclosure	Once the IdP and RP have entered into a trust agreement and completed registration, the federation protocol can be used to pass subscriber attributes from the IdP to the RP. A subscriber’s identity attributes SHALL only be transmitted betwe	changed here
3.8 in 3	RP Subscriber Accounts	An RP typically keeps a record known as the RP subscriber account to locally represent a subscriber. The RP subscriber account can contain things like access rights at the RP as well as a cache of identity attributes for the subscriber. The	changed here
3.8.1 in 3.8	Account Linking	A single RP subscriber account MAY be associated with more than one federated identifier. This practice is sometimes known as account linking . If the RP allows a subscriber to link multiple subscriber accounts in this way, the RP SHALL req	changed here
3.8.2 in 3.8	Account Resolution	If the RP has access to existing information about a set of subscribers, and this information is not associated with a federated identifier, the RP performs a process known as account resolution to determine which set of subscriber informat	changed here
3.8.3 in 3.8	Alternative Authentication Processes	The RP MAY allow a subscriber to access their RP subscriber account using direct authentication processes by allowing the subscriber to add and remove authenticators in the RP subscriber account. The RP SHALL follow the requirements in [SP8	changed here
3.9 in 3	Authenticated Sessions at the RP	The ultimate goal of a federation transaction is to create an authenticated session between the subscriber and the RP that is backed by a verified assertion from the IdP. This authenticated session can be used for allowing the subscriber ac	changed here
3.10 in 3	Privacy Requirements	The goal of a subscriber is to interact with and use the RP. Federation involves the transfer of personal attributes from the IdP, a party that is not involved during direct authentication to an RP. Federation also potentially gives the IdP	changed here
3.10.1 in 3.10	Transmitting Subscriber Information	The IdP SHALL limit the transmission of subscriber information to only that which is necessary for the system to function and is stipulated and disclosed by the trust agreement. These functions include the following: • Identity proofing, a	changed here
3.10.2 in 3.10	Sharing Information Between CSPs	In some larger federation systems, particularly multilateral federations managed by federation authorities, there can be multiple CSPs involved in the same trust agreement. In such cases, it could be desirable for CSPs to share information	changed here
3.11 in 3	Security Controls	IdPs and CSPs SHALL employ appropriately tailored security controls from at least the moderate baseline security controls defined in [SP800-53] or an equivalent federal (e.g., [FEDRAMP] ) or industry standard that the organization has deter	changed here
3.11.1 in 3.11	Protection From Assertion Injection Attacks	An assertion injection attack in the context of a federated protocol consists of an attacker attempting to force an RP to accept or process an assertion or assertion reference in order to gain access to the RP or deny a legitimate subscribe	changed here
3.11.2 in 3.11	Protecting Subscriber Information	Communications between the IdP and the RP SHALL be protected in transit using an authenticated protected channel. Communications between the subscriber and either the IdP or the RP (usually through a user agent) SHALL be made using an authe	changed here
3.11.3 in 3.11	Storing Subscriber Information	Whether the account is active or not, the IdP and RP SHALL store personal information in a subscriber account or RP subscriber account using tailored security controls defined in [SP800-53] or an equivalent federal (e.g., [FEDRAMP] ) or ind	changed here
3.12 in 3	Identity Attributes	Identity attributes that represent the subscriber are sent to the RP during a federation transaction. These attributes take on multiple aspects that can be combined in different ways. Bundling: Attributes SHALL be either unbundled (i.e., pr	changed here
3.12.1 in 3.12	Attribute Bundles	Other protocols and specifications often refer to attribute bundles as credentials . However, this term would be in conflict with its use within these guidelines for a different concept. Consequently, these guidelines use the term “attribut	changed here
3.12.2 in 3.12	Derived Attribute Values	For some use cases, knowing the actual value of an identity attribute is not strictly necessary for the RP to function, and a value derived from the identity attribute is sufficient. For example, if the RP needs to know whether the subscrib	changed here
3.12.3 in 3.12	Identity APIs	Attributes about the subscriber, including profile information, MAY be provided to the RP through a protected API known as the identity API . The RP is granted limited access to the identity API during the federation transaction in concert	changed here
3.12.3.1 in 3.12.3	External Identity APIs	While most identity APIs used in federation protocols are hosted as part of the IdP, it is also possible for the IdP to grant the RP access to external identity APIs that are hosted outside of the IdP. External identity APIs are normally pr	changed here
3.13 in 3	Assertion Protection	Assertions SHALL include a set of protections to prevent attackers from manufacturing valid assertions or reusing captured assertions at different RPs. The required protections depend on the details of the use case being considered, and spe	changed here
3.13.1 in 3.13	Assertion Identifier	Assertions SHALL be sufficiently unique to permit unique identification by the target RP. Assertions MAY accomplish this by using an embedded nonce, issuance timestamp, assertion identifier, or a combination of these or other techniques.	changed here
3.13.2 in 3.13	Signed Assertion	Assertions SHALL be cryptographically signed by the issuer (IdP). The RP SHALL validate the digital signature or MAC of each such assertion based on the issuer’s verification key. This signature SHALL cover the entire assertion, including i	changed here
3.13.3 in 3.13	Encrypted Assertion	The contents of the assertion can be encrypted to protect against exposing sensitive information to untrusted third parties, such as a user agent. This protection is especially relevant when the assertion contains personal information about	changed here
3.13.4 in 3.13	Audience Restriction	Assertions SHALL use audience restriction techniques to allow an RP to recognize whether it is the intended target of an issued assertion. All RPs SHALL check that the audience of an assertion contains an identifier for their RP to prevent	changed here
3.14 in 3	Bearer Assertions	A bearer assertion can be presented on its own as proof of the identity of the party presenting it. No other proof beyond validation of the assertion is required. Similarly, a bearer assertion reference can be presented on its own to the RP	changed here
3.15 in 3	Holder-of-Key Assertions	A holder-of-key assertion ( Fig. 3 ) SHALL include a unique identifier for an authenticator that can be verified independently by the RP, such as the public key of a certificate controlled by the subscriber. The RP SHALL verify that the sub	changed here
3.16 in 3	Bound Authenticators	A bound authenticator ( Fig. 4 ) is an authenticator that is bound to the RP subscriber account and managed by the RP. The IdP SHALL include an indicator in the assertion when the assertion is to be used with a bound authenticator at FAL3.	changed here
3.16.1 in 3.16	RP-Provided Bound Authenticator Issuance	For RP-provided authenticators, the system administrator of the RP SHALL issue the authenticator directly to the subscriber for use with an FAL3 federation transaction. The system administrator of the RP SHALL use an independent means to de	changed here
3.16.2 in 3.16	Subscriber-Provided Bound Authenticator Binding Ceremony	The RP MAY provide a process for associating subscriber-provided authenticators to the RP subscriber account on a trust-on-first-use basis. This process is known as a binding ceremony and has additional requirements beyond a typical FAL3 fe	changed here
3.17 in 3	RP Processing of Holder-of-Key Assertions and Bound Authenticators	When the RP receives an assertion that is associated with a bound authenticator, the subscriber proves possession of the bound authenticator directly to the RP. The primary authentication at the IdP and the federated authentication at the R	changed here
4	Validity time window: A period of time outside of which the assertion SHALL NOT	be accepted as valid by the RP for the purposes of authenticating the subscriber and starting an authenticated session at the RP. This is usually communicated by means of an expiration timestamp for the assertion in addition to the issuance	changed here

Introduction

This section is informative. Federation is the process of authenticating a subscriber to a relying party (RP) without the RP directly verifying the subscriber’s authenticators. An identity provider (IdP) makes the subscriber account define

changed here

1.1

in 1

Notations

This guideline uses the following typographical conventions in text: • Specific terms in CAPITALS represent normative requirements. When these same terms are not in CAPITALS , the term does not represent a normative requirement. – The ter

changed here

1.1.1

in 1.1

Cryptographic Terminology

In these guidelines, assertions, attribute bundles, and other elements of the federation protocol are verified by an asymmetric digital signature or a symmetric message authentication code (MAC). When either asymmetric or symmetric cryptogr

changed here

1.2

in 1

Document Structure

This document is organized as follows. Each section is labeled as either normative (i.e., mandatory for compliance) or informative (i.e., not mandatory). • Section 1 introduces the document. This section is informative . • Section 2 descr

changed here

2

Federation Assurance Level (FAL)

This section is normative. This section defines federation assurance levels (FALs) and the requirements for securing federation transactions at each FAL. In order to fulfill the requirements for a given FAL, the federation transaction SHAL

changed here

2.1

in 2

Common FAL Requirements

If no FAL is specified by the trust agreement or federation transaction, the requirements of this section still apply. At all FALs, all federation transactions SHALL comply with the requirements in Sec. 3 to deliver an assertion to the RP

changed here

2.2

in 2

Federation Assurance Level 1 (FAL1)

FAL1 provides a basic level of protection for federation transactions and allows for a wide range of use cases and deployment decisions. At FAL1, the federation protocol SHOULD apply assertion injection protection, as discussed in Sec. 3.1

changed here

2.3

in 2

Federation Assurance Level 2 (FAL2)

FAL2 provides a high level of protection for federation transactions by requiring additional protections against a variety of attacks on federated systems, including attempts to inject assertions into a federated transaction. All of the req

changed here

2.4

in 2

Federation Assurance Level 3 (FAL3)

FAL3 provides a very high level of protection for federation transactions and establishes very high confidence that the information communicated in the federation transaction matches what was established by the CSP and IdP. FAL3 also protec

changed here

2.5

in 2

Requesting and Processing xALs

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

changed here

3

Common Federation Requirements

This section is normative. A federation transaction allows the subscriber to establish an authenticated session with the RP based on a subscriber account known to the IdP. The federation transaction can also provide the RP with a set of id

changed here

3.1

in 3

Federation Models

These guidelines provide requirements for two models of federation: general-purpose IdPs and subscriber-controlled wallets. Subscriber-controlled wallets can in turn be hosted on a device that is controlled by the subscriber or on a remote-

changed here

3.2

in 3

Roles

changed here

3.2.1

in 3.2

Credential Service Provider (CSP)

The CSP collects and verifies attributes from the subscriber and stores them in a subscriber account. The CSP also binds one or more authenticators to the subscriber account and allows the subscriber to directly authenticate to systems capa

changed here

3.2.2

in 3.2

Identity Provider (IdP)

The IdP provides a bridge between the subscriber account (as established by the CSP) and the RP that the subscriber is accessing. An IdP can be deployed as a service for multiple subscriber accounts or as a component controlled by a single

changed here

3.2.3

in 3.2

Relying Party (RP)

The RP processes assertions from the IdP and provides the service that the subscriber is trying to access. Unlike in a direct authentication model, the RP does not provide the verifier function to authenticators that are tied to the subscri

changed here

3.3

in 3

Functions

changed here

3.3.1

in 3.3

Trust Agreement Management

The trust agreement that defines the terms for a federated transaction (see Sec. 3.5 ) can be directly established and managed by the parties involved, such as an RP and IdP making a pairwise agreement to connect with each other or a subscr

changed here

3.3.2

in 3.3

Authorized Party

The authorized party in a trust agreement is the organization, person, or entity that is responsible for the specific release decisions covered by the trust agreement, including the release of subscriber attributes. The trust agreement stip

changed here

3.3.3

in 3.3

Proxied Federation

In some architectures, the IdP and RP do not communicate directly with each other. A federation proxy acts as an intermediary between the IdP and RP for all communication in the federation protocol. The proxy functions as an RP on the upstr

changed here

3.3.4

in 3.3

Fulfilling Roles and Functions of a Federation Model

The roles in a federation transaction can be connected in a variety of ways, but several common patterns are anticipated by these guidelines. The expected trust agreement structure and connection between components will vary based on which

changed here

3.4

in 3

Federated Identifiers

The subscriber is identified in the federation transaction by information in the assertion, which allows the RP to associate the assertion with an RP subscriber account. This identification can happen through an account resolution process (

changed here

3.4.1

in 3.4

Pairwise Pseudonymous Identifiers (PPI)

In some circumstances, it is desirable to prevent the subscriber account from being easily linked at multiple RPs through the use of a common subject identifier. A pairwise pseudonymous identifier (PPI) allows an IdP to provide multiple dis

changed here

3.4.1.1

in 3.4.1

General Requirements

When using pairwise pseudonymous identifiers within the assertions generated by the IdP for the RP, the IdP SHALL generate a different federated identifier for each RP (see Sec. 3.4.1.2 ) or set of RPs (see Sec. 3.4.1.3 ). Some identity at

changed here

3.4.1.2

in 3.4.1

Pairwise Pseudonymous Identifier Generation

The PPI SHALL contain no identifying information about the subscriber (e.g., username, email address, employee number). The PPI SHALL be difficult to guess by a party with access to information about the subscriber and SHALL provide suffici

changed here

3.4.1.3

in 3.4.1

Shared Pairwise Pseudonymous Identifiers

The same shared PPI SHALL be used for a specific set of RPs if all of the following criteria are met: • The trust agreement stipulates a shared PPI for a specific set of RPs. • The authorized party consents to and is notified of the use o

changed here

3.5

in 3

Trust Agreements

Trust agreements are a construct that represent the set of trust relationships established to support parties in a federation transaction. A trust agreement SHALL address one or more of the following relationships: IdP to CSP: The IdP trust

changed here

3.5.1

in 3.5

Bilateral Trust Agreements

In a bilateral trust agreement, the establishment of the trust agreement occurs directly between the federated parties, and the trust agreement is not managed or facilitated by a separate party. Bilateral trust agreements allow for a point-

changed here

3.5.2

in 3.5

Multilateral Trust Agreements

In a multilateral trust agreement, the federated parties look to a federation authority to assist in establishing the trust agreement between parties. In this model, the federation authority facilitates the inclusion of CSPs, IdPs, and RPs

changed here

3.5.3

in 3.5

Redress Requirements

Federation transactions occur between multiple parties that are often controlled by multiple entities, and different stages of the federation transaction can lead to situations in which a subscriber would need to seek redress from the other

changed here

3.6

in 3

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

While a trust agreement establishes permission to federate, it does not facilitate the secure connection of parties in the federation. In order to communicate over a federation protocol, the CSP, IdP, and RP need to be able to identify each

changed here

3.6.1

in 3.6

Cryptographic Key Rotation

Over time, it can be desirable or necessary to update the cryptographic key associated with a CSP, IdP, or RP. The allowable update process for any identifiers and cryptographic keys SHALL be defined by the trust agreement and SHALL be exec

changed here

3.6.2

in 3.6

Cryptographic Key Storage

CSPs, IdPs (including subscriber-controlled wallets), and RPs SHALL store all signing keys, decryption keys, and symmetric keys in a secure fashion. Cryptographic key storage is subject to applicable [FIPS140] requirements, including applic

changed here

3.6.3

in 3.6

Software Attestations

Software and device attestations can augment the establishment of identifiers and cryptographic keys, especially in dynamic and distributed systems. Attestations in this usage are cryptographically bound statements that a particular piece o

changed here

3.7

in 3

Authentication and Attribute Disclosure

Once the IdP and RP have entered into a trust agreement and completed registration, the federation protocol can be used to pass subscriber attributes from the IdP to the RP. A subscriber’s identity attributes SHALL only be transmitted betwe

changed here

3.8

in 3

RP Subscriber Accounts

An RP typically keeps a record known as the RP subscriber account to locally represent a subscriber. The RP subscriber account can contain things like access rights at the RP as well as a cache of identity attributes for the subscriber. The

changed here

3.8.1

in 3.8

Account Linking

A single RP subscriber account MAY be associated with more than one federated identifier. This practice is sometimes known as account linking . If the RP allows a subscriber to link multiple subscriber accounts in this way, the RP SHALL req

changed here

3.8.2

in 3.8

Account Resolution

If the RP has access to existing information about a set of subscribers, and this information is not associated with a federated identifier, the RP performs a process known as account resolution to determine which set of subscriber informat

changed here

3.8.3

in 3.8

Alternative Authentication Processes

The RP MAY allow a subscriber to access their RP subscriber account using direct authentication processes by allowing the subscriber to add and remove authenticators in the RP subscriber account. The RP SHALL follow the requirements in [SP8

changed here

3.9

in 3

Authenticated Sessions at the RP

The ultimate goal of a federation transaction is to create an authenticated session between the subscriber and the RP that is backed by a verified assertion from the IdP. This authenticated session can be used for allowing the subscriber ac

changed here

3.10

in 3

Privacy Requirements

The goal of a subscriber is to interact with and use the RP. Federation involves the transfer of personal attributes from the IdP, a party that is not involved during direct authentication to an RP. Federation also potentially gives the IdP

changed here

3.10.1

in 3.10

Transmitting Subscriber Information

The IdP SHALL limit the transmission of subscriber information to only that which is necessary for the system to function and is stipulated and disclosed by the trust agreement. These functions include the following: • Identity proofing, a

changed here

3.10.2

in 3.10

Sharing Information Between CSPs

In some larger federation systems, particularly multilateral federations managed by federation authorities, there can be multiple CSPs involved in the same trust agreement. In such cases, it could be desirable for CSPs to share information

changed here

3.11

in 3

Security Controls

IdPs and CSPs SHALL employ appropriately tailored security controls from at least the moderate baseline security controls defined in [SP800-53] or an equivalent federal (e.g., [FEDRAMP] ) or industry standard that the organization has deter

changed here

3.11.1

in 3.11

Protection From Assertion Injection Attacks

An assertion injection attack in the context of a federated protocol consists of an attacker attempting to force an RP to accept or process an assertion or assertion reference in order to gain access to the RP or deny a legitimate subscribe

changed here

3.11.2

in 3.11

Protecting Subscriber Information

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

changed here

3.11.3

in 3.11

Storing Subscriber Information

Whether the account is active or not, the IdP and RP SHALL store personal information in a subscriber account or RP subscriber account using tailored security controls defined in [SP800-53] or an equivalent federal (e.g., [FEDRAMP] ) or ind

changed here

3.12

in 3

Identity Attributes

Identity attributes that represent the subscriber are sent to the RP during a federation transaction. These attributes take on multiple aspects that can be combined in different ways. Bundling: Attributes SHALL be either unbundled (i.e., pr

changed here

3.12.1

in 3.12

Attribute Bundles

Other protocols and specifications often refer to attribute bundles as credentials . However, this term would be in conflict with its use within these guidelines for a different concept. Consequently, these guidelines use the term “attribut

changed here

3.12.2

in 3.12

Derived Attribute Values

For some use cases, knowing the actual value of an identity attribute is not strictly necessary for the RP to function, and a value derived from the identity attribute is sufficient. For example, if the RP needs to know whether the subscrib

changed here

3.12.3

in 3.12

Identity APIs

Attributes about the subscriber, including profile information, MAY be provided to the RP through a protected API known as the identity API . The RP is granted limited access to the identity API during the federation transaction in concert

changed here

3.12.3.1

in 3.12.3

External Identity APIs

While most identity APIs used in federation protocols are hosted as part of the IdP, it is also possible for the IdP to grant the RP access to external identity APIs that are hosted outside of the IdP. External identity APIs are normally pr

changed here

3.13

in 3

Assertion Protection

Assertions SHALL include a set of protections to prevent attackers from manufacturing valid assertions or reusing captured assertions at different RPs. The required protections depend on the details of the use case being considered, and spe

changed here

3.13.1

in 3.13

Assertion Identifier

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

changed here

3.13.2

in 3.13

Signed Assertion

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

changed here

3.13.3

in 3.13

Encrypted Assertion

The contents of the assertion can be encrypted to protect against exposing sensitive information to untrusted third parties, such as a user agent. This protection is especially relevant when the assertion contains personal information about

changed here

3.13.4

in 3.13

Audience Restriction

Assertions SHALL use audience restriction techniques to allow an RP to recognize whether it is the intended target of an issued assertion. All RPs SHALL check that the audience of an assertion contains an identifier for their RP to prevent

changed here

3.14

in 3

Bearer Assertions

A bearer assertion can be presented on its own as proof of the identity of the party presenting it. No other proof beyond validation of the assertion is required. Similarly, a bearer assertion reference can be presented on its own to the RP

changed here

3.15

in 3

Holder-of-Key Assertions

A holder-of-key assertion ( Fig. 3 ) SHALL include a unique identifier for an authenticator that can be verified independently by the RP, such as the public key of a certificate controlled by the subscriber. The RP SHALL verify that the sub

changed here

3.16

in 3

Bound Authenticators

A bound authenticator ( Fig. 4 ) is an authenticator that is bound to the RP subscriber account and managed by the RP. The IdP SHALL include an indicator in the assertion when the assertion is to be used with a bound authenticator at FAL3.

changed here

3.16.1

in 3.16

RP-Provided Bound Authenticator Issuance

For RP-provided authenticators, the system administrator of the RP SHALL issue the authenticator directly to the subscriber for use with an FAL3 federation transaction. The system administrator of the RP SHALL use an independent means to de

changed here

3.16.2

in 3.16

Subscriber-Provided Bound Authenticator Binding Ceremony

The RP MAY provide a process for associating subscriber-provided authenticators to the RP subscriber account on a trust-on-first-use basis. This process is known as a binding ceremony and has additional requirements beyond a typical FAL3 fe

changed here

3.17

in 3

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

When the RP receives an assertion that is associated with a bound authenticator, the subscriber proves possession of the bound authenticator directly to the RP. The primary authentication at the IdP and the federated authentication at the R

changed here

4

Validity time window: A period of time outside of which the assertion SHALL NOT

be accepted as valid by the RP for the purposes of authenticating the subscriber and starting an authenticated session at the RP. This is usually communicated by means of an expiration timestamp for the assertion in addition to the issuance

changed here