Closed Zegnat closed 2 years ago
We took inspiration from OpenID Connect and their profile
as well as email
scopes. In OpenID Connect an access token would be issued with these scopes on it, as it would allow future calls to the UserInfo endpoint to retrieve the information again. This seems to be supported by multiple implementations (Auth0, Google, ...).
For IndieAuth to be compatible with other forms of OAuth extensions (like OIDC), I would propose allowing for access tokens to be created even if the only scope requested is profile
.
If there is a use-case for re-fetching profile information, maybe the profile
object should be returned not only during the exchange step but also in 6.2 Access Token Verification Response? This would allow clients to do the OIDC-like flow of storing a token with profile
scope and retrieving the information whenever they need it.
hopefully this clarifies the confusion:
The unexpected case of a client requesting only the profile
scope and then asking for an access token from the token endpoint isn't necessarily disallowed but isn't well defined in the spec, and that might be okay.
I believe, @Zegnat this was addressed in the recent spec refresh. If this does not address, please reopen.
Because authorization codes can be redeemed at both the authorization and token endpoints in IndieAuth, I am not sure about the intended flow for a code that was requested with only profile scopes.
The request, per 5.3.1., is the same to both endpoints.
From 5.3.2. it says:
But there is no guarantee that a client will behave this way. It may try to exchange the authorization code at the token endpoint.
From 5.3.3. we get:
Do the profile scopes count as scopes here? I believe they do. Does this mean the client can pick which endpoint to use depending on whether they want to be issued an access token or not? In 5.3.4. we seem to get an example of an access token that includes a profile scope, but there it is only one of several scopes.
Could a client have a reason to want an access token that only includes a profile scope and no other scopes?
I also wonder if anything about this changes if we were to make the change from #58. That issue does mention the following (which does not seem to be part of the actual spec today):
This suggests to me that profile scopes are not supposed to count as scopes today?
I think this may need some clarification in the spec, even if we are holding of on #58 until further discussion. Implementers today could be running into ambiguities here.