W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: The Hypertext Transfer Protocol (HTTP) Authentication-Info Header Field

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 28 Jan 2015 22:59:17 +1300
Message-ID: <54C8B2F5.4060506@treenet.co.nz>
To: ietf-http-wg@w3.org
On 28/01/2015 9:56 p.m., Julian Reschke wrote:
> Dear WG,
> 
> when we worked on RFC 7235, we extracted the authentication framework
> from RFC 2617, but failed to realize that the section about the DIGEST
> authentication scheme indeed added another pair of generic header
> fields: (Proxy-)Authentication-Info.
> 
> As a matter of fact, Alexey Melnikov noticed this in time, but back then
> we didn't have the time & energy to do the right thing.
> 
> Today, we have the DIGEST revision coming up in the HTTPAuth WG, and
> that still contains the header field definition
> (<https://trac.tools.ietf.org/html/draft-ietf-httpauth-digest-12#section-3.5>).
> Furthermore, Alexey's SCRAM draft uses it, but does not reference DIGEST
> (<https://trac.tools.ietf.org/html/draft-ietf-httpauth-scram-auth-04#section-5>,
> although with a minor syntax variation).
> 
> Last weekend I sat down and wrote a tiny draft (5 pages incl.
> boilerplate, ToC, references, whatnot) that makes these header field
> definitions standalone:
> 
> <http://greenbytes.de/tech/webdav/draft-reschke-httpauth-auth-info-00.html>
> (*)
> 
> ...with the purpose of
> 
> - allowing DIGEST refer to it instead of in-lining the definition,
> 
> - allowing Alexey to use it, and most importantly
> 
> - having a clear path for RFC 7235bis.
> 
> The last point makes it a candidate for this working group; to be useful
> for the work over in HTTPAuth we'd need to be quick, though; optimally
> IETF LC before the Dallas meeting; given the size of the draft this
> should be possible...
> 
> What do others think?
> 

I think its a good idea.


It is also worth noting at this point that those headers are already in
use in the wild (by Squid at least) for Negotiate scheme in a way that
does not match the ABNF. Instead they just echo back from the server the
accepted "Negotiate <token>" credentials received from the client.

I am not sure exactly why Squid does this, I've queried our dev team to
see if anyone knows.

Amos
Received on Wednesday, 28 January 2015 10:00:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:42 UTC