Moreover, in today's security-conscious environment, authentication is a legal issue. A company's legal obligation to provide information security clearly includes a duty to properly authenticate persons seeking access to the company's computer systems or services. For example, in a recent case brought by the victim of identity theft, the issuer of a credit card was held liable for failing to properly authenticate the identity of the applicant/imposter.

Enter federated identity management, a promising approach to dealing with the cost and complexity of addressing this often-difficult identity problem. Much work is being done by groups such as Liberty Alliance, WS-Federation and others to develop technical specifications that allow a business to verify the identity of a person seeking to access its systems by obtaining a digital credential issued by a third party. Yet the concept of federated identity management raises critical legal issues that often get overlooked in the struggle to develop appropriate specifications. And failure to recognize and address these legal issues will delay the widespread implementation of federated identity options.

At its essence, identity management has two components. First, individuals (or businesses or devices) must be properly identified (e.g., this is John Smith, an employee of ABC company who works in accounting). Second, a mechanism must be devised to verify that someone claiming to be a particular person and seeking remote access is, in fact, the same person as the one previously identified (e.g., the person claiming to be John Smith and seeking remote access to the accounting database is really John Smith because he has presented the shared secret we gave to the person we previously identified as John Smith).

Traditionally, each business has handled its own identity management. That is, a company identified its own employees and customers and then set up a mechanism, such as a system of shared secrets or passwords, by which those persons could be authenticated for remote network access. Today, however, businesses and government agencies are increasingly looking to third parties to handle the difficult—and often expensive—task of identification. And users, overloaded with passwords, are looking for a one-stop option.

Federated identity has emerged as a promising solution. A federated identity model enables the portability of identity information or identity tokens across different systems and entities. Thus, for example, one organization (e.g., the Social Security Administration) can authenticate a person by relying on an identity assertion made by a separate organization (e.g., a bank) that previously identified the person when he opened an account. So long as a protocol exists for sharing the identity data between the bank and SSA, that person can do business with SSA using the user ID and password issued by his bank.

That assumes, of course, that SSA trusts the identity verification process used by the bank, and that the bank can appropriately limit its liability risk should it make a mistake. These issues, among many others, are some of the key legal problems that must be addressed before the process will scale.

While the technical details and specifications of a federated identity system can become quite complex, the legal issues are readily apparent by looking at an oversimplified summary of what actually happens:

• Someone (a relying party) wants to know something about the identity of a particular person (the subject). The subject may, for example, be an individual seeking access to the relying party's network, a person seeking to enter into an online contract with the relying party or someone seeking to access an account with the relying party.
• To provide the required identity information, a third party that has previously identified the subject (the identity provider) issues a digital credential or token to make an assertion about the identity of the subject to the relying party.
• The token is communicated to the relying party (by either the subject or the identity provider, depending on the system involved) and the relying party validates the token, and then relies on the associated identity assertion from the identity provider in order to grant access to the subject or proceed with the proposed transaction.