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

[Phillip Hallam-Baker <[e-mail]>]

I have a different proposal. Lets take the high value authentication use
cases out of the browser completely.

Back in 1993 when Digest was designed, a Web browser could be written in
about ten thousand lines of code. Today a modern browser has a code
footprint that is larger than the memory plus pagefile of machine I used to
work on at CERN.

The modern browser is contaminated with plugins and active code. The worst
disservice that Netscape did to the Web was when they added Javascript to
Navigator unilaterally. Once a program conflates code and data it is never
going to be possible to make it secure.


The alternative would be to have a mini-browser whose sole purpose was to be
used to confirm high value transactions. This could be on the same machine
as the browser or a totally different machine such as a mobile phone.

If we start small with an application whose sole purpose is security we have
a good chance of getting some secure implementations.

This type of approach is not going to be acceptable for every possible
application or for every user. But the same is true of smart-cards, tokens
and the like.


So imagine that we had such a capability (I have a draft, I am just working
on getting preliminary feedback), what would we want HTTP authentication to
look like?

At that point what I would want most from the browser is to be able to
authenticate the browser and the machine it is running on in a manner that
is secure and robust. Cookies try to do this but again the implementation
was shoddy.

Where I think this conversation tends to go off the rails is when people get
the idea that the problem is the lack of an authentication protocol or an
authentication framework API. We have both of them, we have cartloads of
both of them.

The other point where I think the conversation went into a dead end was five
years ago when people started to sniff out the possibility of a something
that turned out to be Facebook. All those people who were wittering on about
'Identity' were not trying to solve the problem of how users authenticate or
manage attributes they were trying to solve the problem of how they could
win the spot in the industry that Facebook now occupies.


The missing like here in my view is the account identifier and the mechanism
by which it is mapped to a service.

The market has already decided that the federated account identifier for
Internet login will look like an email address. So Alice is going to be
something like [e-mail].


The problem with the current authentication infrastructure is that Alice now
has hundreds of accounts under that account name being maintained all over
the Web and example.com really has no control over how they are used.

One side effect of that lack of control is the type of idiocy I encountered
trying to report a bug in Visual Studio yesterday. First I had to register
to create a Windows Live ID. Which was irritating since I already have
registered several products with Microsoft. But never mind. So I register
for that and then I am told that I have to register my Windows Live account
again and verify my email a second time. Plus give all the same personal
details again.

Now the reason that Microsoft ended up in that situation is quite easy to
see. They have a bunch of divisions run as silos and one does not exchange
information with another. But they do have management degrees coming down
from the top telling one division to use another's dog food.

If my [e-mail] accounts were all managed by gmail.com there would be
no need for any callback mechanism whatsoever. Nor would there have been any
need for the Windows Live account or the crazy register then register all
over again.


If we could accept the simple idea that use of an authentication account
should work the exact same way as use of an email account, this type of
problem can be eliminated.

You don't expect to be able to use gmail.com for email unless gmail.com has
a Web server. So why do people try to write protocols that are designed to
allow people to use gmail.com for authentication when gmail.com is not
involved in the running of the authentication service in question?