I'm also fine with a note in the spec that says, something like "If you need to support 1.0a and 2 on the same protected resource it is RECOMMENDED that you always use the Authorization header variant."
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] > On Behalf Of William Mills > Sent: Thursday, July 01, 2010 2:36 PM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning > > In re: > > 1. Token syntax > 2. Presence of 'oauth_signature_method' > 3. Presence of 'oauth_signature' > 4. Presence of no other 'oauth_' parameter than 'oauth_token' > > We can certainly do better than this. Yeah, the server > should be smart enough, but this seems unneccesary when we > could be a lot simpler. > > Can we require the presence of the Authorization header with > "Token", and if nothing else is there you have to go to the > query params or post body? > > > -----Original Message----- > > From: oauth-boun...@ietf.org > [mailto:oauth-boun...@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Thursday, July 01, 2010 2:24 PM > > To: oauth@ietf.org > > Subject: Re: [OAUTH-WG] Versioning > > > > [Replying to everything at once...] > > > > > -----Original Message----- > > > From: Marius Scurtescu [mailto:mscurte...@google.com] > > > Sent: Thursday, July 01, 2010 11:36 AM > > > > > 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. > > > > First, this is limited to non-header methods. Look for > > 'oauth_signature_method'. > > > > If it is not there, assume this is a 2.0 request. I don't buy the > > suggestion that in practice, developers are likely to omit *this* > > parameter in a malformed 1.0 requests. If an existing 1.0 > provider can > > demonstrate how this is a problem from experience, I might > reconsider. > > > > > I was not part of the 1.0 vs 1.0a discussions, so not > sure what was > > > the conclusion there. > > > > The conclusion was that beyond "this sounds like a good idea" > > we didn't know what the heck we were doing. Blaine at the time > > strongly opposed it and lost the argument to me. Since the 1.0a > > discussions, I have changed my view and am no decidedly against > > version parameters because they are impossible to design. > > > > > > > -----Original Message----- > > > From: Rob Richards [mailto:rricha...@cdatazone.org] > > > Sent: Thursday, July 01, 2010 11:43 AM > > > > > Exactly. While it might be needed in the future, there is > a need to > > > differentiate OAuth 1.0 from 2.0 on resource endpoints right now. > > > Outside of requiring an oauth_version parameter (or > equivalent) all > > > other suggestions leave versioning as a grey area, where > > things can be > > > interpreted one way or another with no consistency. Grey > > areas in specs are a bad thing. > > > You end up with different languages/libraries dealing with > > things in > > > completely different and incompatible ways because > > something was not > > > clearly spelled out. > > > > This is an area that is clearly on the server side, not the > > client. Since the core specification leaves discovery out, > > client developers need to know what version of OAuth is > > supported by the server and use the right one. Without > > discovery, the client must know ahead of time what to do. > > With discovery, the client can choose the right protocol. > > Either way, the client never just sends a 1.0 or 2.0 requests > > and hopes for the best. > > > > On the server side, the challenge isn't that significant. > > When not using a header, the server can use multiple methods > > to differentiate the version used by the client: > > > > 1. Token syntax > > 2. Presence of 'oauth_signature_method' > > 3. Presence of 'oauth_signature' > > 4. Presence of no other 'oauth_' parameter than 'oauth_token' > > > > > With this the spec needs to including some wording to explicitly > > > define how to handle the case when running an endpoint > > supporting both > > > OAuth 1.0 and 2.0 and the oauth2_token is missing then > the call is > > > handled according to the OAuth 1.0/a spec. Whatever is > > decided, be it > > > a version parameter, the use of oauth2_token or the check for the > > > existence of the oauth_signature_method parameter, > etc///, the spec > > > needs to define and be explicit on how a resource endpoint > > determines > > > between a 1.0 and 2.0 call when both are supported. > > > > The damage done by interpreting a malformed 1.0 request (the > > odd attempt to use 1.0 by only including 'oauth_token') is at > > most returning an 'invalid-token' response. I hope every > > server developer understands that they should not share > > tokens between 1.0 and 2.0 with completely different security > > properties. > > > > I think there are more issue with regard to 1.0 to 2.0 > > migration that should be addressed, and I have asked those > > who care about this to propose a draft. Given that such a > > draft will not be useful for a long time, given that the vast > > majority of OAuth implementation 1-2 years from now will be > > 2.0, I do not want to include it in the core specification. > > > > In order for your argument to stand, you need to show how the > > current setup leads to interoperability problems. Given the 4 > > options above, and the fact that a malformed 1.0 request will > > still fail, I do not agree that interop is affected. > > > > > > > -----Original Message----- > > > From: Justin Richer [mailto:jric...@mitre.org] > > > Sent: Thursday, July 01, 2010 11:50 AM > > > > > 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). > > > > Yes, we can rename the 'oauth_token' parameter to something > > else. I might be included to support such an idea but not to > > 'oauth2_token', but to something that would use the same > > parameter name across the header and query/body. At the same > > time, I consider using the query/body parameters as hacks so > > I'm generally not sympathetic to changes there. > > > > 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
