refresh token expiry time

[Joseph Heenan]

Both the UK ( https://github.com/OpenBankingUK/read-write-api-docs-pub/blob/v3.1.3-draft1/profiles/read-write-data-api-profile.md#token-expiry-time ) and Australian ( https://consumerdatastandardsaustralia.github.io/standards/#scopes-and-claims ) standards define (different ) ways to pass back the refresh token expiry time.

It may make sense for FAPI to define a standard mechanism?

[Ralph Bragg]

Would be grand - The standard alternative was to allow the RP’s to introspect the refresh token post it being returned, this has been implemented by a couple of vendors.

[Stuart Low]

I hadn’t recognised that OBIE and CDS were not aligned. I agree standardising this is a good idea although perhaps this is beyond FAPI as it seems like something various OPs globally have solved in a variety of ways? Any ideas on vendor coverage? Any clear majority?

Regarding the OBIE vs. CDS divergence, I will migrate what was previously a custom claim in Profile Specific to Non-Spec Compliant Changes and link to this thread.

[Joseph Heenan]

Stuart pointed out linkedin uses another slightly different variation:

‌

https://developer.linkedin.com/docs/Refresh-Tokens-with-OAuth-2#

‌

and there’s a thread on this on the connect working group here:

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20190826/thread.html

[Stuart Low]

Just adding a footnote here regarding FAPI compared to CDS. The rename of the claim is one element however there appears to be a change in business rule behaviour with respect to if the claim is present when token is not supplied. In FAPI I believe it is specifically ABSENT while in CDS it is “a zero value”. null != 0 || ““ || “0”

[Stuart Low]

As discussed on call, the two main variations of this I’ve seen are refresh_token_expires_at with an epoch and refresh_token_expires_in with a countdown of seconds. OBIE realms refresh_token_expires_at but the value format (numeric epoch) remains the same. ACDS it is unrealmed but it MUST be provided with a “zero value” supplied if no refresh token is in use.

Considering fractured adoptions, perhaps at least optional support for both a registered set of refresh_token_expires_at and refresh_token_expires_in could be a starting point?

[Joseph Heenan]

discussed on 16th Oct WG bug call and suggestion was this should be raised up to see if the openid connect WG have any appetite for standardising it.

[Stuart Low]

Interesting additional note here and raised by another ACDS participant. The exp claim at the refresh token introspection endpoint at least within ACDS appears to be the same as it’s refresh_token_expires_at. LinkedIn’s addition of refresh_token_expires_in seems to be an alternative to avoid offering token introspection (which they don’t appear to support).

As per RFC7662 it would seem the addition of this claim is only necessary for when introspection endpoints are not mandated within the deployment environment or where the participants want to avoid the need for a call back to retrieve it?

[Tom Jones]

Claims are mandated by the RP. Some standard may have an opinion, but people do what the feel necessary and possible.

[Stuart Low]

@Tom Jones The challenge I see here is claims with same or very similar names having different interpretations. This makes it challenging environments where implementers are building for multiple standards in a single platform.

[Ralph Bragg]

It’s a fair shout - an IANA registry for clams or a standard for identify the claims as unique resource would be useful however back to an earlier point. knowing where a refreshtoken will expire is a common feature so really it should be an oAuth or connect core respoinsibility to specify it.

[Dave Tonge]

I don’t think this should be added to the FAPI spec and propose we close.

[Dave Tonge]

Closing as no activity