The Legal Thicket of Federated Identity Management

In this age of phishing, hacking, identity fraud, and other forms of cybercrime, answering two simple questions — “Who are you?” and “How can you prove it?” — is fast becoming a critical requirement for all online business activities.

Moreover, solving this “identity management” challenge has become quite complex as the increasing need for cross-organization collaboration, concerns about security, and the problem of user password management suggest that the traditional company-issued username and password approach is no longer adequate. As a consequence, federated identity management, in which a third-party identity provider plays a key role, is rapidly emerging as a preferred approach.

The cross-organizational nature of a federated approach to identity management presents numerous technical and procedural challenges that are the subject of ongoing work by many private and government groups, such as the Kantara Initiative, OpenID Foundation, Information Card Foundation, EURIM, SAFE-BioPharma, Certipath, the General Services Administration, OECD, PRIME — Privacy and Identity Management for Europe, the Federation for Identity and Cross-Credentialing Systems (FiXs), IdenTrust, and others. Yet structuring a federated approach to identity management also raises many new and complex legal issues that few have yet attempted to completely identify or resolve.

Recognizing the need to comprehensively address the legal issues raised by identity management, the American Bar Association has established a Federated Identity Management Legal Task Force to undertake such a project. Organized in 2009 following discussions with the Liberty Alliance (which has since become part of the Kantara Initiative), the ABA Legal Task Force is reaching out to all stakeholders, public and private, to become involved in this process.

The Basic Federated Identity Process

To appreciate the magnitude of the legal issues raised by the deployment and use of federated identity management systems, as well as the challenges of addressing them, it is helpful to begin with a very basic understanding of the process and the roles.

All identity management consists of two fundamental processes: 1) identification — that is, identifying individuals by assigning attributes to them that are relevant for a given purpose — e.g., name, age, address, account number, credit history, gender, photo, etc.; and 2) authentication — i.e., later verifying online that someone claiming to be a previously identified person is, in fact, such person.

The key difference with a federated model is that at least three roles are involved: 1) subjects — i.e., the persons being identified; 2) the identity provider, the entity that identifies the subjects and makes an assertion regarding their identity to third parties; and 3) the relying parties — the third parties that rely on those identity assertions for the purpose of granting subjects access to the services or resources they provide. This allows one organization to rely on identity assertions coming from a separate organization.

A familiar offline example of the federated model can be seen when a TSA agent at an airport (a relying party) relies on the identity assertion regarding the name of a subject contained in a driver’s license issued by a state (an identity provider) to determine whether to allow the subject into the boarding area.

The same basic approach can also be used in the online environment. For example, a government agency might rely on an identity assertion made by a subject’s bank (which has previously identified that subject as part of its customer screening process), in order to allow the subject online access to an account relating to his pension benefits. The subject might simply sign onto the agency Web site using the user ID and password he uses to access his online bank account. After the bank verifies that the individual’s user ID and password are still valid, and provides appropriate information regarding the subject’s identity, the agency would then grant him access to his account

As long as a trusted protocol exists for sharing the identity data between the bank and the agency, an individual can do business with the government agency using the identity credential issued by his bank. The agency avoids the need to set up its own costly identity proofing and authentication processes, and the individual avoids the need to keep track of two passwords.

That assumes, of course, that the agency trusts the process used by the bank to identify the customer, that the bank can limit to a reasonable level its liability risk should it make a mistake, and that the individual involved trusts both the bank and the government agency to properly use and protect the personal information initially provided to the bank. These concerns, among others, raise some of the key legal problems that the parties must address.

Identifying the Legal Issues

The ABA Legal Task Force has undertaken two key projects to address these challenges. The first is to identify the legal issues and risks that must be addressed in a federated identity management system. These legal risks can come from a variety of sources, including statutes and regulations, common law, applicable standards, contractual obligations, and self-imposed obligations. They vary depending on the jurisdictions involved, further complicating the operation of a cross-border identity management system — but until they are fully known and understood, they cannot be addressed.

Many of the legal issues arise when things go wrong, such as incorrect identification, faulty authentication, or misuse of personal data. A variety of legal principles may be involved in each case.

For example, if an identity provider makes an incorrect online statement to a relying party about the identity of a subject, applicable law might treat issuing that incorrect identity assertion as a breach of a warranty, as a tort of negligent misrepresentation, or as an unfair business practice. The scope of the identity provider’s liability for any damages suffered by the relying party (which may grant access to or enter into an unauthorized transaction with an imposter as a result) may well depend on which jurisdiction’s law and which legal theories apply.

In other cases, existing laws and regulations impose a variety of obligations on the parties. For example, identity management involves the collection (by an identity provider) and disclosure (to a relying party) of personal information about a subject. Potentially conflicting obligations may arise from the requirements of applicable privacy laws, the needs and wishes of the subject, the assurance level requirements of the identity management system, and the potential uses to which the identity provider and the relying party would like to make of the data.

Building a Legal Framework

A second key project undertaken by the ABA Legal Task Force will be to consider what legal frameworks might work best for addressing and controlling these legal obligations and risks. This will involve identifying and evaluating structures for contractual relationships among the various roles in an identity system. It will also include analysis of various contractual approaches that define the rights and obligations of each role, recognize the requirements of applicable law, allocate the risks among the roles, and provide an appropriate enforcement mechanism.

It is important to recognize, however, that some statutes and regulations impose requirements that cannot be altered by contract. Obligations imposed by some privacy laws, for example, may fall into this category. In those cases, participants must identify, understand, and comply with those obligations.

At the end of the day, federated identity management requires not only the deployment and use of appropriate technologies, standards, and policies, but also a clear understanding of the applicable laws and legal issues, and legally binding agreements to define and regulate the rights and obligations of the parties.