Document ID: chunk:federal_register_of_legislation:F2024L01443:body:0:p30
Version: federal_register_of_legislation:F2024L01443
Segment Type: other
Provision Reference: 
Character Range: 102076–104946

MUST respond with an authentication error.

 If the acr claim is not marked as essential or no acr value was supplied in the authentication request, then an IXP MUST respond with the level of assurance the individual was able to achieve.

     1.10  User consent

 Given IXPs operate as central trusted entity in the AGDIS, IXPs MUST collect consent of the individual to whom the digital ID relates before redirecting the individual to the client that originated the authentication request.

     1.11  Privacy considerations

 An IXP MUST adhere to all the attribute sharing policies set out in Chapter 2 and Chapter 3 of Schedule 3 (AGDIS Attribute Profile).

     1.12  Security considerations

 All clients of an IXP SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.

2.        Identity service provider

 This Chapter outlines the requirements for:

 1.             IXPs in their role as a TRP to ISPs; and
 2.             ISPs in their roles as OIDC providers to IXPs.

2.1   Client types

 The resource owner password credential grant type as defined in RFC 6749 MUST NOT be used under this Schedule.

 Given an IXP is only acting as a proxy, the Full Client with delegation is the only client available.

2.1.1      Full Client with User Delegation

 This client type applies to clients that act on behalf of a particular resource owner and require delegation of that user's authority to access the protected resource. This client type can interact with a separate web browser application to facilitate the resource owner's interaction with the authentication endpoint of the authorisation server.

 An ISP MUST only support clients of this type.

 All clients of an ISP MUST use the authorisation code flow of RFC 6749 by sending the resource owner to the Authorisation Endpoint to obtain authorisation.

 An ISP MUST ensure that the user authenticates to the Authorisation Endpoint.

 The user's web browser is then redirected back to a URI hosted by the client service, from which the client can obtain an authorisation code passed as a query parameter. The client then presents that authorisation code along with its own credentials (private_key_jwt) to the authorisation server's Token Endpoint to obtain an access token.

 An ISP MUST associate the clients with a unique public key as described in section 2.4 of this Schedule.

 If an ISP issues a refresh token to this type of client, they MUST only do so if the security parameters of the request permit its issuance.

2.2   Client registration

 An IXP MUST register with the authorisation server.

 Each client IXP MUST receive a unique client identifier from the authorisation server. Clients of the authorisation server MUST be statically configured.
 An ISP MUST NOT support the dynamic registration of IXPs.

2.3   Redirect