Are you actually (planning on) writing something like this? EHL
> -----Original Message----- > From: John Panzer [mailto:jpan...@google.com] > Sent: Monday, May 10, 2010 10:40 PM > To: Eran Hammer-Lahav > Cc: Marius Scurtescu; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] modifying the scope of an access token > > 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 <e...@hueniverse.com> > wrote: > > 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 > >> > > > _______________ > > -- > -- > John Panzer / Google > jpan...@google.com / abstractioneer.org / @jpanzer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
