Document ID: chunk:federal_register_of_legislation:F2024L01443:body:0:p34
Version: federal_register_of_legislation:F2024L01443
Segment Type: other
Provision Reference: 
Character Range: 113779–116693

described in RFC 6750.

2.6.5      ID Tokens

 An IXP MUST validate the signature of an ID Token before accepting it by using the public key of the ISP that issued it.

 An IXP MAY require an ISP to encrypt the ID Tokens it returns.

 If an ISP supports encrypting ID Tokens, it MUST use the appropriate key of the requesting IXP. An IXP MUST verify the following in received ID Tokens:

       * iss
                + The issue field is the URL of the expected issuer.
       * aud
                + The audience field contains the client ID of the IXP.
       * nonce
                + String value used to associate the client session with the ID Token.
       * exp, iat, nbf
                + The expiration, issued at and not before tokens are dates (integer number of seconds since 00:00:00Z 1st January 1970, i.e. Unix epoch) are within acceptable ranges.

2.6.6      Request Objects

 An IXP MAY optionally send requests to the Authorisation Endpoint using the request parameter as defined in the OpenID Connect Core 1.0.

 An IXP MUST sign the request object with its registered key.

 An IXP MAY encrypt the request object using the ISP's public key.

2.6.7      Discovery

 An IXP MAY cache the ISP's OIDC provider metadata once the ISP has been discovered and used by that IXP.

2.7   Identity Provider Profile

 An ISP providing authentication services to an IXP using OpenID Connect Core 1.0 MUST implement this Schedule.

2.7.1      Audit Logging

 An ISP MUST log all authentication requests and responses, including the values of the client_id
 and the state parameters associated with the request.

2.7.2      Connecting to clients

          2.7.2.1                  Grant types

 The only supported grant type is authorization_code.

 The authorisation code flow is the only authentication flow support under this Schedule. The authorisation code flow returns an Authorisation Code to the client that the client can then exchange for an ID Token and an Access Token. This provides the benefit of not exposing any tokens to the User Agent and potentially malicious applications with access to the User Agent.

 The ISP MUST validate all redirect URIs for the authorization_code grant type.

          2.7.2.2                  Client authentication

 An ISP MUST enforce client authentication for access to the authorisation server's Token Endpoint.

 An ISP MUST only authenticate clients using the private_jwt_key method as prescribed in the OpenID Connect Core 1.0.

 An ISP's authorisation server MUST NOT authenticate clients using any other method.

 The JWT used to authenticate the client MUST expire and have a lifetime of no longer than 300 seconds.

 An ISP's authorisation server MUST reject a JWT with an expiry time that has passed. An ISP SHOULD:
      1.             allow for clock skew of 300 seconds between systems when assessing the expiry of a JWT; and
      2.