Yes; a service that does a one time configuration step, requiring extensive access, followed by an ongoing lower level of access (say, read-only). Lowering access means it only needs to store low-risk tokens in its data store, limiting exposure (and liability).
On Monday, May 10, 2010, Eran Hammer-Lahav <[email protected]> wrote: > Are there actual use cases for this? Either way sounds like it belongs in an > extension. > > EHL > >> -----Original Message----- >> From: Marius Scurtescu [mailto:[email protected]] >> Sent: Monday, May 10, 2010 12:49 PM >> To: Eran Hammer-Lahav >> Cc: Dick Hardt; OAuth WG ([email protected]) >> Subject: Re: [OAUTH-WG] modifying the scope of an access token >> >> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav >> <[email protected]> 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: [email protected] [mailto:[email protected]] On >> >> Behalf Of Dick Hardt >> >> Sent: Sunday, May 09, 2010 7:19 PM >> >> To: OAuth WG ([email protected]) >> >> 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 >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ >> > OAuth mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/oauth >> > > _______________ -- -- John Panzer / Google [email protected] / abstractioneer.org / @jpanzer _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
