- changed status to open
certification clarification request: grant_types_supported in discovery
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?
Comments (7)
-
-
reporter 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.
-
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
-
reporter - changed status to closed
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.
-
- changed component to Part 2: Advanced
-
- changed component to FAPI 1 – Part 2: Advanced
-
- changed component to FAPI 1: Advanced
- Log in to comment