On 26/02/2012, at 12:32 PM, Stephen Farrell 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). > > That's a fair question that doesn't have a good and quick > answer, and some of the argument applies to the httpbis wg > and not to HTTP/2.0 per se. Aha. If we can decouple the auth work from the HTTP/2.0 deliverable, I'm less concerned -- although we're going to be quite busy. For *this* re-charter, can we only solicit proposals for auth, and make the decision about what/if we'll go ahead in the *next* re-charter? I.e., I'd like to wait before we decide on both pieces (the wire protocol and auth) before making commitments, or even plans. Part of the selection process for the wire protocol is determining implementer interest, and gathering the same information about the auth proposals will shed a lot more light on this conversation, I think. > Caveats: this is probably something that needs more bandwidth > than mail; most of the points below were already raised by > others on this thread (though I didn't go back through all > the mail yet) and this is not in any particular ordering. That's OK - we'll be in Paris soon. > - We've not really improved this in over a decade. Its time. Don't disagree. > - The community's appreciation of better security has > changed in that time as well so maybe its more tractable > now and we've more experience of real attacks. > - Improving security after the fact is not a good plan. Of course. > - Thinking a separate security WG could provide an answer > that'd be adopted seems less likely to work to some. (It > does seem more likely to work for some others admittedly.) Yes, there are arguments on both sides. > - A backwards-incompatible change (if needed) could be > done much more easily when changing HTTP. Its at least > time to explore the area with that possibility in mind.. Hmm. One of the core ideas we're moving forward with is that 2.0 is semantically compatible with 1.x, even if it isn't syntactically. > - A scheme less susceptible to phishing that got deployed > could be very valuable. Its not ridiculous to think that > might require breaking backwards compatibility somehow. Agreed, but I think that's much more about the browser UI than about the wire protocol. > So, a bunch of things. Maybe none individually compelling. > But arguably taken together sufficiently convincing that > not attempting again to do something here would really be > inexcusable. > > And yes, I do recognise that attempting to solve this does > add some risk. Most good things do. Absolutely. Cheers, -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf