Document ID: chunk:federal_register_of_legislation:F2024L01443:body:0:p29
Version: federal_register_of_legislation:F2024L01443
Segment Type: other
Provision Reference: 
Character Range: 99422–102304

presented access token.

 An IXP MUST NOT return empty or null values for claims that cannot be fulfilled unless Chapter 2 and Chapter 3 of Schedule 3 (AGDIS Attribute Profile) specifically permits these values for a given attribute set.

 The sub claim MUST always be present in the UserInfo response.

1.8.5      Request Objects

 An IXP operating as OpenID Connect provider MUST accept requests containing a request object signed by the client's private key.

 An IXP MUST validate the signature on request objects using the client's public key.

 An IXP MUST implement support for receiving requests objects encrypted with one of its public keys.

1.8.6      Authentication Context

 An IXP MUST provide an ACR in line with the claims outlined in section 4.4.1.3 of Schedule 3 (AGDIS Attribute Profile).

 An IXP MUST return the acr attained by the individual during authentication at the ISP even if the acr was not marked as essential, the acr_values parameter was used, or no acr value was supplied in the TRP's authentication request.

1.9   Entity information

1.9.1      Claims supported

 An authorisation server MUST return claims on best effort basis. An IXP asserting it can support specific claims does not guarantee it is available for all individuals.

 An IXP MUST only return claims in accordance with data sharing requirements and data formats outlined in Chapter 4 of Schedule 3 (AGDIS Attribute Profile).

1.9.2      Scope profiles

 An authorisation server MUST fulfill scopes on best effort basis.

 An IXP MUST only return scopes in accordance with the data sharing policies and data formats outlined in Chapter 4 of Schedule 3 (AGDIS Attribute Profile).

1.9.3      Valid ACR Claims

 Assurance levels are outlined in section 2.1.3 of Schedule 1 (AGDIS Onboarding Specifications).

 An IXP MUST implement support to allow its PRPs to use either the acr_values or acr claim to request their required ACR.

 An IXP MUST reject any request that include both the acr_values and acr claims.

 When the acr claim is requested an IXP MUST support the acr claim being optionally marked as essential claim by the client. For example:

"claims": {
    "id_token": {
         "acr": {
             "essential": true,
             "values": ["urn:id.gov.au:tdif:acr:ip2:cl3"]
         }
}
}

 Figure 6 Requesting authentication assurance level with claims

 When the acr values are marked as an essential claim, the IXP MUST return a value that matches the requested values.

 If the individual is unable to achieve the required level of assurance outlined in the request and the acr
 claim is marked as essential, then an IXP 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