An easy fix here is to use oauth2_token instead of oauth_token here, since that's the only place we seem to be using the oauth_ namespace now. Makes figuring out the two completely deterministic since it's a different parameter name when passed as a GET or POST variable, and a different header name when passed as a header (using the current Token scheme or an OAuth2 scheme or whatever).
-- Justin On Thu, 2010-07-01 at 14:25 -0400, William Mills wrote: > +1 on this. Makes life interesting on the PR. > > > When tokens are passed in the query string there is no scheme. > > > -----Original Message----- > > From: Marius Scurtescu [mailto:[email protected]] > > Sent: Thursday, July 01, 2010 11:16 AM > > To: Eran Hammer-Lahav > > Cc: William Mills; Rob Richards; [email protected] > > Subject: Re: [OAUTH-WG] Versioning > > > > On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav > > <[email protected]> wrote: > > > Why is a version better than a new scheme name? > > > > Sure, but then make the scheme more specific. What will the > > scheme name be for OAuth 3? > > > > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
