Tangled in the Threads
Jon Udell, March 28, 2001A Storm Brewing
HailStorm will be controversial
At the core of Microsoft's .NET platform is the notion of web services. Last week, with its HailStorm announcement, the company sketched out a plan for its own menu of such services. Whether intended or not, the connotations of the project's code-name are fitting. The idea that Microsoft, or indeed any commercial entity, will manage personal data on behalf of consumers is rather shocking, and will create a storm of controversy.
But while Microsoft conspiracy theorists will have a field day with this, the HailStorm idea had to emerge sooner or later. The rhetoric of Microsoft's white paper -- "silos of information," "people not in control" -- is absolutely on target. Every day, we project more of ourselves into cyberspace. We don't have to, but increasingly we choose to, and in so choosing we build our digital identies. We manage these ourselves, manually and on a case by case basis, but in the long run we'll need software to help us do that.
As readers of this column know, I've long been preoccupied with the theme of digital identity. While I don't agree fully with Microsoft's approach, I'm glad that HailStorm is pushing the issue to the forefront. It won't go away, ever, and we are going to have to work through a thicket of social and technical issues.
Web passports
Almost every day, it seems, I find myself signing up for some new web service. Although I use and advocate client certificates, and although I appear on the Net at a fixed IP address, I have yet to encounter a web service that will wholly or partly authenticate me using either of these kinds of credentials. Invariably, I'm asked for a name and password. There is, of course, no good strategy for managing these proliferating credentials. Like a lot of you, I try to classify the services I use -- "top-secret," "mildly sensitive," "don't care" -- and reuse passwords accordingly. This helps, but since only some services let me use a preferred login name, while others assign me one, it's impossible to avoid credential bloat.
Microsoft's Passport service, touted as a cornerstone of HailStorm, tackles this problem. It's a simple idea: sign up once at passport.com, then use those credentials to authenticate yourself to participating sites. Unfortunately, there are hardly any of these outside the Microsoft family of websites. I'd love to be able to use Passport, or an equivalent service, especially for the "don't care" category of services. Signing up for these can be more trouble than it's worth. I'd explore and use more of them if the activation threshold were lower.
Would I worry about letting Passport manage my credential for me? You bet I would! Microsoft has a crummy track record on security. And any centralized pool of credentials, no matter who manages it, is a prime target for attackers who, almost inevitably, will succeed. This is the worm that eats away at HailStorm or any comparable scheme. Passport's centralized authentication is only the tip of the iceberg. HailStorm proposes to manage all sorts of stuff -- including calendar entries, transaction records, address books, even documents and email messages -- in a central datastore accessible by way of XML APIs. The owner of a HailStorm datastore will delegate, to selected client services, the access privileges needed to read, or write, the data.
The potential benefits are obvious, and tantalizing. If I say that it can, an airline ticketing service can inject filght times into my calendar. And if I say that it can, a business associate's calendar service can then read my calendar to check my travel plans.
The potential problems are equally obvious, and terrifying. I would urge anyone who's thinking about committing significant amounts of sensitive data to a central service to read, and deeply contemplate, Bruce Schneier's Secrets and Lies. The plain truth is that nobody can guarantee the level of security that we would like to expect from a HailStorm-like system. This doesn't mean that nobody should use such a system. HailStorm need not, and should not, be a monolithic thing. There will be a spectrum of services, each with its own peculiar risks and benefits. Here are some of the principles we can use to navigate the emerging web services landscape.
Pseudonymity
When people debate the social impact of Net technologies, they often conflate two very different notions: privacy and anonymity. Privacy means that Amazon.com won't share my transaction history with anyone else. Of course, we all want and expect that. Anonymity means that Amazon doesn't know who I am. This makes sense if I'm only browsing the site, and don't need or want the recommendations it offers when it can recognize me. It makes no sense, though, when I decide to buy a book. If we had a digital cash infrastructure that would enable me to purchase anonymously, I would still have to identify myself in order to receive the book. Even purely electronic goods -- an e-book, or a subscription to an online service such as Safari -- can't be consumed in a completely anonymous way.
There should be nothing surprising about this. We don't expect to transact business anonymously in the real world either. My visit to a bricks-and-mortar store is recorded in the memory of the clerk, and increasingly on videotape as well.
Cyberspace does, however, afford the interesting option of pseudonymity. Were there Passport support on a useful number of sites, I would likely set up a number of different identities for myself. Ideally, there would be a variety of authentication services equivalent to Passport, so that I could distribute my identities -- and thus spread the risk of compromise -- among them.
Of course this is a non-starter if each of these services has its own protocol, and if sites have to implement many protocols to support the services. But it's easy (in principle) to define a common protocol, using SOAP, or XML-RPC, or something even simpler, to be spoken between a bunch of authentication-providing sites on the one hand, and a bunch of authentication-using sites on the other.
Pseudonymity isn't always appropriate. On eBay, for example, it arguably causes more trouble than it's worth, by making it easier to manipulate the bidding, or to fence stolen goods. But there are lots of times when it's useful to be pseudonymous. In the realm of printed junk mail, many people already use variations on name or address to shield their core identities from unwanted exposure, and to track the kinds of attention that an alternate identity attracts.
One software system with deluxe support for pseudonymity is Groove. A Groove account is a container of identities, and when I join a shared space, I choose which identity -- that is, which business or personal role -- I project into that space. This kind of capability, managed by a loose federation of authentication-providing services, would be a wonderful enhancement to today's web.
Evanescence
Built into HailStorm is the very important notion that some kinds of data are evanescent, and will expire. How to ensure that such data actually will expire, and what expiration really means, are interesting questions. But it's really useful to have term limits on the personal data that I might commit to a central store.
It's even better to find ways to avoid such storage altogether. A great example of this is the Orbiscom one-time credit card number scheme. I first wrote about this brilliant idea in a column last October. Briefly, you use a piece of software to request, from a participating card issuer, a temporary one-time credit card number for use in one time-and-dollar-limited online purchase. Because the temporary number looks and acts like a normal credit card number, merchants don't know it isn't one, and don't need any special technology to process it.
The subject came up recently in my newsgroup when Randy Switt mentioned that he's been using Discover's implementation of the scheme. I was curious enough that I searched for the signup page because, though I don't hold a Discover card, I'd have considered getting one just to try this out. I was pleasantly surprised to find that my own MBNA America card now offers a similar service, called ShopSafe.
The setup procedure wasn't flawless. The ShopSafe software is based on IBM's Sash Weblication Manager, and has to install that first. I already had version 1.0 of Sash on my machine; ShopSafe wanted version 2.0; there ensued a flurry of confusing activity, and a reboot. It happens that I knew about Sash, and understood what was going on. Most people would have found this rigmarole bewildering.
Once installed, the user experience wasn't great either. The software is very RAM- and CPU-hungry. You can drag/drop shipping information from ShopSafe into web forms, but it's arduous. There needs to be an XML schema defining a single object of this type on both ends, so you can just do one single clean transfer. (According to Randy Switt, Discover's implementation does automate form-filling, apparently by hard-coding specific knowledge of certain sites.)
All in all, there are enough hoops to jump through so that, I suspect, few people will avail themselves of this first-generation Orbiscon technology. But the idea remains a brilliant one, and I'm sure it will be refined.
Stored credit card numbers are a prime target for attackers. If I were to use HailStorm, I wouldn't want to give it my credit card number. Thanks to Orbiscom's clever innovation, I shouldn't have to.
Decentralization
Although Microsoft's HailStorm whitepaper envisions a world of services hosted by Microsoft and on other central sites, there is no reason why selected services can't be pushed out to clients. The SOAP listener that governs access to my calendar could run on a central server, but almost as easily could run on my own PC, or some other device attached to my home network. I say "almost" because there are some firewall/NAT issues standing in the way of pervasive peer-to-peer computing across the Net. But these will have to be resolved anyway, and the desire to control our own data rather than hand it over to HailStorm should help to drive this issue forward.
As with our hypothetical federation of authentication services, here too, distribution helps us avoid the risk of having too much sensitive data in one place. Admittedly, this is a complex equation. Users generally can't manage home networks as securely as professionally-run central sites -- at least not yet. Perhaps systems like Groove, which makes ultra-strong security transparently available to ordinary users, can tip the balance in our favor.
In any case, peer-to-peer computing should enable us to realize the HailStorm vision without surrendering all our data to the central authorities. The P2P rhetoric, lately, tends to spurn centralization and celebrate decentralization. In reality, these are complementary tools. We'll need to use both side by side in order to make our way safely and happily in the new world of web services.
Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads
This work is licensed under a
Creative Commons License.