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>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: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 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 stuff and so far no one has demonstrated any *real* > > > value in doing so. "Confusing" is not a technical argument and this > > > is an technical document. > > > > > > EHL > > > > > > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
