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.
Rob
Justin Richer wrote:
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).
-- Justin
On Thu, 2010-07-01 at 14:25 -0400, William Mills wrote:
+1 on this. Makes life interesting on the PR.
When tokens are passed in the query string there is no scheme.
-----Original Message-----
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, July 01, 2010 11:16 AM
To: Eran Hammer-Lahav
Cc: William Mills; Rob Richards; oauth@ietf.org
Subject: Re: [OAUTH-WG] Versioning
On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav
<e...@hueniverse.com> wrote:
Why is a version better than a new scheme name?
Sure, but then make the scheme more specific. What will the
scheme name be for OAuth 3?
When tokens are passed in the query string there is no scheme.
Marius
EHL
-----Original Message-----
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Thursday, July 01, 2010 10:49 AM
To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org
Subject: RE: [OAUTH-WG] Versioning
My feeling on this is that versioning explicitly in the
protocol adds
clarity and some small level of compatibility. Different auth and
token endpoints are easy, what's harder is supporting multiple
protocols on the same protected resource. It's on the protected
resource I'd like to see some clearer protocol version spec so I'm
not having to figure out from the variable names which
protocol it is.
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Eran Hammer-Lahav
Sent: Thursday, July 01, 2010 9:36 AM
To: Rob Richards; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Versioning
Hi Rob,
-----Original Message-----
From: Rob Richards [mailto:rricha...@cdatazone.org]
Sent: Thursday, July 01, 2010 3:26 AM
To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav
Subject: Versioning
Versioning is still something that needs to be addressed
before being
being able to consider the draft core complete.
Versioning rarely works because when you define it, you have no
idea what the requirements will be for the next version. A good
example is the OAuth 1.0 version parameter. When we worked to
revised 1.0 into 1.0a, we had a long debate on changing the
protocol version number. We had a hard time agreeing on what the
version meant and what was it a version
*of*: the signature method or the token flow.
If this protocol will require significant changes in the future
that go beyond its extensibility support, such a new
version will
need to use different endpoints (token or end-user
authorization)
and/or different HTTP authentication scheme.
If you want to discuss versioning, you must provide your
requirements for such a feature, and clearly show how
they are not
served by the current extensibility proposal.
On this I'm still of the opinion that at the very minimum you
will need to require an oauth_version parameter for
the resource
endpoints,
if not also for the others as well.
I think the difficulty of differentiating a 1.0 from a 2.0
protected resource request is exaggerated. As said
before, you can
tell the difference based on the presence of other parameter
(oauth_signature_method), or by examining the provided token
(assuming you issue different tokens for each version). The
argument that a 2.0 request can also be a malformed 1.0
request is
silly. I have yet to hear about that level of incompetence for a
1.0 developer (and I've heard about a lot) - omitting
every other required parameter.
At most, I'm open to renaming the oauth_token parameter to
something else (oauth_access_token, oauth.token, oauth-token,
etc.) but I think even that is not needed.
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
_______________________________________________
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
