This must be an editing error. Version 0.9.7.2 of the spec requires exactly the other way around, the correct way: Client Account and Password (5.1) does not return a refresh token, and Username and Password (5.3) requires a refresh token to be returned.
Marius On Tue, Mar 30, 2010 at 2:34 PM, Brian Eaton <[email protected]> wrote: > Still working on security considerations. I'm comparing these two > profiles based on passwords: > > http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.1 > - this is probably used by automated tasks. > - the password can be assumed to be high-entropy, since no one > needs to remember it. > - why is this profile returning a refresh token? AFAICT, it is not > useful. When the access token expires, the client can use the client > password to get a new one. > > http://tools.ietf.org/html/draft-hardt-oauth-01#section-6.1 > - this is probably used by installed applications > - the password is low-entropy, it belongs to a human being. > - this profile *should* return a refresh token, because otherwise > the installed application needs to save the password in order to get > long-lived access to user data. > > Thoughts? > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
