Re: [OAUTH-WG] Versioning

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

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: [e-mail] [mailto:[e-mail]] 
> On Behalf Of William Mills
> Sent: Thursday, July 01, 2010 2:36 PM
> To: Eran Hammer-Lahav; [e-mail]
> 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: [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
> > 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>