[OAUTH-WG] WWW-Authenticate Header (Bearer etc.)

Eran Hammer <eran@hueniverse.com> Wed, 25 January 2012 18:14 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C960E21F85C4 for <oauth@ietfa.amsl.com>; Wed, 25 Jan 2012 10:14:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.484
X-Spam-Level:
X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbZpI-+sXkWJ for <oauth@ietfa.amsl.com>; Wed, 25 Jan 2012 10:14:43 -0800 (PST)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 352F321F8597 for <oauth@ietf.org>; Wed, 25 Jan 2012 10:14:43 -0800 (PST)
Received: (qmail 29474 invoked from network); 25 Jan 2012 18:12:55 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jan 2012 18:12:55 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 25 Jan 2012 11:12:47 -0700
From: Eran Hammer <eran@hueniverse.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Date: Wed, 25 Jan 2012 11:12:46 -0700
Thread-Topic: WWW-Authenticate Header (Bearer etc.)
Thread-Index: AczbjPC+fOyJLtFtQXmA9XYmFqaU5w==
Message-ID: <CB45861E.FE53%eran@hueniverse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CB45861EFE53eranhueniversecom_"
MIME-Version: 1.0
Subject: [OAUTH-WG] WWW-Authenticate Header (Bearer etc.)
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: Wed, 25 Jan 2012 18:14:43 -0000

People seems confused about the issue raised by Julian. It is pretty simple.

The HTTP WWW-Authenticate header definition allows each header parameter to have a quoted string or token value. Token values are very restrictive and not suitable for scope (no spaces, etc.). Quoted strings allow a wider set of characters at the cost of requiring escaping for " and \.

The WG decided that in order to avoid escaping, we will restrict scope values to only those characters legal in quotes string without escaping. This change was made in –23.

The issue here is different.

The WWW-Authenticate header isn't OAuth-specific and it allows the server to declare more than one scheme. For example:

WWW-Authenticate: Bearer realm="xyz", Basic realm="123"

This is how HTTP works and this WG doesn't get to change it. The problem is that the bearer token specification is changing the *general* definition of the WWW-Authenticate header to only use quoted strings and not tokens. This is wrong.

It is true that a *generic* parser will be able to parse a bearer token header without any issues. But a parser written specifically for the bearer token use case will most likely fail when parsing the WWW-Authenticate header with other schemes.

OAuth must not define its own WWW-Authenticate handing logic. It should opt into the HTTP framework without any modifications. It is perfectly fine to restrict values and by doing so, we made servers simpler by not having to ever encode scopes but we cannot try to simplify client code by "profiling" HTTP.

My view has not changed and trying to portray it in this fashion shows ignorance of the issue. I supported restricting the character set of scopes. I am against changing the HTTP definition of WWW-Authenticate.

EHL