View this document as: a single page | multiple pages.

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 identity attributes associated with the authenticated session. The authenticated session can then be used by the RP for activities to support use cases, such as the following:

A federation transaction requires relatively complex multi-party protocols that have subtle security and privacy characteristics. When evaluating a particular federation protocol, profile, or deployment structure, it is often instructive to break it down into its component relationships and evaluate the needs for each of them:

In addition, the subscriber often interacts with the CSP, IdP, and RP through a user agent (e.g., a web browser) that is, as a result, involved in the federation process. While the actions of the subscriber described throughout these guidelines can optionally be performed through a user agent, a user agent is not necessary for all types of applications and interactions (e.g., native applications). When necessary, requirements on the user agent are called out directly.

Each party in a federation protocol bears specific responsibilities and expectations that must be fulfilled in order for the federated system to function as intended.

Federation transactions are comprised of three separate but related elements:

Trust Agreements:
The establishment of a policy decision that allows the CSP, IdP, and RP to connect for the purposes of federation. This policy is governed by a set of terms that establish the permission to connect.
Identifier and Key Establishment:
The association of cryptographic keys and identifiers for the CSP, IdP, and RP that take part in the federation transaction. This process enables the parties to identify each other securely for future exchanges.
Federation Protocol:
The verification of the subscriber’s identity by the IdP and subsequent issuance of an assertion to the RP. This results in the passing of subscriber attributes to the RP and establishing an authenticated session for the subscriber at the RP.

These elements all need to be fulfilled for a federation process to be complete. The exact order in which that happens and which parties are involved in which steps can vary depending on the deployment model, protocol choices, and other factors.

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-hosted system that is operated on behalf of the subscriber. The models are generally distinguished by the way in which the contents of the subscriber account are made available to the federation system. In a general-purpose IdP, the subscriber account is made available in whole or in part by the CSP through an action that does not usually involve the subscriber. In a subscriber-controlled wallet, the subscriber account is made available by the CSP through the issuance of attribute bundles.

Requirements that are specific to general-purpose IdPs, such as a multi-account identity provider hosted by an organization, are discussed in Sec. 4. Requirements that are specific to subscriber-controlled wallets, such as an on-device digital wallet software or a cloud-hosted wallet provider, are discussed in Sec. 5. All other requirements, including the general requirements in Sec. 3, apply to both models unless otherwise specified. The different models of federation systems fulfill trust and information requirements in different ways.

Table 2 provides a non-normative list of requirements for different models of federated systems and illustrates where core pieces of information are communicated in either an assertion from the IdP or an attribute bundle from the CSP. If a federation implementation has aspects of both models, then the relevant portions of the section in question apply.

Table 2. Federation models

Requirement Location General-Purpose IdP Subscriber-controlled Wallet
IdP issuer identifier Assertion Required Optional
IdP issuer identifier Attribute bundle Optional Optional
IdP verification key Attribute bundle Optional Required
Subject identifier Assertion Required Optional
Subject identifier Attribute bundle Optional Required unless ephemeral provisioning or account resolution are used
CSP issuer identifier Attribute bundle Required Required

Roles

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 capable of verifying an authenticator.

The CSP provides attributes, derived attribute values, or attribute bundles to the IdP for use in the federation transaction. In particular, the CSP issues signed attribute bundles to subscriber-controlled wallets to allow the wallet to act as an IdP in the federation process, as discussed in Sec. 5.1.

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 subscriber, such as a subscriber-controlled wallet on the subscriber’s device.

The IdP establishes an authentication event with the subscriber, either through the verification of an authenticator (for general-purpose IdPs) or the presentation of an activation factor (for subscriber-controlled wallets). The IdP creates assertions to represent the authentication event.

The IdP augments the subscriber account from the CSP with federation-specific items, including but not limited to the following:

The IdP makes the identity attributes of the subscriber available within the assertion or through an identity API (see Sec. 3.12.3).

In some systems, this is also known as the offering party (OP).

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

Identity attributes can be made available to the RP through the federation process, either in the assertion or through an identity API (see Sec. 3.12.3). These attributes are often used in determining access privileges for attribute-based access control (ABAC) or facilitating a transaction (e.g., providing a shipping address). The details of authorization and access control are outside of the scope of these guidelines. Requirements for which attributes are required in assertions are found in Sec. 4.9 and Sec. 5.8.

To keep and manage these attributes, the RP often maintains an RP subscriber account to represent the subscriber. The RP subscriber account contains information that is local to the RP itself, as described in Sec. 3.8.

In some systems, this is also known as the service provider (SP).

Functions

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 subscriber making a decision to share their identity from an IdP with an RP. In other situations, the trust agreement can be managed through a dedicated party known as a federation authority. The federation authority facilitates the onboarding and management of parties that fullfil different roles and functions within a trust agreement. The federation authority’s function provides a basis for parties in the agreement to trust each other without those parties needing to make pairwise trust decisions.

For example, an RP that joins a trust agreement managed by a federation authority can decide that any IdP approved by that federation authority is suitable for its purposes. Alternatively, the RP can select a subset of the IdPs approved by the federation authority based on the RP’s specific application needs. If a particular IdP was not part of the managed trust agreement when the RP joined, the RP can benefit from the federation authority’s ongoing management by trusting the newly added IdP. Federation authorities are used in multilateral trust agreements, as discussed in Sec. 3.5.2.

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 stipulates who the expected authorized party is and the parameters under which a request could be automatically granted, be automatically denied, or require a runtime decision from an individual. For public-facing scenarios, the authorized party is expected to be the subscriber. The subscriber’s consent to release attributes is often gathered through an explicit consent process during the federation transaction (see Sec. 4.6.1.3).

For enterprise scenarios, the authorized party is expected to be the organization. Consent to release attributes is decided by the organization on behalf of all subscribers, and this consent is represented by an allowlist (see Sec. 4.6.1.1) to enable the disclosure of identity attributes without direct decisions and involvement by the subscriber.

Examples of different authorized parties are found in Sec. 9.10.

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 upstream side and an IdP on the downstream side, as shown in Fig. 1. When communicating through a proxy, the upstream IdP and downstream RP communicate with the proxy using a standard federation protocol, and the subscriber takes part in two separate federation transactions. As a consequence, all normative requirements that apply to IdPs and RPs SHALL apply to proxies in their respective roles on each side. Additionally, a proxy can act as an upstream IdP to a downstream proxy in a chaining scenario.

Fig. 1. Federation proxy

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

The role of the proxy is limited to the federation protocol. It is not involved in the establishment or facilitation of a trust agreement between the upstream IdP and downstream RP. The same party can operate a federation authority and a proxy to facilitate federation transactions, but the proxy function is separate from the federation authority’s role in managing the trust agreement. Just like other members of a federation system, the proxy can be involved in separate trust agreements with each of the upstream and downstream components, or a single trust agreement can apply to all parties, such as in a multilateral agreement.

The downstream RP receives and validates the assertion generated by the proxy, as it would an assertion from any other IdP. This assertion is based on the assertion that the proxy receives from the upstream IdP. The contents of the assertion from the upstream IdP can be handled in several ways, depending on the method used by the proxy:

The federated identifier (see Sec. 3.4) of an assertion from a proxy SHALL indicate the proxy as the issuer of the assertion.

A proxied federation model can provide several benefits. Federation proxies can simplify technical integration between the RP and IdP by providing a common interface for integration, as well as providing translation between federation protocols, formats, and schemas. Additionally, to the extent that a proxy effectively blinds the RP and IdP from each other, it can provide some business confidentiality for organizations that want to guard their subscriber lists from each other. Proxies can also mitigate some of the privacy risks described in Sec. 3.10, though other risks arise from their use since an additional party is now involved in handling subscriber information. For example, if an attacker is able to compromise the proxy, the attacker need not target the IdP or RP directly in order to gain access to subscriber attributes or activity since all of that information flows through the proxy. Additionally, the proxy can perform additional profiling (i.e., aggregating information on which identity the subscriber uses at which RPs) of the subscriber beyond what the IdP and RP can do, since the proxy brokers the federation transactions between the parties and binds the subscriber account to either side of the connection.

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

The FAL of the connection between the proxy and the downstream RP is considered to be the lowest FAL along the entire path, and the proxy SHALL accurately represent this to the downstream RP. For example, if the connection between the upstream IdP and the proxy is FAL1 and the connection between the proxy and the downstream RP otherwise meets the requirements of FAL2, the connection between the proxy and the downstream RP is still considered FAL1. Likewise, if the connection between the upstream IdP and the proxy is FAL2 and the connection between the proxy and the downstream RP is only FAL1, the overall connection through the proxy is considered FAL1.

A subscriber-controlled wallet could potentially function as a proxy. To do so, wallet software would need to act as an RP to an external IdP, just as any other proxy, and then provide those attributes to the downstream RP.

In some systems, the proxy is referred to as a broker.

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 pattern is in use.

Different roles and functions can be fulfilled by separate parties that integrate with each other. For example, a CSP can provide attributes of the subscriber account to an IdP that is not operated by the same party or organization as the CSP.

It is also possible for a single party to fulfill multiple roles within a given federation agreement. For example, if the CSP provides the IdP as part of its identity services, the CSP can provision the subscriber accounts at the IdP as part of the subscriber account establishment process. Similarly, the RP can also be in the same security and administrative domain as the IdP but still use federation technology to connect for technical, deployment, and account management benefits.

The same is true for other functions in the overall federation system, such as a federation authority and proxy. While the roles may seem similar, they are fundamentally distinct and do not need to be connected. A federation authority facilitates the establishment of a trust agreement between parties, and a proxy facilitates the connection of the federation protocol. The same entity can fulfill both the federation authority and proxy functions in the system, providing a means of establishing both trust agreements and technical connections between IdPs and RPs.

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 (see Sec. 3.8.2) or through a federated identifier.

For general purpose IdPs, a federated identifier is the logical combination of a subject identifier that represents a subscriber account and an issuer identifier that represents the IdP. The subject identifier is assigned by the IdP, and the issuer identifier is usually assigned to the IdP through configuration.

For subscriber-controlled wallets, a federated identifier is the logical combination of a subscriber identifier that represents the subscriber account and an issuer identifier that represents the CSP that issued the attribute bundle. The subject identifier is assigned by the CSP, and the issuer identifier is usually assigned to the CSP through configuration. However, these will not always be available, for example in the case of mobile driver’s licenses where the account resolution is typically done through the use of the driver’s license number and the issuer of the driver’s license. Such a pattern is addressed in Sec. 3.8.2.

The multi-part federated identifier pattern is required because different IdPs manage their subject identifiers independently, and could, therefore, potentially collide in their choices of subject identifiers for different subjects. Therefore, it is imperative that an RP never process the subject identifier without accounting for the IdP that issued the subject identifier. For most use cases, the federated identifier is stable for the subscriber across multiple sessions and independent of the authenticator used, allowing the RP to reliably identify the subscriber across multiple authenticated sessions and account changes. However, it is also possible for the federated identifier and its associated use at the RP to be ephemeral to provide some privacy enhancement. Federated identifiers and their constituent parts are intended to be machine-readable and not managed by or exposed to the subscriber, unlike a username or other human-facing identifier.

When federated identifiers are used, the federated identifier SHALL be unique to that subscriber. Federated identifiers SHALL be associated with a single subscriber at the RP.

It is recommended that federated identifiers contain no plaintext personal information, such as usernames, email addresses, employee numbers. This restriction is a requirement at FAL2 and above. When a federation process uses account resolution (see Sec. 3.8.2), the RP subscriber account can be resolved by the RP without the use of a federated identifier.

Federated identifiers are a logical concept and will typically not be an explicit value distinct from the subject identifier and issuer identifier. Instead, federated identifiers comprise the information needed to ensure that a subscriber is uniquely distinguished and there are no collisions between subject identifiers provided by different IdPs.

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 distinct federated identifiers to different RPs for a single subscriber account. The use of a PPI prevents different RPs from colluding to track the subscriber using the federated identifier.

General Requirements

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

Some identity attributes such as names, physical addresses, phone numbers, email addresses, and others can be used to identify a subscriber outside of a federation transaction. When PPIs are used alongside these kinds of identifying attributes, it may still be possible for multiple colluding RPs to re-identify a subscriber by correlation across systems. For example, if two independent RPs each see the same subscriber identified with a different PPI, the RPs could still determine that the subscriber is the same person by comparing the name, email address, physical address, or other identifying attributes carried alongside the PPI in the respective assertions. If PPIs are used alongside identifying attributes, RPs SHALL establish privacy policies, processes, and procedures to prevent the correlation of subscriber data consistent with applicable legal and regulatory requirements.

In a proxied federation model (see Sec. 3.3.3), the upstream IdP may not be able to generate a PPI for the downstream RP, since the proxy could blind the IdP from knowing which RP is being accessed by the subscriber. In such situations, the PPI is generally established between the IdP and the federation proxy. Acting as an IdP, the proxy can provide a PPI to the downstream RP. Depending on the protocol, the federation proxy may need to map the PPI back to the associated identifiers from upstream IdPs in order to allow the identity protocol to function. In such cases, the proxy will be able to track and determine which PPIs represent the same subscriber at different RPs. The mapping of a PPI to other identifiers is considered subscriber information and SHALL be treated in accordance with the requirements in Sec. 3.10.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 sufficient entropy as to be unguessable by an attacker. PPIs can be generated randomly and assigned to subscribers by the IdP or derived from other subscriber information if the derivation is done in an irreversible, unguessable manner (e.g., using a keyed hash function with a secret key, as discussed in [SP800-131A]).

Unless the PPI is designated as shared by the trust agreement, the PPI SHALL be disclosed to only a single RP.

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 RPs SHALL conduct a privacy risk assessment to consider the privacy risks associated with requesting a shared PPI. See Sec. 7.2 for further privacy considerations.

The IdP SHALL ensure that only intended RPs are included in the set. Otherwise, a rogue RP could learn the shared PPI for a set of RPs by fraudulently posing as part of that set.

The sector identifier feature of [OIDC] provides a mechanism to calculate a shared PPI for a group of RPs. In this protocol, the identifiers of the RPs are all listed at a URL that can be fetched by the IdP over an authenticated protected channel. The shared PPI is calculated by considering the sector identifier URL along with other inputs to the algorithm such that all RPs listed in the sector identifier URL’s contents receive the same shared PPI.

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 trusts the CSP to provide access to attributes in subscriber accounts, through either an IdP onboarding process or the issuance of attribute bundles. The IdP trusts the CSP’s identity proofing processes used in the establishment of the subscriber account.
CSP to IdP:
The CSP trusts the IdP to accurately represent subscriber identity attributes to RPs and to not disclose identity attributes outside of agreed-upon functionality. The CSP trusts the IdP to protect the release of attributes, such as requiring authentication of the subscriber or the presentation of an activation factor before attributes are released.
RP to IdP:
The RP trusts the IdP to accurately represent subscriber identity attributes as provided by the CSP. The RP trusts the IdP to authenticate or identify the subscriber when representing an authentication event.
IdP to RP:
The IdP trusts the RP to only use the requested attributes for its stated purposes.
RP to CSP:
The RP trusts the CSP to provide access to subscriber identity attributes through IdPs. The RP trusts that the CSP has identity-proofed the subscriber and is managing the subscriber account.

All federation transactions SHALL be governed by the terms of one or more trust agreements between the applicable parties. Different relationships MAY be established at different times and by different processes. For example, a CSP and IdP entering into a trust agreement is generally separate from an RP and IdP entering into a trust agreement, but the overall set of terms for a federation transaction under these parties is drawn from both sets of relationships.

Different scenarios will require different combinations of trust in order to function, and these combinations can vary based on the federation model in use. The combination of individual trust agreements that are applicable to a federation transaction fulfills the requirements of these guidelines. Trust agreements can take different forms, including formal contractual agreements, informal dynamic user agreements, and other documented bilateral or multilateral trust decisions by the parties in the federation. In many cases, trust agreements can be implemented using a trust framework, which formalizes a set of rules for parties to connect with each other. Trust frameworks are often used by federation authorities to formalize the rules for the federation being managed by the federation authority.

For example, consider the case of subscriber-controlled wallets in which an RP might accept assertions without a direct or complete trust agreement with the CSP. As described in Sec. 5.3, provisions of the relevant trust agreements might be determined unilaterally by the RP through the evaluation of publicly available information about CSPs and their processes for issuing attribute bundles. The CSP does not need to know about the RP in order for this part of the trust relationship to be established. In order to fulfill the requirement to disclose the RP’s purpose for using attributes, the RP can disclose these purposes to the subscriber at runtime without informing the CSP.

Trust agreements establish the terms for federation transactions between the parties they affect, including the allowed xALs and the intended purposes of identity attributes exchanged in the federation transaction. The trust agreement SHALL establish customer experience requirements for the federation transaction, as discussed in Sec. 8. The trust agreement SHALL include details of the proofing process used at the CSP for subscribers covered by the trust agreement, including any compensating controls and exception handling processes.

All trust agreements SHALL define a specific population of subscriber accounts to which the agreement is applicable. The exact means of defining this population are out of scope for this document. In many cases, the population is defined as the full set of subscriber accounts that the CSP manages and makes available through an IdP. In other cases, the population is a demarcated subset of accounts that are available through an IdP. It is also possible for an RP to have a distinct trust agreement established with an IdP for a single subscriber account, such as in a subscriber-driven trust agreement.

During the course of a single federation transaction, it is important for the policies and expectations of all parties to be unambiguous. Therefore, there SHOULD only be one set of trust agreements in effect for a given transaction. This will usually be determined by the unique combination of CSP, IdP, and RP that are participating in the transaction. However, these agreements could vary in other ways, such as different populations of subscribers being governed by different trust agreements. If more than one trust agreement is applicable to a federation transaction, the combined set of terms of all applicable trust agreements SHALL constitute the effective trust agreement of that transaction.

The existence of a trust agreement between parties does not preclude the existence of other agreements for each party with other parties. For example, an IdP can have independent agreements with multiple RPs simultaneously, and an RP can likewise have independent agreements with multiple IdPs simultaneously. The IdP and RP need not disclose the existence or terms of trust agreements to parties outside of or not covered by the agreement in question.

Trust agreements SHALL establish terms regarding expected and acceptable IALs, AALs, and FALs in connection with the federated relationship.

Trust agreements SHALL define necessary mechanisms and materials to coordinate redress and issues between the different participants in the federation, as discussed in Sec. 3.5.3.

Trust agreements SHALL declare the data retention policies expected of all parties.

Even though subscribers are not generally directly involved in the trust agreement’s terms, subscribers are affected by the terms of the trust agreement and the resulting federation transactions. As such, the relevant terms of the trust agreement SHALL be made available to subscribers in clear and understandable language. The terms of the trust agreement SHALL be reviewed by all parties (e.g., the CSP, IdP, RP, or a federation authority) that are responsible for informing the subscriber of the terms of the trust agreement before the disclosure to the subscriber occurs in order to avoid revealing sensitive security information.

The means by which the subscriber can access these terms and the party responsible for informing the subscriber vary based on the means of establishing the trust agreement and the terms of the trust agreement itself. Common methods for disclosure include:

The establishment of a trust agreement is required for all federation transactions, even those for which the roles and applications exist within a single security domain or shared legal ownership, such as an enterprise system. In these cases, the establishment of the trust agreement can be an internal process and does not need to involve a formal agreement. Even in such cases, the organization must still document and disclose the terms of the trust agreement to the subscriber upon request.

The subscriber’s user agent is not usually party to the trust agreement, unless it is acting in one of the roles of the federation transaction (e.g., a subscriber-controlled wallet running in the subscriber’s browser software).

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-to-point connection to be established between organizations that wish to provide federated identity access to services. Bilateral connections can take many forms, including large enterprise applications with static contracts or subscriber-driven dynamic connections to previously unknown RPs. In all cases, the CSP, IdP, and RP directly manage their policies regarding the federated connection.

Bilateral trust agreements conform to the stated requirements for all trust agreements. However, since these trust agreements do not involve additional parties, there are no additional normative requirements for their establishment and management, such as those mandated for multi-lateral trust agreements (see Sec. 3.5.2).

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 under the trust agreement.

When onboarding a party in any role, the federation authority conducts vetting on that party to verify its compliance with the terms of the trust agreement, as shown in Fig. 2. The level of vetting is unique to the use cases and models employed within the federation, and details are outside of the scope of this document. As with many other functions, the federation authority can outsource the vetting process to another party, but the federation authority is ultimately responsible for the results of the vetting process.

Fig. 2. Federation authority

Diagram of a federation authority facilitating trust agreement terms for a variety of parties under the federation authority.

The trust agreement SHALL enumerate the required practices for vetting all parties and SHALL indicate the party or parties that are responsible for performing the vetting process.

At a minimum, the vetting of CSPs, IdPs, and RPs SHALL establish that:

The federation authority MAY provide a programmatic means for parties under the trust agreement to verify the membership of other parties in the trust agreement. For example, a federation authority could provide a discovery API that provides the vetted capabilities of an IdP for providing identities to RPs within the system. Alternatively, the federation authority could provide a signed attestation for RPs to present to IdPs during a registration step.

Federation authorities SHALL periodically reevaluate members for compliance with terms disclosed in the trust agreement.

A multilateral trust agreement MAY establish trust based on other trust agreements that are managed by other entities by creating an interfederation agreement. For example, IdP1 has been vetted under a multilateral agreement with federation authority A1, and RP2 has been vetted under a multilateral agreement with federation authority A2. In order to facilitate connection between IdP1 and RP2, a new federation authority A3 can provide a multilateral agreement that accepts IdPs from A1 and RPs from A2. If IdP1 and RP2 accept the authority of A3, the federation connection can continue under the auspices of this interfederation agreement.

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

As the recipient of a subscriber’s identity attributes, the RP is the subscriber’s primary view into the federated system. In some instances, the subscriber may be unaware that an IdP is involved with their use of the RP. Therefore, it falls to the RP to provide the subscriber with a clear and accessible method of contacting the RP to request redress. For matters that involve the RP subscriber account (including any attributes stored in the account), RP functionality, bound authenticators, RP allowlists, and other items under the RP’s control, the RP SHALL provide a clear and accessible means of redress to the subscriber. For matters that involve the IdP or CSP, the RP SHALL provide the subscriber with a means of initiating the redress process with the IdP or CSP, as appropriate.

For matters that involve the use of the subscriber account in federation transactions, including attribute values and derived attribute values made available over federation transactions, IdP functionality, holder-of-key authenticators, IdP allowlists, and other items in the IdP’s control, the IdP SHALL provide a clear and accessible means of redress to the subscriber. For matters that also involve a particular RP, the IdP SHALL provide the subscriber with a means of initiating the redress process with the RP. For matters that involve a subscriber account that has been made available to the IdP, the IdP SHALL provide the subscriber with a means of initiating the redress process with the CSP.

For matters that involve the subscriber account, including identity attributes and authenticators in the subscriber account, the CSP SHALL provide the subscriber with a clear and accessible means of redress.

See Sec. 3.6 of [SP800-63] for more requirements on providing redress.

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 other in a secure fashion with the ability to associate identifiers with cryptographic keys and related security artifacts. In this way, an RP can ensure that an assertion is coming from the intended IdP or that an attribute bundle is coming from the intended CSP. Likewise, an IdP can ensure that it is sending an assertion to the intended RP.

The process of an RP establishing identifiers and cryptographic keys for an IdP or CSP is known as discovery. The process of an IdP establishing identifiers and cryptographic keys for the RP is known as registration. Both the discovery and registration processes can happen prior to any federation transaction or inline as part of the transaction itself. Additionally, both the discovery and registration processes can happen directly between parties or be facilitated through the use of a third-party service, as defined in the trust agreement. These processes can use a combination of manual distribution of keys and identifiers between the IdP, CSP, and RP or associate these entities with sources in which cryptographic key material and metadata can be fetched through automated processes. Different federation protocols and processes have different processes for establishing these identifiers and cryptographic keys, but the end result is that each party can properly identify others as necessary within the protocol.

The discovery and registration processes SHALL be established in a secure fashion, as defined by the trust agreement that governs the federation transaction. In many cases, the identifier is associated with a trusted source of cryptographic key material and not the key material itself. For example, a URL hosted by an IdP can serve the public signing keys for that IdP. Even if the RP is manually configured with this association, the RP can fetch the actual cryptographic key material at runtime. Protocols that require the transfer of cryptographic key information SHALL use an authenticated protected channel to exchange the cryptographic key information needed to operate the federated relationship, including any shared secrets or public keys. Any symmetric keys used in this relationship SHALL be unique to a pair of federation participants.

CSPs, IdPs (including subscriber-controlled wallets), and RPs MAY have multiple identifiers and cryptographic keys to serve different purposes within a trust agreement or different trust agreements. For example, an IdP could use one set of assertion signing keys for all FAL1 and FAL2 transactions and use a separately managed set of signing keys for FAL3 transactions that are stored in a higher security container.

When domain names, URIs, or other structured identifiers are used to identify parties, wildcards SHALL NOT be used. For example, if an RP is deployed at “www.example.com”, “service.example.com”, and “gateway.example.com”, then each of these identifiers would have to be registered for the RP. A wildcard of “*.example.com” cannot be used, as it would unintentionally allow access to “user.example.com” and “unknown.example.com” under the same RP identifier.

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 executed using an authenticated protected channel, as in the initial cryptographic key establishment.

For example, if the IdP is identified by a URL, the IdP could publish its current public key set at a location underneath that URL. The IdP can update which keys are published at that location as needed. RPs can then fetch the public key from the known location as needed and obtain updated public keys as they are made available.

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 applicable tamper resistance requirements.

Some circumstances require the cryptographic keys to be stored in a non-exportable manner, such as reaching FAL3 with a subscriber-controlled wallet on a subscriber’s device (see Sec. 5.4.1). To be considered non-exportable, key storage SHALL either be a separate piece of hardware or an embedded processor or execution environment, such as a secure element, trusted execution environment (TEE), or trusted platform module (TPM). These hardware modules or embedded processors are separate from a host processor, such as the CPU on a laptop or mobile device. Non-exportable key storage SHALL be designed to prohibit the export of the secret keys to the host processor and SHALL NOT be capable of being reprogrammed by the host processor to allow the secret keys to be extracted.

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 of software, device, or runtime system meets a set of agreed-upon parameters. The attestation is presented by the software in the context of establishing the identity of the software, device, or system with which the receiver is interacting. The attestation allows the receiver to verify the request with a higher degree of certainty than they would be able to otherwise.

For example, a specific distribution of subscriber-controlled wallet software can be signed by its distributor to allow RPs to recognize individual instances of that software. Alternatively, an RP could be issued an attestation from a federation authority to allow IdPs to recognize the RP as part of the federation.

When attestations are required by the trust agreement or requested as part of the federation protocol, received attestations SHALL be validated by the receiver.

See [RFC7591] Sec. 2.3 for more information about software statements, which are a means for OAuth and OpenID Connect RPs to communicate a signed set of software attributes during dynamic client registration.

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 between the IdP and the RP for federation transactions or support functions, such as identification of compromised subscriber accounts (see Sec. 3.10.1), even when parties are allowlisted for federation purposes.

A subscriber’s identity attributes SHALL NOT be used by the RP for purposes other than those stipulated in the trust agreement unless the subscriber specifically consents to such purposes. A subscriber’s attributes SHALL be stored and managed in accordance with Sec. 3.11.3.

The subscriber SHALL be informed of the transmission of attributes to an RP. If the authorized party is the organization, the organization SHALL make the list of approved RPs and the associated sets of attributes sent to those RPs available to the subscriber. If the authorized party is the subscriber, the subscriber SHALL be prompted prior to the release of attributes using a runtime decision at the IdP, as described in Sec. 4.6.1.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 RP subscriber account has a separate life cycle from any subscriber account on which it might be based (e.g., the subscriber accounts maintained by a CSP or IdP).

An RP subscriber account is provisioned when the RP has associated a set of attributes about the subscriber with a data record that represents the subscriber account at the RP. The provisioning can happen prior to authentication or as a result of the federated authentication process, depending on the deployment patterns (see Sec. 4.6.3). The RP subscriber account MAY be associated with one or more federated identifiers at the time of provisioning or MAY be later linked to federated identifiers through account resolution, as discussed in Sec. 3.8.2.

An RP subscriber account is available for federated authentication when it is bound to one or more federated identifiers from the RP’s trusted IdPs, or an account resolution process is established. The successful authentication of a subscriber through a federation protocol allows the subscriber to access the information and functionality of the RP protected by the RP subscriber account.

An RP subscriber account is terminated when the RP removes all access to the account at the RP. Termination SHALL include the removal of all federated identifiers, bound authenticators, attributes, and identity information associated with the account, in accordance with Sec. 3.11.3. An RP MAY terminate an RP subscriber account independently from the IdP, regardless of the current validity of the subscriber account from which it is derived.

An RP subscriber account is disabled when the subscriber cannot access the RP using the account, such as when all federated identifiers and alternate authenticators are removed from the RP subscriber account, but the information in the account is retained. An RP could choose to disable an RP subscriber account rather than terminate it in order to facilitate records retention or investigate suspicious behavior associated with the account.

An RP MAY offer a means of recovery of an RP subscriber account with no current means of access.

An RP subscriber account can be provisioned at the RP without an authenticated session, but an authenticated session can only be created based on a provisioned account. See Sec. 3.9 for more information on sessions.

The RP SHALL document the practices and policies that it enacts when an RP subscriber account reaches a state of having zero associated federated identifiers; no means of access, including alternative authenticators (see Sec. 3.8.3); and no means of recovery, including account linking (see Sec. 3.8.1) and account resolution (see Sec. 3.8.2). In such cases, the RP subscriber account SHOULD be disabled or terminated.

The RP SHALL provide a notice to the subscriber when:

The RP SHOULD provide a notice to the subscriber when the RP subscriber account is disabled or terminated. The RP SHALL consider the reason for termination when determining whether to send a notice to the subscriber, as discussed in Sec. 5.4 of [SP800-63A].

For additional considerations on providing a notice to a subscriber about account management events, see Sec. 4.6 of [SP800-63B].

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 require an authenticated session with the subscriber account for all linking functions. This authenticated session SHOULD require authentication using one existing federated identifier before linking the new federated identifier to the RP subscriber account.

When a federated identifier is removed from an RP subscriber account, the RP SHALL disallow access to the RP subscriber account from the removed federated identifier.

The RP MAY associate different access rights with the same account, depending on which federated account is used to access the RP. The means by which an RP determines authorization and access is out of scope for these guidelines.

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 information to associate with a new RP subscriber account.

An RP that performs account resolution SHALL ensure that the attributes requested from the IdP are sufficient to uniquely resolve the subscriber within the RP’s system before linking the federated identifier with the RP subscriber account and granting access. The intended use of each attribute by the RP is detailed in the trust agreement, including whether the attribute is used for account resolution in this manner.

An RP that performs account resolution SHALL design the process such that it does not associate an RP subscriber account’s information with a federated identifier that does not belong to the subscriber.

For example, a subscriber-controlled wallet might not provide an RP with a federated identifier but could allow the RP to conduct account resolution by providing the RP an attribute bundle from the CSP that allows the RP to uniquely resolve the subscriber to an RP subscriber account. Alternatively, an RP using a pre-provisioning model could uniquely associate an incoming assertion to an RP subscriber account based on an agreed-upon set of attributes.

A similar account resolution process is also used when the RP verifies an authenticator used in a holder-of-key assertion for the first time. In this case, the RP SHALL ensure that the attributes carried with the authenticator uniquely resolve to the RP subscriber account before accepting the authenticator.

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 [SP800-63B] to manage all alternative authenticators.

Since the RP is using the direct authentication model discussed in [SP800-63], there is no federation transaction and therefore no FAL assigned.

If the RP allows this kind of access, the RP SHOULD disclose the following in the trust agreement to allow IdPs to make decisions regarding information shared with the RP:

For additional considerations on providing notice to a subscriber about authenticator management events, see Sec. 4.6 of [SP800-63B].

While it is possible for bound authenticators (see Sec. 3.16) to be used as an alternative authenticator for direct access to the RP, these uses are distinct from each other and an RP SHALL determine whether a given authenticator can be used in one or both scenarios.

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 access to functions at the RP (i.e., logging in), identifying the subscriber to the RP, or processing attributes about the subscriber carried in the federation transaction. An authenticated session SHALL be created by the RP only when the following conditions are true:

When federation is used as part of an identification process, an RP subscriber account may not be established until other processes have been completed.

If the assertion is a holder-of-key assertion at FAL3, the authenticator indicated in the assertion SHALL be verified before the RP subscriber account is associated with an authenticated session, as discussed in Sec. 3.15. If the assertion also requires authentication with a bound authenticator at FAL3, a bound authenticator SHALL be verified before the RP subscriber account is associated with an authenticated session, as discussed in Sec. 3.16.

The authenticated session MAY be ended by the RP at any time.

See [SP800-63B] Sec. 5 for more information about session management requirements for both IdPs and RPs. For additional session requirements with general purpose IdPs, see Sec. 4.7.

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 broad visibility into a subscriber’s activities and status. Accordingly, there are specific privacy requirements associated with federation that do not exist in direct authentication.

When the RP requests a federation transaction from the IdP, this request and the subsequent processing of the federation transaction reveal to the IdP where the subscriber is logging in. Over time, the IdP could build a profile of subscriber transactions based on the knowledge of which RPs a given subscriber is using. This aggregation could enable new opportunities for subscriber tracking and the use of subscriber identity information in ways that do not align with subscribers’ privacy interests.

If the same subscriber account is asserted to multiple RPs, and those RPs communicate with each other, the colluding RPs could track a subscriber’s activity across multiple applications and security domains. The IdP SHOULD employ technical measures (e.g., the use of pairwise pseudonymous identifiers described in Sec. 3.4.1, privacy-enhancing cryptographic protocols) to provide disassociability and discourage subscriber activity tracking and profiling between RPs. When determining such measures, the IdP SHOULD apply relevant guidelines and standards, such as the NIST Privacy Framework [NIST-Privacy].

The following requirements apply specifically to federal agencies that act as an IdP, an RP, or both:

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

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

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

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

  5. The agency SHALL conduct a privacy risk assessment regarding the sharing of subscriber identity information between the IdP and RP.

If the RP subscriber account life cycle process gives the RP access to attributes through a provisioning API (see Sec. 4.6.3), additional privacy measures SHALL be implemented to account for the difference in the RP subscriber account life cycle (e.g., separation of non-active subscriber accounts, proactive removal of disabled and terminated accounts). The IdP SHALL minimize the attributes that are made available to the RP through the provisioning API. The IdP SHALL limit the population of subscriber accounts that are available via the provisioning API to the population of subscribers authorized to use the RP by the trust agreement. To prevent RP retention of identity attributes for accounts that have been terminated at the IdP, the IdP SHALL use the provisioning API to de-provision RP subscriber accounts for terminated subscriber accounts except where restricted by RP data retention requirements, policies, or regulation. This measure helps enforce data minimization principles (see the example in Sec. 9.5). When an RP subscriber account is linked to multiple federated identifiers (see Sec. 3.8.1), the de-provisioning process could result in the RP subscriber account still existing at the RP but linked to a different federated identifier.

The IdP and RP SHALL exchange only the minimum data necessary to achieve the function of the system.

To increase subscriber control over the release of their identity attributes, trust agreements SHOULD use a runtime decision to control attribute release, as discussed in Sec. 4.6.1.3.

When the federation transaction uses an ephemeral provisioning mechanism (see Sec. 4.6.3), the IdP SHOULD use an ephemeral federated identifier for each authorization request to the RP to prevent the RP from storing or correlating information between sessions.

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:

If an IdP discloses information on subscriber activities at an RP to any party or processes the subscriber’s attributes for any purpose other than these cases, the IdP SHALL implement measures to maintain predictability and manageability commensurate with the privacy risks that arise from the additional processing. Measures MAY include providing clear notice, obtaining subscriber consent, or enabling the selective use or disclosure of attributes. When an IdP gathers the subscriber’s consent to use information outside the identity transaction, the IdP SHALL NOT make consent for the additional processing a condition of the identity service. For example, an IdP cannot require a subscriber to consent to receiving a newsletter in order to allow the subscriber to log into an RP.

An RP SHALL limit the transmission of subscriber activities to the associated IdP to the following cases and only if stipulated and disclosed by the trust agreement:

If an RP uses the subscriber’s identity information for any purpose other than those stipulated in the trust agreement, the RP SHALL inform the subscriber and obtain their consent for such additional uses.

Subscriber information could also be transmitted to comply with laws or legal processes, regardless of the terms of the trust agreement.

See [NISTIR8062] for additional information on privacy engineering and risk management.

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 with each other for activities, such as fraud mitigation (e.g., to prevent an attacker from jumping between CSPs with different accounts to avoid detection). While sharing information in this way can be used to mitigate fraud, there are also substantial privacy concerns as the CSPs could learn subscriber attributes and actions from each other that were not originally disclosed to all CSPs that the subscriber uses.

Similar information sharing could be desirable between IdPs that may operate independently from the CSP, such as between subscriber-controlled wallets that are hosted on remote systems, and such sharing has similar privacy considerations.

All information transmissions between CSPs and/or IdPs SHALL be subject to the limitations for IdPs enumerated in Sec. 3.10.1. Any such information sharing between CSPs and/or IdPs SHALL be included in their privacy risk assessments.

The terms of the trust agreement that connects CSPs SHALL define the policies that apply for the transfer of information shared between CSPs. In a trust agreement managed by a federation authority, the federation authority defines these terms.

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 determined for the information systems, applications, and online services that these guidelines are used to protect. RPs SHALL employ appropriately tailored security controls from at least the low baseline security controls defined in [SP800-53] or an equivalent federal (e.g., [FEDRAMP]) or industry standard that the organization has determined for the information systems, applications, and online services that these guidelines are used to protect. RPs that request or process personal information 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. CSPs, IdPs, and RPs SHALL ensure that the minimum assurance-related controls for the appropriate systems or equivalent are satisfied or exceeded.

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 subscriber access to the RP. The attacker does this by taking an assertion or assertion reference and injecting it into a vulnerable RP. A successful attacker can trick an RP into binding the attacker’s session to the federated identifier in the assertion. The attacker’s assertion could be either stolen from a legitimate subscriber or manufactured to perpetrate the attack.

Protection from assertion injection attacks is recommended at all FALs and required at FAL2 and above. In all cases, the RP needs to take reasonable steps to prevent an attacker from presenting an injected assertion or assertion reference based on the nature of the RP software, the capabilities of the federation protocol in use, and the needs of the overall system. Both [OIDC] and [SAML] provide mechanisms for assertion injection protection, including nonces sent from the RP during the request, RP authentication for back-channel communications, and methods for the RP to start the federation transaction and track its state throughout the process. Different mechanisms provide different degrees of protection and are applicable in different circumstances. While the details of specific protections will vary based on the federation protocol and technology in use, common best practices can be used to limit the attack surface, such as:

Assertion injection attacks are particularly dangerous when combined with phishing attacks because the attacker can either trick the subscriber into generating a valid assertion for the attacker to inject into the attacker’s session, or the attacker can trick the subscriber into injecting the attacker’s assertion into the subscriber’s session at the RP.

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 authenticated protected channel.

The IdP may have access to information that may be useful to the RP in enforcing security policies, such as device identity, location, system health checks, and configuration management. The IdP MAY disclose this information to the RP within the bounds of the trust agreement and subject to the subscriber’s notice and consent, as described in Sec. 7.2.

Identity attributes MAY be included outside of the assertion itself by authorizing access to an identity API, as discussed in Sec. 3.12.3. Splitting identity information in this manner can help protect subscriber privacy and can allow for the limited disclosure of personal information in addition to the essential information in the authentication assertion itself. The use of identity APIs SHALL be enumerated in the terms of the trust agreement.

When derived attribute values are available and fulfill the RP’s needs, the RP SHOULD request derived attribute values rather than full attribute values, as described in Sec. 7.3. The IdP SHOULD support derived attribute values to the extent that the underlying federation protocol allows.

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

When an RP subscriber account can no longer be accessed by a subscriber (e.g., when there are no federated identifiers associated with the account and no alternate means of authentication), the RP SHOULD terminate the RP subscriber account. In particular, if an RP supports account linking (see Sec. 3.8.1) or alternative authenticators (see Sec. 3.8.3), the RP MAY choose to not terminate the RP subscriber account and instead disable the account and retain necessary information in it.

The IdP and RP SHOULD support the deletion of personal information in the subscriber account and RP subscriber account upon account termination, except when otherwise restricted by regulations, laws, or policies or when the risk of an application deems it essential to retain the subscriber’s information. IdPs and RPs that do not support deletion SHALL provide a statutory or risk-based justification and document it in the trust agreement. For example, the RP could record the federated identifier in access and audit logs that are retained even after the account has been terminated. However, all identity attributes and personal information are removed from the RP’s own storage as the RP no longer needs them for its functions.

When the RP subscriber account is terminated, the RP SHALL remove all subscriber attributes from storage, except when otherwise restricted by regulations, laws, or policies or when the risk of an application deems it essential.

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.

\clearpage
Bundling:
Attributes SHALL be either unbundled (i.e., presented directly in an assertion by the IdP) or bundled into a package that is cryptographically signed by the CSP, as described in Sec. 3.12.1.
Derivation:
Attributes SHALL be either attribute values (e.g., a date of birth) or derived attribute values (e.g., an indication of age of majority).
Presentation:
Attributes SHALL be either presented in the assertion and covered by the assertion’s signature or be made available as part of a protected identity API.

Trust agreements SHALL point to the CSP’s practice statements that describe the processes and sources used for attribute validation.

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 “attribute bundle” instead.

As an alternative to sending attributes directly from the IdP in an assertion or identity API, attribute values and derived attribute values can be collected into bundles that are signed by the CSP. These attribute bundles can be verified by the RP using the cryptographic protections of the attribute bundle, independently of protections provided by the IdP. Attribute bundles are commonly used by subscriber-controlled wallets. Some examples of technologies used to bundle attributes are Selective Disclosure JSON Web Tokens [SD-JWT], the Verifiable Credentials Data Model defined in [VC], and the mDoc Mobile Security Object defined in [ISOIEC18013-5].

The presentation of an attribute bundle SHALL be protected by the IdP in the same manner as non-bundled attributes. That is, attribute bundles that are presented in an assertion are covered by the signature of the assertion, and attribute bundles that are made available by an identity API are protected by the limited access controls to that API.

Attribute bundles include one or more attribute values and derived attribute values along with an identifier for the issuing CSP. One of these attribute values could function as a subscriber identifier if the issuing CSP ensures the uniqueness of this value across its subscribers. Since attribute bundles are carried in the assertion from the IdP, the subscriber attributes within the bundle do not need to be fully disclosed to all RPs on every transaction and can instead be selectively disclosed to the RP. An attribute bundle using selective disclosure technology can increase the privacy of a system by limiting which attributes an RP can read from the attribute bundle without needing a new bundle to be issued to the IdP. The RP can still verify the signature of the attribute bundle as a whole and confirm the bundle’s source as the CSP without the IdP having to disclose all of the contents of the attribute bundle to the RP.

The RP SHALL validate the signature specific to the attribute bundle as well as any container signatures, such as the signature of the assertion as a whole.

An attribute bundle MAY optionally include a verification key for the IdP to which the bundle has been issued. In such cases, the RP SHALL confirm that the assertion is presented by the identity claimed in the attribute bundle by verifying the signature over the assertion using the IdP’s verification key in the signed attribute bundle.

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 subscriber is above the age of majority, the RP could request the subscriber’s birth date and calculate the majority age question from this value. However, doing so reveals more specific information to the RP than is truly needed for the RP’s functional requirements. Instead, the IdP could calculate whether the subscriber’s age meets the definitions for majority at the time of the RP’s request and return a simple boolean for this derivation instead of the birth date value itself. The RP can then continue its processing without needing to see the underlying value.

Derived attribute values increase the privacy of a system since they allow a more focused release of information to the RP. While some federation systems allow the RP to dynamically query for an arbitrary derived attribute value at request time, many common use cases can be accommodated by the IdP pre-calculating common derived attribute values and offering them as alternatives to the full attribute value. To preserve privacy, derived attribute values SHALL NOT disclose the underlying attribute value to a requester. Selective disclosure technology, as found in some attribute bundles, can be used to carry both full attribute values and derived attribute values in the same response, disclosing only that which is necessary for the application.

Derived attribute values are directly included in assertions (see Sec. 4.9 and Sec. 5.8) or included in attribute bundles (see Sec. 3.12.1).

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 with the assertion. For example, in OpenID Connect, the UserInfo Endpoint provides a standardized identity API for fetching attributes about the subscriber. This API is protected by an OAuth 2.0 Access Token, which is issued to the RP along with OpenID Connect’s assertion, the ID Token. Identity APIs SHOULD require sender-constrained access to ensure that identity information is only made available to authorized RPs.

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

Identity APIs also make it possible for the RP to help manage the transmission of subscriber attributes from the IdP. The RP often caches attributes that are provided by the IdP in an RP subscriber account (see Sec. 3.8), and the RP can record when these attributes were last received from the IdP. The RP can request subscriber attributes only when needed to update the RP subscriber account, instead of receiving them on every federation transaction in the assertion. The IdP can aid this decision by indicating in the assertion the time at which any of the subscriber attributes available to the RP were updated at the IdP. This approach is particularly helpful when a subscriber’s attributes are stable over time, allowing the RP to function without fetching them on every request.

All possible use of identity APIs, including which provisioning models are available through the API, SHALL be recorded and disclosed as part of the trust agreement. Access to the identity API SHALL be time-limited by the trust agreement. Access to the identity API SHOULD be limited to the duration of the federation transaction plus the time necessary to synchronize attributes, as discussed in Sec. 4.6.4. Since the time limitation is separate from the validity time window of the assertion and the lifetime of the authenticated session at the RP, access to an identity API by the RP without an associated valid assertion SHALL NOT be sufficient for the establishment of an authenticated session at the RP.

A given identity API deployment is expected to be capable of providing attributes for all subscribers for whom the IdP can create assertions. However, when access to the identity API is granted within the context of a federation transaction, the attributes provided by an identity API SHALL be associated with only the single subscriber identified in the associated assertion. If the identity API is hosted by the IdP, the returned attributes SHALL include the subject identifier for the subscriber. This allows the RP to positively correlate the assertion’s subject to the returned attributes. When access to an identity API is provided as part of pre-provisioning RP subscriber accounts (see Sec. 4.6.3), the RP is usually granted blanket access to the identity API outside of the context of the federation transaction, and these requirements do not apply. For pre-provisioning use cases, the privacy considerations SHALL be evaluated and recorded as part of the trust agreement. If the identity API is hosted externally from the IdP, the requirements in Sec. 3.12.3.1 apply.

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 provided by attribute providers other than the CSP and provide attributes about the subscriber in addition to those available from the subscriber account. When the IdP grants access to an external identity API, the information returned from the external identity API is associated with the subscriber just like an identity API hosted by the IdP. For the purposes of the trust agreement, the IdP is responsible for the association of the external identity API’s content with the subscriber account, even though the IdP does not have control of the data returned by the external identity API.

As the attributes returned by the external identity API are assumed to be independent of those returned directly from the IdP, the contents of the external Identity API MAY use different identifiers, formats, or schemas from those used by the IdP. In particular, an external identity API is not expected to use the same federated identifier as an IdP-hosted identity API. For example, an IdP could provide access to a subscriber’s medical license information. Instead of the IdP asserting the license status directly, the IdP provides the RP access to a record at a medical licensure agency that represents the subscriber. The federation protocol can enable this by allowing the IdP to provide a link to an API with the record that represents the subscriber as well as a credential that allows limited access to this API. The RP can then make a strong association between the subscriber and the medical license record, even though the license record will likely use a different identifier and would not otherwise be correlatable by the RP. The IdP remains responsible for providing this link to the RP.

Any use of external identity APIs for providing attributes SHALL be enumerated by the trust agreement as part of listing attribute sources.

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 specific protections are listed in the following subsections.

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.

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 its identifier, issuer, audience, subject, and time validity window.

The assertion signature SHALL either be a digital signature using asymmetric keys or a MAC using a symmetric key that is shared between the RP and issuer with approved cryptography.

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

A trust agreement MAY require the encryption of assertion contents in other situations.

While most assertion formats support encryption of the entire assertion, some assertion formats allow for only the personal information portions of the assertion to be encrypted, providing the selective disclosure of sensitive information to the RP without encrypting the entire assertion. When portions of the assertion are encrypted, only an RP that holds the necessary decryption key will be able to access the encrypted information in the assertion.

When encrypting assertions, the IdP SHALL encrypt the contents of the assertion using the RP’s encryption key with approved cryptography. For example, a SAML assertion can be encrypted using XML-Encryption, while an OpenID Connect ID Token can be encrypted using JSON Web Encryption (JWE).

When used with back-channel presentation, an assertion can also be encrypted in transit with a mutually authenticated TLS connection if there are no intermediaries between the IdP and RP that interrupt the TLS channel.

The meaning of subject identifiers is contextual to their target systems, unlike other possible identifiers, such as SSNs, email addresses, or driver’s license numbers. Therefore, subject identifiers alone do not trigger encryption requirements based on protecting personal information.

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 the assertion injection and replay of an assertion generated for one RP at another RP.

In order to limit the places that an assertion could successfully be replayed by an attacker, IdPs SHOULD issue assertions that are designated for only a single audience. Restriction to a single audience is required at FAL2 and above.

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 and used by the RP to fetch an assertion. If an attacker can capture or manufacture a valid assertion or assertion reference that represents a subscriber and can successfully present that assertion or reference to the RP, then the attacker could impersonate the subscriber at that RP.

The mere possession of a bearer assertion or reference is not always enough to impersonate a subscriber. For example, if an assertion is presented in the back-channel federation model (see Sec. 4.11.1), additional controls can be placed on the transaction (e.g., identification of the RP, assertion injection protections) that help further protect the RP from fraudulent activity.

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 subscriber possesses the authenticator identified by the assertion. Holder-of-key assertions are most often used when the authenticator technology is tied to a public-key infrastructure (PKI) trusted by both the IdP and RP.

Fig. 3. Holder-of-key assertions

Diagram illustrating the use of holder-of-key assertions.

The authenticator identified in a holder-of-key assertion MAY be distinct from the primary authenticator that the subscriber uses to authenticate to the IdP. The authenticator identified in a holder-of-key assertion SHALL be phishing-resistant, as defined by Sec. 3.2.5 of [SP800-63B]. When the RP encounters an authenticator in a holder-of-key assertion for the first time, the RP SHALL ensure that the authenticator can be uniquely resolved to the RP subscriber account, as discussed in Sec. 3.8.2.

A holder-of-key assertion SHALL NOT include an unencrypted private key or symmetric key to be used as an authenticator.

Assertions from subscriber-controlled wallets that run on a subscriber’s device can be considered holder-of-key assertions.

Section 9.6 provides a more complete example of the use of a mutual TLS connection to provide the proof of possession of a certificate on a smart card that is listed by the assertion.

Since the authenticators used in holder-of-key assertions could be presented to multiple parties, and these authenticators often contain identity attributes, there are additional privacy considerations to address, as discussed in Sec. 7.

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. The unique identifier for the authenticator (such as its public key) SHALL be stored in the RP subscriber account. The RP needs to have a reliable basis for evaluating the characteristics of the bound authenticator, such as the inclusion of a signed attestation, as discussed in Sec. 3.2.4 of [SP800-63B]. Bound authenticators are most often used when the authenticator technology is not tied to a PKI trusted by both the IdP and RP, for example when no such PKI exists.

Fig. 4. Bound authenticators

Diagram illustrating the use of bound authenticators managed at the RP.

A bound authenticator SHALL be unique per subscriber at the RP such that two subscribers cannot present the same authenticator for their separate RP subscriber accounts. All bound authenticators SHALL use phishing-resistant authentication mechanisms, as defined by Sec. 3.2.5 of [SP800-63B]. Consequently, subscriber-chosen values such as a password cannot be used as bound authenticators. Bound authenticators SHALL be accepted for authentication in the context of processing an FAL3 assertion for a federated transaction. While it is possible for the same authenticator to also be used for direct authentication to the RP (see Sec. 3.8.3), such use is not considered a bound authenticator, and the RP SHALL document these as distinct use cases.

The IdP MAY specify types or characteristics for allowable bound authenticators in the trust agreement.

Before an RP can successfully accept an FAL3 assertion, the RP subscriber account SHALL include a reference to a bound authenticator that is to be verified during the FAL3 transaction. These authenticators can be provided by either the RP (as in Sec. 13.15.1) or the subscriber (as in Sec. 13.15.2), and different requirements apply to the initial binding of the authenticator to the RP subscriber account in each case.

The RP SHALL send a notification to the subscriber via an out-of-band mechanism (e.g., an email to an address previously associated with the subscriber) and SHOULD notify the IdP using a shared signaling system (see Sec. 4.8) if any of the following events occur:

For additional considerations on providing notice to a subscriber about authenticator management events, see Sec. 4.6 of [SP800-63B].

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 determine whether the identified subject of the RP subscriber account is the party to which the authenticator is issued. The system administrator of the RP SHALL follow the initial authenticator binding requirements in Sec. 4 of [SP800-63A] or the post-enrollment binding requirements in Sec. 4.1.2 of [SP800-63B], as appropriate. The system administrator of the RP SHALL store a unique identifier for the bound authenticator in the RP subscriber account, such as the public key of the authenticator.

For example, consider an RP that has a collection of cryptographic authenticators that it has purchased for use with FAL3 authentication. These authenticators are each provisioned to a specific RP subscriber account but are held in a controlled environment by the system administrator of the RP. To issue the authenticator, the RP could use an in-person process in which the system administrator of the RP has the subscriber authenticate to an RP-controlled workstation using an FAL3 federation transaction from the IdP. The system administrator then hands the subscriber the bound authenticator indicated by the RP subscriber account and has them authenticate to the workstation using that. The subscriber is now in possession of a bound authenticator supplied by the RP, which can be used to reach FAL3 for future transactions. Alternatively, the system administrator of the RP could send the authenticator to a verified address for the subscriber and have the subscriber verify receipt through an activation process. Since the use of the bound authenticator still requires a valid assertion from the IdP, interception of the authenticator alone is not sufficient for accessing the RP subscriber account at FAL3.

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 federation process. The binding cermony is similar to the subscriber-provided authenticator binding process discussed in Sec. 4.1.3 of [SP800-63B].

If no bound authenticators are associated with the RP subscriber account, the RP SHALL perform a binding ceremony to establish the connection between the authenticator, the subscriber, and the RP subscriber account, as shown in Fig. 5. The RP SHALL first establish an authenticated session using federation with an assertion that meets all the other requirements of FAL3, including an indication that the assertion is intended for use at FAL3 with a bound authenticator (e.g., the assertion contains an authentication class reference or a Vectors of Trust [RFC8485] value indicating this). The subscriber SHALL immediately be prompted to present and authenticate with the proposed authenticator. Upon successful presentation of the authenticator, the RP SHALL store a unique identifier for the authenticator (such as its public key) and associate this with the RP subscriber account that is associated with the federated identifier. If the subscriber fails to successfully authenticate to the RP using an appropriate authenticator, the binding ceremony fails. The binding ceremony session SHALL have a timeout of five minutes or less and SHALL NOT be used as an authenticated session for any other purpose, as described in Sec. 3.9. Upon successful completion of the binding ceremony, the RP SHALL immediately request a new assertion from the IdP at FAL3. Upon receiving the new assertion, the RP SHALL prompt the subscriber for the newly bound authenticator and SHALL validate the authenticator output.

Fig. 5. Subscriber-provided bound authenticator binding ceremony

Sequence diagram of the steps involved in the binding ceremony used for bound authenticators managed at the RP and provided by the subscriber.

Subscriber-provided bound authenticators are particularly helpful when the subscriber already has access to an appropriate authenticator that the RP allows them to use for FAL3 transactions. For example, a subscriber could have a single-factor cryptographic authenticator that uses name-based phishing resistance, as described in Sec. 3.2.5.2 of [SP800-63B]. With such a device, the IdP and RP would see different verification keys when the authenticator is used in each location, meaning that the bound authenticator cannot be easily verified by the IdP. Furthermore, since the RP did not issue the authenticator, the RP does not know the authenticator’s verification key ahead of time, nor does it know which subscriber account to associate with the verification key. Instead, the RP can use a binding ceremony to allow the subscriber to use this device as a bound authenticator at FAL3. A more complete example is found in Sec. 9.7.

An RP MAY allow a subscriber to bind multiple subscriber-provided authenticators at FAL3. If this is the case, and the RP subscriber account has one or more existing bound authenticators, the binding ceremony makes use of one of the subscriber’s existing bound authenticators to reach FAL3. During the initial authentication step of the binding ceremony, the RP SHALL request authentication with an existing bound authenticator to reach FAL3. Once this authentication is complete and the binding ceremony session is established, the RP SHALL request authentication with the new authenticator and associate it with the RP subscriber account as a bound authenticator. The RP completes the binding ceremony by requesting a new assertion at FAL3.

In addition to an RP determining that a bound authenticator is no longer viable, a subscriber could choose to stop using a bound authenticator for a variety of reasons, such as the authenticator being lost, compromised, or no longer usable due to technology and platform changes. In such cases, an RP MAY allow a subscriber to remove a subscriber-provided bound authenticator from their RP subscriber account, thereby removing the ability to use that authenticator for FAL3 sessions. When a bound authenticator is removed, the RP SHALL terminate all current FAL3 sessions for the subscriber and SHALL require reauthentication of the subscriber from the IdP at FAL3. The RP SHALL NOT prompt the subscriber to authenticate with the authenticator being removed, since the subscriber will often not have access to the authenticator in question during the unbinding process, particularly if the authenticator is lost or compromised. If all bound authenticators are removed, the subscriber will no longer be able to reach FAL3 until a new bound authenticator is added to the RP subscriber account. This situation poses similar risks to account recovery at the RP.

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 RP are processed separately. While the subscriber could use the same authenticator during the primary authentication at the IdP as the bound authenticator at the RP, there is no assumption that these will be the same.

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

  1. The subscriber SHALL prove possession of the bound authenticator to the RP in addition to presenting the assertion itself.
  2. For a holder-of-key assertion, a reference to a given authenticator that is found within an assertion SHALL be trusted at the same level as all other information within the assertion, as stipulated in the trust agreement.
  3. The RP SHALL process and validate the assertion in addition to the bound authenticator.
  4. Failure to authenticate with the bound authenticator SHALL result in an error at the RP and SHALL NOT create an authenticated session at the RP.