Re: #78: Relationship between 401, Authorization and WWW-Authenticate

Julian Reschke <julian.reschke@gmx.de> Mon, 25 July 2011 21:55 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA2F21F886E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Jul 2011 14:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAneZ41CqGTs for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Jul 2011 14:55:40 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1C40821F886D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 25 Jul 2011 14:55:40 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1QlT6z-0001DV-9b for ietf-http-wg-dist@listhub.w3.org; Mon, 25 Jul 2011 21:54:53 +0000
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <julian.reschke@gmx.de>) id 1QlT6m-0001C2-LF for ietf-http-wg@listhub.w3.org; Mon, 25 Jul 2011 21:54:40 +0000
Received: from mailout-de.gmx.net ([213.165.64.22]) by lisa.w3.org with smtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1QlT6k-0001lb-Uy for ietf-http-wg@w3.org; Mon, 25 Jul 2011 21:54:40 +0000
Received: (qmail invoked by alias); 25 Jul 2011 21:54:12 -0000
Received: from dhcp-14e3.meeting.ietf.org (EHLO [130.129.20.227]) [130.129.20.227] by mail.gmx.net (mp070) with SMTP; 25 Jul 2011 23:54:12 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19WVo4Ls7hW8jy9NmH6fFj0lm5tDGAXLLygpKfk8P TJNbil7NLT/gX6
Message-ID: <4E2DE5FF.7060801@gmx.de>
Date: Mon, 25 Jul 2011 23:54:07 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "Manger, James H" <James.H.Manger@team.telstra.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
References: <798C1D1A-C0C7-40DD-8993-31DB735A4961@mnot.net> <255B9BB34FB7D647A506DC292726F6E112892DE4A4@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112892DE4A4@WSMSG3153V.srv.dir.telstra.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=213.165.64.22; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1QlT6k-0001lb-Uy ffda7c26493e56e65411fdc6110cbc1d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #78: Relationship between 401, Authorization and WWW-Authenticate
Archived-At: <http://www.w3.org/mid/4E2DE5FF.7060801@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/11081
X-Loop: ietf-http-wg@w3.org
Sender: ietf-http-wg-request@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1QlT6z-0001DV-9b@frink.w3.org>
Resent-Date: Mon, 25 Jul 2011 21:54:53 +0000

On 2011-07-25 05:19, Manger, James H wrote:
> ...
>> 2) Clarify that an Authentication scheme that uses WWW-Authenticate and/or 401 MUST use the Authorization header in the request, because of its implications for caching. Schemes MAY specify additional headers to be used alongside it.
>
> Not so great.
>
> If an authentication mechanism uses the Authorization header then it benefits from some default caching rules. Good.
> Plenty of other authentication mechanisms don't use that header, primarily because they operate at higher or lower layers of the protocol stack (eg forms, cookies, TLS...). Even in these cases a WWW-Authenticate response header can be a useful signal about the authentication options available. They may need to handle caching explicitly, but they can do that.
>
> If anything needs to be said, perhaps something like the following could be appended to section 4.1 "Authorization":
>
>    A server may need to explicitly indicate the cachability of responses
>    if a request uses an authentication mechanism that does not involve
>    the Authorization header.
> ...

Good catch. I knew we were missing something.

Maybe...:

Use of the Authorization header to transfer credentials implies 
"Cache-Control: private" [ref] and thus affects cacheability of 
responses. Thus, definitions of new authentication schemes that do not 
use "Authorization" will need to ensure that response messages do not 
leak in an unintended way, for instance by specifying "Cache-Control" or 
"Vary: *" [ref] explicitly.

Feedback appreciated,

Julian