Clarify differences in refresh token responses

[aaronpk]

Section 5.1

From Vittorio:

On the refresh_token parameter. The lack of details in how OAuth2 describes how/when an AS returns refresh tokens led to today’s complicated situation in which many implementations issue RTs only when OIDC’s offline_access is received in the scopes, as it was the only mention in public specs describing a concrete behavior. See the associated online_access discussion on the OIDC list, as RTs gain importance as session artifacts of sort for SPAs now that implicit is dead and ITP makes iframe renewals problematic. Unfortunately it is too late to be prescriptive here, as we cannot break compatibility with whatever choices existing AS implementations made. However we can be more descriptive and give the reader a better idea of what’s the range of possibilities. Some nonnormative examples of how existing AS determine whether to issue an RT or not (eg as an option determined at client registration time, or any other heuristic you guys encountered in the wild) might help people to better understand their options and the intent of the specification here.

[tlodderstedt]

We should consider to make support for refresh tokens a MUST on the client side. This would allow ASs to issue RTs if needed (either always or based on policy).

Some text on what policies ASs might use would be good as well.

[dickhardt]

Why would the client MUST support a RT if it does not use / need one?

[aaronpk]

The text in 5.1 is now in 3.2.3 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-03#section-3.2.3

[aaronpk]

We'll add a new Security Considerations section for refresh tokens and describe more detail the things mentioned in this paragraph:

Issuing a refresh token is optional at the discretion of the authorization server, and may be issued based on properties of the client, properties of the request, policies within the authorization server, or any other criteria