W3C home > Mailing lists > Public > public-identity@w3.org > June 2011

Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF

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
Message-Id: <E1QXUZh-0007S2-RN@login01.fos.auckland.ac.nz>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 17 June 2011 08:39:39 GMT