Narrowing scope is one of the most common tools of object-capability systems. It makes it much cheaper to keep deputies from being confused. Check out Ben Laurie, Mark Miller and Caja.
But I sure don't care enough to implement. On May 16, 2010, at 3:01 PM, Luke Shepard wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[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 >> > >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> <ATT00001..txt> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
