Document ID: chunk:federal_register_of_legislation:F2024L01443:body:0:p25
Version: federal_register_of_legislation:F2024L01443
Segment Type: other
Provision Reference: 
Character Range: 87283–90321

tokens are dates (integer number of seconds since 00:00:00Z 1st January 1970, i.e. Unix epoch) are within acceptable ranges.

1.7.4      Request to the UserInfo Endpoint

 An IXP MUST be able to accept UserInfo Request from clients using either the HTTP GET or POST methods.

 An IXP MUST only accept Access Tokens from its clients when presented as Bearer Tokens, as outlined in the RFC 6750.

1.7.5      Request Object

 A client MAY send request to the authorisation end point using the request parameters as outlined in OpenID Connect Core 1.0.

 Request objects MUST be signed by the client's public key.

 A client MAY encrypt the request object with the authorisation server's public key.

1.7.6      Discovery

 Clients and protected resources MAY cache an IXP's OpenID Connect metadata once the IXP has been discovered, as outlined in this Schedule.

1.8   Identity Exchange OpenID Connect provider Profile

1.8.1      Connecting to clients

          1.8.1.1                  Grant types

 The authorization_code grant type is the only grant type that is supported under this Schedule. Accordingly, an IXP MUST only support the authorization_code grant type when fulfilling PRP authentication requests for individuals.

 The authorisation code flow returns an authorisation code to the client. The client can then exchange this one-time code 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.

          1.8.1.2                  Client authentication

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

 An authorisation server MUST only authenticate clients using the private_key_jwt method as prescribed in the OpenID Connect Core 1.0.

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

 The JWT used to authenticate the client MUST expire with a lifetime no longer than 300 seconds. An authorisation server MUST reject an JWT with an expiry time passed.
 An authorisation server SHOULD:

 1.             allow for clock skew of 300 seconds between systems when assessing the expiry of a JWT; and
 2.             reject any JWT with expiry that is unreasonably far into the future.

 The JWT MUST contain the following REQUIRED claims and MAY contain the following OPTIONAL claims:

  *          iss

  *          sub

  *          aud

  *          jti

    * REQUIRED. Issuer. This MUST contain the client_id of the client creating the token.

    * REQUIRED. Subject. This MUST contain the client_id of the client creating the token.

    * REQUIRED. Audience. The value that identifies the authorisation server as an intended audience. The authorisation server MUST verify that it is an intended audience for the token. The Audience MAY be the URL of the authorisation server's Token Endpoint.

    * REQUIRED. JWT ID. A unique identifier for the token generated by the client, which