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

Amos Jeffries <squid3@treenet.co.nz> Tue, 26 July 2011 01:45 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 1E27D11E80DF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Jul 2011 18:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.556
X-Spam-Level:
X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 cZ5DLW2nr7vQ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Jul 2011 18:45:57 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2D611E80D7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 25 Jul 2011 18:45:51 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1QlWiB-0001gi-As for ietf-http-wg-dist@listhub.w3.org; Tue, 26 Jul 2011 01:45:31 +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 1QlWhu-0000rw-6L for ietf-http-wg@listhub.w3.org; Tue, 26 Jul 2011 01:45:14 +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 1QlWhq-0006WW-M3 for ietf-http-wg@w3.org; Tue, 26 Jul 2011 01:45:13 +0000
Received: by treenet.co.nz (Postfix, from userid 33) id 08355E7062; Tue, 26 Jul 2011 13:44:37 +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 13:44:37 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
In-Reply-To: <r92s27l82b2b7mt8ta9te03vrg0rjslpa5@hive.bjoern.hoehrmann.de>
References: <798C1D1A-C0C7-40DD-8993-31DB735A4961@mnot.net> <255B9BB34FB7D647A506DC292726F6E112892DE4A4@WSMSG3153V.srv.dir.telstra.com> <4E2DE5FF.7060801@gmx.de> <r92s27l82b2b7mt8ta9te03vrg0rjslpa5@hive.bjoern.hoehrmann.de>
Message-ID: <22faf62a2106a83f792022e60bb70e9e@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 1QlWhq-0006WW-M3 fb3918345381fae5d2c6911833bd2111
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/22faf62a2106a83f792022e60bb70e9e@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/11088
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: <E1QlWiB-0001gi-As@frink.w3.org>
Resent-Date: Tue, 26 Jul 2011 01:45:31 +0000

 On Tue, 26 Jul 2011 02:38:37 +0200, Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>>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.
>
> This should refer to disclosure or something like that rather than 
> leak-
> age (you wouldn't design a protocol that intentionally leaks 
> something),
> and `Vary: *` strikes me as odd in this context (why, then, doesn't 
> the
> use of Authorization imply just `Vary: Authorization`, for instance).

 I've been thinking along these lines recently too. It seems 
 Authorization, ETag, and maybe others should be implicit Vary: headers. 
 But that text seems to belong better in the definition of Vary: and 
 seems rather out of place in areas like auth.
  For instance, non-caching agents do not need to bother with Vary:, but 
 may want to do authentication. So there should be no need to make them 
 care about Vary: by mentioning a dependence on its syntax by 
 Authoritzation:.

 AYJ

>
> I would rather say something along the lines that use of 
> "Authorization"
> implies that the message is confidential with respect to the 
> credentials
> provided in that header, meaning messages should be treated as if 
> they
> had `Cache-Control: private`, and that new schemes must take explicit
> measures to ensure the confidentiality of messages, like using that 
> same
> header, because deployed servers are otherwise unaware of the 
> semantics.