So, you want to give developers the option to reduce the abilities of their token after it's already been issued? I have never heard a developer ask for this feature.
Beyond the general principle of "least-authority", can you describe a specific case where this would be useful? Are you talking about transferring tokens to a third party, or maintaining multiple tokens of different scopes within the same client? On May 16, 2010, at 10:34 AM, Dick Hardt wrote: John / David: is this a feature you would want to implement? If no one wants it, we can drop it. On Mon, May 10, 2010 at 11:52 PM, John Panzer <jpan...@google.com<mailto:jpan...@google.com>> wrote: (Note that in my use case, it's actually the client who wants to dispose of its dangerous full-access token as quickly as possible, retaining only the least-authority token it needs to continue its ongoing work. This would be the case even if the token granting service is handing out tokens like free candy.) On Mon, May 10, 2010 at 10:43 PM, David Recordon <record...@gmail.com<mailto:record...@gmail.com>> wrote: I'm wondering if this could be achieved by adding an optional scope parameter to the existing refresh request versus creating a new request type. Both because Dick's proposed text requires a refresh token and it seems like services worried about this sort of risk would not want to issue long lived access tokens. --David On Mon, May 10, 2010 at 10:39 PM, John Panzer <jpan...@google.com<mailto:jpan...@google.com>> wrote: > 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<mailto: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<mailto:mscurte...@google.com>] >>> Sent: Monday, May 10, 2010 12:49 PM >>> To: Eran Hammer-Lahav >>> Cc: Dick Hardt; OAuth WG (oauth@ietf.org<mailto: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<mailto: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> >>> >> [mailto: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<mailto: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<mailto:OAuth@ietf.org> >>> >> https://www.ietf.org/mailman/listinfo/oauth >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org<mailto:OAuth@ietf.org> >>> > https://www.ietf.org/mailman/listinfo/oauth >>> > >> _______________ > > -- > -- > John Panzer / Google > jpan...@google.com<mailto:jpan...@google.com> / > abstractioneer.org<http://abstractioneer.org/> / @jpanzer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <ATT00001..txt>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
