Subject: [OAUTH-WG] Bear token scheme name

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 19 Jan 2011 00:05:56 -0700

Please change the draft to use a different scheme name than 'OAuth2' for the bearer token authentication scheme. Given the unstable state of the header (still is), it is perfectly fine to make this change. The list includes a detailed discussion about this. I am strongly opposed to giving the bearer token scheme a name giving it the appearance of the preferred or canonical token authentication method. I don't care what you change it to as long as it is not 'OAuth2' or 'OAuth'.

EHL

---

From: Mike Jones <[email-masked]>
Date: Wed, 19 Jan 2011 18:10:55 +0000

I'd like a sense from the working group whether others want this change, and if so, what the name should be changed to.

                                                            Thanks,
                                                            -- Mike

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 11:06 PM
To: Mike Jones
Cc: OAuth WG
Subject: Bear token scheme name

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 25 Jan 2011 18:26:20 -0800

On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones
<[email-masked]> wrote:
> I’d like a sense from the working group whether others want this change, and
> if so, what the name should be changed to.

Probably this was debated, but I will ask again.

Why can't we use "OAuth2" as the scheme in all cases and require a
token_type name/value pair?

Is it wise to dump lots of new schemes in a name space we do not control?

Marius

---

From: William Mills <[email-masked]>
Date: Tue, 25 Jan 2011 18:34:48 -0800

As I remember there was serious objection by a few to putting versioning in the scheme name.  OAuth, OAuth2, and soon we're on OAuthN+1 seemed to be the objection.  Some are passionate about it and no one was sufficiently passionate about going with OAuth2 and some kind of token_type.

Logically token_type doesn't actually fully describe the possibilities, since we can extend to signed requests etc that don't include a token per se.

So...  since the extensions were going to be broken out into their own specs, I believe the thought was to have those specs define their own namespaces.  There is certainly a land grab problem there on the scheme namespace.

I personally don't have a preference, but it does seem cleaner to me to have an IANA style registry for the OAuth2 auth_subtype= or some such.

-bill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Marius Scurtescu
> Sent: Tuesday, January 25, 2011 6:26 PM
> To: Mike Jones
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Bear token scheme name
> 
> > I'd like a sense from the working group whether others want this
> change, and
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Tue, 25 Jan 2011 18:40:20 -0800

Also it's possible that extensions will define an authentication scheme which is available through Oauth2 and also through other pathways.  It might be you can obtain a MAC token through a flow other than OAuth.

> Of William Mills
> Sent: Tuesday, January 25, 2011 6:35 PM
> To: Marius Scurtescu; Mike Jones
> Cc: OAuth WG
> As I remember there was serious objection by a few to putting
> versioning in the scheme name.  OAuth, OAuth2, and soon we're on
> OAuthN+1 seemed to be the objection.  Some are passionate about it and
> no one was sufficiently passionate about going with OAuth2 and some
> kind of token_type.
> 
> Logically token_type doesn't actually fully describe the possibilities,
> since we can extend to signed requests etc that don't include a token
> per se.
> 
> So...  since the extensions were going to be broken out into their own
> specs, I believe the thought was to have those specs define their own
> namespaces.  There is certainly a land grab problem there on the scheme
> namespace.
> 
> I personally don't have a preference, but it does seem cleaner to me to
> have an IANA style registry for the OAuth2 auth_subtype= or some such.
> 
> -bill
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 25 Jan 2011 22:59:08 -0700

Simply because authentication is not what OAuth is about.

OAuth is an authorization protocol for issuing access tokens. Access tokens can have different properties and therefore need different schemes. I was the first to suggest a scheme with sub-schemes but that idea was strongly rejected (over a year ago). Since then I came to the same conclusion that the proper way is to define separate authentication schemes. It is also how most HTTP authentication framework operate.

One benefit to this approach is that HTTP authentication already covers the discovery of which schemes are supported by the resource server, as well as token schemes can be used independently from OAuth, something the 2-legged OAuth 1.0 has shown has great value. Also, it keeps the protocol modular which enable providers to tailor it to their security needs.

OAuth 2.0 is authentication agnostic and must remain so. It is an authorization protocol and as such has no business defining authentication mechanisms.

For this reason, I object to using the OAuth2 scheme name with the bearer token scheme. It's a "trademark" issue.

EHL

> > change, and if so, what the name should be changed to.
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 26 Jan 2011 06:07:26 +0000

To the extent that the OAuth2 protocols are intended to provide an end-to-end solution, the more consistency the better, hence the "OAuth2" name.  Since the same feature used the "OAuth" name in draft 10 (which you authored), I find it hard to take seriously your objections to the "OAuth2" name in the bearer token spec, when the description of the feature is exactly the same (and which you actually wrote). 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, January 25, 2011 9:59 PM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Bear token scheme name

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 25 Jan 2011 23:27:12 -0700

Since you are a recent addition to the working group, you probably don't know that I objected to using both the OAuth and OAuth2 scheme names and wanted to call the scheme name Token. Producing a generally applicable HTTP authentication scheme is actually in our original charter and was one of the goals. Calling it OAuth2 is not generally applicable.

As for the end-to-end solution, it was never intended to be (nor can it), with or without the bearer token addition. OAuth is a single (authorization) protocol. The bearer token is a separate protocol with an OAuth2 binding, as is the MAC authentication scheme.

For 10 drafts, the bearer token language was part of the document I edited. I don't think anyone has any doubts regarding my disagreement with it throughout the process. I am pretty sure I also made it clear when I spent an hour on the phone helping get started on the draft, including explicitly telling you that the scheme name is an open issue you need to approach the working group about.

And speaking of being taken seriously, you can't be serious suggesting that my editorial role obliges me to subscribe to any views expressed in a working group document.

EHL

> From: Mike Jones [mailto:[email-masked]]
> Sent: Tuesday, January 25, 2011 10:07 PM
> To: Eran Hammer-Lahav; Marius Scurtescu
> Cc: OAuth WG
> Subject: RE: [OAUTH-WG] Bear token scheme name
> 
> To the extent that the OAuth2 protocols are intended to provide an end-to-
> end solution, the more consistency the better, hence the "OAuth2" name.
> Since the same feature used the "OAuth" name in draft 10 (which you
> authored), I find it hard to take seriously your objections to the "OAuth2"
> name in the bearer token spec, when the description of the feature is
> exactly the same (and which you actually wrote).
> 
> Of Eran Hammer-Lahav
> OAuth is an authorization protocol for issuing access tokens. Access tokens
> can have different properties and therefore need different schemes. I was
> the first to suggest a scheme with sub-schemes but that idea was strongly
> rejected (over a year ago). Since then I came to the same conclusion that the
> proper way is to define separate authentication schemes. It is also how most
> HTTP authentication framework operate.
> 
> One benefit to this approach is that HTTP authentication already covers the
> discovery of which schemes are supported by the resource server, as well as
> token schemes can be used independently from OAuth, something the 2-
> legged OAuth 1.0 has shown has great value. Also, it keeps the protocol
> modular which enable providers to tailor it to their security needs.
> 
> OAuth 2.0 is authentication agnostic and must remain so. It is an
> authorization protocol and as such has no business defining authentication
> mechanisms.
>

---

From: William Mills <[email-masked]>
Date: Tue, 25 Jan 2011 23:23:06 -0800

Back to Marius' question though, which is about how we determine how to treat the Authenticate header when you see it.  I, for one, was not happy with the way that Wrap added on to the OAuth scheme.  There are at least 3 possibilities that it seems to be worth discussing:

1) a fixed scheme name with a variable indicating flavor, i.e. Oauth2 authtype=bearer, but we could go more agnostic like "Authz type=bearer" if OAuth2 really chafes.

PRO: simple namespace

2) a scheme per auth type extension: i.e. bearer, MAC, SAML, etc.  \

PRO: easy to extend, in no way semantically bound to OAuth
CON: namespace pollution and a proliferation of auth types

3) as yet un-discussed, we could reserve a namespace like oauth2_ and use things like oauth2_bearer.

2 and 3 are not exclusive.  Are there more?  

There's also discussion that this is authorization, not authentication, and if we really want to go there then the source of the problem might be that we're choosing to overload the Authenticate header.  Even more muddy, it's entirely possible that a bearer token might contain a user credential.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 01:48:31 -0700

Thanks William.

It is important to differentiate between style and substance (both of which are very important to people).

Style-wise, we can use either of the three options below, but they are essentially the same. You take the string and put it through a parser and end up with the actual scheme name and some attributes. I don't really buy the arguments about namespaces and pollution.

Creating a super scheme that then has to be extended for sub-schemes is actually a lot more complex. AFAIK, all the existing HTTP authentication schemes are not extensible (or at least have not been extended). There is something very helpful in moving extensibility out of the scheme so that a client that can speak it today can also speak it 10 years from now. If you need new options, create a new scheme.

I like the scheme-per-type approach because it is modular and does not require much coordination. The lack of consensus we've seen between bearer tokens and mac tokens is an example. I don't want to have to negotiate parameter names and other formats when such collaboration will just slow both efforts and lead to no meaningful interoperability (given that the two token types are completely incompatible).

The HTTP authentication headers are named poorly. The WWW-Authenticate means 'you need to authenticate' and the Authorization header means 'here is my authentication credentials'. There is no actual authorization as implemented by OAuth (in terms of third party and grants). When talking about using a token to access a protected resource, we are dealing exclusively with authentication and should use the right HTTP vehicle for that.

EHL

> From: William Mills [mailto:[email-masked]]
> Sent: Tuesday, January 25, 2011 11:23 PM
> To: Eran Hammer-Lahav; Mike Jones
> Cc: OAuth WG
> Back to Marius' question though, which is about how we determine how to
> treat the Authenticate header when you see it.  I, for one, was not happy
> with the way that Wrap added on to the OAuth scheme.  There are at least 3
> possibilities that it seems to be worth discussing:
> 
> 1) a fixed scheme name with a variable indicating flavor, i.e. Oauth2
> authtype=bearer, but we could go more agnostic like "Authz type=bearer" if
> OAuth2 really chafes.
> 
> PRO: simple namespace
> 
> There's also discussion that this is authorization, not authentication, and if we
> really want to go there then the source of the problem might be that we're
> choosing to overload the Authenticate header.  Even more muddy, it's
> entirely possible that a bearer token might contain a user credential.
> 
>

---

From: William Mills <[email-masked]>
Date: Wed, 26 Jan 2011 08:43:35 -0800

I question how much name space pollution is a problem, how many auth schemes are we really going to have?  

> Sent: Wednesday, January 26, 2011 12:49 AM
> To: William Mills
> Cc: OAuth WG
> Style-wise, we can use either of the three options below, but they are
> essentially the same. You take the string and put it through a parser
> and end up with the actual scheme name and some attributes. I don't
> really buy the arguments about namespaces and pollution.
> 
> Creating a super scheme that then has to be extended for sub-schemes is
> actually a lot more complex. AFAIK, all the existing HTTP
> authentication schemes are not extensible (or at least have not been
> extended). There is something very helpful in moving extensibility out
> of the scheme so that a client that can speak it today can also speak
> it 10 years from now. If you need new options, create a new scheme.
> 
> I like the scheme-per-type approach because it is modular and does not
> require much coordination. The lack of consensus we've seen between
> bearer tokens and mac tokens is an example. I don't want to have to
> negotiate parameter names and other formats when such collaboration
> will just slow both efforts and lead to no meaningful interoperability
> (given that the two token types are completely incompatible).
> 
> The HTTP authentication headers are named poorly. The WWW-Authenticate
> means 'you need to authenticate' and the Authorization header means
> 'here is my authentication credentials'. There is no actual
> authorization as implemented by OAuth (in terms of third party and
> grants). When talking about using a token to access a protected
> resource, we are dealing exclusively with authentication and should use
> the right HTTP vehicle for that.
> 
> EHL
> 
> > 3) as yet un-discussed, we could reserve a namespace like oauth2_ and
> use
> > things like oauth2_bearer.
> >
> > > > > Is it wise to dump lots of new schemes in a name space we do
> not
> > > control?
> > > > >
> > > > > Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 09:47:42 -0700

No clue, but what difference does it make? Either you "pollute" the OAuth header namespace or the HTTP Authentication scheme name namespace. What's the difference? Either way, I would be surprised if we see more than 10 token types over the next 5 years.

EHL

> Sent: Wednesday, January 26, 2011 8:44 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> > Creating a super scheme that then has to be extended for sub-schemes
> > is actually a lot more complex. AFAIK, all the existing HTTP
> > resource, we are dealing exclusively with authentication and should
> > use the right HTTP vehicle for that.
> >
> > EHL
> >
> > > 1) a fixed scheme name with a variable indicating flavor, i.e.
> > > Oauth2 authtype=bearer, but we could go more agnostic like "Authz
> > type=bearer" if
> > > OAuth2 really chafes.
> > >
> > > PRO: simple namespace
> > >
> > > > > > From: [email-masked] [mailto:[email-masked]]
> > > > > > On
> > > > Behalf
> > > > > > Of Marius Scurtescu

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 26 Jan 2011 13:14:29 -0800

> As I remember there was serious objection by a few to putting versioning in the scheme name.  OAuth, OAuth2, and soon we're on OAuthN+1 seemed to be the objection.  Some are passionate about it and…

Sure, then we can use something version agnostic like "OAuth". And
maybe add a version name/value pair if needed (OAuth 1 has one).

> Logically token_type doesn't actually fully describe the possibilities, since we can extend to signed requests etc that don't include a token per se.

Can you give an example that make sense with OAuth? If there is no
token then that's not OAuth IMO.

> I personally don't have a preference, but it does seem cleaner to me to have an IANA style registry for the OAuth2 auth_subtype= or some such.

Yes, I think that's much cleaner.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 26 Jan 2011 13:22:46 -0800

> For this reason, I object to using the OAuth2 scheme name with the bearer token scheme. It's a "trademark" issue.

I can definitely see your point, but look at the end result. OAuth is
useless with an authentication mechanism so now a bunch of similar
authentication mechanisms are reinvented in related specifications.
All geared to work with OAuth 2, none of them really trying to define
something generic.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Jan 2011 15:27:10 -0700

MAC is clearly trying to define something generic and includes an OAuth binding. I think the bearer token is the exception of something completely useless outside of OAuth, but that doesn't mean it uselessness should promote it to the canonical authentication scheme, all of which was already dealt with when we split it out.

EHL

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Wednesday, January 26, 2011 1:23 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> I can definitely see your point, but look at the end result. OAuth is useless
> with an authentication mechanism so now a bunch of similar authentication
> mechanisms are reinvented in related specifications.