[oauth] Re: OAuth Core 1.0 Rev A, Draft 1
I would prefer it to have a value - for .net the usual way of accessing the form and querystring parameters returns null if the parameter is not there or has no value. To implement an empty value we would have to make two checks to see if the key is present and then check to see if it has a value. I know it's not a big deal but it can lead to bad implementations. oob seems perfectly valid to me. I would prefer the version to be used to identify what flow is in use - have to agree with David Parry that it makes it a lot cleaner to identify if the consumer has sent a version 1.0 request or they are attempting an invalid 1.1/1.0a request. But to enforce this the spec would need to be updated to make the oauth_version parameter mandatory in all requests. I don't think this would be a big leap though as I would have thought that most implementations already include this parameter as standard. --~--~-~--~~~---~--~~ 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] Version Preference
We need to build some consensus around the version preference. As I see it, there are several options: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 Please indicate your support for one of these options, and try to refrain from arguing your case here. The other thread remains open for that purpose. I would especially like to hear from library implementers here, and others who have not voiced their opinions in the other threads. b. --~--~-~--~~~---~--~~ 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
On Fri, May 1, 2009 at 9:07 AM, chris.s.ad...@googlemail.com chris.s.ad...@googlemail.com wrote: I would prefer it to have a value - for .net the usual way of accessing the form and querystring parameters returns null if the parameter is not there or has no value. To implement an empty value we would have to make two checks to see if the key is present and then check to see if it has a value. I know it's not a big deal but it can lead to bad implementations. oob seems perfectly valid to me. What if the oauth_callback value were optional on the request_token step (as Eran has written it in the modified spec)? Then the parameter is not there, so checking is only one step. b. --~--~-~--~~~---~--~~ 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
3 eom 2009/5/1 Blaine Cook rom...@gmail.com We need to build some consensus around the version preference. As I see it, there are several options: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 Please indicate your support for one of these options, and try to refrain from arguing your case here. The other thread remains open for that purpose. I would especially like to hear from library implementers here, and others who have not voiced their opinions in the other threads. b. --~--~-~--~~~---~--~~ 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
Either of 2 or 3 are fine. (Assuming that option 3 implies that oauth_version=1.1, if not, then 2.) Stephen. Blaine Cook wrote: We need to build some consensus around the version preference. As I see it, there are several options: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 Please indicate your support for one of these options, and try to refrain from arguing your case here. The other thread remains open for that purpose. I would especially like to hear from library implementers here, and others who have not voiced their opinions in the other threads. b. --~--~-~--~~~---~--~~ 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
On 5/1/09 4:25 AM, Blaine Cook wrote: 3. 1.1 +1. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ 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
As I stated elsewhere, I think it's easily possible to auto-detect revision A without modified version-parameter, so I would go for option 1. I wouldn't oppose to option 3 either. We should either keep in line with the version is for the signature method, not the flow-rule (option 1) or bump the minor version (option 3).. -Morten On May 1, 2009, at 10:25 AM, Blaine Cook wrote: We need to build some consensus around the version preference. As I see it, there are several options: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 Please indicate your support for one of these options, and try to refrain from arguing your case here. The other thread remains open for that purpose. I would especially like to hear from library implementers here, and others who have not voiced their opinions in the other threads. b. --~--~-~--~~~---~--~~ 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
Blaine Cook wrote: We need to build some consensus around the version preference. As I see it, there are several options: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 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
Option 3. Cheers k/ |-Original Message- |From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf |Of Blaine Cook |Sent: Friday, May 01, 2009 1:25 AM |To: oauth@googlegroups.com |Subject: [oauth] Version Preference | | |We need to build some consensus around the version preference. As I |see it, there are several options: | |1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) |2. 1.0a (with oauth_version=1.0a) |3. 1.1 | |Please indicate your support for one of these options, and try to |refrain from arguing your case here. The other thread remains open for |that purpose. I would especially like to hear from library |implementers here, and others who have not voiced their opinions in |the other threads. | |b. | | --~--~-~--~~~---~--~~ 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 … that's what versions are for, incrementing. On May 1, 2009, at 1:25 AM, Blaine Cook wrote: We need to build some consensus around the version preference. As I see it, there are several options: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 Please indicate your support for one of these options, and try to refrain from arguing your case here. The other thread remains open for that purpose. I would especially like to hear from library implementers here, and others who have not voiced their opinions in the other threads. b. --~--~-~--~~~---~--~~ 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
+1 ... er, +.1 --j On May 1, 2009, at 7:55 AM, Matt Sanford m...@twitter.com wrote: Option 3 … that's what versions are for, incrementing. On May 1, 2009, at 1:25 AM, Blaine Cook wrote: We need to build some consensus around the version preference. As I see it, there are several options: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 Please indicate your support for one of these options, and try to refrain from arguing your case here. The other thread remains open for that purpose. I would especially like to hear from library implementers here, and others who have not voiced their opinions in the other threads. b. --~--~-~--~~~---~--~~ 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 On Fri, May 1, 2009 at 8:29 AM, Jim Meyer jme...@linkedin.com wrote: +1 ... er, +.1 --j On May 1, 2009, at 7:55 AM, Matt Sanford m...@twitter.com wrote: Option 3 … that's what versions are for, incrementing. On May 1, 2009, at 1:25 AM, Blaine Cook wrote: We need to build some consensus around the version preference. As I see it, there are several options: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 Please indicate your support for one of these options, and try to refrain from arguing your case here. The other thread remains open for that purpose. I would especially like to hear from library implementers here, and others who have not voiced their opinions in the other threads. b. --~--~-~--~~~---~--~~ 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
Version 3, where the string literal is supposed to be interpreted as manual entry or out-of-band exchange of the callback token. Version 1 is already supported. There is interest to support some form of manual entry (for instance, SPs could give less stern warnings for such desktop apps). On Fri, May 1, 2009 at 1:43 AM, Blaine Cook rom...@gmail.com wrote: We need to gain some consensus around the value (or lack thereof) that should be used for the oauth_callback parameter that is sent from the consumer to the service provider when obtaining the request token in the new flow. Our options: 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. 2. String literal none 3. String literal, other than none I have omitted oob explicitly since it seems as though there was a lot of confusion around it. However, there is the option for a different string literal. I'd also like to hear from library authors whose voices have not been present in the discussions over the past week. Please indicate your preferred option as soon as possible. b. -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --~--~-~--~~~---~--~~ 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 1, 1:43 am, Blaine Cook rom...@gmail.com wrote: We need to gain some consensus around the value (or lack thereof) that should be used for the oauth_callback parameter that is sent from the consumer to the service provider when obtaining the request token in the new flow. Our options: 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. 2. String literal none 3. String literal, other than none I have omitted oob explicitly since it seems as though there was a lot of confusion around it. However, there is the option for a different string literal. I'd also like to hear from library authors whose voices have not been present in the discussions over the past week. Please indicate your preferred option as soon as possible. b. 3 for all the reasons Breno mentioned. --~--~-~--~~~---~--~~ 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 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. --~--~-~--~~~---~--~~ 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
On May 1, 1:25 am, Blaine Cook rom...@gmail.com wrote: 3. 1.1 Option 3, 1.1 -cheers, Manish --~--~-~--~~~---~--~~ 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
On Fri, May 1, 2009 at 1:25 AM, Blaine Cook rom...@gmail.com wrote: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 Option 1. Version string should not change unless we hate developers. --~--~-~--~~~---~--~~ 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 Fri, May 1, 2009 at 5:19 PM, 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. Sorry, I didn't mean to bias the question; I just sought to clarify what the intent of the option was. Further to the point, I think in general it should be assumed that desktop applications should never be allowed to update the callback to point at an HTTP URI, since that means attackers need only steal consumer keys from an installed application to perform the attack we're trying to correct for here. My preference is actually Breno's proposal, which is somewhat different than any of the options I presented above, somewhere between #1 and #2. b. --~--~-~--~~~---~--~~ 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] This whole version business
I think the discussion around the version number is completely misguided because we don't have a basic agreement on what the hell the version is even for. This means that based on your personal interpretation of what it means, you come to a different conclusion. Just because we change the specification, doesn't mean we should change the version - we need to first agree what it is for. For those new here, at the OAuth Summit last year we had a wide consensus not to change the oauth_version value, even with proposals to add new parameters, error codes, etc. This is not much different. --- There are 4 elements of the protocol with a version associated with them: * The specification document - this tells readers that there is a new document. * The authorization flow used to obtain an Access Token - this is what we are changing (getting an Access Token). * The authentication method - the way in which signed OAuth requests are made and transmitted (using an Access Token). * The signature method - the way in which the signature value is calculated. The versioning of each of these must be addressed separately or we will be breaking stuff for no reason (like 2-legged clients). * The specification document - give it a new title (without overlapping with any other version indicator). I have moved away from using version numbers for specifications I write, and am now advocating using dates or revisions instead. * The authorization flow used to obtain an Access Token - we don't have a way to indicate which flow is being used, and the oauth_version parameter was not put in the specification for this (I know because I put it there). There are two obvious ways to address this: use different endpoints (with optional discovery) or add a new parameter (something like oauth_flow) and simply name different flows (or different versions of flow) with different names. * The authentication method - this is what the current oauth_version is for. It provides a version for the combination of parameter used (nonce, timestamp, signature method, signature, token, etc.), as well as how OAuth parameters are encoded, transmitted, and verified. * The signature method - each method has a name and if we ever want to change them or add new ones, we simply give it a new name. --- The Core 1.0 specification structure is shit. It completely blur the lines between these 4 elements which is why most of you are misguided in advocating for a version change. If you read my editor's cut version of the specification, you'll see that the oauth_version parameter is clearly part of how to make an authenticated OAuth request and not about how to get an Access Token. The fact the current document title uses the same indicator (1.0) as the version of the authentication method is also not helping. We need to address two changes: * A new document - I think a simple Revision A in the title is enough to indicate that the specification language has changed. If you feel this is not enough please suggest a stronger language that is not a new version number. We cannot increment the document version number without also incrementing the parameter value or we will completely confuse everyone. In the future, there will not be a new document called OAuth Core with a new numerical version number (like OAuth 2.0). And before you go and argue, take a look at HTTP 1.1 - it has multiple (different) specifications (RFCs) with the same protocol version number and no one seems confused... * A new authorization flow - we are basically adding a new workflow to replace the existing 3-steps flow. It is very easy to identify which flow is being used (see below) and there is no *need* to add an explicit indicator that a new flow is being used by a client. For this reason I suggest we don't add anything new at this point. I would like to look into this further in the future and find better ways to support multiple authorization flows, but this is probably not the time to address it. To identify which flow a client is using: 1. Use two different endpoint URLs! Developers will have to go and make code changes and if they use a library, will have to reconfigure it to indicate which flow they are using. No application is expected to use both flows. This means providers supporting multiple versions for some time as part of their transition can simply use different endpoints for each revision. In the future, discovery will make this automated - and this is the exact direction the discovery work has been advocating for multiple flows. 2. Use the presence of an oauth_callback parameter as indicator which version is being used. If you are not going to support dynamic callbacks see #1. 3. Add your own flag. This is pointless and wasteful but if it makes you feel better... --- If it wasn't clear, my vote is to give the specification a new title (Revision A) and leave the oauth_version unchanged. Changing the version breaks
[oauth] Re: Desktop Application Callback Value
Out of band is the correct term here and at least half the people here figured it out intuitively. I still like it better than other suggestions and think this would be a non-issue if the spec spells is out use 'oob' (out of bank). I think using a value to indicate oob is better than empty or no parameter because we *know* that will work. We are not sure yet about how the other options will affect different systems and we don't have time to fully find out. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of John Kemp Sent: Friday, May 01, 2009 10:27 AM To: oauth@googlegroups.com Subject: [oauth] Re: Desktop Application Callback Value On May 1, 2009, at 12:02 PM, Breno de Medeiros wrote: Version 3, where the string literal is supposed to be interpreted as manual entry or out-of-band exchange of the callback token. +1 - johnk Version 1 is already supported. There is interest to support some form of manual entry (for instance, SPs could give less stern warnings for such desktop apps). On Fri, May 1, 2009 at 1:43 AM, Blaine Cook rom...@gmail.com wrote: We need to gain some consensus around the value (or lack thereof) that should be used for the oauth_callback parameter that is sent from the consumer to the service provider when obtaining the request token in the new flow. Our options: 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. 2. String literal none 3. String literal, other than none I have omitted oob explicitly since it seems as though there was a lot of confusion around it. However, there is the option for a different string literal. I'd also like to hear from library authors whose voices have not been present in the discussions over the past week. Please indicate your preferred option as soon as possible. b. -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --~--~-~--~~~---~--~~ 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
+1 on option 3 On May 1, 4:25 am, Blaine Cook rom...@gmail.com wrote: We need to build some consensus around the version preference. As I see it, there are several options: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 Please indicate your support for one of these options, and try to refrain from arguing your case here. The other thread remains open for that purpose. I would especially like to hear from library implementers here, and others who have not voiced their opinions in the other threads. b. --~--~-~--~~~---~--~~ 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: This whole version business
There is a difference between what you name the specification and the string value you put on the wire. My point is that there is no reason to change what is transmitted on the wire. I also made the point that not changing the wire string but changing the document version will be more confusing. Changing both just because it helps with communication with *people* makes no sense. Protocols are for *machines* and those do not need a new version number. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Matt Sanford Sent: Friday, May 01, 2009 10:53 AM To: oauth@googlegroups.com Subject: [oauth] Re: This whole version business Hi Eran, If it requires a two-page email to explain what a version number is perhaps the concept is over complicated. My understanding from years of working with software is that major versions are radical departures from the previous interface, whereas minor versions are enhancements and changes which are material but also backward compatible. I would say this change we've discussed is material (otherwise we would not be changing) but also backward compatible (otherwise the revision discussion would have died). I would have just read the mail and continued on my way where it not for the statement 'Confusing' is not a technical argument and this is an technical document.. That statement makes me want to take up the banner of 1.1. To ignore the ease of development in your protocol, design or documentation is to doom yourself to failure. I am not sure your description has shown to me any *real* reason this is not a backward compatible change, as I think a minor version number would indicate. I voted for 1.1 because of my understanding of major/ minor version numbers, redefinition of the term not withstanding. Take it or leave it. Thanks; - Matt Sanford On May 1, 2009, at 10:39 AM, Eran Hammer-Lahav wrote: I think the discussion around the version number is completely misguided because we don't have a basic agreement on what the hell the version is even for. This means that based on your personal interpretation of what it means, you come to a different conclusion. Just because we change the specification, doesn't mean we should change the version - we need to first agree what it is for. For those new here, at the OAuth Summit last year we had a wide consensus not to change the oauth_version value, even with proposals to add new parameters, error codes, etc. This is not much different. --- There are 4 elements of the protocol with a version associated with them: * The specification document - this tells readers that there is a new document. * The authorization flow used to obtain an Access Token - this is what we are changing (getting an Access Token). * The authentication method - the way in which signed OAuth requests are made and transmitted (using an Access Token). * The signature method - the way in which the signature value is calculated. The versioning of each of these must be addressed separately or we will be breaking stuff for no reason (like 2-legged clients). * The specification document - give it a new title (without overlapping with any other version indicator). I have moved away from using version numbers for specifications I write, and am now advocating using dates or revisions instead. * The authorization flow used to obtain an Access Token - we don't have a way to indicate which flow is being used, and the oauth_version parameter was not put in the specification for this (I know because I put it there). There are two obvious ways to address this: use different endpoints (with optional discovery) or add a new parameter (something like oauth_flow) and simply name different flows (or different versions of flow) with different names. * The authentication method - this is what the current oauth_version is for. It provides a version for the combination of parameter used (nonce, timestamp, signature method, signature, token, etc.), as well as how OAuth parameters are encoded, transmitted, and verified. * The signature method - each method has a name and if we ever want to change them or add new ones, we simply give it a new name. --- The Core 1.0 specification structure is shit. It completely blur the lines between these 4 elements which is why most of you are misguided in advocating for a version change. If you read my editor's cut version of the specification, you'll see that the oauth_version parameter is clearly part of how to make an authenticated OAuth request and not about how to get an Access Token. The fact the current document title uses the same indicator (1.0) as the version of the authentication method is also not helping. We need to address two changes: * A new document - I think a simple Revision A in the title is enough to
[oauth] Re: OAuth Core 1.0 Rev A, Draft 1
On Thu, Apr 30, 2009 at 5:28 PM, Josh Roesslein jroessl...@gmail.comwrote: Dirk, I see now what you are getting at. Yes I guess the SP could use a signature to generate the verifier, so it would not need to persist it. As long as the signature secrete changes ever so often, I don't think an attacker could compromise this method. But to me the wording of that section still doesn't state how the SP can verify the verifier. Well, the wording as it is now mentions two verification codes, and says that the SP MUST make sure that they are identical. That looks like a prescription for implementation to me. And not an implementation that I would choose :-) Dirk. Using the signature approach still does the same thing, makes sure the verifier matches. It might be a good idea to suggest this signature approach in the spec as an implementation tip. --~--~-~--~~~---~--~~ 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: This whole version business
First I believe the version number should increment when ever the spec changes. To me this clearly provides the SP with the version of the spec this consumer is running. Now the SP can properly determine if the requests from this consumer should work. Now how do we determine backward compatibility for 1.0 consumers? I propose that any changes made to a new spec should be clearly marked (ex. New: changes). This should also state if these changes are optional and thus providing backward compatibility for 1.0 consumers (so SP's should not block oauth_version 's with 1.0). If these changes are mandatory (ex. the oauth_verifier for callbacks) then SP's should block older oauth_versions. We should not simply just block all older version for all endpoints. We must be selective in this and only block when a mandatory change is required and the consumer should be using a newer version. I think it is important we have a way to deal with backward compatibility. On Fri, May 1, 2009 at 1:29 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: There is a difference between what you name the specification and the string value you put on the wire. My point is that there is no reason to change what is transmitted on the wire. I also made the point that not changing the wire string but changing the document version will be more confusing. Changing both just because it helps with communication with *people* makes no sense. Protocols are for *machines* and those do not need a new version number. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Matt Sanford Sent: Friday, May 01, 2009 10:53 AM To: oauth@googlegroups.com Subject: [oauth] Re: This whole version business Hi Eran, If it requires a two-page email to explain what a version number is perhaps the concept is over complicated. My understanding from years of working with software is that major versions are radical departures from the previous interface, whereas minor versions are enhancements and changes which are material but also backward compatible. I would say this change we've discussed is material (otherwise we would not be changing) but also backward compatible (otherwise the revision discussion would have died). I would have just read the mail and continued on my way where it not for the statement 'Confusing' is not a technical argument and this is an technical document.. That statement makes me want to take up the banner of 1.1. To ignore the ease of development in your protocol, design or documentation is to doom yourself to failure. I am not sure your description has shown to me any *real* reason this is not a backward compatible change, as I think a minor version number would indicate. I voted for 1.1 because of my understanding of major/ minor version numbers, redefinition of the term not withstanding. Take it or leave it. Thanks; - Matt Sanford On May 1, 2009, at 10:39 AM, Eran Hammer-Lahav wrote: I think the discussion around the version number is completely misguided because we don't have a basic agreement on what the hell the version is even for. This means that based on your personal interpretation of what it means, you come to a different conclusion. Just because we change the specification, doesn't mean we should change the version - we need to first agree what it is for. For those new here, at the OAuth Summit last year we had a wide consensus not to change the oauth_version value, even with proposals to add new parameters, error codes, etc. This is not much different. --- There are 4 elements of the protocol with a version associated with them: * The specification document - this tells readers that there is a new document. * The authorization flow used to obtain an Access Token - this is what we are changing (getting an Access Token). * The authentication method - the way in which signed OAuth requests are made and transmitted (using an Access Token). * The signature method - the way in which the signature value is calculated. The versioning of each of these must be addressed separately or we will be breaking stuff for no reason (like 2-legged clients). * The specification document - give it a new title (without overlapping with any other version indicator). I have moved away from using version numbers for specifications I write, and am now advocating using dates or revisions instead. * The authorization flow used to obtain an Access Token - we don't have a way to indicate which flow is being used, and the oauth_version parameter was not put in the specification for this (I know because I put it there). There are two obvious ways to address this: use different endpoints (with optional discovery) or add a new parameter (something like oauth_flow) and simply name different flows (or
[oauth] Re: Version Preference
Here's a quick count of the votes: Option 1: 8 Option 3: 12 Eran has made some good points in another thread. In this revision we can auto detect which from we are using, but in the future this might not be true. So do we create different versions? Wire version - only incremented if we can't auto detect the changes in the updated spec (example: signature changes) Document version - incremented with each revision to the document. (example 1.0 Rev A, 2009.1, etc) To me this adds some complexity and might confuse people we use two different versions. This is why I am leaning towards making them the same and incrementing the version. SP's can still support 1.0 wire versions just fine so we won't be breaking anything. I would just like a consistent increment pattern for this version. When we can auto detect we just ignore this version. If we can't auto detect we look at this value. Well that's my two cents on this topic. On Fri, May 1, 2009 at 1:23 PM, J. Trent Adams jtrentad...@gmail.comwrote: +1 for Option 3. Version 1.1 Blaine Cook wrote: We need to build some consensus around the version preference. As I see it, there are several options: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 Please indicate your support for one of these options, and try to refrain from arguing your case here. The other thread remains open for that purpose. I would especially like to hear from library implementers here, and others who have not voiced their opinions in the other threads. b. -- J. Trent Adams =jtrentadams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams --~--~-~--~~~---~--~~ 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
On Fri, May 1, 2009 at 10:25 AM, Blaine Cook rom...@gmail.com wrote: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) +1 for this Luca --~--~-~--~~~---~--~~ 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 Fri, May 1, 2009 at 10:43 AM, Blaine Cook rom...@gmail.com wrote: 2. String literal none 3. String literal, other than none +1 for an explicit string (whether none or oob) Luca --~--~-~--~~~---~--~~ 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
I think we can clearly label the document so that people will not be confused about which specification they need to use. As long as we don't use '1.1' in the title of the specification, we will not confuse anyone. EHL From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Josh Roesslein Sent: Friday, May 01, 2009 1:13 PM To: oauth@googlegroups.com Subject: [oauth] Re: Version Preference Here's a quick count of the votes: Option 1: 8 Option 3: 12 Eran has made some good points in another thread. In this revision we can auto detect which from we are using, but in the future this might not be true. So do we create different versions? Wire version - only incremented if we can't auto detect the changes in the updated spec (example: signature changes) Document version - incremented with each revision to the document. (example 1.0 Rev A, 2009.1, etc) To me this adds some complexity and might confuse people we use two different versions. This is why I am leaning towards making them the same and incrementing the version. SP's can still support 1.0 wire versions just fine so we won't be breaking anything. I would just like a consistent increment pattern for this version. When we can auto detect we just ignore this version. If we can't auto detect we look at this value. Well that's my two cents on this topic. On Fri, May 1, 2009 at 1:23 PM, J. Trent Adams jtrentad...@gmail.commailto:jtrentad...@gmail.com wrote: +1 for Option 3. Version 1.1 Blaine Cook wrote: We need to build some consensus around the version preference. As I see it, there are several options: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 Please indicate your support for one of these options, and try to refrain from arguing your case here. The other thread remains open for that purpose. I would especially like to hear from library implementers here, and others who have not voiced their opinions in the other threads. b. -- J. Trent Adams =jtrentadams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams --~--~-~--~~~---~--~~ 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 1. The others are a waste of time and introduce unnecessary incompatibilities. If we had more leeway to make changes now, I would vote for remove the oauth_version parameter because it is underspecified and generally sucks but nobody agreed with me about this in 2007 either. On Fri, May 1, 2009 at 1:25 AM, Blaine Cook rom...@gmail.com wrote: We need to build some consensus around the version preference. As I see it, there are several options: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) 2. 1.0a (with oauth_version=1.0a) 3. 1.1 Please indicate your support for one of these options, and try to refrain from arguing your case here. The other thread remains open for that purpose. I would especially like to hear from library implementers here, and others who have not voiced their opinions in the other threads. b. --~--~-~--~~~---~--~~ 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
That was not what I did. I was just explaining how this process works and I clearly stated the need (and the full historical record) of getting to decisions by consensus. This is for cases where everything else has failed. We never had such a case so far and I doubt this will be one of them. If I thought me or anyone else had more weight here I would not be spending my entire day trying to convince people I'm right and engaging them. However, since this is a security issue with deployed software, if we cannot reach a consensus, someone will have to make a decision. My bet is we will not need it but if we do, that someone will be heavily weighted on the side of those with running code at risk... But let's go back to the discussion. I think we are making progress in communicating our positions. Let me repeat that: we make decisions by consensus, not votes. This is the IETF process as well. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Krishna Sankar (ksankar) Sent: Friday, May 01, 2009 2:24 PM To: oauth@googlegroups.com Subject: [oauth] Re: Version Preference Eran, While you might be technically right, wielding the meritocracy badge forcefully is not the right thing to do, imho. While the folks who have contributed to the specs, obviously, have the knowledge and so their voices have more force per se (and should be respected - no doubt), the community that uses the spec has a voice too. And one doesn't have to be a permanent contributor to be heard and considered. There is a reason for this, if you care to think ... am leaving out philosophy, for now ... Also as we move to IETF, this will be more clear - I see that there are couple of e-mail on this, already in the IETF list, alluding to this fact. Even there, for now, it is OK, as the spec is not with IETF yet. Cheers k/ |-Original Message- |From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf |Of Eran Hammer-Lahav |Sent: Friday, May 01, 2009 2:07 PM |To: oauth@googlegroups.com |Subject: [oauth] Re: Version Preference | | |On voting: this is not a democracy. Specs written by committee are |almost always a piece of shit. Our process is to build consensus as much |as possible, trying to get people to agree and when we don't try to |focus the conversation using actual technical arguments. At the end, if |there isn't a clear consensus, at least in this community, meritocracy |wins. This means that people who have contributed more and have earned |their seat at the table get to lead the way. But this is an extreme case |and I don't think we ever had to use it. | |The vote is just to get a sense where people are. It is not a way to |make decisions. At some point, Blaine or someone else will try to figure |out where people are, and write a short consensus proposal. Then we will |go through this again and see where we are. This sounds complicated but |it works pretty well. There are no hard rules for building consensus, |but we have been successful accomplishing it. | |--- | |As for your argument, I agree with you on the version of the |specification. I don't agree with you on the wire version. I don't think |they are the same at all. | |EHL | | | | -Original Message- | From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf | Of Matt Sanford | Sent: Friday, May 01, 2009 1:57 PM | To: oauth@googlegroups.com | Subject: [oauth] Re: Version Preference | | | Well ... | | The argument from me was that there is a material change and that | is the place of minor revisions. If this is an optional extension to | the existing protocol we should not change the revision at all. If it | is a minor change that requires a change to the base protocol rather | than an extension document, I call that a revision. This seem logical | enough to me but apparently I am in the minority, 1.0a it is then. | As far as voting and discussion ... I was under the impression |that | the 'Open' moniker sort of encouraged this. Must have been my | confusion, I missed the early on discussions. I'll read back in the | group some for more history. | | - Matt | | On May 1, 2009, at 1:44 PM, Jonathan Sergent wrote: | | Let me additionally say that this discussion is dangerous and voting | is no way to design a protocol. What are the arguments in favor of | changing the version number, and what are the arguments against | changing it? I haven't personally seen any arguments in favor of | changing it that explained the rationale other than of course you | should change it because you changed the version number on the |spec. | | | | | | | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to
[oauth] Re: This whole version business
Since you didn't take our suggestion to call the callback token the Breno Token we could at least go for oauth_version=brenodemedeiros. On Fri, May 1, 2009 at 2:41 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: How about we change the current version to 0.9 because it is clearly not a finished specification. Then we increment it for the new spec to 1.0! EHL PS. Yes, this is a joke (with joint credit to Breno) :-) --~--~-~--~~~---~--~~ 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: This whole version business
On 5/1/09 5:41 PM, Eran Hammer-Lahav wrote: How about we change the current version to 0.9 because it is clearly not a finished specification. Then we increment it for the new spec to 1.0! EHL PS. Yes, this is a joke (with joint credit to Breno) :-) Sadly, OAuth falls into the Microsoft Version trap: NEVER use a .0 release or always wait for Service Pack 1. So, 1.1 is a good thing - maybe folks will take it seriously, hoping the kinks have been worked out. There we go: OAuth Service Pack 1. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ 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
On voting: this is not a democracy. Specs written by committee are almost always a piece of shit. Our process is to build consensus as much as possible, trying to get people to agree and when we don't try to focus the conversation using actual technical arguments. At the end, if there isn't a clear consensus, at least in this community, meritocracy wins. This means that people who have contributed more and have earned their seat at the table get to lead the way. But this is an extreme case and I don't think we ever had to use it. The vote is just to get a sense where people are. It is not a way to make decisions. At some point, Blaine or someone else will try to figure out where people are, and write a short consensus proposal. Then we will go through this again and see where we are. This sounds complicated but it works pretty well. There are no hard rules for building consensus, but we have been successful accomplishing it. --- As for your argument, I agree with you on the version of the specification. I don't agree with you on the wire version. I don't think they are the same at all. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Matt Sanford Sent: Friday, May 01, 2009 1:57 PM To: oauth@googlegroups.com Subject: [oauth] Re: Version Preference Well ... The argument from me was that there is a material change and that is the place of minor revisions. If this is an optional extension to the existing protocol we should not change the revision at all. If it is a minor change that requires a change to the base protocol rather than an extension document, I call that a revision. This seem logical enough to me but apparently I am in the minority, 1.0a it is then. As far as voting and discussion ... I was under the impression that the 'Open' moniker sort of encouraged this. Must have been my confusion, I missed the early on discussions. I'll read back in the group some for more history. - Matt On May 1, 2009, at 1:44 PM, Jonathan Sergent wrote: Let me additionally say that this discussion is dangerous and voting is no way to design a protocol. What are the arguments in favor of changing the version number, and what are the arguments against changing it? I haven't personally seen any arguments in favor of changing it that explained the rationale other than of course you should change it because you changed the version number on the spec. --~--~-~--~~~---~--~~ 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
On Fri, May 1, 2009 at 1:56 PM, Matt Sanford m...@twitter.com wrote: Well … The argument from me was that there is a material change and that is the place of minor revisions. If this is an optional extension to the existing protocol we should not change the revision at all. If it is a minor change that requires a change to the base protocol rather than an extension document, I call that a revision. This seem logical enough to me but apparently I am in the minority, 1.0a it is then. Why does this mean we should change the version code on the wire? As far as voting and discussion … I was under the impression that the 'Open' moniker sort of encouraged this. Must have been my confusion, I missed the early on discussions. I'll read back in the group some for more history. Discussion is great, but we need to have consensus, rather than leave 49% of the people disagreeing. — Matt On May 1, 2009, at 1:44 PM, Jonathan Sergent wrote: Let me additionally say that this discussion is dangerous and voting is no way to design a protocol. What are the arguments in favor of changing the version number, and what are the arguments against changing it? I haven't personally seen any arguments in favor of changing it that explained the rationale other than of course you should change it because you changed the version number on the spec. --~--~-~--~~~---~--~~ 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: Desktop Application Callback Value
We either need an explicit string for the null callback, or we need to increment the version number, because the SP needs a way to determine which OAuth dialect the consumer is speaking as early on in the dance as possible. I believe that it's more pain than its worth to increment the version number, so we'll need a string literal. I vote for oob since it's as good as any, and its already in Draft 1. Allen Luca Mearelli wrote: On Fri, May 1, 2009 at 10:43 AM, Blaine Cook rom...@gmail.com wrote: 2. String literal none 3. String literal, other than none +1 for an explicit string (whether none or oob) Luca --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
