refresh_token_expires_at claim

[versent1Jas]

Request For Clarification

Scopes and Claims section here , mandates the inclusion of refresh_token_expires_at claim. It is unclear which token must include this claim. It is conflicting to include this in ID token as the OIDC spec here does mention inclusion of refresh token information in Id tokens.

[CDR-API-Stream]

It is implied that the the refresh_token_expires_at claim is included in the refresh token, since that is the token the expiration is associated with. The information in the claim is obtainable via token introspection.

[perlboy]

A little OT but seems to be related, the refresh_token_expires_at field has a fractured standardisation across multiple standards. There is an open issue with FAPI WG (https://bitbucket.org/openid/fapi/issues/251/refresh-token-expiry-time) discussing this also. As a member of FAPI WG I would encourage feedback on the best way forward there also.

[versent1Jas]

@CDR-API-Stream : Thanks for responding , is refresh_token_expires_at claim different to exp: claim mentioned here under Introspection Endpoint. The name of this claim should be consistent in both locations.

[CDR-API-Stream]

The 'refresh_token_expires_at' and 'exp' claim refer to the same thing (the expiration time of a token) but one is specific and one is generic. This difference is equivalent to the 'expires_at' and 'exp' claims applicable to an access token which are part of the normative standards.

The difference in name allows for a generic introspection end point but also allows for both expiration claims to be returned in a single call to the token end point where two different tokens (access and refresh) can be returned.

[versent1Jas]

@CDR-API-Stream : Based on your last response, exp should only be included in the output for token Introspection for refresh Tokens. Thanks for clarifying this.

However, the token to include refresh_token_expires_at claim is still unclear and based on OIDC or OAuth spec, adding claims to refresh tokens is not a standard practice.

Can the sample output be updated to accurately reflect the expectation.
Excerpt from data 61 spec here:

HTTP/1.1 200 OK
Content-Type: application/json
{
"issuer": "https://www.dh.com.au",
"authorization_endpoint": "https://www.dh.com.au/authorise",
"token_endpoint": "https://www.dh.com.au/token",
"introspection_endpoint": "https://www.dh.com.au/introspect",
"revocation_endpoint": "https://www.dh.com.au/revoke",
"userinfo_endpoint": "https://www.dh.com.au/userinfo",
"registration_endpoint": "https://www.dh.com.au/register",
"jwks_uri": "https://www.dh.com.au/jwks",
"scopes_supported": ["openid", "profile", "..."],
"response_types_supported": ["code id_token"],
"response_modes_supported": ["fragment"],
"grant_types_supported": ["authorization_code", "client_credentials", "urn:openid:params:modrna:grant-type:backchannel_request"],
"acr_values_supported": ["urn:cds.au:cdr:2","urn:cds.au:cdr:3"],
"vot_values_supported": ["CL1","CL2"],
"subject_types_supported": ["pairwise"],
"id_token_signing_alg_values_supported": ["ES256", "PS256"],
"request_object_signing_alg_values_supported": ["ES256", "PS256"],
"token_endpoint_auth_methods_supported": ["private_key_jwt"],
"mutual_tls_sender_constrained_access_tokens": "true",
"claims_supported": ["name", "given_name", "family_name", "vot", "acr", "auth_time", "sub", "refresh_token_expires_at", "sharing_expires_at"]
}

[CDR-API-Stream]

The non-normative sample will be updated as requested.

While the inclusion of an expiry claim in a refresh token is not included in OAuth 2 or OIDC it is a relatively common practice and is also an approach adopted in the UK Open Banking standards (which uses a claim with the same name).

[WestpacOpenBanking]

As described in section 1.5 of RFC6749, refresh tokens are strings which are usually opaque to the client. As such, they cannot include claims. We think the intent of the above is not to include the refresh_token_expires_at claim in the ID token and to add a refresh_token_expires_at claim to the response of the token endpoint and would appreciate if this could be confirmed in the documentation.

[pcurtisrab]

Regional Australia Bank's view is that that the refresh_token_expires_at claim is required to be supported as a requestable claim in the ID token. We do not observe a conflict between specifications in this case.

Our reasoning follows:

1. The CDS Scopes and Claims states that refresh_token_expires_at MUST be supported as an "additional claim" along with sharing_expires_at. "Additional claims" are defined in OIDC 5.1.2.
2. Accessing these claims using ID Token or UserInfo is explicitly described in OIDC 5.5. As the two methods for evaluating such additional claims, the ID Token and the UserInfo info endpoint are equally obliged to support them (except for documented exceptions?).
3. Within OIDC, additional claims are not somehow optional by virtue of being "additional".
4. The specifications do mention additional claims which are specifically "ID Token claims" (e.g. nonce, s_hash, c_hash) - as opposed to general claims which are available through both the ID Token and the UserInfo Endpoint. CDS ID Token stipulates that PI claims must not be returned in the ID Token. However, there is no distinction indicating that the refresh_token_expires_at claim should be supported by one method or the other, and therefore it must be supported by both methods. Further, the fact that the standard needs to stipulate that the Standard PI claims should not be returned in the ID Token seems to assume that all other claims are available.

As an aside, we also contend that refresh_token_expires_at must be supported on the same basis as sharing_expires_at since they appear in the same section of CDS.

[CDR-API-Stream]

The analysis provided by @pcurtisrab above is an accurate reading of the standards.

[perlboy]

While I broadly support @pcurtisrab's feedback I note that the naming of claims is governed by JWT Sections 4.2 & 4.3. These standards give guidance that claim names should be IANA registered or use a Public Name. A public name is typically a realmed URI and is utilised by OBIE as http://openbanking.org.uk/refresh_token_expires_at

This is particularly relevant as there is already existing implementations of refresh_token_expires_at and as noted in my previous comments the interpretation used in ACDS is different to that used by OBIE which itself is a subset of that used by other industry implementations. Specifically, ACDS itself appears to make a slight change with respect to null versus "0 value" which, while minor on paper, is very relevant for some software languages.

If it was realmed appropriately (http://cdr.gov.au/refresh_token_expires_at) it would be broadly acceptable but as it stands it collides with an already fractured standardisation of a claim and doesn't follow the designated naming rules. The side note here is that if the discussion in FAPI/OIDF linked does result in standardisation of the base refresh_token_expires_at it will potentially be in conflict with ACDS implementations.