W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

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

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 26 Jul 2011 13:44:37 +1200
To: <ietf-http-wg@w3.org>
Message-ID: <22faf62a2106a83f792022e60bb70e9e@treenet.co.nz>
 On Tue, 26 Jul 2011 02:38:37 +0200, Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>>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 


> 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.
Received on Tuesday, 26 July 2011 01:45:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC