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

Bjoern Hoehrmann <derhoermi@gmx.net> Tue, 26 July 2011 00:39 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 71950228011 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Jul 2011 17:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.59
X-Spam-Level:
X-Spam-Status: No, score=-7.59 tagged_above=-999 required=5 tests=[AWL=3.009, 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 pVBbjSbIJBbA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Jul 2011 17:39:57 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id AFDE622800F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 25 Jul 2011 17:39:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1QlVgG-0002ql-31 for ietf-http-wg-dist@listhub.w3.org; Tue, 26 Jul 2011 00:39:28 +0000
Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <derhoermi@gmx.net>) id 1QlVg2-0002p2-Ug for ietf-http-wg@listhub.w3.org; Tue, 26 Jul 2011 00:39:15 +0000
Received: from mailout-de.gmx.net ([213.165.64.23]) by aji.keio.w3.org with smtp (Exim 4.72) (envelope-from <derhoermi@gmx.net>) id 1QlVfx-0004QB-GK for ietf-http-wg@w3.org; Tue, 26 Jul 2011 00:39:14 +0000
Received: (qmail invoked by alias); 26 Jul 2011 00:38:35 -0000
Received: from dslb-094-223-187-169.pools.arcor-ip.net (EHLO HIVE) [94.223.187.169] by mail.gmx.net (mp043) with SMTP; 26 Jul 2011 02:38:35 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+oAvl+JhqoXo8xU4UPpoIoe9DZvV9ikpbJd2cQ/k lHeFoJ0aU8zGm+
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Date: Tue, 26 Jul 2011 02:38:37 +0200
Message-ID: <r92s27l82b2b7mt8ta9te03vrg0rjslpa5@hive.bjoern.hoehrmann.de>
References: <798C1D1A-C0C7-40DD-8993-31DB735A4961@mnot.net> <255B9BB34FB7D647A506DC292726F6E112892DE4A4@WSMSG3153V.srv.dir.telstra.com> <4E2DE5FF.7060801@gmx.de>
In-Reply-To: <4E2DE5FF.7060801@gmx.de>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=213.165.64.23; envelope-from=derhoermi@gmx.net; helo=mailout-de.gmx.net
X-W3C-Hub-Spam-Status: No, score=-3.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.191, SPF_PASS=-0.001
X-W3C-Scan-Sig: aji.keio.w3.org 1QlVfx-0004QB-GK 748408f971c7915e426508972d4185a9
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/r92s27l82b2b7mt8ta9te03vrg0rjslpa5@hive.bjoern.hoehrmann.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/11086
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: <E1QlVgG-0002ql-31@frink.w3.org>
Resent-Date: Tue, 26 Jul 2011 00:39:28 +0000

* 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 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.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/