You have to keep track which flow is used with each Request Token either way! The authorization endpoint doesn't include the oauth_version parameter. How else would you know what to show the user and how to redirect it back? Are you simply going to assume clients will not break when you send them an unknown parameter (oauth_verifier)? Are you going to show users of manual entry clients the verification code anyway, even if the client uses the old flow?
Using separate endpoints isn't that complex or confusing and is as easy to transition and retire. For all new clients you only show the new endpoints. For all existing clients you help them transition to the new endpoints and flow. At some point you shut down the old endpoints without having any impact (unintentional) on the new endpoints. The oauth_version in underspecified in the specification. I know why I had it added to the protocol but I agree that it doesn't really matter much at this point. If you read my previous posts on the topic, you can see that it should be incremented when we change how authenticated requests are made. That is, if we change how the nonce, timestamp, signature method, token, and signature parameters are set, used, and transmitted. I am well aware I sound like a broken record... OAuth has two layers. One layer is a client-server authentication method and the other is an authorization flow (which uses 3 endpoints, 2 of which use the client-server authentication method). My opinion is that if we change the client-server authentication method, we should increment the wire version. EHL > -----Original Message----- > From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf > Of David Parry > Sent: Friday, May 01, 2009 11:53 PM > To: OAuth > Subject: [oauth] Re: Version Preference > > > Using the current draft, SPs now have to be able to determine/detect > the spec version being used (1.0 or 1.0a). This can be achieved by > either sending the oauth_callback when a request token is obtained or > by using alternate endpoints as you suggested. The SP now has to > essentially store the version of the auth flow used when the request > token was obtained. Then in the auth and access token phases, use this > stored version to determine to if the oauth_verifier is required. > > IF the oauth_version WAS incremented to 1.1, I wouldn't have to > maintain prior knowledge of which auth flow was used. In the authorize > phase, I would always return the oauth_verifier. Then when an Access > Token is requested, for oauth_version 1.1, I would enforce that the > oauth_verifier was required and for oauth_version 1.0, I would verify > oauth_verifier if it was sent. > > The benefits of using the latter method (at least for me)... > 1. The required changes are a lot easier to implement > 2. I can easily deprecate oauth_version 1.0 when I want > 3. I don't have to maintain multiple endpoints for my consumers, which > is going to be confusing > > My main gripe about not incrementing the oauth_version, if it's not > going to be incremented when we are fixing a flaw which it at the > heart of OAuth, when would it ever be incremented ? And If it's not > ever going to change why even have it ? > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
