Every few years Microsoft issues another grand, unified plan for identity management. Well, they've done it again.

At the turn of the millennium, Microsoft launched Passport, an initiative under which the vendor sought to become the world's pre-eminent identity aggregator and authentication service. A few years later, Microsoft issued a comprehensive Web services security road map that included the WS-Federation protocol and marginalized Passport's role in identity management. Now we have a new Microsoft strategy, Identity Metasystem, which grants WS-Federation and such rivals as the Security Assertion Markup Language (SAML) more or less equal footing.

Why is Microsoft distancing itself from its previous identity management strategies? The reason is simple. Neither Passport nor WS-Federation has gained much industry support beyond a hard core of Microsoft's closest business partners while the rest of the industry has flocked to SAML.

Microsoft's new party line for identity management stresses the need for a universal identity environment that supports interoperation of multiple identity technologies run by multiple identity providers. This represents a 180-degree turn away from WS-Federation and Passport. The former was intended to serve as the single universal federated identity management protocol; the latter was positioned as an uber-identity provider for all of cyberspace.

To a great extent, the Identity Metasystem strategy repackages the core WS specifications that Microsoft has championed over the past three years. Microsoft hasn't totally abandoned WS-Federation but now positions it as the federated identity management plumbing within the Active Directory Federation Services feature of Windows Server 2003 and Longhorn.

The only truly new component of Microsoft's identity management strategy is InfoCard, which will be implemented in Longhorn. InfoCard is a privacy-protection feature within the Longhorn client. It will provide a secure client-side store of identity information for authenticating to various relying services. Users also will be able to selectively withhold privacy-sensitive InfoCard identity attributes from relying services, and to define and enforce policies regarding which relying services may access which client-store attributes.