[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 -~--~~~~--~~--~--~---
[oauth] Re: Desktop Application Callback Value
On May 2, 2:19 am, Brian Eaton bea...@google.com wrote: On Fri, May 1, 2009 at 1:43 AM, Blaine Cook rom...@gmail.com wrote: 1. None. Applications that cannot receive callbacks (or that have static callback endpoints) should be configured as such in an out-of-band flow, along with the service provider issues the consumer key and secret. Just because the callback is preregistered doesn't mean an application won't want to update it at runtime. For example, they might want to add session state information or language preference information. We allowed for this with our implementation by returning any additional Consumer query parameters that were provided in the authorize url. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] Re: Version Preference
Option 3 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] Re: Version Preference
You're trying to maximize interoperability between the new and flawed spec. ie. SP 1.0 - Consumer 1.0a SP 1.0a - Consumer 1.0 On May 2, 11:22 am, Eran Hammer-Lahav e...@hueniverse.com wrote: I have no idea what point you are trying to make. Specifications are about interoperability (what else would it be about?). EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of David Parry Sent: Friday, May 01, 2009 5:57 PM To: OAuth Subject: [oauth] Re: Version Preference Let's play devils advocate for a minute, considering the current exploit was in plain view for over a year before it was found. Are you willing to bet OAuth's reputation (in sake of interoperability) that no flaws exist in this trapdoor switch ? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] Re: Version Preference
Large corporations like Google and Yahoo have more resources at their disposal, so it's all relative. On May 2, 12:08 pm, Eran Hammer-Lahav e...@hueniverse.com wrote: No. I'm trying not to break areas of the spec that are unaffected by the security hole, provide tools to close the hole, and do it in a way that allows providers who choose to, to offer a migration path to their developers that is not just shutting down their existing old-flow OAuth endpoints. When you consider the fact that the authorization flow is merely 3 endpoints out of potentially tens or hundreds of API endpoints, the deployment impact on the server is much greater on the API side than on the OAuth authorization side. This might not be an issue to small providers where the entire API is managed by a single server/codebase, but for large provider such as Yahoo! and Google with a huge distributed deployment, this is a real impact. Add to that OpenSocial which uses 2-legged, the size of secure and unbroken deployment that a new wire version will break for no gain at all is significant. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of David Parry Sent: Friday, May 01, 2009 6:51 PM To: OAuth Subject: [oauth] Re: Version Preference You're trying to maximize interoperability between the new and flawed spec. ie. SP 1.0 - Consumer 1.0a SP 1.0a - Consumer 1.0 On May 2, 11:22 am, Eran Hammer-Lahav e...@hueniverse.com wrote: I have no idea what point you are trying to make. Specifications are about interoperability (what else would it be about?). EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of David Parry Sent: Friday, May 01, 2009 5:57 PM To: OAuth Subject: [oauth] Re: Version Preference Let's play devils advocate for a minute, considering the current exploit was in plain view for over a year before it was found. Are you willing to bet OAuth's reputation (in sake of interoperability) that no flaws exist in this trapdoor switch ? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 1
Not incrementing the oauth_version for the new spec is a mistake imho. It seems kinda flaky to me to switch between the specs 1.0/1.0a purely based on whether the oauth_callback is sent when a consumer obtains a request token. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 1
As a Service Provider, I want to be able to run both 1.0 and 1.0a (or 1.1) concurrently for a period of time while my consumers implement the new version. Then disable 1.0 and return an error if a consumer attempts to use the old version. At least to me, this provides the easiest and most fail safe migration path for all parties. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
