my bad, Marius is correct On 2010-03-30, at 12:07 PM, Marius Scurtescu wrote:
> 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
