Refresh Token Cycling about standards-maintenance HOT 17 CLOSED

1. Active revocation by a customer via a dashboard with subsequent notification
2. The establishment of a new consent resulting in the revocation of any previously provided tokens
   In any other scenarios the normative standards apply.

Specifically with relation to Refreshing of tokens the normative standard I believe you are referring to is RFC6749 Section 6:

The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client. If a new refresh token is issued, the refresh token scope MUST be identical to that of the refresh token included by the client in the request.

As I understand it from various responses the ACDS seeks to modify this normative standard from a MAY to a MUST. This has implicit flow on impacts with respect to error handling scenarios whether it be transport, OP or RP side, there are a few variations.

The possible work around here is that a Holder doesn't expire the old refresh token until the new token has been used by the Recipient at least once.

from standards-maintenance.

The process for cycling refresh tokens is covered in the normative references and the standards have not sought to add or constrain those mechanisms beyond setting minimum expectations for expiration times of the resulting tokens. The normative references allow optionality for the authorisation server presents a new refresh token or not.

Under the concept of single, extant consent, and the association of the refresh token with the consent for the purposes of revocation the CDR standards implicitly require that only a single refresh token is active at any one time for a subject.

This means that behaviour is expected to be aligned to option 1 as articulated in the issue description.

from standards-maintenance.

Thanks for the response.

Trying to get this clear, the refresh token MAY be cycled for every access token issued but it must be issued with a lifetime of at least 28 days unless it is replaced ("pseudo revoked") by a subsequent refresh token issuance?

If this is the case and there is a communications error which the recipient detects but the holder does not (ie. a new refresh token is issued but the recipient doesn't receive it) how does a recipient gain access to the consent agreement (sharing_id) again?

from standards-maintenance.

If a refresh token is provided but not received (or lost in some other way) then the sharing arrangement is still in place as far as the holder is concerned but no more requests can effectively be made and the arrangement can not be revoked. In this case authorisation will need to be requested again.

While the CDR standards define expiration constraints on OAuth tokens the meaning and operation of these tokens are defined by the underlying standards and protocols. The case described above would be able to be handled only to the extent that the mechanisms of these standards and protocols allow.

from standards-maintenance.

Not sure why this has been closed after 7 days. Given responses from this Stream are measured in the order of weeks this closure seems premature.

If a refresh token is provided but not received (or lost in some other way) then the sharing arrangement is still in place as far as the holder is concerned but no more requests can effectively be made and the arrangement can not be revoked. In this case authorisation will need to be requested again.

So there will be dangling consents which may need termination when authorisation is requested again? Is that to say the intended behaviour is that a new sharing request will automatically overwrite any existing one? Is this documented in the Standards somewhere?

While the CDR standards define expiration constraints on OAuth tokens the meaning and operation of these tokens are defined by the underlying standards and protocols. The case described above would be able to be handled only to the extent that the mechanisms of these standards and protocols allow.

The difference is that the OAuth standard does not deal with sharing agreements as this is overlaid within ACDS. It also doesn't make explicit statements with respect to retired tokens and immediate termination. That is to say that in the event of a communication failure a relying party can simply issue a new refresh token with the previous token, possibly within some sort of trailing validity period.

Within ACDS refreshing of tokens explicitly and immediately terminates previous ones AND irreversibly updates the association to the sharing agreement.

from standards-maintenance.

As this issue was a query and the query was responded to the issue was closed. Happy to reopen if more clarification is required.

from standards-maintenance.

Closure of a ticket removes reception of messages to the watchers (of which very few have migrated from standards). New ticket created #44

from standards-maintenance.

If a refresh token is provided but not received (or lost in some other way) then the sharing arrangement is still in place as far as the holder is concerned but no more requests can effectively be made and the arrangement can not be revoked. In this case authorisation will need to be requested again.

So there will be dangling consents which may need termination when authorisation is requested again? Is that to say the intended behaviour is that a new sharing request will automatically overwrite any existing one? Is this documented in the Standards somewhere?

The standards currently explicitly allow for single extant consent. This is specified at:
https://consumerdatastandardsaustralia.github.io/standards/#consent

While the CDR standards define expiration constraints on OAuth tokens the meaning and operation of these tokens are defined by the underlying standards and protocols. The case described above would be able to be handled only to the extent that the mechanisms of these standards and protocols allow.

The difference is that the OAuth standard does not deal with sharing agreements as this is overlaid within ACDS. It also doesn't make explicit statements with respect to retired tokens and immediate termination. That is to say that in the event of a communication failure a relying party can simply issue a new refresh token with the previous token, possibly within some sort of trailing validity period.

Within ACDS refreshing of tokens explicitly and immediately terminates previous ones AND irreversibly updates the association to the sharing agreement.

It is the DSB understand (open to correction if something is missed) that explicit revocation of tokens is only stipulated in the standards in two scenarios:

1. Active revocation by a customer via a dashboard with subsequent notification
2. The establishment of a new consent resulting in the revocation of any previously provided tokens

In any other scenarios the normative standards apply.

from standards-maintenance.

Has this query been adequately responded to?

from standards-maintenance.

@perlboy , is there a relation to #52, since there I also highlight the issue of losing sync in refresh tokens? I don't propose a solution, but I think the concerns overlap significantly. I would appreciate your comments there.

In particular, I think the following case also needs to be clarified:

• I have a refresh token from a data holder that performs refresh token cycling
• 20 days before the end of the sharing agreement, I ask for a new token.

Is the new token active for 20 days or 28 days or more? It appears to me that neither possibility can be aligned with refresh token restrictions in the standard.

Nevertheless, for clarity I would favour changing the normative standard from a MAY to a MUST.

from standards-maintenance.

Has this query been adequately responded to?

As I understand it from various responses the ACDS seeks to modify this normative standard from a MAY to a MUST. <-- This was meant to be a question, and leads to a further response regarding documentation of workflows.

@pcurtisrab quite possibly although in the absence of documented sequence flows for these scenarios it's difficult to clarify. Essentially these tweaks of upstream standards have flow-on effects specific to CDS in an environment of relatively high friction and brittle business consent with typically automated protocol interactions. I suspect this looks good on paper but the reality of distributed systems is undiscovered problems that CDR will be on it's own with.

Additionally within the source protocol definition (ie. oauth2) this functionality is not only optional but also relatively untested in the wild. Indications from OIDF FAPI WG members are that even if it is in place, expiry times for refresh tokens are usually significantly longer than the specified minimum and primarily intended to be infrequent in nature (ie. for use cases like encryption key rotation every 3, 6 or 12 months). Further, there is no concept of business logic tied to such a token so it's a bit of a blank space...

I'll hopefully have a chance to get back to evaluating these scenarios over Christmas but at this stage, ultimately in the absence of documented sequence flows, the only thing left is runtime code to deliberately test these scenarios and watch things blow up, how that impacts those working to Feb 1 timeline in relation to backlog items (refreshed refresh token support) and technical debt (broken things that happen down the line) I guess is left to be determined....

from standards-maintenance.

In response to @perlboy:

As I understand it from various responses the ACDS seeks to modify this normative standard from a MAY to a MUST. <-- This was meant to be a question, and leads to a further response regarding documentation of workflows.

No. The standard does not convert this MAY to a MUST. The situations where token revocation is stipulated are in cases of active revocation or the establishment of a new consent that overrides an existing one. These do not relate to refresh token cycling.

In response to @pcurtisrab:

In particular, I think the following case also needs to be clarified:

• I have a refresh token from a data holder that performs refresh token cycling
• 20 days before the end of the sharing agreement, I ask for a new token.

Is the new token active for 20 days or 28 days or more? It appears to me that neither possibility can be aligned with refresh token restrictions in the standard.

This is case is specifically addressed in the standards. The standards state that if refresh token cycling is not used then the expiration of the refresh token should align to the sharing expiration. If refresh cycling is used then the refresh token should have a lifespan longer than 28 days but not beyond the expiration time of the sharing arrangement. In your example the refresh token would then be required to have an expiration time 20 days from when it was issued coinciding with the end of the sharing agreement.

from standards-maintenance.

In response to @perlboy:
No. The standard does not convert this MAY to a MUST. The situations where token revocation is stipulated are in cases of active revocation or the establishment of a new consent that overrides an existing one. These do not relate to refresh token cycling.

Requoting the specific sentence from the RFC and from my prior comment:

"The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client."

And correlating it to the CDS spec:

Data Holders MAY cycle Refresh Tokens when an Access Token is issued.

That is to say that in the RFC definition the authorisation server MAY choose to keep two refresh tokens alive, for instance, until the client (which MUST use the new one IF it receives it) has used it or more arbitrarily with some sort of lagging expiration, thereby ensuring continued ability to token refresh capability.

Within the CDR, as refresh tokens seem to be bound to consent agreements on a 1:1 basis this implication results in the above statement being modified from a MAY to a MUST. This now comes full circle back to my request for clarification 20 November 2019.

So, I ask the question again in a slightly modified way, does the DSB intend to allow Holder's to choose, at their discretion, to associate 2 refresh tokens to exist for a single consent agreement (which would consequently align to the wording contained in RFC6749) or does it intend to alter the statement in RFC6749 from a MAY to a MUST?

If the latter, could the DSB provide details of:

1. What failure scenarios have been considered to mitigate this potentially result in a "dangling consent"
2. Provide guidance of behaviours expected should a replacement refresh token be lost in transit
3. And outline what considerations have been given with respect to the flow on impacts, with specific regard to data minimisation requirements, to a Data Recipient who is now no longer aware of the state of a consent agreement due to a technical loss of access

from standards-maintenance.

So, I ask the question again in a slightly modified way, does the DSB intend to allow Holder's to choose, at their discretion, to associate 2 refresh tokens to exist for a single consent agreement (which would consequently align to the wording contained in RFC6749) or does it intend to alter the statement in RFC6749 from a MAY to a MUST?

No. The standard does not convert the referred to statement in the RFC from a MAY to a MUST. In the token section of the standards the use of refresh cycling is explicitly endorsed with some constraint on the setting of expiry times but, beyond these constraints, the normative standards are stated as applying.

If the latter, could the DSB provide details of:

1. What failure scenarios have been considered to mitigate this potentially result in a "dangling consent"
2. Provide guidance of behaviours expected should a replacement refresh token be lost in transit
3. And outline what considerations have been given with respect to the flow on impacts, with specific regard to data minimisation requirements, to a Data Recipient who is now no longer aware of the state of a consent agreement due to a technical loss of access

It isn't the latter. These considerations are left to the normative standards.

from standards-maintenance.

So on this basis Holder's can, at their discretion, associate >1 refresh token to a single consent agreement?

from standards-maintenance.

Yes, but only in the situation of refresh token cycling. In circumstances of explicit revocation the entire sharing arrangement is understood to be revoked implying that all active refresh tokens are to be expired. Also, the existence of multiple live refresh tokens (arising from cycling) should not imply multiple sharing arrangements for the purposes of consumer presentment via holder dashboards.

All that being said, I would expect most holders in the banking sector to take a relatively conservative position with the handling of refresh tokens. The number of holders taking advantage of the "MAY" scenario is likely to be small.

from standards-maintenance.

If there is no further discussion on this query it will be closed on Friday.

from standards-maintenance.