On Thu, Jul 1, 2010 at 11:24 AM, Eran Hammer-Lahav <[email protected]> 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. 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:[email protected]] >> >> Sent: Thursday, July 01, 2010 10:49 AM >> >> To: Eran Hammer-Lahav; Rob Richards; [email protected] >> >> 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: [email protected] [mailto:[email protected]] On >> >> > Behalf Of Eran Hammer-Lahav >> >> > Sent: Thursday, July 01, 2010 9:36 AM >> >> > To: Rob Richards; OAuth WG ([email protected]) >> >> > Subject: Re: [OAUTH-WG] Versioning >> >> > >> >> > Hi Rob, >> >> > >> >> > > -----Original Message----- >> >> > > From: Rob Richards [mailto:[email protected]] >> >> > > Sent: Thursday, July 01, 2010 3:26 AM >> >> > > To: OAuth WG ([email protected]); 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 >> >> > [email protected] >> >> > https://www.ietf.org/mailman/listinfo/oauth >> >> > >> > _______________________________________________ >> > OAuth mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
