Subject: [OAUTH-WG] Update required for bearer token spec

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 27 Jan 2011 14:42:00 -0700

Please update the draft to comply with -12 registration guidelines and requirements asap.

EHL

---

From: Mike Jones <[email-masked]>
Date: Thu, 27 Jan 2011 22:09:47 +0000

Your request below is ambiguous.  Please provide the precise new text you're requesting and the rationale for it.

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Thursday, January 27, 2011 1:42 PM
To: Mike Jones
Cc: OAuth WG
Subject: Update required for bearer token spec

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 27 Jan 2011 15:35:41 -0700

-12 section 8.1 and 10.1.

EHL

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, January 27, 2011 2:10 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: RE: Update required for bearer token spec

EHL

---

From: Mike Jones <[email-masked]>
Date: Fri, 28 Jan 2011 01:15:27 +0000

Once approved, the existing names will be registered, hence no changes are needed to the bearer token draft to comply with these requirements.

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Thursday, January 27, 2011 2:36 PM
To: Mike Jones
Cc: OAuth WG
Subject: RE: Update required for bearer token spec

EHL

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 27 Jan 2011 19:23:33 -0700

The bearer draft must include the registration template as done in draft-hammer-oauth-v2-mac-token section 8 including giving the name used for issuing such tokens for the token_type parameter. Every RFC must include an IANA Considerations section and your is currently in violation of -12. If you have an issue with the registration process or language in -12, the appropriate thing to do is to raise those issues on the list.

I will remove the bearer token examples from -13 due to my objections to the 'OAuth2' scheme name (which makes it an open issue) and lack of registration and token type name in the bearer token draft. I will gladly put those examples back (as they are listed in -12) once these concerns are resolved (or if instructed to by the chairs and area director). I will keep the informative reference in -13, and will only remove the examples which are incorrect.

---

As for the open issues: the bearer token scheme name - if it wasn't clear, I plan to use every mean available to me to block the bearer token draft from using the 'OAuth2' scheme name, and will raise this issue in the WGLC, Area Director review, IETF LC, and direct appeal to the IESG if necessary. You might consider this childish, but I consider  bearer tokens a disaster waiting to happen and will not allow the weakest form of token authentication to carry the strongest form of endorsement and perception (via the OAuth brand).

At the end, you might get the scheme name you want, but it will cost you significant delays in getting that document published as an RFC and with a Proposed Standard designation. So far you have failed to raise any technical justification for your insistence of using that name. The only reason so far is that it will be less confusing. Perhaps. But will be more damaging. After all, why would anyone look at the MAC token specification or other stronger authentication schemes, when you offer them the "official" OAuth 2.0 scheme.

I also want to point out that I am not the only one here who made this request. I consent that there isn't consensus to changing the name, but there isn't consensus to keeping it either. The "vote" is around 2-4 on each side.

If you are willing to spend the next few months arguing over 6 characters in your document, I will gladly oblige.

EHL

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, January 27, 2011 5:15 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: RE: Update required for bearer token spec

EHL

EHL

---

From: Mike Jones <[email-masked]>
Date: Fri, 28 Jan 2011 21:40:04 +0000

Draft 02 as published registers the parameters in the IANA Considerations section and therefore conforms to draft -12, per your request.  Therefore please retain the bearer token examples, as they are useful to implementers.

I intentionally made no breaking changes to maintain specification stability.

                                                                -- Mike

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Thursday, January 27, 2011 6:24 PM
To: Mike Jones
Cc: OAuth WG; 'Manger, James H ([email-masked])'
Subject: RE: Update required for bearer token spec

---

EHL

EHL

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 28 Jan 2011 14:55:09 -0700

I will but will replace the scheme and token names with [[tbd]] until the issue is resolved.

EHL

On Jan 28, 2011, at 13:40, "Mike Jones" <[email-masked]<mailto:[email-masked]>> wrote:

                                                                -- Mike

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Thursday, January 27, 2011 6:24 PM
To: Mike Jones
Cc: OAuth WG; 'Manger, James H ([email-masked]<mailto:[email-masked]>)'
Subject: RE: Update required for bearer token spec

I will remove the bearer token examples from -13 due to my objections to the ‘OAuth2’ scheme name (which makes it an open issue) and lack of registration and token type name in the bearer token draft. I will gladly put those examples back (as they are listed in -12) once these concerns are resolved (or if instructed to by the chairs and area director). I will keep the informative reference in -13, and will only remove the examples which are incorrect.

---

As for the open issues: the bearer token scheme name - if it wasn’t clear, I plan to use every mean available to me to block the bearer token draft from using the ‘OAuth2’ scheme name, and will raise this issue in the WGLC, Area Director review, IETF LC, and direct appeal to the IESG if necessary. You might consider this childish, but I consider  bearer tokens a disaster waiting to happen and will not allow the weakest form of token authentication to carry the strongest form of endorsement and perception (via the OAuth brand).

At the end, you might get the scheme name you want, but it will cost you significant delays in getting that document published as an RFC and with a Proposed Standard designation. So far you have failed to raise any technical justification for your insistence of using that name. The only reason so far is that it will be less confusing. Perhaps. But will be more damaging. After all, why would anyone look at the MAC token specification or other stronger authentication schemes, when you offer them the “official” OAuth 2.0 scheme.

I also want to point out that I am not the only one here who made this request. I consent that there isn’t consensus to changing the name, but there isn’t consensus to keeping it either. The “vote” is around 2-4 on each side.

EHL

EHL

Your request below is ambiguous.  Please provide the precise new text you’re requesting and the rationale for it.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Sun, 30 Jan 2011 14:45:07 -0800

On Thu, Jan 27, 2011 at 6:23 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> As for the open issues: the bearer token scheme name - if it wasn’t clear, I
> plan to use every mean available to me to block the bearer token draft from
> using the ‘OAuth2’ scheme name, and will raise this issue in the WGLC, Area
> Director review, IETF LC, and direct appeal to the IESG if necessary. You
> might consider this childish, but I consider  bearer tokens a disaster
> waiting to happen and will not allow the weakest form of token
> authentication to carry the strongest form of endorsement and perception
> (via the OAuth brand).

I do respect your opinion Eran, but is there consensus around this? If
anything, the consensus seems to be around bearer tokens. As far as I
can tell this is the big selling point of OAuth 2 and all
implementations I am aware of will support it. For all intents and
purposes OAuth 2 is bearer tokens.

> At the end, you might get the scheme name you want, but it will cost you
> significant delays in getting that document published as an RFC and with a
> Proposed Standard designation. So far you have failed to raise any technical
> justification for your insistence of using that name. The only reason so far
> is that it will be less confusing. Perhaps. But will be more damaging.

Such delays would be unfortunate, I truly hope we can sort this out.

> After
> all, why would anyone look at the MAC token specification or other stronger
> authentication schemes, when you offer them the “official” OAuth 2.0 scheme.

That's a good point. What about using a common prefix for all OAuth 2
related scheme names? Something like "OAuth2Bearer", "OAuth2Mac".

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 30 Jan 2011 16:08:20 -0700

Hey Marius,

> -----Original Message-----
> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Sunday, January 30, 2011 2:45 PM
> To: Eran Hammer-Lahav
> Cc: Mike Jones; OAuth WG
> Subject: Re: [OAUTH-WG] Update required for bearer token spec
> 
> > As for the open issues: the bearer token scheme name - if it wasn't
> > clear, I plan to use every mean available to me to block the bearer
> > token draft from using the 'OAuth2' scheme name, and will raise this
> > issue in the WGLC, Area Director review, IETF LC, and direct appeal to
> > the IESG if necessary. You might consider this childish, but I
> > consider  bearer tokens a disaster waiting to happen and will not
> > allow the weakest form of token authentication to carry the strongest
> > form of endorsement and perception (via the OAuth brand).
> 
> anything, the consensus seems to be around bearer tokens. As far as I can
> tell this is the big selling point of OAuth 2 and all implementations I am aware
> of will support it.

There is no consensus around names.

My project does not support bearer token so at least one Yahoo! product API is going to ban bearer tokens. We have published an open source client and server MAC token implementation in JS and node.js. I do not speak on behalf of the rest of the company, and given past opinion, expect them to support bearer tokens.

> For all intents and purposes OAuth 2 is bearer tokens.

And this is the issue! It is exactly why I am being so forceful against this perception and why I refuse to allow the bearer token to be named the OAuth2 token type. This will have the exact effect you have stated. Where I disagree with you is that this is a foregone conclusion.

I am committed to the message that bearer tokens are a feature of OAuth 2.0, and when implemented correctly can provide a security level adequate for any current web services. I am opposed to any perception of bearer tokens as the default type, implying that people should always start with bearer token and "upgrade" to something stronger only when needed.

> > At the end, you might get the scheme name you want, but it will cost
> > you significant delays in getting that document published as an RFC
> > and with a Proposed Standard designation. So far you have failed to
> > raise any technical justification for your insistence of using that
> > name. The only reason so far is that it will be less confusing. Perhaps. But
> will be more damaging.
> 

I will follow up with a proposal later today and will get a discussion going.
 
> > After
> > all, why would anyone look at the MAC token specification or other
> > stronger authentication schemes, when you offer them the "official"
> OAuth 2.0 scheme.
> 

I don't see value in limiting MAC to OAuth. It is a generally useful scheme, especially for "2-legged" authentication as used with 1.0.

I'll cover these suggestions in my new discussion thread.

Thanks for the feedback.

EHL