Are there actual use cases for this? Either way sounds like it belongs in an extension.
EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Monday, May 10, 2010 12:49 PM > To: Eran Hammer-Lahav > Cc: Dick Hardt; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] modifying the scope of an access token > > On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav > <e...@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-boun...@ietf.org [mailto:oauth-boun...@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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
