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