“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?
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
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
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
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.