Clarification on issueing token with profile scope

[Zegnat]

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:

When the client receives an authorization code that was requested with either no scope or only profile scopes (defined below), the client will exchange the authorization code at the authorization endpoint, [...]

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:

The token endpoint needs to verify that the authorization code is valid, and that it was issued for the matching client_id and redirect_uri, contains at least one scope, [...]

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):

Token endpoints need to be aware that they should not issue an access token if no scope or only profile scopes are issued, only returning the user's profile URL and profile info instead

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.

[Zegnat]

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.

[aaronpk]

hopefully this clarifies the confusion:

• Modified the Profile URL Response section to say "If the client only needs to know the user who logged in" instead of talking about "no scope or only profile scope"
• Modified proposal in Allow clients to always exchange authorization codes at the token endpoint #58 to avoid talking about "only profile scope"
• Modified the Access Token Response section to clarify when to return profile instead of just "optionally"

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.

[dshanske]

I believe, @Zegnat this was addressed in the recent spec refresh. If this does not address, please reopen.