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

Eran Hammer-Lahav <> Sun, 30 January 2011 23:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C59E3A6B3A for <>; Sun, 30 Jan 2011 15:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.575
X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yVkWn9LjGJYy for <>; Sun, 30 Jan 2011 15:05:21 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 050E53A6B33 for <>; Sun, 30 Jan 2011 15:05:20 -0800 (PST)
Received: (qmail 18955 invoked from network); 30 Jan 2011 23:08:33 -0000
Received: from unknown (HELO ( by with SMTP; 30 Jan 2011 23:08:33 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([]) with mapi; Sun, 30 Jan 2011 16:08:22 -0700
From: Eran Hammer-Lahav <>
To: Marius Scurtescu <>
Date: Sun, 30 Jan 2011 16:08:20 -0700
Thread-Topic: [OAUTH-WG] Update required for bearer token spec
Thread-Index: AcvAz2a1dsWgo23tSPSYXICbTd6dxAAAdKQg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2B15@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2785@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E723445A8FB281B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG <>
Subject: Re: [OAUTH-WG] Update required for bearer token spec
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 30 Jan 2011 23:05:22 -0000

Hey Marius,

> -----Original Message-----
> From: Marius Scurtescu []
> 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
> On Thu, Jan 27, 2011 at 6:23 PM, Eran Hammer-Lahav
> <> 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.

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.
> Such delays would be unfortunate, I truly hope we can sort this out.

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.
> That's a good point. What about using a common prefix for all OAuth 2
> related scheme names? Something like "OAuth2Bearer", "OAuth2Mac".

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.