Document ID: chunk:federal_register_of_legislation:F2024L01443:body:0:p37
Version: federal_register_of_legislation:F2024L01443
Segment Type: other
Provision Reference: 
Character Range: 122173–125777

as per section 3.1.3.3 (Successful Token Response) of the OpenID Connect Core 1.0.

 An ISP MAY also include a Refresh Token in the Token Response.

          2.7.6.1                  ID Token
An ISP MAY encrypt ID Tokens using the appropriate key of the requesting IXP.
An ISP issued ID Token MUST expire with a lifespan of no longer than 300 seconds.
An ISP SHOULD assign lifespans shorter than 300 seconds to the ID Tokens it issues.
An ISP issued ID Token MUST contain the following fields that are defined as REQUIRED.

       * iss
                + REQUIRED. The issuer field is the URL of the expected issuer.
       * aud
                + REQUIRED. The audience field contains the client ID of the client.
       * sub
                + REQUIRED. The identifier of the user. Note it MUST be a pairwise anonymous identifier and be unique to the client's OpenID Sector.
       * acr
                + REQUIRED. This is the level of assurance at which the user was authenticated at.
       * nonce
                + If a nonce value was supplied with the authentication request, then this value is REQUIRED.
       * jti
                + REQUIRED. A unique identifier for the token which can be used to prevent the reuse of the token.
       * exp, iat, nbf
                + REQUIRED. The expiration, issued at, and not before timestamps for the tokens. They are dates presented as an integer representing the number of seconds since 1970-01-01T00:00:00Z UTC (Unix epoch) within acceptable ranges.
The following is an example of an ID token signed using the server's RSA key.
eyJhbGciOiJSUzI1NiJ9.eyJhdXRoX3RpbWUiOjE0
MTg2OTg3ODIsImV4cCI6MTQxODY5OTQxMiwic3ViI
joiNldaUVBwblF4ViIsIm5vbmNlIjoiMTg4NjM3Yj
NhZjE0YSIsImF1ZCI6WyJjMWJjODRlNC00N2VlLTR
iNjQtYmI1Mi01Y2RhNmM4MWY3ODgiXSwiaXNzIjoi
aHR0cHM6XC9cL2lkcC1wLmV4YW1wbGUuY29tXC8iL
CJpYXQiOjE0MTg2OTg4MTJ9mQc0rtL56dnJ7_zO_f
x8-qObsQhXcn-qN-FC3JIDBuNmP8i11LRA_sgh_om
RRfQAUhZD5qTRPAKbLuCD451lf7ALAUwoGg8zAASI
5QNGXoBVVn7buxPd2SElbSnHxu0o8ZsUZZwNpircW
NUlYLje6APJf0kre9ztTj-5J1hRKFbbHodR2I1m5q

8zQR0ql-FoFlOfPhvfurXxCRGqP1xpvLLBUi0JAw3
F8hZt_i1RUYWMqLQZV4VU3eVNeIPAD38qD1fxTXGV
Ed2XDJpmlcxjrWxzJ8fGfJrbsiHCzmCjflhv34O22
zb0lJpC0d0VScqxXjNTa2-ULyCoehLcezmssg

 Figure 9 Sample ID Token signature

 Its claims are as follows:
{
    "auth_time": 1418698782,
    "exp": 1418699412,
    "sub": "6WZQPpnQxV",
    "nonce": "188637b3af14a",
    "aud": [
        "c1bc84e4-47ee-4b64-bb52-5cda6c81f788"
    ],
    "iss": "https://idp.gov.au/",
    "acr":"urn:id.gov.au:tdif:acr:ip3:cl2",
    "iat": 1418698812,
    "nbf": 1418698812
}

 Figure 10 Claims used to the generate the prior signature

2.7.7      UserInfo Endpoint

 An ISP MUST support returning claims via the UserInfo endpoint as prescribed by the requirements outlined in Schedule 3 (AGDIS Attribute Profile).

 When processing a UserInfo request an ISP MUST only return the claims that are authorised within the authentication request associated with the presented access token.

 An ISP MUST NOT return empty or null values for claims that cannot be fulfilled unless 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.

2.7.8      Request Object

 An ISP MUST accept requests containing a request object signed 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