On Wed, Jun 16, 2010 at 8:49 AM, Justin Richer <[email protected]> wrote: > We're looking at using the rescope operation to support redelegation, > and in this we wouldn't want to give the second client a refresh token > of their own, just an access token that is good for a subset of scopes > attached to the original refresh/access combination that the user > authorized. I'm not seeing a use case for asking for a new refresh token > using an existing refresh token as auth, though. Could you elaborate > what this might be?
Looking at the beginning of this thread, there is a proposal to return each scope as a separate token. This is presumably a separation of trust issue that the client would like to enforce. >From a protocol perspective, it would be simpler to exchange the new refresh token for one with fewer privileges instead of requesting/receiving one token per scope. > > -- Justin > > On Wed, 2010-06-16 at 11:32 -0400, Eran Hammer-Lahav wrote: >> The refresh token represents what the resource owner authorized. The >> access token can be a subset of that. The current draft already >> supports asking for less scope than was granted. It doesn’t support >> asking for a new refresh token with less scope. Well, what about just returning a refresh token with the access token when the requested set of scopes for the access token is stricter? Of course, in the user-agent flow there is no refresh token. >> >> >> >> EHL >> >> >> >> From: Breno [mailto:[email protected]] >> Sent: Wednesday, June 16, 2010 8:17 AM >> To: Eran Hammer-Lahav >> Cc: Torsten Lodderstedt; OAuth WG ([email protected]) >> Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single >> authorization flow >> >> >> >> Alternative proposal. Create a new call for 'dropping privileges' >> where a client can present a single refresh token and scopes and >> obtain a new refresh token/access token with defined scopes provided >> that these scopes were already granted to the original token. >> >> The advantage of a separate call is that it has less impact in >> implementations because it does not modify existing flows. It is also >> more flexible. For instance it would allow a client too split its >> privileges into tokens with overlapping scopes for arbitrary >> requirements around security and functionality of delegating its >> privileges. >> >> On Jun 11, 2010 1:12 PM, "Eran Hammer-Lahav" >> <[email protected]> wrote: >> >> I'll let you know when I see the I-D :-) >> >> EHL >> >> >> > -----Original Message----- >> > From: Torsten Lodderstedt [mailto:[email protected]] >> > Sent: F... >> > > > -- Breno de Medeiros _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
