Legal Obstacles Delaying Federated Identity Management

“Who are you?” is a fundamental question for all online business activities. Whether a company wants to allow employees, contractors or business partners to remotely access its networks, or engage in online commercial transactions, the need to authenticate the identity of the remote party is a critical one.

MORE ON Identity Management

The Truth About Federated Identity Management

Thinking of Doing Federated Identity Management?

An Introduction to Identity Management

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.

There are, of course, many ways to accomplish the foregoing, ranging from relatively simple user ID and password systems to very complex public key infrastructures. But in all cases there are some very basic questions that need to be asked, all of which raise potentially significant legal issues.

Identification Process First and foremost, what is the process that the identity provider uses to establish the identity of the subject? That process is critical to the reliability of an identity assertion. For example, does the identity provider do an in-person interview of the subject and examine multiple government-issued photo identification documents, or does it simply rely on the subject’s self-asserted claims made over the Internet? And what mechanisms are in place to ensure that the identity provider has actually complied with that process? For example, is there a requirement for an external audit?

Personal Information What are the rules that govern the privacy and security of the personal information about the subject that is collected by the identity provider? Since the subject must provide the identity provider with certain personal information to establish his or her identity, the protection of that information becomes critical. Likewise, if the identity provider will be communicating some of that information to a relying party as part of an identity assertion, the subject needs to know what rights the relying party has to use and further communicate, and what obligations it has to protect, that information.

Scope of Assertion What is the scope of the identity assertion? For example, does an assertion that someone is “Bill Gates” mean that this person is Bill Gates of Microsoft, Bill Gates of Peoria, Illinois, or some other random person with that name? Does it mean that this person has a bank account in the name of Bill Gates? Or does it simply mean that this person claims to be Bill Gates? The answer to this type of question will have a significant impact on the willingness of the relying party to proceed with different types of transactions on the basis of the identity assertion. And it will also affect the liability of the identity provider in the event the assertion is incorrect.

Use of Assertion What type of transaction is appropriate for use of the identity assertion? The level of identity checking required to make an identity assertion for accessing the control processes of a nuclear reactor is presumably much greater than the identity verification necessary to justify access to the local garden club website. The identity provider will want to limit the scope of the use of an identity assertion.

Liability The potential liability of the each of the parties is also important to consider. Specifically, what is the liability of the subject for providing false identity information, or for failing to protect the password or key necessary to initiate an identity assertion? What is the liability of the identity provider for failing to follow proper identification procedures that result in an incorrect identity assertion? What is the liability of the relying party for trusting a fraudulent assertion (e.g., in the case of identity theft), especially in a case where it could have determined that the assertion was false?

There are a variety of possible approaches to developing a legal infrastructure to address questions like these. They include enacting legislation or regulations (such as those we see in some other countries), establishing a set of private system rules that all parties contractually agree to (such as used by funds transfer systems and in the credit card industry), establishing public standards that parties publicly agree to and are audited against as a condition of participating (as in the case of Extended Validation SSL certificates), entering into a series of one-on-one contractual relationships (such as the federal government has been doing with selected identity providers), and relying on public disclosures of practices (such as with the traditional PKI approach). Each of these approaches has positive and negative attributes.

Without some type of a legal framework to address these issues, however, a federated identity model will likely not scale. At least in the case of economically significant transactions, the risks to each of the parties of such unresolved issues are simply too great to justify reliance on the federated process. These questions, and others like them, are the legal land mines that stand in the way of a viable federated identity management infrastructure.

Thomas J. Smedinghoff is a partner in the privacy, data security and information law practice at the law firm of Wildman Harrold in Chicago.