- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 26 Feb 2012 15:54:10 +0100
- To: Yoav Nir <ynir@checkpoint.com>
- CC: Mark Nottingham <mnot@mnot.net>, The IESG <iesg@ietf.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, IETF-Discussion Discussion <ietf@ietf.org>
On 2012-02-26 10:44, Yoav Nir wrote: > ... >> Could you please explain why you think tying this effort to HTTP/2.0 is necessary to achieve that? To me that's the critical bit, and I still haven't seen the reasoning (perhaps I missed it). > > I think I have *an* answer to this, though probably not *the* answer. > > There's two stages to adoption - implementation and roll-out. Obviously you can't roll out "new authentication" before the browsers and servers implement it. For my website, I wouldn't roll out new auth if only one or two of the browsers out there implemented it. Even if all the big ones (IE, Firefox, Chrome, Opera) did, I would still have to provide a backwards compatibility authentication scheme to support older browsers. This would lead to both inconsistent UI and to ugly javascript that detects the browser version, and makes the roll-out slower. You can send multiple challenges in one response. We could also define a way to make HTML-form-based login an HTTP scheme (see <http://tools.ietf.org/id/draft-broyer-http-cookie-auth-00.txt>) to integrate better what people use today. > If any HTTP/2.0 browser is bound to have "new authentication" it makes things much easier. > > This could be circumvented by adding request headers that advertise capabilities, but I don't think we like those much. I don't believe we need those. If we do, we should retrofit this into 1.1 as well. Anyway, I see lots of theoretical discussion about process. What's needed is people doing the actual work, both spec-wise and implementation-wise. That's the critical problem. Best regards, Julian
Received on Sunday, 26 February 2012 14:54:56 UTC