- From: Dave Cridland <dave@cridland.net>
- Date: Mon, 13 Dec 2010 15:16:12 +0000
- To: Carsten Bormann <cabo@tzi.org>, Common Authentication Technologies - Next Generation <kitten@ietf.org>, websec <websec@ietf.org>, "saag@ietf.org" <saag@ietf.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, General discussion of application-layer protocols <apps-discuss@ietf.org>, "http-auth@ietf.org" <http-auth@ietf.org>
On Mon Dec 13 12:14:03 2010, Carsten Bormann wrote: > Maybe the only way to address both requirements is to have > something in HTML/CSS/JS that addresses authentication interactions. > Replacing <input type="password"/> for the 21st century. This > would allow web app designers to design a nice context for this > interaction, and would allow running security protocols that are > binding themselves to a browser-server security association that > may be identical to or different from the TLS envelope. "Storing > passwords" in the browser might turn into storing those security > associations. > > Or storing credentials rather than username/password pairs, possibly. But in any case, I think that's close to what we want. As I say, I think we need to establish a session credential of some kind that can be used over unencrypted sessions with some improvement in security over typical fixed cookies that exist today. I'm fine if one of these credential options happens to tie into a TLS property, but I think we'll have to have reasonable security over non-TLS, too. (And by "reasonable", I'm expecting this to be "not as good as if you had TLS") And I absolutely agree that this effort needs strong support from the browser implementors from the start - we also need the same from a few major webapps. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Received on Monday, 13 December 2010 15:16:51 UTC