W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

Re: [saag] [websec] [kitten] HTTP authentication: the next generation

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Sat, 8 Jan 2011 11:21:42 -0500
Message-ID: <AANLkTimL=VdmhWdk3Yi-P5gdiHOOd_JpcgFX_uvBo2=E@mail.gmail.com>
To: Ben Laurie <benl@google.com>
Cc: David Morris <dwm@xpasc.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, websec <websec@ietf.org>, "kitten@ietf.org" <kitten@ietf.org>, "http-auth@ietf.org" <http-auth@ietf.org>, "saag@ietf.org" <saag@ietf.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie <benl@google.com> wrote:

> On 6 January 2011 16:03, David Morris <dwm@xpasc.com> wrote:
> >
> >
> > On Thu, 6 Jan 2011, Ben Laurie wrote:
> >
> >> The answer to this problem is hard, since it brings us back to taking
> the UI
> >> out of the sites hands.
> >
> > Which is only helpful if you can somehow gaurantee that the user agent
> > software hasn't been compromised. Not something I'd bet on...
> That's rather overstating it. It's perfectly helpful when the UA
> software hasn't been compromised, which is a non-zero fraction of the
> time.
> When the UA s/w has been compromised I'm quite happy to fail to fix
> the problem: the right answer to that is to improve the robustness of
> the UA.


If the UA is stuffed then the user is totally and utterly stuffed anyway.

In particular if the UA is stuffed then a forms based experience is just as
stuffed. If we are going to hypothecate attack models people have to be
willing to apply them to their preferred solution too.

The sensible approach is to work out how to stop the user from being stuffed

 * Comodo's free Anti-Virus with Default Deny Protection (TM)
 * Use code signing + trustworthy computing
 * Use a restricted browser

Now I have a lot of ideas on how we can tackle these, but they are not
relevant to this debate.

I do however have a different take on the UI issue.

HTML forms did have an advantage over the pathetic UI that browsers provided
for BASIC and DIGEST (most don't even tell the user which is in use).

But a federated auth scheme supported at the HTTP level could be simpler
still. Instead of the user having to register for each site, they register
once. Instead of the user having to log in to each site they log in once per
session. Instead of the site having to manage lost passwords and forgotten
accounts because the user has hundreds, this problem does not exist.

It is a user interface crisis that is driving this need in my view.

Website: http://hallambaker.com/
Received on Saturday, 8 January 2011 16:22:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:56 UTC