On Fri, Apr 9, 2010 at 1:01 AM, Eran Hammer-Lahav <[email protected]> wrote: > On 4/8/10 4:25 PM, "Marius Scurtescu" <[email protected]> wrote: > >> On Thu, Apr 8, 2010 at 3:36 PM, Eran Hammer-Lahav <[email protected]> >> wrote: >>> This seems reasonable, but it does add more complexity for the client. >> >> True, but not that much. Just an extra request parameter if it wants a >> refresh token. Default could be "no". > > Its a growing list... :-) > > If the client can ask for a refresh token, why not also let it ask for a > secret in each flow, and a username, and specific UI, etc. At some point we > cross a line and the protocol becomes complex (even if rich). I'm asking > where that line is, and if this qualifies as worth of extra complexity. I > don't have an answer.
I'm also prefer to reduce the number of parameters. If an AS returns a refresh token and the Client chooses to ignore it, that's easy code to write. :) >>> The >>> thing is, there is no point in a refresh token if the token lifetime is the >>> same as the access grant. Should the server ignore the client¹s request in >>> such cases? >> >> Lost you. What do you mean by access grant? The refresh token is >> probably unlimited, at least long lived. The client cannot control the >> lifetime of the access token either. > > User approves access to his resources for 2 weeks (the access grant). The > server issues an access token good for 2 weeks. The client asked for a > refresh token (not knowing it is pointless). What should the server do? > > EHL > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
