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

Eran Hammer-Lahav <eran@hueniverse.com> Fri, 28 January 2011 21:52 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7010A3A6960 for <oauth@core3.amsl.com>; Fri, 28 Jan 2011 13:52:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level:
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0khAWzmJskG for <oauth@core3.amsl.com>; Fri, 28 Jan 2011 13:52:11 -0800 (PST)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C25873A6975 for <oauth@ietf.org>; Fri, 28 Jan 2011 13:52:10 -0800 (PST)
Received: (qmail 9448 invoked from network); 28 Jan 2011 21:55:17 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Jan 2011 21:55:17 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 28 Jan 2011 14:55:14 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Date: Fri, 28 Jan 2011 14:55:09 -0700
Thread-Topic: Update required for bearer token spec
Thread-Index: Acu/Ngr27SB15OSEROGX4k45HjPihw==
Message-ID: <236CB996-6D46-4590-B308-F4C045F23C84@hueniverse.com>
References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2785@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FB43B@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FBB0C@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB281B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FD332@TK5EX14MBXC202.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246FD332@TK5EX14MBXC202.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_236CB9966D464590B308F4C045F23C84hueniversecom_"
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Update required for bearer token spec
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2011 21:52:13 -0000

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" <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:

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:eran@hueniverse.com]
Sent: Thursday, January 27, 2011 6:24 PM
To: Mike Jones
Cc: OAuth WG; 'Manger, James H (James.H.Manger@team.telstra.com<mailto:James.H.Manger@team.telstra.com>)'
Subject: RE: Update required for bearer token spec

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:Michael.Jones@microsoft.com]
Sent: Thursday, January 27, 2011 5:15 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: RE: Update required for bearer token spec

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:eran@hueniverse.com]
Sent: Thursday, January 27, 2011 2:36 PM
To: Mike Jones
Cc: OAuth WG
Subject: RE: Update required for bearer token spec

-12 section 8.1 and 10.1.

EHL

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

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

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

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

EHL