Closed anzbankau closed 2 months ago
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.
This proposed change could result in the following -
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 asharing_duration
was not requested in the authorisation request object then a zero value should be returned.
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.
refresh_token_expires_at
and sharing_expires_at
in the Non-normative Examples.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.
This issue was discussed in the 20th March Maintenance Iteration call.
This change has been staged for review here: https://github.com/ConsumerDataStandardsAustralia/standards-staging/compare/release/1.30.0...maintenance/543
As discussed:
exp
claim in "tokens" as tokens involving the relevant exp
are opaque. Should be exclusively introspection endpoint.Thanks @perlboy Re: your points -
Standards version 1.30.0 was published on 24/04/2024 incorporating this change from MI18.
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:
DSB Proposed Solution
The proposed solution can be found through the staging link provided in this comment.