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
