Hello.. Despite the fact that it might complicate the spec, I would like to see the ability to get a token secret without having to make an extra refresh token request.. if "secret_type" were added to the request parameters in 3.4.1.2 (Client Requests Access Token), the response could contain the token secret instead of the refresh_token.. Perhaps it isn't as clean in other flows, but at least in this one, I think it's worthwhile..
Not only would this match the interactions in Oauth 1.0 better (easy migration path for those wanting to adopt 2.0), but it eliminates an extra API call.. I imagine that refresh tokens and token secrets are generally mutually-exlusive.. It's unlikely that I will need to expire an access token that is properly signed, so no need for a refresh token.. But, the way the spec is written now, I'm forced to deal with a refresh token just to get the secret, which feels a bit strange.. Though the spec might be simpler as-is, implementation won't be easier for the folks wanting to use token secrets.. Providers will have to manage a new type of token, or at least pretend to (make the refresh and access tokens the same).. And clients will have to make an extra API call per flow execution for no discernable benefit.. My 2 cents, Saleem. -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Friday, April 09, 2010 2:53 AM To: David Recordon Cc: OAuth WG Subject: Re: [OAUTH-WG] Consistency across access token replies >> 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 same holds for token secrets, why not returning them with every response? regards, Torsten. _______________________________________________ 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
