I'll add that those of you worried about confusion and complexity, keep in mind that today approved applications work without any problem. Changing the oauth_version will break it. The one area many people (I assume a significant overlap with those promoting a new wire version) are complaining about is getting signatures to match. Why would you change the wire format and break signatures? Isn't that going to add more confusion?
EHL On May 1, 12:06 pm, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > It is trivial to tell the difference between the two flows without any > additional wire changes. The spec itself should not have a version at all, it > should have something else that will allow *people* to reference the same > document to each other. And it is not our business to decide how providers > will handle the old flow. As long as providers can easily detect what flow > the client is using, they can figure out the rest. > > We are looking to make the smaller change possible and break the least amount > of running code. There is a large deployment of 2-legged OAuth that doesn't > need to break. Also, half the libraries don't even handle the authorization > flow, just the authentication flow (signatures) and don't need to break. > > Let's call the spec OAuth Core 2009.1 and be done with it. No version at all, > just a document timestamp. You can increment that as much as you want! > > A reason to change the wire format of signed OAuth requests needs to clearly > show that there is no other way to tell the difference between old and new. > So far none of the people proposing we change the value of the oauth_version > parameter presented such a reason. We can debate the title of the document > all you want, since it is a marketing decision. But if you want to convince > me to increment the parameter value, you need to offer a technical reason. > > Trying to argue that incrementing wire indicators in such cases is both false > (see transition from RFC 2068 to 2616) and not a valid reason. HTTP 1.1 used > to have LINK and UNLINK methods (you know, like GET, POST, etc.). They are no > longer part of 1.1 because the HTTP working group decided to drop them. The > figured it was pretty easy for a server to tell if a client is using the > older RFC. They didn't change the protocol version (as in 'GET /something > HTTP/1.1') because it added no value and would have just broke the web. How > is that any different? We can *clearly* accomplish what we have set to do > here without a wire change in the oauth_version parameter. *That* is the > default behavior - not to break what is not broken (using Access Tokens or > 2-legged requests). If you want to go and break more stuff than needed, the > burden is on *you* to show why. > > EHL > > From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of > Josh Roesslein > Sent: Friday, May 01, 2009 11:45 AM > To: oauth@googlegroups.com > Subject: [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.com<mailto:e...@hueniverse.com>> wrote: > > 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:oauth@googlegroups.com> > > [mailto:oauth@googlegroups.com<mailto:oauth@googlegroups.com>] On Behalf > > Of Matt Sanford > > Sent: Friday, May 01, 2009 10:53 AM > > To: oauth@googlegroups.com<mailto: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 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
