- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 25 Feb 2012 00:42:19 +1300
- 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 hop. 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. AYJ
Received on Friday, 24 February 2012 11:43:01 UTC