Document ID: chunk:federal_register_of_legislation:F2024L01443:body:0:p20
Version: federal_register_of_legislation:F2024L01443
Segment Type: other
Provision Reference: 
Character Range: 72086–74839

is seeking to register by dynamic configuration, an IXP MUST require the TRP provide an initial access token (as defined in RFC 7591).

 If an IXP supports dynamic registration of clients, the IXP MUST implement support for bearer tokens in the manner prescribed in RFC 6750.

1.4   Redirect URI

 An IXP's clients that use the authorisation code grant type MUST register its full redirect URIs.

 An IXP MUST as the authorisation server validate the redirect URI given by the client at the Authorisation Endpoint using strict string comparison.

 An IXP MUST ensure that the redirect URI used by a client is one of the following:

      1.             hosted on a website with TLS protection (HTTPS);
      2.             hosted on a local domain of the client (for example: http://localhost/); or
 3.             hosted on a client specific non-remote protocol URI scheme (for example: myapp:// or au.gov.app://).

 If a client's redirect URI is either hosted on the local domain of the client or hosted on a client specific non-remote protocol URI schema, then a IXP MAY require that the TRP uses the PKCE extension to the authorisation code flow.

 An IXP MUST NOT allow its ASPs to have URIs in more than one of the 3 categories outlined above. An IXP SHOULD NOT allow ASP clients to have multiple redirects URIs on different domains.

1.4.1      Native Client Applications

 The use of client specific non-remote protocol URI schemes SHOULD be phased out for native application.

 An IXP MAY allow existing native application clients to continue using non-remote protocol URI schemes in their redirect URI.

 When a new Native Client Application is running on a platform that supports Claimed HTTPs Scheme URI redirection, an IXP SHOULD require these native applications to use that scheme in their redirect URI.

1.5   Connection to the authorisation server

1.5.1      Client keys

 An IXP MUST require clients using the authorisation code grant type to have a public and private key pair type for use in authentication to the Token Endpoint.

 An IXP MUST require each client to register its public keys in its client registration metadata by either sending the public key directly in the jwks field or by registering a jwks_uri.

 If a client registers a jwks_uri, the IXP MUST require the URI to be reachable by the authorisation server.

 An IXP SHOULD require the use of a jwks_uri as it allows for easier key rotation.

 An IXP MUST reject a jwks field or the content available from a jwks_uri provided by the client if the content does not contain a public key in the format prescribed in RFC 7517.

 As the authorisation server, a IXP MUST verify the content available from a client's registered
 jwks_uri contains a valid JSON Web