2.5 Requesting and Processing xALs

Before · SP 800-63C

After · SP 800-63C-4

Requesting and Processing xALs

Before · SP 800-63C

After · SP 800-63C-4

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

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

The IdP SHALL inform the RP of the following information for each federation transaction:

• The IAL of the subscriber account being presented to the RP, or an indication that no IAL claim is being made

• The AAL of the currently active session of the subscriber at the IdP, or an indication that no AAL claim is being made

• The FAL of the federation transaction

The RP obtains this xAL information from a combination of the terms of the trust agreement (see Sec. 3.5 ) and information included in the assertion (see Sec. 4.9 and Sec. 5.8 ). If the xAL is unchanging for all messages between the IdP and RP (e.g., enterprise scenarios in which all subscribers are identity-proofed at the same IAL and use the same authenticator type), the xAL information SHALL be included in the terms of the trust agreement between the IdP and RP. If the xAL could be within a range of possible values specified by the trust agreement, then sufficient information SHALL be included as part of the assertion contents to allow the RP to determine the xALs.

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

The RP SHALL determine the minimum IAL, AAL, and FAL that it is willing to accept for access to any offered functionality and assess all IdP assertions to ensure that these xALs have been met before granting access to protected resources. If IdP responses do not meet the requested parameters, the RP SHALL have a mechanism for addressing these requests (e.g., declining the request or routing the user to an exception handling process). The RP MAY vary its functionality based on the IAL, AAL, and FAL of a specific federated authentication. For example, an RP can allow federation transactions authenticated at AAL2 for common functionality (e.g., viewing the status of a dam system) but require AAL3 to be used for higher risk functionality (e.g., changing the flow rates of a dam system). Similarly, an RP could restrict high-risk functionality (e.g., accessing sensitive information) to only certain subscriber accounts that have been identity-proofed at IAL2 while allowing basic functionality for all subscriber accounts, regardless of IAL.

In a federation process, the RP does not have direct access to the details of the subscriber account that have been provided to the IdP by the CSP, which details determine the IAL for the subscriber account. Additionally, since the RP does not participate in the authentication event or activation event at the IdP, the RP cannot determine the AAL. The RP sees many aspects of the federation transaction that determine the FAL, but the IdP also has its own responsibilities related to FAL, including signaling the IdP’s intended FAL of the federation transaction to the RP. Consequently, the IdP SHALL provide the RP with sufficient information to determine the IAL, AAL, and the IdP’s intended FAL for each federation transaction. This MAY be done in the assertions, through previous arrangement in the trust agreement, or a combination of both.

The RP SHALL ensure that it meets its obligations in the federation transaction for the FAL declared in the transaction. For example, the RP needs to ensure that the presentation method meets the assertion injection protection requirements at FAL2 and above and that the appropriate holder-of-key proof or bound authenticator is presented at FAL3.