Re: [OAUTH-WG] Versioning

["William Mills" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Eran Hammer-Lahav
> Sent: Thursday, July 01, 2010 2:24 PM
> To: [e-mail]
> Subject: Re: [OAUTH-WG] Versioning
> 
> [Replying to everything at once...]
> 
> > -----Original Message-----
> > From: Marius Scurtescu [mailto:[e-mail]]
> > 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:[e-mail]]
> > 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:[e-mail]]
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>