On Sat, Apr 17, 2010 at 1:33 AM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > -1 to this > > If a refresh token is the only way to obtain an access token with > corresponding secret than making refresh tokens an optional result parameter > will not suffice.
I think Eran is going to change that IIRC. > How shall the client indicate that it requires a request token? From my > point of view, either refresh tokens become a mandatory parameter or the > client is given an input parameter to indicate its desire with every flow. > > My suggestion is to add "secret_type" to all flows and to issue request > tokens where they are really needed. In all flows, where user interaction > takes place or user credentials are processed. > > My impression is, the API design is slowly getting weird because we want to > circumvent this single parameter. > > regards, > Torsten. > > Am 16.04.2010 18:24, schrieb Mark Mcgloin: >> >> +1 to this >> >> Mark McGloin >> >> >>> >>> On 16/04/2010 17:08, Richard Barnes<rbar...@bbn.com> wrote: >>> >> >> >>> >>> Sure, this seems sensible, especially with the *optional* part. >>> >> >> >> >>> >>> On Apr 15, 2010, at 3:22 PM, David Recordon wrote: >>> >> >> >>>> >>>> +1, remember discussing this a week or so ago on the list >>>> >>>> >>>>> >>>>> On Thu, Apr 15, 2010 at 12:12 PM, Eran Hammer-Lahav >>>>> >> >> <e...@hueniverse.com >> >>>>> >>>>> wrote: >>>>> >>>> >>>> Proposal: Keep bearer tokens as the default first-issued credential >>>> and add >>>> an optional refresh token everywhere. >>>> >>>> EHL >>>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
