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

Amos Jeffries <squid3@treenet.co.nz> Mon, 25 July 2011 23:16 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 060FB21F8AB8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Jul 2011 16:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.539
X-Spam-Level:
X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 KotiAi0HPwKR for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Jul 2011 16:16:07 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 036DF21F8A96 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 25 Jul 2011 16:16:06 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1QlUMU-0000gT-IP for ietf-http-wg-dist@listhub.w3.org; Mon, 25 Jul 2011 23:14:58 +0000
Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <squid3@treenet.co.nz>) id 1QlUMG-0000fV-Rh for ietf-http-wg@listhub.w3.org; Mon, 25 Jul 2011 23:14:45 +0000
Received: from [2002:3a1c:99e9:0:206:5bff:fe7c:b8a] (helo=treenet.co.nz) by aji.keio.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1QlUMD-0002CJ-3v for ietf-http-wg@w3.org; Mon, 25 Jul 2011 23:14:43 +0000
Received: by treenet.co.nz (Postfix, from userid 33) id A400DE6E61; Tue, 26 Jul 2011 11:14:06 +1200 (NZST)
To: ietf-http-wg@w3.org
X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Tue, 26 Jul 2011 11:14:06 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
In-Reply-To: <4E2DE5FF.7060801@gmx.de>
References: <798C1D1A-C0C7-40DD-8993-31DB735A4961@mnot.net> <255B9BB34FB7D647A506DC292726F6E112892DE4A4@WSMSG3153V.srv.dir.telstra.com> <4E2DE5FF.7060801@gmx.de>
Message-ID: <4f3f267f8f426a1f9e186dcf04604955@treenet.co.nz>
X-Sender: squid3@treenet.co.nz
User-Agent: Roundcube Webmail/0.5.1
Received-SPF: permerror client-ip=2002:3a1c:99e9:0:206:5bff:fe7c:b8a; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-1.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RDNS_NONE=0.793
X-W3C-Scan-Sig: aji.keio.w3.org 1QlUMD-0002CJ-3v 393ffadf04bfd5cac77d6593528ed525
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/4f3f267f8f426a1f9e186dcf04604955@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/11083
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: <E1QlUMU-0000gT-IP@frink.w3.org>
Resent-Date: Mon, 25 Jul 2011 23:14:58 +0000

 On Mon, 25 Jul 2011 23:54:07 +0200, Julian Reschke wrote:
> 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

 Was about to suggest exactly that. Sound great.

 AYJ