Empty scope in Token Exchange response

[ctriant]

Hello,

We are facing a situation in our implementation of Token Exchange where the client's requested scope is filtered out to an empty list as a result of applying specific policy restrictions.

I.e the CLIENT_A asks to exchange an access token with another access token by setting a specific set of scopes in the Token Exchange request. However the configured token exchange policy restricts the specific client from asking all the requested scopes.

According to RFC8693 for a successful Token Exchange response:

scope
OPTIONAL if the scope of the issued security token is identical to
the scope requested by the client; otherwise, it is REQUIRED."
since the requested scope is altered then the scope field must be appended to the response.

In addition according to RFC6749 regarding the Access Token Scope:

The authorization server MAY fully or partially ignore the scope
requested by the client, based on the authorization server policy or
the resource owner's instructions. If the issued access token scope
is different from the one requested by the client, the authorization
server MUST include the "scope" response parameter to inform the
client of the actual scope granted."

Based on the references above I think it is rational to permit empty string as a legitimate scope in the Exchange Token and (?) Access Token responses. Any comments?

[rohe]

Interesting! I think that in most cases leaving out scope is interpreted as a scope with no value.
As you've pointed out that doesn't work in the use cases you refer to.
Which logically leads to the conclusion that indeed an empty string should be a legitimate value.

But if you look at the definition of scope (RFC6749 section 3.3) it says:

scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

Which means if I remember my ABNF right, that scope="" is NOT permitted.

[rohe]

Begs the question why would you issue an access token with no scope ?

[ctriant]

I guess there is no reasonable usage of an access token with no scope, so maybe we should just leave oidcmsg as is and raise an appropriate error in oidcop.