Over the weekend I needed to log in to eBay from somebody else's machine. The browser was Firefox, but it would have been impolite to install Greasemonkey and Password Composer, or even to install a bookmarklet, so instead I just used the live version of the password generator that has dramatically streamlined my online life in recent months.
Astonishing. Three different implementations of a lightweight single-sign-on protocol; all interoperable; at least one guaranteed to be available to me on any Web-connected computer. This is the effect I hoped to achieve in 1996 or 1997 when I first began using client-side digital certificates. Back then I figured that the technology would soon be woven into every Internet client. I'd use certificates to authenticate myself to online services. In some cases I'd also use them to release more information encoded as attributes on certificates.
I was so stubbornly committed to this idea that I ignored all the warning signs. The S/MIME signatures that I dutifully affixed to all my outbound email restricted me to specific email clients. Certificates were painful to acquire, and were bound to specific machines. Nobody else was acquiring or using digital certificates, and my use of them confused and annoyed people. Worst of all, the scenario that originally motivated my use of certificates -- to achieve Web single sign-on -- never materialized.
In fairness, I've met folks who do implement certificate-based single-sign-on. A number of case studies were presented at the Dartmouth PKI Summit I attended last summer (and which repeats this year). And I recently interviewed Gil Nolte, who directs the PKI Program Office at the Department of Defense, about their large-scale rollout of identity cards. Clearly when you control infrastructure, both on the back end and on the client, this stuff can be made to work. But when a technology operates within such a narrowly circumscribed environment, how generally useful can it be?
Meanwhile, on the public Internet, we use names and passwords for everything under the sun: e-commerce, online banking, corporate intranets. It's a horrible situation, but it trumps the alternatives just because it's ubiquitous. So the inverse question is: Can we make the ubiquitous name/password approach less horrible? My recent experience with the password generator shows me we can.
It's a timely notion because Microsoft has recently begun to explain its plan for an identity metasystem. Like everyone with an interest in digital identity, I have closely followed the rationale that its architect, Kim Cameron, has been thoughtfully articulating on his blog. Yesterday, commenting on the blogosphere's reaction to the "InfoCard" Identity Selector -- a digital-certificate-like technology that, according to the whitepaper, is "a WinFX component that provides the consistent user experience required by the identity metasystem" -- he wrote:
The Identity Selector itself does need to be part of the platform - in order to increase the safety and usability of the identity system by offering a consistent experience and making it very much harder for attackers to subvert than is the case with current applications and the browser-based technology.
However, there is nothing in the architecture to imply that the Identity Selector needs to store state on the thin client.
I can imagine "ultra thin" implementations of an Identity Selector store in which the card collection would be hosted by a distant web service, for example. [Kim Cameron: Bridging the chasm]
There are some big assumptions about safety and usability made here, and also in the whitepaper, that really need to be unpacked. The InfoCard will be safe, we're told, because it will be hardwired into Longhorn-style Windows operating systems. Maybe so. Microsoft has learned hard lessons about attack surface reduction, and I'm more willing than many skeptics to believe they can get this component done right.
Then there's a sense in which the InfoCard's safety is tied to its usability. A consistent user experience, it is suggested, will bring order from the chaos of ad-hoc browser-based identity mechanisms. But "consistent user experience" implies ubiquity. And it's been quite a while since I've been able, with a straight face, to regard Windows operating systems -- never mind future versions of them -- as ubiquitous. There are more client platforms than ever, and they're more viable than ever. Ways of dealing with that diversity have to be baked into any purportedly universal identity system, not bolted on.
So I'm quite curious to hear more about "ultra thin" implementations of InfoCard -- and not just of its certificate store, but also its user interface. The modern browser is more flexible, powerful, and secure than the Longhorn evangelists have allowed themselves (or wanted us) to believe. Firefox's security track record is very good, and it has become a breeding ground for improvements to the venerable name/password protocol. These trends suggest that Microsoft's proposal, which is laudably open in every other respect, could also support non-Windows user interfaces.
It had better.
Former URL: http://weblog.infoworld.com/udell/2005/05/31.html#a1241