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

Marius Scurtescu <> Sun, 30 January 2011 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E7693A6B43 for <>; Sun, 30 Jan 2011 14:42:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.958
X-Spam-Status: No, score=-103.958 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pO+y+MDF9cw5 for <>; Sun, 30 Jan 2011 14:42:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2E8623A6B41 for <>; Sun, 30 Jan 2011 14:42:18 -0800 (PST)
Received: from ( []) by with ESMTP id p0UMjUiC012316 for <>; Sun, 30 Jan 2011 14:45:30 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=beta; t=1296427530; bh=h/ffY83oOF6qFOJWWwNJoceqm2c=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ud3trhVix8FJ7rAEDUD7qGtPXCW+pDEB/Pq3v7a4Vyh1m/jrNawy3O3W6RT7QfRpA IIwUCYr73LPkI99MVMxjg==
Received: from gxk4 ( []) by with ESMTP id p0UMjSut003269 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <>; Sun, 30 Jan 2011 14:45:29 -0800
Received: by gxk4 with SMTP id 4so1944520gxk.35 for <>; Sun, 30 Jan 2011 14:45:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=xFfRy2aAjQjITy409frKgg1E8nXf9gmYT7l81AUBgag=; b=wLjVEahChxtXyRQGdsp5IpSBhzU3bUOi7tk0wO8vPjutqotIjQv4s7hvCQBgY0dgjo rueb+wcDTQGHIUmtgQBg==
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=XitT639Lwvep6rYVxOMd+TBzxIGhmYQA7Nzif2aKj+YeUy5gkEBefhbtdUG6I1z5dR 4Dcxr8phCZDUQQuPfoXQ==
Received: by with SMTP id y2mr3470517ank.78.1296427527951; Sun, 30 Jan 2011 14:45:27 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 30 Jan 2011 14:45:07 -0800 (PST)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB281B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2785@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E723445A8FB281B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Marius Scurtescu <>
Date: Sun, 30 Jan 2011 14:45:07 -0800
Message-ID: <>
To: Eran Hammer-Lahav <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
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 22:42:19 -0000

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. 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".