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
