My design preference would be to have a new request type. A AS could then support or not support the feature, and it keeps refresh as refresh rather than overloading it.
On Mon, May 10, 2010 at 10:43 PM, David Recordon <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> 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> 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 > > > _______________________________________________ > 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
