- From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
- Date: Fri, 17 Jun 2011 20:38:45 +1200
- To: nico@cryptonector.com, pgut001@cs.auckland.ac.nz
- Cc: hallam@gmail.com, http-auth@ietf.org, julian.reschke@gmx.de, public-identity@w3.org, saag@ietf.org, websec@ietf.org
Nico Williams <nico@cryptonector.com> writes: >Some aspects of the designs are important. Definitely. Before we launch into the inevitable bikeshedding, I think we should set out what it is we're documenting/specifying (since this is copied across several lists, it's a bit hard to see what the target/goal is). Is it a new crypto mutual-auth mechanism? A recommendation to use crypto mutual auth? Is it for browsers/HTTP, or general use? Is it a MUST for a protocol, or a BCP, or an informational RFC? If we're going to go into UI issues then it's probably going to be an informational RFC, which won't have much effect on browser behaviour, while if it's a crytpto mutual-auth protocol for HTTP that'll become a MUST (I hope so!) then we're not really going to be able to lay out requirements for UI design. >Shall we have just one authentication mechanism? *If* the idea is to specify a new auth mechanism and *if* it's for browsers and similar devices, I'd just say "Use EAP with X", it's been studied and spec'd to death, there's lots of implementations, it's pretty simple to do, etc. >at the application layer and in a RESTful way: I would really, *really* prefer to not invent another auth mechanism. There'd have to be a pretty strong argument to not use what we've already got. I happen to like EAP because it's simple, already spec'd out for lots of things (including cellphones via SIMs and other non-browser devices), and you can just say "use this", as long as "this" is profiled a bit to be something more specific than "any EAP mechanism you feel like". Peter.
Received on Friday, 17 June 2011 08:39:38 UTC