certification clarification request: grant_types_supported in discovery

[Joseph Heenan]

Can the FAPI WG provide clarity on their understanding of the discovery spec please, in particular from https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata ‘grant_types_supported’ is defined as:

‌

grant_types_supported
OPTIONAL. JSON array containing a list of the OAuth 2.0 Grant Type values that this OP supports. Dynamic OpenID Providers MUST support the authorization_code and implicit Grant Type values and MAY support other Grant Types. If omitted, the default value is ["authorization_code", "implicit"].

Is it considered compliant for a server to support a grant type (in this case refresh_token) and not list it in grant_types_supported?

[Joseph Heenan]

This was discussed on today’s call.

There was a general consensus the servers “should” list refresh token grant in grant_types_supported (if they support refresh tokens), but there wasn’t a clear conclusion on whether this is a ‘should’ or a ‘must’ - further thoughts are welcome.

[Torsten Lodderstedt]

I think every AS/OP should advertise the features it supports in the discovery document. I cannot preclude that there are legitimate reasons not to advertise some features. I therefore would recommend it.

I also think a OAuth Client should be prepared to handle refresh tokens since it is at the discretion of the AS to issue those. But that’s more a feeling than an advice

[Joseph Heenan]

Discussed again on today’s call and we decided to go with ‘should’ (meaning ‘warning’ in the conformance suite) for this and to close the issue.