-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.
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
