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

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Sat, 25 Feb 2012 00:42:19 +1300
Message-ID: <4F47779B.5030004@treenet.co.nz>
To: ietf-http-wg@w3.org
On 24/02/2012 8:25 p.m., Willy Tarreau wrote:
> On Thu, Feb 23, 2012 at 05:23:45PM -0800, Paul Hoffman wrote:
>> If only it were that simple. If the answer is "design an HTTP auth mechanism
>> that is better than Digest", then this is a tractable goal. If it is "get
>> IETF consensus on that auth mechanism", then it isn't. The latter has proven
>> to be impossible because people say (possibly rightly) that web developers
>> don't want auth mechanisms that use the browser chrome: they want auth in
>> HTML, and anything that relies on the browser chrome is insufficient.
> Maybe but you still need HTTP-based auth for proxies anyway. Also, I
> partially disagree with your point, seeing the number of applications
> in enterprise which rely on the hated NTLM auth which is also HTTP-based ;
> they're using it because it's transparent to the user, and enterprise
> customers do ask for such transparent auth schemes.
> There would also be much less need for cookies if auth was carried by the
> browser, and this would let the user log off. So I think there's a need
> for this.

Keeping the focus for charter firmly on the transport area and away from 
the "web"/resource/content area allows us to split the two auth models 
HTTP currently supports (www-auth and proxy-auth) along those same lines.

www-auth is end-to-end and only in that single-hop scenario can it be 
considered close to a transport authentication. For all other hop counts 
it is an effective *message* authentication, with no bearing on the 
transport. The proxy-auth layer is the only one which remains strictly 
transport-related, since it explicitly stops and re-starts at every HTTP 

So IMHO, we can (indeed must) acknowledge that HTTP transport uses a 
relay hop model. Charter security as a per-hop thing in HTTP. Any 
proposals can define something to adapt/extend/replace/erase proxy-auth 
into a real transport-auth. Specific to the two communicating hops. With 
the same semantics and viability whether they be client-proxy or 
client-server hops.
  Bonus: per-hop allows us to ignore 2.0->1.x->2.0 compatibility. This 
auth requirement only applies on 2.0->2.0+ hops.

www-auth can be left as the message-oriented authentication it is today 
for the "web auth" stuff. Either pushed off to somebody else (again) or 
to ourselves some years in the future when messaging semantics are up 
for change.

Looking a little forward to potential proposals. We have TLS, Kerberos, 
PGP, maybe OAuth and others all available right now (meeting that "over 
current infrastructure" charter requirement) as schemes to define 
proposals around. Being a "new" transport-authentication mechanism all 
we have to do is ensure that implementation is reasonably easy and any 
management tools to generate tokens or whatever are readily/easily 
available to even clueless junior admin.

Received on Friday, 24 February 2012 11:43:01 UTC

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