Document ID: chunk:federal_register_of_legislation:F2024L01443:body:0:p39
Version: federal_register_of_legislation:F2024L01443
Segment Type: other
Provision Reference: 
Character Range: 128157–131012

security considerations in section 10 (Security Considerations) of RFC 6749; and
 2.    SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.

3.        Protocol brokering

 An IXP MUST implement support to broker between the protocols used by its connected ISPs and PRPs.

 The AGDIS only supports the OpenID Connect Core 1.0.

3.1   OIDC to OIDC brokering

 When an IXP is accepting an authentication request from a TRP using OIDC, if the selected ISP implements this Schedule, an IXP MUST interact with the ISP using the ISP technical relying party profile as prescribed in section 2.6 of this Schedule.

       3.1.1         Mapping Claims and Scopes

 If the sub claim is specified it MUST be handled as outlined in section 3.1.2 of this Schedule.

 If the TRP's authentication request includes attributes that are fulfilled by itself or an ASP, an IXP SHOULD NOT forward theses attribute requests to the ISP unless it is necessary.

 All other attributes included in the TRP's authentication request MUST be included in the IXPs authentication request to the ISP in accordance with the attribute sharing policies as prescribed in Chapter 4 of Schedule 3 (AGDIS Attribute Profile).

 An IXP MAY expand the scopes defined in an authentication request into underlying claims when brokering an authentication request to its ISPs and ASPs.

 Scopes and claims not outlined in Schedule 3 (AGDIS Attribute Profile) MUST be ignored by the IXP when brokering an authentication request. The IXP MUST NOT raise an error when scopes and claims are ignored.

       3.1.2         Handling of Subject ID

 An IXP MAY support the sub claim in authentication requests.

 If an IXP implements support the sub claim in authentication requests:

 1.     the IXP MUST resolve the pairwise identifier presented in the sub claim in the authentication request from the TRP to an existing pairwise identifier; and
 2.    the IXP MAY return an error if the pairwise identifier for the user cannot be resolved to the target ISP.

       3.1.3         Mapping assurance levels

 If an IXP receives a single value for the acr_values or acr claim in an authentication request, the IXP MUST pass the set of ACR values that meet or exceed the requested value to the ISP in the brokered authentication request.

 If the acr claim is marked as essential in the authentication request, an IXP MUST mark the acr claim as essential when sending the authentication request to the selected ISP.

 An IXP MUST evaluate the ACR returned from the ISP and if the ACR meets or exceeds the originally requested value(s), return one of the originally requested values.

       3.1.4         Prompt Parameter

 An IXP MUST implement these processing rules to broker the OIDC prompt parameter.

 Table 1 IXP prompt parameter brokering