Re: [OAUTH-WG] Call for Consensus on Document Split

"Manger, James H" <> Thu, 14 October 2010 23:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76B213A69E3 for <>; Thu, 14 Oct 2010 16:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.467
X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id STBH0fZZuzEJ for <>; Thu, 14 Oct 2010 16:18:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 458883A69D7 for <>; Thu, 14 Oct 2010 16:18:20 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.57,333,1283695200"; d="scan'208";a="14307287"
Received: from unknown (HELO ([]) by with ESMTP; 15 Oct 2010 10:19:39 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6136"; a="10816957"
Received: from ([]) by with ESMTP; 15 Oct 2010 10:19:39 +1100
Received: from ([]) by ([]) with mapi; Fri, 15 Oct 2010 10:19:38 +1100
From: "Manger, James H" <>
To: Blaine Cook <>, "" <>
Date: Fri, 15 Oct 2010 10:19:36 +1100
Thread-Topic: [OAUTH-WG] Call for Consensus on Document Split
Thread-Index: ActrN3SADdtlmDJIRsyK9ERucPk/wgAuEXqQ
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Call for Consensus on Document Split
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: Thu, 14 Oct 2010 23:18:22 -0000


I am in favour of splitting the specification, but the right dividing line is not the whole of section 5 "Accessing a Protected Resource".

The core OAuth spec needs to keep a section defining a WWW-Authenticate response header with which to tell a client that the OAuth "get a token" flows can be used to get access to a resource. This is a bit like section 5.2 "The WWW-Authenticate Response Header Field".

Error codes [section 5.2] like "expired_token" or "insufficient_scope" only make sense in a spec that defines the flows to renew a token or change its scope. I assume that will be the core OAuth spec, not the bearer token spec. For comparison, the HTTP BASIC spec does not tell you how to change your password or register for a password.

My suggestion for the editorial split:
* Remove 5, 5.1, 5.1.1, 5.1.2, and 5.1.3.
* Keep 5.2, and 5.2.1.

James Manger

-----Original Message-----
From: [] On Behalf Of Blaine Cook
Sent: Thursday, 14 October 2010 11:32 AM
Subject: [OAUTH-WG] Call for Consensus on Document Split

Over the past few weeks, the working group debated the issues around
the introduction of signatures and the structure of the specification.
The working group seems to endorse the proposal to split the current
specification into two parts: one including section 5 (bearer token)
and the other including the rest (how to obtain a token), with an
additional specification covering signature use cases.

This serves as a call for consensus on the proposed editorial work.
Before we proceed with the changes, the chairs would like to ask if
anyone has any concerns or objections against this proposal.

In addition, the chairs are seeking a volunteer to take over the
bearer token specification (section 5) as editor.

Please submit your comments by Wednesday, October 20th.

- The OAuth Working Group Chairs
OAuth mailing list