Document ID: chunk:federal_register_of_legislation:F2024L01443:body:0:p38
Version: federal_register_of_legislation:F2024L01443
Segment Type: other
Provision Reference: 
Character Range: 125511–128451

by the requesting IXPs private key. An ISP MUST validate the signature on request objects using the requesting IXP's public key.
 An ISP MUST implement support for receiving requests objects encrypted with one of its public keys.

2.7.9      Authentication context

 An ISP MUST return the ACR value used for the authentication even if the acr claim was not marked as essential or the acr_values parameter was used.

2.8   Entity information

2.8.1      Claims supported

 IXPs and ISPs MUST return claims on a best effort basis.

 An ISP or its connected IXPs asserting it can provide a user claim does not imply that the data is available for all users.

 An IXP MAY returns claims outside of the claims_supported list but MUST ensure that they do not violate the data sharing and privacy constraints where prescribed under one or more of the following:

 1.             the Act;
 2.             the Accreditation Rules;
 3.             the Digital ID Rules; or
 4.             the Accreditation Data Standards.

2.8.2      Scope profiles

 An ISP MUST implement the OpenID Connect support ISP specific scopes and claims outlined as in Schedule 3 (AGDIS Attribute Profile).

2.8.3      Valid ACR Claims

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

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

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

 When the acr claim is requested, an ISP 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 11 Sample assurance level requests using claims

 When the acr values are marked as an essential claim, the ISP 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 ISP MUST respond with an authentication error.

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

2.9   Privacy Requirements

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

     2.10  Security Considerations

 All clients of an ISP:

 1.     MUST comply with the security considerations in section 10 (Security Considerations) of RFC 6749; and
 2.    SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.

3.        Protocol brokering

 An IXP MUST implement support to broker between the protocols used