refresh_token_expires_at and sharing_expires_at claims listed as MUST be supported

[anzbankau]

Description

Currently there is conflicting information in the standards about the ID token claims 'sharing_expires_at' and 'refresh_token_expires_at'. The ‘Token Expiry’ section states these claims may be retired from 16th September, however the ‘Scopes and Claims’ section lists that these claims must be supported.

Area Affected

https://consumerdatastandardsaustralia.github.io/standards/#scopes-and-claims

Change Proposed

Remove statements from ‘Scopes and Claims’ section that state 'sharing_expires_at' and 'refresh_token_expires_at' must be supported:
The following additional claims MUST be supported:

• refresh_token_expires_at: indicates the date-time at which the most recently provided refresh token will expire. Its value MUST be a number containing a NumericDate value, as specified in section 2 of section 2 [JWT]. If no refresh token has been provided then a zero value should be returned.
• sharing_expires_at: indicates the date-time at which the current sharing arrangement will expire. Its value MUST be a number containing a NumericDate value, as specified in section 2 of [JWT]. If consent is not complete or a sharing_duration was not requested in the authorisation request object then a zero value should be returned.

DSB Proposed Solution

The proposed solution can be found through the staging link provided in this comment.

[nils-work]

Thanks @anzbankau

It appears that the MUST statements you've referred to should have also been removed when the following details in the Token Expiry section were removed, as the obligation had passed by version 1.25.0 (8 July 2023) -

Until September 16th 2022: The Data Holder MUST indicate the expiration time of the refresh token using the refresh_token_expires_at claim.
From September 16th 2022 (FAPI 1.0 Migration Phase 2) Data Holders MAY retire "sharing_expires_at" and "refresh_token_expires_at" claims.

[nils-work]

This proposed change could result in the following -

1. Remove the section quoted below from the Scopes and Claims section -

The following additional claims MUST be supported:

• refresh_token_expires_at: indicates the date-time at which the most recently provided refresh token will expire. Its value MUST be a number containing a NumericDate value, as specified in section 2 of section 2 [JWT]. If no refresh token has been provided then a zero value should be returned.
• sharing_expires_at: indicates the date-time at which the current sharing arrangement will expire. Its value MUST be a number containing a NumericDate value, as specified in section 2 of [JWT]. If consent is not complete or a sharing_duration was not requested in the authorisation request object then a zero value should be returned.

2. Replace the following sentence under Requesting Sharing Duration -

The Data Recipient Software Product is able to obtain the expiration of sharing via the sharing_expires_at claim.

with -

The Data Recipient Software Product is able to obtain the expiration of sharing via the exp field in tokens and the introspection endpoint.

3. Remove references to refresh_token_expires_at and sharing_expires_at in the Non-normative Examples.

[nils-work]

Attendees of the 6 March Maintenance Iteration call discussed the implications of removing outdated statements related to the refresh_token_expires_at field.

For context; statements noting that '[From September 16th 2022] Data Holders MAY retire "sharing_expires_at" and "refresh_token_expires_at" claims' were included in the standards from version 1.15.0 (23/12/2021) until version 1.24.0 (07/05/2023), however there are still related statements in the current Standards declaring that they 'MUST be supported'.

There was feedback that calling the introspection endpoint after each token collection call would increase load on Data Holders.
The DSB considers that this should not occur as refresh token cycling is disallowed, and repeated introspection calls should yield the same exp value.

One attendee noted that while refresh_token_expires_at is not part of a normative standard, it is commonly used, and where it is supported by a data holder, there could be a requirement placed on Data Recipients to use it rather than performing introspection.

The DSB does not consider that such a requirement is necessary to be added to the Standards, and it could be in opposition to Decision 209 - Transition to FAPI 1.0 Advanced Profile (16/12/2021) which incorporated feedback to the original design questions:

• Feedback identified that the "sharing_expires_at" and "refresh_token_expires_at" claims can be retired once refresh token cycling has been deprecated. This would simplify the token response and remove redundant claims. The normative "exp" claim would represent the expiry time of the authorisation and consequently the sharing arrangement.

As the proposed change would ensure the Standards are aligned to that decision, and it does not preclude the use of the previous fields where supported, it remains the preferred approach and is considered to be a non-breaking change.

Any further comments are welcome.

[nils-work]

This issue was discussed in the 20th March Maintenance Iteration call.

• Attendees discussed implications for possible future requirements, and the binding between refresh token expiry and arrangement expiry.
• One attendee that does not provide these claims noted that they had not experienced any notable impact to service load due to introspection requests.
• It was suggested that new claims or other solutions may be introduced to better suit future requirements as necessary.
• The Change Proposed was generally accepted.

[nils-work]

This change has been staged for review here: ConsumerDataStandardsAustralia/standards-staging@release/1.30.0...maintenance/543

[perlboy]

As discussed:

1. There shouldn't be a reference to the exp claim in "tokens" as tokens involving the relevant exp are opaque. Should be exclusively introspection endpoint.
2. There is a question of interoperability as the claims are retired. Suggestion is to instead introduce a REQUIRED statement for Recipients to utilise the Holder discovery document (which would include the supported claims)

[nils-work]

Thanks @perlboy
Re: your points -

1. The staging link for the proposal should now show the updated wording.
2. A statement about requiring recipients to use the discovery document is not deemed to be necessary at this time, as it is assumed they have already had to deal with the transition, due to the earlier retirement statement and the corresponding changes adopted by some data holders.

[nils-work]

Standards version 1.30.0 was published on 24/04/2024 incorporating this change from MI18.