Re: [OAUTH-WG] modifying the scope of an access token

On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> This would only work for the client credentials flow (because you keep the same authorization source). For all other flows you are breaking the authorization boundaries.

If the requested scope is a subset of the original scope associated
with the refresh token then it should be acceptable, right?

This would allow a client to request a larger set of scopes, needed
for all API calls need for its function, but then get sub-scoped
access tokens, particular to each API. This will prevent an API from
receiving a too powerful access token. A compromised API could use
access tokens to place calls against other APIs, but not if it is
narrowly scoped.

Marius

>
> What would be useful is to allow asking for more scope. For example, when asking for a token (the last step of each flow), also include a valid token to get a new token with the combined scope (new approval and previous).
>
> EHL
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Dick Hardt
>> Sent: Sunday, May 09, 2010 7:19 PM
>> To: OAuth WG (oauth@ietf.org)
>> Subject: [OAUTH-WG] modifying the scope of an access token
>>
>> There has been some discussion about modifying the scope of the access
>> token during a refresh. Perhaps we can add another "method" to what the
>> AS MAY support that allows modifying the scope of an access token. Type of
>> request is "modify" and the scope parameter is required to indicate the new
>> scope required. Suggested copy below:
>>
>> type
>>       REQUIRED. The parameter value MUST be set to modify
>>
>> client_id
>>       REQUIRED. The client identifier as described in Section 3.4.
>>
>> client_secret
>>       REQUIRED if the client was issued a secret. The client secret.
>>
>> refresh_token
>>       REQUIRED. The refresh token associated with the access token to be
>> refreshed.
>>
>> scope
>>       REQUIRED. The new scope of the access request expressed as a list
>> of space-delimited strings. The value of the scope parameter is defined by
>> the authorization server. If the value contains multiple space-delimited
>> strings, their order does not matter, and each string adds additional access
>> range to the requested scope.
>>
>> secret_type
>>       OPTIONAL. The access token secret type as described by Section 8.3.
>> If omitted, the authorization server will issue a bearer token (an access token
>> without a matching secret) as described by Section 8.2.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>