Re: [OAUTH-WG] 'Scope' parameter proposal

["Manger, James H" <[e-mail]>]

>    HTTP/1.1 401 Unauthorized
>    WWW-Authenticate: Token realm='Example', scope='x2'

I assume the WWW-Authenticate response header also has an "authz-uri" parameter.

     WWW-Authenticate: Token realm='Example', scope='x2', authz-uri="https://as.example.com/"

The first time a client app gets this response all it can do is add the 'scope' to the 'authz-uri'. In which case the separate 'scope' parameter offered no advantage. The resource server could have more simply returned:

     WWW-Authenticate: Token realm='Example', authz-uri="https://as.example.com/?scope=x2"


The one situation where a 'scope' parameter can help interop (between client with no server-specific knowledge and the server) is when scopes are combined.

A client with a token for scope 'x1' that receives a 401 can request a new token that includes the extra scope 'x2' as well. Even in this situation, defining a 'scope' parameter is not necessary. The resource server knows the offered token was for scope 'x1', but scope 'x2' is required so the response can be:

     WWW-Authenticate: Token realm='Example', authz-uri="https://as.example.com/?scope=x2,x1"

The client just sees a URI and uses it to get a new token. This approach might require some resource servers to dynamically generate the 'authz-uri' value in error responses. I doubt that is too onerous.


An alternative way to support combining scopes would be to include (or reference) an existing token when requesting a new one. For instance, define an 'access_token' parameter to include when redirecting a user to the AS. This would work for updating a token for another 'scope', for a longer duration, for extra 'permissions' etc.
This is not absolutely necessary to define this extra 'access_token' parameter since the resource server could dynamically insert the current token into the returned 'authz_uri' value by itself, without requiring client code to do so.
Another difficulty is that some access_tokens should not be exposed to users. There may need to be an 'access_token_id' separate from the actual 'access_token' value.


In conclusion,
* -1 to Eran’s 'scope' proposal;
* perhaps add explicit support for updating a token (as opposed to refreshing) by referencing an existing token when getting a new one.


-- 
James Manger