The text is in -04. -02 made the refresh token available in token refresh. EHL
> -----Original Message----- > From: Torsten Lodderstedt [mailto:[email protected]] > Sent: Sunday, May 09, 2010 2:57 PM > To: Eran Hammer-Lahav > Cc: OAuth WG ([email protected]) > Subject: Re: [OAUTH-WG] Refresh tokens security enhancement > > Hi Eran, > > I cannot find this text in -02 or -03. Would you please refer my to the > respective page/section? > > regads, > Torsten. > > Am 09.05.2010 19:56, schrieb Eran Hammer-Lahav: > > Draft -02 made this possible already. > > > > I added the following text: > > > > The authorization server MAY issue a new refresh token in which > > case > the client MUST NOT > > use the previous refresh token and replace it with the newly issued > refresh token. > > > > EHL > > > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On > >> Behalf Of Torsten Lodderstedt > >> Sent: Wednesday, May 05, 2010 12:28 PM > >> To: Marius Scurtescu > >> Cc: OAuth WG ([email protected]) > >> Subject: Re: [OAUTH-WG] Refresh tokens security enhancement > >> > >> Am 04.05.2010 21:44, schrieb Marius Scurtescu: > >> > >>> On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt > >>> <[email protected]> wrote: > >>> > >>> > >>>> Am 03.05.2010 18:55, schrieb Allen Tom: > >>>> > >>>> > >>>>> Invalidating the Refresh Token (and presumably also invalidating > >>>>> any outstanding Access Tokens) would make sense as an option for > >>>>> applications that require a high level of security. However, I do > >>>>> not think that invalidating the Refresh Token on every Refresh > >>>>> request should be required in the spec - it should be an > >>>>> implementation > >>>>> > >> specific detail. > >> > >>>>> > >>>>> > >>>> It could be an optional feature of the spec (as many other features). > >>>> > >>>> > >>> Torsten, can you please have a look a the "explicit request for > >>> refresh token" thread? > >>> > >>> Would a "refresh_token_type=single" parameter solve the above? > >>> > >>> > >>> Marius > >>> > >>> > >> Hi Marius, > >> > >> I expected the authorization server to decide which kind of token to use. > >> Your proposal makes sense as well. > >> So the client can act according to its security requirements. If the > >> authorization server would like to enforce its own policy, it can > >> detect any mismatch during token issuance. > >> > >> Nevertheless, support for the optional "refresh_token" response > >> parameter of the "refresh" request is the prerequisite. > >> > >> regards, > >> Torsten. > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
