Subject: [OAUTH-WG] OAuth vs OAuth2 in Authorization header

From: Brian Eaton <[email-masked]>
Date: Wed, 14 Jul 2010 22:38:43 -0700

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" is that there are existing
implementations in the wild that have special behavior implemented for
OAuth authorization headers.  Since OAuth2 headers don't have the same
semantics, we're going to break those implementations.  We shouldn't
reuse "OAuth" for the same reasons we shouldn't reuse "Negotiate",
"NTLM", "Digest", or "Basic.

Cheers,
Brian

---

From: "William Mills" <[email-masked]>
Date: Wed, 14 Jul 2010 22:51:03 -0700

Token makes sense in the context of provisioning a more general token
auth header which we overload on.  That said I'm glad we're getting
simpler.   

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Eaton
> Sent: Wednesday, July 14, 2010 10:39 PM
> To: [email-masked]
> 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.  
> 'OAuth2' would be great.
> Spec section: 
> http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30
> 
> implementations in the wild that have special behavior 
> implemented for OAuth authorization headers.  Since OAuth2 
> headers don't have the same semantics, we're going to break 
> those implementations.  We shouldn't reuse "OAuth" for the 
> same reasons we shouldn't reuse "Negotiate", "NTLM", 
> "Digest", or "Basic.
> 
> Cheers,
> Brian
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 15 Jul 2010 08:23:00 +0200

+1 for "OAuth2"

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 15 Jul 2010 17:00:44 +1000

> "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-Authentication scheme that announces that user delegation or credential-swapping can be used to get credentials to access this service. "OAuth2" would be a decent choice for this, "Delegate" might be even better.

--> GET ...
<-- 401
    WWW-Authenticate: Delegate realm=... user_uri=... token_uri=... features=...
<-> do the OAuth2 stuff
--> GET ...
    Authorization: Bearer a=...

-- 
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Jul 2010 06:07:20 -0700

I would like people to raise their hand and explain how this will break actual 1.0 deployments. 

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Jul 2010 06:25:57 -0700

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 body. Since there is no discovery, no 2.0 client is going to try and talk to a 1.0 server because that would be a like trying to speak SMTP to an XMPP port. On the server side, adding support for 2.0 already requires code changes.

If this proves to be an actual issue with a deployed system, I don't care about using a different name but:

- 'OAuth2' is "ugly as sin", and puts us on the broken path to produce an 'OAuth3', etc.
- We need to have more discussions about using different schemes with different token properties (i.e. Bearer, Signed, etc.). Some here want to break this into highly specialized schemes, while others want to use 2, and some a single scheme for everything (similar to 1.0). Using multiple headers doesn't break much on the 'Authorization' side because the server can easily handle it. But on the 'WWW-Authenticate' side it means having to define multiple schemes with their own discovery parameters, their own extensions, etc. This will turn into an complex and messy framework with too many confusing headers, etc.

So bikeshedding aside, we need to reach consensus on how to architect the headers first, then we can find a name or names that don't annoy people like 'Token', 'OAuth', or 'OAuth2'.

EHL

On 7/15/10 6:07 AM, "Eran Hammer-Lahav" <[email-masked]> wrote:

EHL

---

From: Justin Richer <[email-masked]>
Date: Thu, 15 Jul 2010 10:59:29 -0400

+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 coexist. 

 -- Justin

---

From: Blaine Cook <[email-masked]>
Date: Thu, 15 Jul 2010 16:13:40 +0100

> protocols are not backwards compatible, they should be able to coexist.

I tend to agree with Eran here – 1.0 clients talking to systems that
support both OAuth 2 and OAuth 1 will notice no difference. The server
will have to switch protocol handling, but can do so on the presence
of OAuth 1 or OAuth 2-specific parameters. Clients using OAuth 1.0
shouldn't have to do anything, and shouldn't notice any change.

This absolutely makes things a tiny bit more complicated for service
providers that have already deployed OAuth 1 services and wish to move
to OAuth 2, but frankly if the provider can't figure it out, they have
larger problems (unless someone can provide a really compelling reason
why switching in this way is actually really hard, I just can't buy
it).

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.

---

From: "William Mills" <[email-masked]>
Date: Thu, 15 Jul 2010 09:22:36 -0700

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.

---

From: Brian Eaton <[email-masked]>
Date: Thu, 15 Jul 2010 10:12:56 -0700

> +1 on OAuth2 header, and I also want to see oauth2_token in URI and form

Good point about the query parameter names needing to be unambiguous.

---

From: Lukas Rosenstock <[email-masked]>
Date: Thu, 15 Jul 2010 19:36:25 +0200

+1 for both

---

From: David Recordon <[email-masked]>
Date: Thu, 15 Jul 2010 10:37:56 -0700

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

---

From: Brian Eaton <[email-masked]>
Date: Thu, 15 Jul 2010 10:40:17 -0700

On Thu, Jul 15, 2010 at 10:37 AM, David Recordon <[email-masked]> wrote:
> I thought this topic had been beaten to death before.

Can you give me a pointer to the earlier threads?

---

From: "William Mills" <[email-masked]>
Date: Thu, 15 Jul 2010 10:41:49 -0700

No, the people who don't like the sharing of the namespace between the 2
still don't like it, and the people that can;t stand teh idea of using
oauth2 for anything still won't move.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Recordon
	Sent: Thursday, July 15, 2010 10:38 AM
	To: Brian Eaton
	Cc: [email-masked]
	Subject: Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header

	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
<[email-masked]> wrote:

		> +1 on OAuth2 header, and I also want to see
oauth2_token in URI and form

		Good point about the query parameter names needing to be
unambiguous.

---

From: Justin Richer <[email-masked]>
Date: Thu, 15 Jul 2010 13:51:31 -0400

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 to set up the OAuth 2 system to have to catch
failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad
OAuth 1 call should be distinguishable from the start. Also, what about
when we finally get a signed-request going? I would assume that that's
going to add back in things like oauth_signature, oauth_nonce, and the
other parameters whose absence you should filter on. 

 -- Justin

On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote:
> I thought this topic had been beaten to death before. An OAuth 1.0
> protected resource request includes a variety of oauth_ parameters

---

From: Luke Shepard <[email-masked]>
Date: Thu, 15 Jul 2010 18:24:20 +0000

> heard seems to sound like "I don't like it to have a 2 on it". 

I don't like it to have a 2 in it.

> other parameters whose absence you should filter on. 

The latest signature discussions have all focused on a single, self-contained, signed parameter that includes both data and signature. I think it's unlikely that we will introduce the plethora of parameters that we had in OAuth 1.0.

---

From: John Kemp <[email-masked]>
Date: Thu, 15 Jul 2010 14:33:06 -0400

> 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 then attempt OAuth 1 with a 2.0 token service (and thus just fail without being able to know what went wrong)? 

- johnk

---

From: David Recordon <[email-masked]>
Date: Thu, 15 Jul 2010 11:35:38 -0700

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 <[email-masked]> wrote:

> 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)?
>
> - johnk
>
> >
> > EHL
> >
> >
> >

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Jul 2010 11:36:13 -0700

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 attractive to change the protocol than extend it.

So far the arguments made are all theoretical.

I will maintain  my objection and preference to reuse the existing names until someone with an existing 1.0 deployment can make a compelling reason why they can rely on the presence of the oauth_signature_method to differentiate. 

EHL

---

From: John Kemp <[email-masked]>
Date: Thu, 15 Jul 2010 14:37:56 -0400

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, and (thought it) knew what to do with the OAuth mechanism.

- johnk

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Jul 2010 11:39:15 -0700

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

---

From: "William Mills" <[email-masked]>
Date: Thu, 15 Jul 2010 11:50:07 -0700

Lots of things can be done.  Checking presence of oauth_signature_method
implies that the format is the same in all cases including the auth
header right?

What you seem to be arguing for right now is parsing the entire line to
decide which auth you do.  I would *much* prefer a leading tag or scheme
name so I don't have to go there.

To me this is an argument about complexity.  Your solution involves more
complex code to differentiate. 

> On Behalf Of Eran Hammer-Lahav
> Sent: Thursday, July 15, 2010 11:36 AM
> To: Luke Shepard
> Cc: [email-masked]
> 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 attractive to change the protocol than extend it.
> 
> I will maintain  my objection and preference to reuse the 
> existing names until someone with an existing 1.0 deployment 
> can make a compelling reason why they can rely on the 
> presence of the oauth_signature_method to differentiate. 
> 
> EHL
> 
> 
> 
> >> 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".
> > 
> >> OAuth 1 call should be distinguishable from the start. Also, what 
> >> about when we finally get a signed-request going? I would 
> assume that 
> >> that's going to add back in things like oauth_signature, 
> oauth_nonce, 
> >> and the other parameters whose absence you should filter on.
> > 
> > The latest signature discussions have all focused on a 
> single, self-contained, signed parameter that includes both 
> data and signature. I think it's unlikely that we will 
> introduce the plethora of parameters that we had in OAuth 1.0.
> > 
> >> -- Justin
> >>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 15 Jul 2010 11:56:49 -0700

> 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 t…

Sure, but clearly there is no evolution from OAuth 1 to OAuth 2. If
the next version of OAuth is an evolution of OAuth 2 then it probably
should not be called OAuth 3 but rather OAtuh 2.1 and then header and
parameter names can be kept the same. At some point a new revolution
will be needed and then OAuth 3 is appropriate, as well as new header
and parameter names.

Marius

---

From: Justin Richer <[email-masked]>
Date: Thu, 15 Jul 2010 15:15:15 -0400

> I don't like it to have a 2 in it.

OK, I would. :)

> The latest signature discussions have all focused on a single, self-contained, signed parameter that includes both data and signature. I think it's unlikely that we will introduce the plethora of p…

Yeah, I'd noticed that; but those all stemmed around cryptographic
verification of the token itself, and not the request that contained the
token. There seems to be a lot of interest in coming up with a way for
the AS to sign the token so that the PR can verify its authenticity, but
what about the original use case of the PR being able to verify the
authenticity of the call?

 -- Justin

---

From: Justin Richer <[email-masked]>
Date: Thu, 15 Jul 2010 15:26:47 -0400

> 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 t…

I think that it is bikeshedding. You can build new and amazing things on
a framework named oauth2 as much as you can on something named oauth. If
OAuth3 is as backwards-incompatible as OAuth2 is, then it's going to
need its own namespace anyway, isn't it? 

> So far the arguments made are all theoretical.

Putting the '2' in there solves an issue that several WG members have
brought up when dealing with both OAuth1 and 2 simultaneously -- a case
that I think is actually going to happen. I have servers that need to
support both 1.0 and 1.0a flows simultaneously, right now. I cannot see
OAuth2 adoption and cutover being instantaneous enough across all these
different systems for these endpoints to not also support OAuth2. 

> I will maintain  my objection and preference to reuse the existing names until someone with an existing 1.0 deployment can make a compelling reason why they can rely on the presence of the oauth_si…

I'm sorry, but I simply don't understand your staunch opposition to a
simple, low-negative-impact, and decently supported request such as
this. I've heard two supporting reasons on the list already: how do I
tell the difference between a misbehaving OAuth1 and a properly-behaving
OAuth2, and how do I branch early? And I'll also add in something that I
admit is more style than anything: It just feels better to branch on the
*presence* of something rather than the *absence* of something, if we
have that choice. 

Conversely, I see no compelling reason (technical, political, or
otherwise) to *not* have it be named "oauth2".

 -- Justin

PS: I think the bikeshed is where we keep the boatcar... :)

---

From: Naitik Shah <[email-masked]>
Date: Thu, 15 Jul 2010 14:34:04 -0700

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
enable upgrading these for internal changes, so why can't the OAuth version
be contained in there too? Given the option to simplify the implementation
for a API provider (Big Company, or someone who has to know how OAuth works)
vs API consumer (Developer, or someone who usually just wants some data), I
hope everyone agrees our focus should be the Developer.

While we (Facebook) didn't have OAuth 1.0 tokens to deal with and so don't
have the same backward compatibility issues, we've already changed our
tokens and introduced new ones a couple of times and this had no impact on
the parameter name being used.

-Naitik

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 16 Jul 2010 00:56:30 +0200

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 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 enable upgrading these for internal changes, 
> so why can't the OAuth version be contained in there too? Given the 
> option to simplify the implementation for a API provider (Big Company, 
> or someone who has to know how OAuth works) vs API consumer 
> (Developer, or someone who usually just wants some data), I hope 
> everyone agrees our focus should be the Developer.
>
> While we (Facebook) didn't have OAuth 1.0 tokens to deal with and so 
> don't have the same backward compatibility issues, we've already 
> changed our tokens and introduced new ones a couple of times and this 
> had no impact on the parameter name being used.
>
>
> -Naitik
>
> On Thu, Jul 15, 2010 at 10:51 AM, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     consensus
>     about
>     > On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton <[email-masked]
>     <mailto:[email-masked]>>
>     > wrote:
>     > <[email-masked] <mailto:[email-masked]>> wrote:
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Naitik Shah <[email-masked]>
Date: Thu, 15 Jul 2010 16:37:44 -0700

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 <
[email-masked]> wrote:

>  where is the relation between token version and HTTP authentication scheme
> version?
>
> regards,
> Torsten.
>
> don't have the same backward compatibility issues, we've already changed our
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: "William Mills" <[email-masked]>
Date: Thu, 15 Jul 2010 16:53:50 -0700

Sure, but it's not easy to early branch, you have to actually parse the
whole header.  It's also fragile if extensions are not careful.

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Naitik Shah
	Sent: Thursday, July 15, 2010 4:38 PM
	To: Torsten Lodderstedt
	Cc: [email-masked]
	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 being used. 

	-Naitik

	On Thu, Jul 15, 2010 at 3:56 PM, Torsten Lodderstedt
<[email-masked]> wrote:

		where is the relation between token version and HTTP
authentication scheme version?
		
		regards,
		Torsten.

			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 enable upgrading
these for internal changes, so why can't the OAuth version be contained
in there too? Given the option to simplify the implementation for a API
provider (Big Company, or someone who has to know how OAuth works) vs
API consumer (Developer, or someone who usually just wants some data), I
hope everyone agrees our focus should be the Developer. 

			While we (Facebook) didn't have OAuth 1.0 tokens
to deal with and so don't have the same backward compatibility issues,
we've already changed our tokens and introduced new ones a couple of
times and this had no impact on the parameter name being used.

			-Naitik

			On Thu, Jul 15, 2010 at 10:51 AM, Justin Richer
<[email-masked]> 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 "I don't like
it to have a 2 on it".
				
				I don't want to have to set up the OAuth
2 system to have to catch
				failed cases of the OAuth 1 protocol. A
good OAuth 2 call and a bad
				OAuth 1 call should be distinguishable
from the start. Also, what about
				when we finally get a signed-request
going? I would assume that that's
				going to add back in things like
oauth_signature, oauth_nonce, and the
				other parameters whose absence you
should filter on.
				
				 -- Justin

				On Thu, 2010-07-15 at 13:37 -0400, David
Recordon wrote:
				> On Thu, Jul 15, 2010 at 10:12 AM,
Brian Eaton <[email-masked]>
				>         > +1 on OAuth2 header, and I
also want to see oauth2_token in
				>         URI and form

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 16 Jul 2010 14:21:53 +1000

>> 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 there is no discovery for 1.0,
> all calls are hardcoded into the client today.
> There is no 'trying things out'.

There was "discovery" in OAuth 1: it was inadequate, but it was present in the spec.
RFC 5849 "OAuth 1.0", section 3.5.1 "Authorization header" <http://tools.ietf.org/html/rfc5849#section-3.5.1> defines "WWW-Authenticate: OAuth realm=..." as indicating a server supports OAuth 1.0.

   Servers MAY indicate their support for the "OAuth" auth-scheme by
   returning the HTTP "WWW-Authenticate" response header field upon
   client requests for protected resources.  As per [RFC2617], such a
   response MAY include additional HTTP "WWW-Authenticate" header
   fields:

   For example:

     WWW-Authenticate: OAuth realm="http://server.example.com/"

Perhaps it wasn't used much, but reusing the "OAuth" scheme to indicate support for OAuth2 is incompatible. It adds human confusion, regardless of any technical ability to distinguish OAuth 1 & 2.

-- 
James Manger