> -----Original Message----- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Thursday, July 01, 2010 11:36 AM > To: Eran Hammer-Lahav > Cc: William Mills; Rob Richards; oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning > > On Thu, Jul 1, 2010 at 11:24 AM, Eran Hammer-Lahav > <e...@hueniverse.com> wrote: > > > > If you would like to discuss a version for the header, > please provide examples and requirements for what changes in > the future you would like to support. > > Not sure about the future, but looking at OAuth 1 vs OAuth 2. > A protected resource request filter may want to decide early > what protocol it deals with so it can call the appropriate > handler, or to enforce HTTPS for OAuth 2 for example. Sure, > it can apply heuristics right now, but it would be nice to > have a more deterministic way which can also be extended in > the future. You can always embed the protocol version inside > the token I guess, so I don't think this is a huge issue.
Yeah, unfortunately early selection of a handler might require peeking into the post body. > > I was not part of the 1.0 vs 1.0a discussions, so not sure > what was the conclusion there. > > Marius > > > > > EHL > > > >> When tokens are passed in the query string there is no scheme. > >> > >> Marius > >> > >> > > >> > EHL > >> > > >> >> -----Original Message----- > >> >> From: William Mills [mailto:wmi...@yahoo-inc.com] > >> >> Sent: Thursday, July 01, 2010 10:49 AM > >> >> To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > >> >> Subject: RE: [OAUTH-WG] Versioning > >> >> > >> >> My feeling on this is that versioning explicitly in the > protocol > >> >> adds clarity and some small level of compatibility. Different > >> >> auth and token endpoints are easy, what's harder is supporting > >> >> multiple protocols on the same protected resource. It's on the > >> >> protected resource I'd like to see some clearer > protocol version > >> >> spec so I'm not having to figure out from the variable > names which protocol it is. > >> >> > >> >> > -----Original Message----- > >> >> > From: oauth-boun...@ietf.org > [mailto:oauth-boun...@ietf.org] On > >> >> > Behalf Of Eran Hammer-Lahav > >> >> > Sent: Thursday, July 01, 2010 9:36 AM > >> >> > To: Rob Richards; OAuth WG (oauth@ietf.org) > >> >> > Subject: Re: [OAUTH-WG] Versioning > >> >> > > >> >> > Hi Rob, > >> >> > > >> >> > > -----Original Message----- > >> >> > > From: Rob Richards [mailto:rricha...@cdatazone.org] > >> >> > > Sent: Thursday, July 01, 2010 3:26 AM > >> >> > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > >> >> > > Subject: Versioning > >> >> > > > >> >> > > Versioning is still something that needs to be addressed > >> >> > before being > >> >> > > being able to consider the draft core complete. > >> >> > > >> >> > Versioning rarely works because when you define it, > you have no > >> >> > idea what the requirements will be for the next > version. A good > >> >> > example is the OAuth 1.0 version parameter. When we worked to > >> >> > revised 1.0 into 1.0a, we had a long debate on changing the > >> >> > protocol version number. We had a hard time agreeing > on what the > >> >> > version meant and what was it a version > >> >> > *of*: the signature method or the token flow. > >> >> > > >> >> > If this protocol will require significant changes in > the future > >> >> > that go beyond its extensibility support, such a new version > >> >> > will need to use different endpoints (token or end-user > >> >> > authorization) and/or different HTTP authentication scheme. > >> >> > > >> >> > If you want to discuss versioning, you must provide your > >> >> > requirements for such a feature, and clearly show how > they are > >> >> > not served by the current extensibility proposal. > >> >> > > >> >> > > On this I'm still of the opinion that at the very > minimum you > >> >> > > will need to require an oauth_version parameter for the > >> >> > > resource > >> >> > endpoints, > >> >> > > if not also for the others as well. > >> >> > > >> >> > I think the difficulty of differentiating a 1.0 from a 2.0 > >> >> > protected resource request is exaggerated. As said > before, you > >> >> > can tell the difference based on the presence of > other parameter > >> >> > (oauth_signature_method), or by examining the provided token > >> >> > (assuming you issue different tokens for each version). The > >> >> > argument that a 2.0 request can also be a malformed > 1.0 request > >> >> > is silly. I have yet to hear about that level of incompetence > >> >> > for a 1.0 developer (and I've heard about a lot) - omitting > >> >> > every other > >> required parameter. > >> >> > > >> >> > At most, I'm open to renaming the oauth_token parameter to > >> >> > something else (oauth_access_token, oauth.token, oauth-token, > >> >> > etc.) but I think even that is not needed. > >> >> > > >> >> > EHL > >> >> > _______________________________________________ > >> >> > OAuth mailing list > >> >> > OAuth@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/oauth > >> >> > > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
