[OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14

"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Thu, 24 November 2011 07:51 UTC

Return-Path: <hannes.tschofenig@nsn.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E86D321F8AF2 for <oauth@ietfa.amsl.com>; Wed, 23 Nov 2011 23:51:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.667
X-Spam-Status: No, score=-106.667 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eone35V3QBR2 for <oauth@ietfa.amsl.com>; Wed, 23 Nov 2011 23:51:23 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net []) by ietfa.amsl.com (Postfix) with ESMTP id B8B0221F86F6 for <oauth@ietf.org>; Wed, 23 Nov 2011 23:51:22 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([]) by demumfd001.nsn-inter.net ( with ESMTP id pAO7pL44014143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <oauth@ietf.org>; Thu, 24 Nov 2011 08:51:21 +0100
Received: from DEMUEXC047.nsn-intra.net ([]) by demuprx017.emea.nsn-intra.net ( with ESMTP id pAO7pIbD023865 for <oauth@ietf.org>; Thu, 24 Nov 2011 08:51:21 +0100
Received: from FIESEXC035.nsn-intra.net ([]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Nov 2011 08:51:06 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 24 Nov 2011 09:51:04 +0200
Message-ID: <999913AB42CC9341B05A99BBF358718DCD2102@FIESEXC035.nsn-intra.net>
Thread-Topic: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14
Thread-Index: AcyqcV5Qq4gANlE2TFCb1dZBk8wPbwADGEFg
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: oauth@ietf.org
X-OriginalArrivalTime: 24 Nov 2011 07:51:06.0034 (UTC) FILETIME=[D2278120:01CCAA7D]
Subject: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 24 Nov 2011 07:51:24 -0000


-----Original Message-----
From: apps-discuss-bounces@ietf.org
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of ext Mark Nottingham
Sent: Thursday, November 24, 2011 8:22 AM
To: IETF Apps Discuss; draft-ietf-oauth-v2-bearer.all@ietf.org
Cc: The IESG
Subject: [apps-discuss] APPS Area review of

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-oauth-v2-bearer-14
Title: OAuth 2.0 Bearer Tokens
Reviewer: Mark Nottingham
Review Date: 24/11/2011

Summary: This draft is almost ready for publication as a Proposed
Standard, but has a few issues that should be fixed.

Major Issues

* Section 2.3 URI Query Parameter

This section effectively reserves a URI query parameter for the draft's
use. This should not be done lightly, since this would be a precedent
for the IETF encroaching upon a server's URIs (done previously in
RFC5785, but in a much more limited fashion, as a tactic to prevent
further, uncontrolled encroachment).

Given that the draft already discourages the use of this mechanism, I'd
recommend dropping it altogether. If the Working Group wishes it to
remain, this issues should be vetted both through the APPS area and the
W3C liaison.

(The same criticism could be leveled at Section 2.2 Form-Encoded Body
Parameter, but that at least isn't surfaced in an identifier)

* Section 3 The WWW-Authenticate Response Header Field

The draft references the quoted-string ABNF from HTTP, but changes its
processing in a later paragraph:

"""In all these cases, no character quoting will occur, as senders are
prohibited from using the %5C ('\') character."""

This is at best surprising (as many readers will reasonably surmise that
using the quoted-string ABNF implies that the same code can be used).
Please either use quoted-string as defined (i.e., with escaping).

Minor Issues

* Section 1: Introduction

The introduction explains oauth, but it doesn't fully explain the
relationship of this specification to OAuth 2.0. E.g., can it be used
independently from the rest of OAuth? Likewise, the overview (section
1.3) seems more specific to the OAuth specification than this document.
As I read it, this mechanism could be used for ANY bearer token, not
just one generated through OAuth flows. 

If it is indeed more general, I'd recommend minimising the discussion of
OAuth, perhaps even removing it from the document title.

* Section 3 The WWW-Authenticate Response Header Field

The difference between a realm and a scope is not explained. Are the
functionally equivalent, just a single value vs. a list? 

Do you really intend to disallow *all* extension parameters on the

Also, the scope, error, error_description and error_uri parameters all
specify only a quoted-string serialisation. HTTPbis strongly suggests
that new schemes allow both forms, because implementation experience has
shown that implementations will likely support both, no matter how
defined; this improves interoperability (see p7 2.3.1). 

Finally, the error_description parameter can carry only ASCII
characters. While I understand a tradeoff has been made here (and, in my
judgement, an appropriate one), it's appropriate to highlight this in

* General

The draft currently doesn't mention whether Bearer is suitable for use
as a proxy authentication scheme. I suspect it *may*; it would be worth
discussing this with some proxy implementers to gauge their interest
(e.g., Squid). 


* Section 2.1 Authorization Request Header Field

"simplicity reasons" --> "simplicity"

"If additional parameters are desired in the future, a different scheme
could be defined." --> "If additional parameters are needed in the
future, a different scheme would need to be defined."

* Section 3 The WWW-Authenticate Response Header Field

The requirement that a resource server MUST include the HTTP
WWW-Authenticate response header field is odd; really this is at the
discretion of the server. Is it really necessary to use a conformance
requirement here?

URI-reference --> URI-Reference

* Section 3.1 Error Codes

405 belongs in the list of typically appropriate status codes as well.

Kind regards,

Mark Nottingham   http://www.mnot.net/

apps-discuss mailing list