[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
