When Microsoft hatched its .NET strategy a few years back, the company had some interesting if poorly executed ideas for moving its traditional software line into a subscription-based model. First, .NET software was to be based on the notion of Web services, in which the features exposed by OSs and applications aren't necessarily hidden in files on your PC but are instead made available from remote servers, to offer instant updating capabilities and much simpler management. Second, .NET was to be based on a subscription software model, in which users pay a regular (i.e., yearly or monthly) fee for updates that keep their software current, rather than upgrade to full new software versions every 3 to 5 years. Finally, .NET was to require an authentication scheme so that users could access the content they subscribe to securely from any location. After all, what good is Internet-based subscription software if you can only access it from a single PC?
Originally, .NET authentication was to have occurred through .NET Passport servers, which were set up years ago to handle users logging on to MSN Hotmail and other Microsoft Web properties. Passport was first conceived as a single sign-on (SSO) service with Ilium Software eWallet capabilities that, in theory, let users browse on compatible sites and escape the necessity of setting up credit card, address, and shipping information separately on each site. Although Passport had the potential to be a real time-saver, the service never took off, and most people viewed it as an annoying Microsoft requirement.
But Passport's biggest problem came about when Microsoft asked its corporate partners to support .NET My Services (formerly code-named HailStorm), the core set of .NET services that was to have used Microsoft's .NET Passport servers for authentication. Companies such as American Express, which already have strong relationships with their customers, had no interest in trusting Microsoft with their proprietary customer information and refused to endorse .NET My Services. Microsoft then abandoned its original plan and will redesign .NET My Services so that its partner corporations can access the services locally, from their own servers.
The new .NET My Services, whatever form it takes, will still require some form of authentication, although my assumption was that Microsoft would simply provide companies with a way to supply Passport functionality locally, from their own servers. This week, however, Microsoft announced a different strategy. Currently code-named TrustBridge, this new technology will let corporations bridge user authentication to other corporations, essentially creating a trust relationship between them. TrustBridge is the final nail in the coffin of Microsoft's earlier "megaservices" strategy, which relied on centralized .NET Passport servers. Now, Microsoft will return to its roots and simply sell corporations the software they need to set up their own services, and the companies choosing to do so can allow fine-grained information-sharing with external servers as well.
For security, TrustBridge uses the new Web Services Security (WS-Security) technology, an XML Web services specification built on Simple Object Access Protocol (SOAP) and backed by heavyweights such as IBM and VeriSign. Microsoft hasn't yet announced specific plans, but TrustBridge will likely be sold as a standalone server or as part of another server or server product that runs on Windows .NET Server (Win.NET Server).
For corporations that want to make .NET services available, TrustBridge addresses the final complaint the corporations had with Microsoft's original plan by removing the Microsoft "middleman." For users who want to take advantage of .NET services, TrustBridge pushes the .NET future back a bit, but when that future does arrive, probably sometime in 2003, .NET services will be more secure and reliable. Microsoft thinks the wait will be worth it. Frankly, the company might be right: .NET Passport was always the great unknown—or even the outright weak link—in the .NET plan anyway.
