"Who are you?" is a fundamental question for all online business activities. \n\nWhether a company wants to allow employees, contractors or business partners to \n\nremotely access its networks, or engage in online commercial transactions, the \n\nneed to authenticate the identity of the remote party is a critical one. \n MORE ON Identity Management\n \nThe Truth About \n\nFederated Identity Management\n\nThinking of Doing Federated Identity Management?\n\nAn \n\nIntroduction to Identity Management\nMoreover, in today's security-conscious environment, authentication is a \n\nlegal issue. A company's legal obligation to provide information security \n\nclearly includes a duty to properly authenticate persons seeking access to the \n\ncompany's computer systems or services. For example, in a recent case brought by \n\nthe victim of identity theft, the issuer of a credit card was held liable for \n\nfailing to properly authenticate the identity of the applicant\/imposter. Enter federated identity management, a promising approach to dealing with the \n\ncost and complexity of addressing this often-difficult identity problem. Much \n\nwork is being done by groups such as Liberty Alliance, WS-Federation and others \n\nto develop technical specifications that allow a business to verify the identity \n\nof a person seeking to access its systems by obtaining a digital credential \n\nissued by a third party. Yet the concept of federated identity management raises \n\ncritical legal issues that often get overlooked in the struggle to develop \n\nappropriate specifications. And failure to recognize and address these legal \n\nissues will delay the widespread implementation of federated identity options. \n\nAt its essence, identity management has two components. First, individuals \n\n(or businesses or devices) must be properly identified (e.g., this is John \n\nSmith, an employee of ABC company who works in accounting). Second, a mechanism \n\nmust be devised to verify that someone claiming to be a particular person and \n\nseeking remote access is, in fact, the same person as the one previously \n\nidentified (e.g., the person claiming to be John Smith and seeking remote access \n\nto the accounting database is really John Smith because he has presented the \n\nshared secret we gave to the person we previously identified as John Smith). \n\nTraditionally, each business has handled its own identity management. That \n\nis, a company identified its own employees and customers and then set up a \n\nmechanism, such as a system of shared secrets or passwords, by which those \n\npersons could be authenticated for remote network access. Today, however, \n\nbusinesses and government agencies are increasingly looking to third parties to \n\nhandle the difficult\u2014and often expensive\u2014task of identification. And \n\nusers, overloaded with passwords, are looking for a one-stop option. Federated identity has emerged as a promising solution. A federated identity \n\nmodel enables the portability of identity information or identity tokens across \n\ndifferent systems and entities. Thus, for example, one organization (e.g., the \n\nSocial Security Administration) can authenticate a person by relying on an \n\nidentity assertion made by a separate organization (e.g., a bank) that \n\npreviously identified the person when he opened an account. So long as a \n\nprotocol exists for sharing the identity data between the bank and SSA, that \n\nperson can do business with SSA using the user ID and password issued by his \n\nbank. That assumes, of course, that SSA trusts the identity verification process \n\nused by the bank, and that the bank can appropriately limit its liability risk \n\nshould it make a mistake. These issues, among many others, are some of the key \n\nlegal problems that must be addressed before the process will scale. While the technical details and specifications of a federated identity system \n\ncan become quite complex, the legal issues are readily apparent by looking at an \n\noversimplified summary of what actually happens:\n \nSomeone (a relying party) wants to know something about the identity of a \n\nparticular person (the subject). The subject may, for example, be an individual \n\nseeking access to the relying party's network, a person seeking to enter into an \n\nonline contract with the relying party or someone seeking to access an account \n\nwith the relying party. \nTo provide the required identity information, a third party that has \n\npreviously identified the subject (the identity provider) issues a digital \n\ncredential or token to make an assertion about the identity of the subject to \n\nthe relying party. \nThe token is communicated to the relying party (by either the subject or the \n\nidentity provider, depending on the system involved) and the relying party \n\nvalidates the token, and then relies on the associated identity assertion from \n\nthe identity provider in order to grant access to the subject or proceed with \n\nthe proposed transaction. \nThere are, of course, many ways to accomplish the foregoing, ranging from \n\nrelatively simple user ID and password systems to very complex public key \n\ninfrastructures. But in all cases there are some very basic questions that need \n\nto be asked, all of which raise potentially significant legal issues. Identification Process First and foremost, what is the \n\nprocess that the identity provider uses to establish the identity of the \n\nsubject? That process is critical to the reliability of an identity assertion. \n\nFor example, does the identity provider do an in-person interview of the subject \n\nand examine multiple government-issued photo identification documents, or does \n\nit simply rely on the subject's self-asserted claims made over the Internet? And \n\nwhat mechanisms are in place to ensure that the identity provider has actually \n\ncomplied with that process? For example, is there a requirement for an external \n\naudit? Personal Information What are the rules that govern the \n\nprivacy and security of the personal information about the subject that is \n\ncollected by the identity provider? Since the subject must provide the identity \n\nprovider with certain personal information to establish his or her identity, the \n\nprotection of that information becomes critical. Likewise, if the identity \n\nprovider will be communicating some of that information to a relying party as \n\npart of an identity assertion, the subject needs to know what rights the relying \n\nparty has to use and further communicate, and what obligations it has to \n\nprotect, that information. Scope of Assertion What is the scope of the identity \n\nassertion? For example, does an assertion that someone is "Bill Gates" mean that \n\nthis person is Bill Gates of Microsoft, Bill Gates of Peoria, Illinois, or some \n\nother random person with that name? Does it mean that this person has a bank \n\naccount in the name of Bill Gates? Or does it simply mean that this person \n\nclaims to be Bill Gates? The answer to this type of question will have \n\na significant impact on the willingness of the relying party to proceed with \n\ndifferent types of transactions on the basis of the identity assertion. And it \n\nwill also affect the liability of the identity provider in the event the \n\nassertion is incorrect. Use of Assertion What type of transaction is appropriate for \n\nuse of the identity assertion? The level of identity checking required to make \n\nan identity assertion for accessing the control processes of a nuclear reactor \n\nis presumably much greater than the identity verification necessary to justify \n\naccess to the local garden club website. The identity provider will want to \n\nlimit the scope of the use of an identity assertion. Liability The potential liability of the each of the parties \n\nis also important to consider. Specifically, what is the liability of the \n\nsubject for providing false identity information, or for failing to protect the \n\npassword or key necessary to initiate an identity assertion? What is the \n\nliability of the identity provider for failing to follow proper identification \n\nprocedures that result in an incorrect identity assertion? What is the liability \n\nof the relying party for trusting a fraudulent assertion (e.g., in the case of \n\nidentity theft), especially in a case where it could have determined that the \n\nassertion was false?There are a variety of possible approaches to developing a legal \n\ninfrastructure to address questions like these. They include enacting \n\nlegislation or regulations (such as those we see in some other countries), \n\nestablishing a set of private system rules that all parties contractually agree \n\nto (such as used by funds transfer systems and in the credit card industry), \n\nestablishing public standards that parties publicly agree to and are audited \n\nagainst as a condition of participating (as in the case of Extended Validation \n\nSSL certificates), entering into a series of one-on-one contractual \n\nrelationships (such as the federal government has been doing with selected \n\nidentity providers), and relying on public disclosures of practices (such as \n\nwith the traditional PKI approach). Each of these approaches has positive and \n\nnegative attributes. Without some type of a legal framework to address these issues, however, a \n\nfederated identity model will likely not scale. At least in the case of \n\neconomically significant transactions, the risks to each of the parties of such \n\nunresolved issues are simply too great to justify reliance on the federated \n\nprocess. These questions, and others like them, are the legal land mines that \n\nstand in the way of a viable federated identity management infrastructure. Thomas J. Smedinghoff is a \n\npartner in the privacy, data security and information law practice at the law \n\nfirm of Wildman Harrold in Chicago.