>> What happens if a 1.0 client receives a WWW-Authenticate header
>> from a 2.0 protected resource with the 'OAuth' mechanism specified?
>> Might it then attempt OAuth 1 with a 2.0 token service (and thus
>> just fail without being able to know what went wrong)?
> There is no such thing. Since th
y, July 15, 2010 4:38 PM
To: Torsten Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header
The formats for 1.0 and 2.0 are sufficiently different that it
is possible to unambiguously figure out what version is
The formats for 1.0 and 2.0 are sufficiently different that it is possible
to unambiguously figure out what version is being used.
-Naitik
On Thu, Jul 15, 2010 at 3:56 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> where is the relation between token version and HTTP authenticatio
where is the relation between token version and HTTP authentication
scheme version?
regards,
Torsten.
Am 15.07.2010 23:34, schrieb Naitik Shah:
I though we'd come to a decision on the versioning too :) IMHO, it's
better to push this burden of versioning into the token itself if
necessary. I t
I though we'd come to a decision on the versioning too :) IMHO, it's better
to push this burden of versioning into the token itself if necessary. I
think it's better from a developers perspective to pass an oauth_token,
because it's cleaner. Most deployments will already have versioned tokens to
en
> Framing the argument against "having a 2 in it" as bikeshedding is missing
> the point. My reason against using OAuth2 is that is will undermine all the
> work put in to build an extensible framework that can evolve without needing
> a whole new version. By putting a version number, we make it
> > It was discussed before, but I don't remember there being any consensus
> > in the group. What are the practical reasons for not using "oauth2"
> > namespacing in the one place we still use namespacing? Most of what I've
> > heard seems to sound like "I don't like it to have a 2 on it".
>
> I
On Thu, Jul 15, 2010 at 11:36 AM, Eran Hammer-Lahav wrote:
> Framing the argument against "having a 2 in it" as bikeshedding is missing
> the point. My reason against using OAuth2 is that is will undermine all the
> work put in to build an extensible framework that can evolve without needing
>
Thursday, July 15, 2010 11:36 AM
> To: Luke Shepard
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header
>
> Framing the argument against "having a 2 in it" as
> bikeshedding is missing the point. My reason against using
> OAuth2 is tha
There is no such thing. Since there is no discovery for 1.0, all calls are
hardcoded into the client today. There is no 'trying things out'.
EHL
On Jul 15, 2010, at 14:33, "John Kemp" wrote:
> On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote:
>
>> I would like people to raise their han
On Jul 15, 2010, at 2:35 PM, David Recordon wrote:
> Given that OAuth discovery hasn't been written yet, how would an OAuth 1.0
> client know about a 2.0 protected resource in the first place?
It wouldn't know anything other than it got back a WWW-Authenticate header when
accessing the resource
Framing the argument against "having a 2 in it" as bikeshedding is missing the
point. My reason against using OAuth2 is that is will undermine all the work
put in to build an extensible framework that can evolve without needing a whole
new version. By putting a version number, we make it more at
Given that OAuth discovery hasn't been written yet, how would an OAuth 1.0
client know about a 2.0 protected resource in the first place?
On Thu, Jul 15, 2010 at 11:33 AM, John Kemp wrote:
> On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote:
>
> > I would like people to raise their hand and
On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote:
> I would like people to raise their hand and explain how this will break
> actual 1.0 deployments.
What happens if a 1.0 client receives a WWW-Authenticate header from a 2.0
protected resource with the 'OAuth' mechanism specified? Might it
On Jul 15, 2010, at 10:51 AM, Justin Richer wrote:
> It was discussed before, but I don't remember there being any consensus
> in the group. What are the practical reasons for not using "oauth2"
> namespacing in the one place we still use namespacing? Most of what I've
> heard seems to sound like
It was discussed before, but I don't remember there being any consensus
in the group. What are the practical reasons for not using "oauth2"
namespacing in the one place we still use namespacing? Most of what I've
heard seems to sound like "I don't like it to have a 2 on it".
I don't want to have
.org] On
Behalf Of David Recordon
Sent: Thursday, July 15, 2010 10:38 AM
To: Brian Eaton
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header
I thought this topic had been beaten to death before. An OAuth
1.0 pro
On Thu, Jul 15, 2010 at 10:37 AM, David Recordon wrote:
> I thought this topic had been beaten to death before.
Can you give me a pointer to the earlier threads?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I thought this topic had been beaten to death before. An OAuth 1.0 protected
resource request includes a variety of oauth_ parameters whereas OAuth 2.0
just has oauth_token.
--David
On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton wrote:
> On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer wrote:
>
+1 for both
2010/7/15 Justin Richer :
> +1 on OAuth2 header, and I also want to see oauth2_token in URI and form
> parameter methods.
>
> 1.0 clients will talk to systems that support both oauth2 and oauth1
> simultaneously. Most likely on the same PR endpoints as well. Since the
> protocols are n
On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer wrote:
> +1 on OAuth2 header, and I also want to see oauth2_token in URI and form
> parameter methods.
Good point about the query parameter names needing to be unambiguous.
___
OAuth mailing list
OAuth@ietf
Well, no. We're rolling out new Oauth 1.0a stuf even now, because 2.0
isn't ready and Oauth 1.0a is better than many alternatives.
>
> OAuth is dead, long live OAuth. Right? I mean, you don't move
> the White House to another address every time you get a new
> president...
>
> b.
On 15 July 2010 15:59, Justin Richer wrote:
> +1 on OAuth2 header, and I also want to see oauth2_token in URI and form
> parameter methods.
>
> 1.0 clients will talk to systems that support both oauth2 and oauth1
> simultaneously. Most likely on the same PR endpoints as well. Since the
> protocols
+1 on OAuth2 header, and I also want to see oauth2_token in URI and form
parameter methods.
1.0 clients will talk to systems that support both oauth2 and oauth1
simultaneously. Most likely on the same PR endpoints as well. Since the
protocols are not backwards compatible, they should be able to co
To elaborate a bit:
Since there is no discovery in 1.0, the only place this can create a conflict
is on the server side, when servers support both new and old schemes, and need
to tell which version the client is using. This is the same issue as using the
'oauth_token' parameter in the query or
I would like people to raise their hand and explain how this will break actual
1.0 deployments.
EHL
On Jul 15, 2010, at 1:38, Brian Eaton wrote:
> Draft 10 switched from "Token" scheme in the authorization header to
> "OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great.
> "
> Draft 10 switched from "Token" scheme in the authorization header to
> "OAuth". I'd rather we didn't reuse OAuth.
I agree that "OAuth" is taken as a scheme name.
I like "Bearer" for the Authorization header scheme holding an access token.
We should use a different name for the WWW-Authenticati
+1 for "OAuth2"
Brian Eaton schrieb:
Draft 10 switched from "Token" scheme in the authorization header to
"OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great.
"Token" is ugly as sin, but is better than "OAuth".
Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#pag
nt: Wednesday, July 14, 2010 10:39 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] OAuth vs OAuth2 in Authorization header
>
> Draft 10 switched from "Token" scheme in the authorization
> header to "OAuth". I'd rather we didn't reuse OAuth.
> '
Draft 10 switched from "Token" scheme in the authorization header to
"OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great.
"Token" is ugly as sin, but is better than "OAuth".
Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30
The problem with reusing "OAuth" i
30 matches
Mail list logo
