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 [email protected]. 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 [email protected] 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?
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
