IDENTITY MANAGEMENT SYSTEMS

Federated Systems: A Privacy-Based Characterization

Eleanor Birrell and Fred B. Schneider | Cornell University

Identity management systems store attributes associated with users and employ these attributes to facilitate authorization. A privacy-driven taxonomy of design choices found in these systems can help technical experts consulting on public policy relating to identity management.

eople use the Internet to manage finances, access implements mechanisms that let users control attribute P employer resources, shop, and communicate. Each release and mechanisms that issue asser- activity involves interacting with a service provider. tions—statements about user attributes. Upon receiv- Such interactions typically require that each user have a ing an authorization request from software executing . For the most part, each service provider on a user’s behalf, a service provider decides whether stores and manages such identities, which are used to to authorize the user on the basis of the accompanying improve the user’s experience, increase the service pro- authentication assertions. vider’s profits, and defend against certain attacks. Existing work on identity management focuses pri- Prior to the introduction of identity management marily on individual systems, each of which focuses on systems, many believed that practices concerning online one of three general types of functionality: identities were problematic because ■■ Single sign-on. These systems issue authentication ■■ each service provider maintains a set of user identi- assertions to multiple service providers after a sin- ties, so users have many identities (at least one for gle user authentication. Examples include Passport, each service provider with which they interact), ­OpenID (http://openid.net), Shibboleth (http:// which becomes a management burden and creates shibboleth.net), and Single Sign-On. potential points of failure; and ■■ . These systems manage multiple dis- ■■ users aren’t given control over their attributes’ dissemi- tinct identities for a single user and issue authentica- nation, leading to privacy violations and identity theft. tion assertions on the basis of any of these identities. Examples include Project Liberty (http://project Over the past 15 years, identity management sys- liberty.org), Higgins (www.eclipse.org/higgins), tems evolved with the goal of addressing these prob- PRIME (www.prime-project.eu), CardSpace, and lems, although actual mitigation of security concerns Client-Side Federation.2 has been limited by the sparse deployment of such ■■ Anonymous credentials. These systems provide authen- systems. Identity management systems enhance secu- tication assertions that don’t reveal the user’s identity rity and convenience by introducing a new party—an to a service provider. Examples include Idemix,3,4 —that must be trusted to perform cer- U-Prove, and P-IMS.5,6 tain functions. User authentication and identity man- agement are delegated to this identity provider, which In this article, we identify key design choices intrinsic

36 September/October 2013 Copublished by the IEEE Computer and Reliability Societies 1540-7993/13/$31.00 © 2013 IEEE Table 1. Existing identity management systems’ design choices. Passport Liberty Idemix Shibboleth Higgins PRIME OpenID CardSpace U-Prove CS- Federation P-IMS Facebook SSO

Interactive ■ ■ ■ ■ ■ Undetectability Active client ■ ■ ■ ■ Credential ■ ■ ■ ■ Centralized ■ ■ Identities Federated ■ ■ Decentralized ■ ■ ■ ■ ■ ■ ■ ■ Identity/ Pseudonymous ■ ■ ■ ? ■ ■ ? ■ ? action Anonymous ■ ■ ? ■ ■ ? ■ ■ Unlinkability Authorization ■ ■ ? ? ? ? ■ ■ ■ ■ Actions request Issue/use ■ ■ ■ ? ■ ? ■ ■ Instance ? ■ ■ ■ ? ■ ■ ■ ■ ■ Intentional Policy ■ ? ■ ■ ? Deniable ■ ■ ■ ■ ? ■ ■ ? ■ Forwarding Obligations ? ■ ?

Confidentiality Actions ■ ■ ■ ? ■ ? ■ ■ ■ ■ Inference Attributes ■ ■ ■ ■ ? ■ ? ■ ■ ■ ■ to existing identity management systems. We focus on impact on identity management system design; how- connections between the design choices identified in ever, other factors affect both the implementation and current systems and discuss the impact of these choices success of an identity management system. For example, on system functionality. We adopt a privacy-driven economic incentives and user-interface design might approach, which centers on three privacy properties: 7,8 trump privacy concerns for some systems. Still, privacy principles constitute an interesting lens through which ■■ undetectability—concealing user actions, to view the motivating principles that inform identity ■■ unlinkability—concealing correlations between com- management system design, because policymakers and binations of actions and identities (for example, un- users often voice privacy concerns. traceability), and ■■ confidentiality—enabling users’ control over dissemi- System Components nation of their attributes. Although we identify and discuss high-level design choices informally rather than conduct a formal treat- Undetectability, unlinkability, and confidentiality ment, a good place to start is with careful definitions for are related properties—all concern which parties have the components and actors of concern. These defini- access to particular data. However, these properties tions are standard.9 depend on orthogonal design choices and thus are best The parties in an identity management system are considered independently. The three properties define users, service providers, and identity providers. For a privacy-focused design space that informs choices convenience, we treat each party as monolithic, even intrinsic to building and deploying identity manage- though it could be implemented by a distributed system. ment systems. Table 1 shows a chart depicting various design choices that impact these properties, listing what Users choices existing systems have made. (For more informa- Each user (sometimes called a subject or principal) is tion on the characterizations of identity management, associated with a person. A user U is characterized by an see the related sidebar.) identity—a collection of attributes that represent prop- We focus primarily on these privacy properties’ erties about U. www.computer.org/security 37 IDENTITY MANAGEMENT SYSTEMS

Other Characterizations of Identity Management

n an effort to understand the failures (and limited successes) of privacy properties. I preceding identity management systems, Kim Cameron proposed User Control and Consent and Minimal Disclosure for seven laws of identity that he claims are essential for successful identity a Constrained Use are what we have termed confidentiality management systems.1 properties. In articulating these laws, Cameron argues that users should control attribute dissemination. In particular, ■■ User Control and Consent: An identity management system must identity management systems should provide users with infor- obtain a user’s consent to reveal information that identifies the user. mation, such as an attribute-use policy, that enables them to ■■ Minimal Disclosure for a Constrained Use: An identity management make informed decisions about attribute dissemination. With system that discloses less identifying information and imposes more the second law, Cameron also argues for mechanisms that limits on its use is preferred. disseminate coarser versions of attributes and for mechanisms ■■ Justifiable Parties: An identity management system must be designed that restrict attribute use (for example, obligations), although so that identifying information is disclosed only to parties having a his work doesn’t include examples of any such mechanisms. necessary and justifiable need. Justifiable Parties is an argument that users should be aware ■■ Directed Identity: An identity management system must support global of the parties with which they interact or share information, identifiers for use by public entities and local identifiers for use by and that information disclosure should be limited to necessary private entities. parties. This rule implies that user actions should be undetect- ■■ Pluralism of Operators and Technologies: An identity management able (for example, as supported by a credential-based system), system must support interoperability of multiple identity technologies because identity providers don’t need to obtain information run by different identity providers. about authorization requests. In practice, an active-client sys- ■■ Human Integration: An identity management system must employ un- tem in which the context of a user action is unobservable would ambiguous human-machine communication mechanisms that prevent suffice to address the privacy concerns that motivate this law. identity-based attacks (for instance, phishing and ­impersonation). Directed Identity is concerned with linking user actions ■■ Consistent Experience across Contexts: An identity management system across multiple service providers. Cameron argues in favor must provide a simple, consistent experience to users while supporting of local pseudonyms over the use of universal pseudonyms. multiple operators and technologies. But as given, Directed Identity precludes the possibility of an anonymous authorization system, although such systems are In terms of the landscape we sketch in the main text, many of Cameron’s consistent with the underlying motivations. laws advocate for particular design choices associated with the various Pluralism of Operators and Technologies precludes central-

Attributes describe inherent qualities (for example, card, for each given activity. Identity management sys- U.age = 25), circumstances (for example, U.employer tems let users select among multiple distinct digital = Example Co.), behaviors (for example, U.shopping identities in an analogous manner; the choice of iden- = true), inclinations (for example, U.likes_­animals tity determines which attributes are disseminated and, = true), or arbitrarily assigned values (for example, in particular, can prevent the dissemination of extrane- U.uid = 124). There’s no restriction on the number of ous attributes. attributes comprising an identity; some identities are small (for example, just a username and password), Service Providers and others might contain many, possibly interdepen- Service providers authorize users on the basis of dent attributes. Identities can be created by the user authentication assertions. The authorization decision or by another party acting on the user’s behalf, such might depend on the attributes received, the format of as an employer. Existing identity management sys- the authentication assertion, or properties of the party tems don’t support compound notions of identity (for P that issued the authentication assertion. example, the intersection of existing identities or a del- Most service providers (for example, or egated identity). The New York Times) currently implement their own A single user can be associated with multiple iden- identity management. Users are thus responsible for tities. Identities are sometimes compared to cards in a managing a separate identity for each service provider wallet, because people interacting in the physical world with which they interact. Many users—seeking con- choose from many different identifying cards, including venience—simply reuse the same authentication cre- driver’s license, credit cards, employer ID, and library dentials with multiple service providers. Therefore,

38 IEEE Security & Privacy September/October 2013 Other Characterizations of Identity Management

ized systems and advocates that different service providers functionality (for example, attribute namespace and propagation,4 ease implement different types of authentication assertions. of deployment,5 or control6) or economic incentives.7,8 Human Integration—which argues that identity manage- ment systems should employ a clear, secure user interface—and References Consistent Experience across Contexts—which argues that this 1. K. Cameron, “The Laws of Identity,” IdentityBlog, 2005; www.identity- interface should be consistent across the various parties in the blog.com/stories/2005/05/13/TheLawsOfIdentity.pdf. system—are universally accepted as good design principles but 2. T. El Maliki and J.-M. Seigneur, “A Survey of User-Centric Identity Man- are orthogonal to the privacy-centered characterization that is agement Technologies,” Proc. Int’l Conf. Emerging Security Information, the focus of our work. Systems, and Technologies, IEEE, 2007, pp. 12–17. In follow-up research, Tewfiq El Maliki and Jean-Marc Seigneur 3. A. Bhargav-Spantzel et al., “Privacy Requirements in Identity Manage- gave overviews of Project Liberty, Shibboleth, OpenID, CardSpace, ment Solutions,” Proc. 2007 Conf. Human Interface: Part II, Springer- and Higgins and evaluated these systems relative to Cameron’s Verlag, 2007, pp. 694–702. laws of identity.2 They concluded that Higgins most closely em- 4. W. Hommel and H. Reiser, “Federated Identity Management: Short- braces the design choices that Cameron’s laws promote. comings of Existing Standards,” Proc. 9th IEEE Symp. Integrated Net- Abhilasha Bhargav-Spantzel and her colleagues took a work Management, IEEE CS, 2005; http://dorii.eu/pub/Publikationen/ sociological approach to identifying key privacy principles for hore05a/PDF-Version/hore05a.pdf. identity management systems.3 After discussing numerous 5. A. Myllyniemi, “Identity Management Systems: A Comparison of Cur- user surveys, they emphasized that users’ privacy goals differ, rent Solutions,” Dec. 2006; www.tml.tkk.fi/Publications/C/22/papers/ depending on the type of attributes and the receiving party. Myllyniemi_final.pdf. They argued that identity management systems should provide 6. Y. Cao and L. Yang, “A Survey of Identity Management Technology,” information about attribute validation, implement protection IEEE Int’l Conf. Information Theory and Information Security (ICITIS 10), against false attributes and identity theft, and eliminate invisible IEEE CS, 2010, pp. 287–293. channels for attribute dissemination (that is, attribute infer- 7. S. Koble and R. Böhme, “Economics of Identity Management: A Sup- ence); they critiqued CardSpace, Project Liberty, and Shibboleth ply-Side Perspective,” Privacy Enhancing Technologies (PET 05), Spring- with respect to the identified privacy concerns. They also -ar er Berlin Heidelberg, 2006, pp. 259–272. gued for the development of new identity management systems 8. S. Landau and T. Moore, “Economic Tussles in Federated Identity Man- that address these concerns. agement,” First Monday, vol. 17, no. 10; http://firstmonday.org/ojs/ Other surveys of identity management systems focus on index.php/fm/article/view/4254.

accepting U’s authentication credentials constitutes an identity provider authenticates users could affect trusting every other service provider in the system to whether service providers accept that identity provid- not impersonate users or release user authentication er’s authentication assertions. credentials, voluntarily or involuntarily. ■■ Storing collections of attributes for users and manag- With identity management systems, service pro- ing these identities. Details vary across systems, but viders would have the flexibility to choose which par- generally, an identity provider would have provisions ties to trust (that is, which authentication assertions for creating, updating, releasing, and deleting attri- to accept), and because only identity providers would butes and identities. (In some systems, attribute val- manage authentication assertions, service providers idation, management, and storage are delegated to a would no longer need to trust other service providers. separate party called the attribute provider.)

Identity Providers Because service providers depend on receiving An identity provider can be implemented as a stand- authentication assertions that contain up-to-date attri- alone party or as a component of a user or service pro- butes, an identity provider might not only be respon- vider. It performs two primary functions: sible for validating attributes initially—that is, verifying their value in connection to a real-world identity—but ■■ Authenticating users—that is, determining whether also be trusted to maintain currency of those attributes. a particular user is associated with a particular iden- The methods used to validate attributes—including tity—and issuing authentication assertions in sup- whether to trust the user or to perform independent port of authenticated users. The manner in which validation of claimed attributes—and to eliminate

www.computer.org/security 39 IDENTITY MANAGEMENT SYSTEMS

2. Request authorization assertion associated with this interaction—interactive, active cli- ent, and credential based—and describe how they impact Identity provider 5. Send authorization assertion Service provider the authorization requests’ detectability. A request is 4. 3. Authentica Authentication considered undetectable to a party if that party can’t distinguish whether the action has occurred. Undetect-

tion reques ability is a privacy property insofar as it concerns users’ response ability to conceal actions from other parties. 1. Request6. servicProvidee service t Of course, whether a request is detectable depends on the adversary’s observational and computational User powers. In this section, let’s assume that the adversary performs the role of the identity provider and has no additional observational capabilities, so eavesdropping Figure 1. Typical control flow using an interactive design. Service providers on communication between other parties and collusion interact with an identity provider during each authorization phase. with service providers are ruled out. Even if a system sup- ports requests now being considered undetectable, an adversary might learn information about user authoriza- or update stale attributes often determine whether a tion requests through other means. However, prevention service provider will accept some identity provider’s of such attacks is beyond the scope of identity manage- authentication assertions. ment systems (although such prevention is necessary for ensuring that user actions are truly undetectable). Threat Model Privacy properties are defined with respect to assump- Interactive tions about adversaries. The adversaries could be By storing an identity at a particular identity provider, parties inside the system, such as adversarial iden- users are trusting that it will disseminate attributes only tity providers, or they could be external parties with for user-sanctioned purposes. If that trust extends to not access to some or all of the information available in the revealing information about user actions (in particu- system, such as hackers who target identity provider lar, authorization requests), then hiding authorization databases, phishers, or snoopers looking over a user’s requests (including context information such as which shoulder. Adversaries attempt to learn about user attri- service provider and which attributes) from the identity butes or past actions through any available means, provider is unnecessary. Identity management systems including forging messages or exploiting transport- can then interactively generate authentication assertions. layer addressing and timing. Multiple adversaries can Interactive systems employ a protocol in which ser- collude with each other (including collusion between vice providers communicate with identity providers adversarial identity providers and service provid- to obtain authentication assertions about users. Users ers, as considered in some systems2), and they might might be sent a request for authentication credentials exchange information or messages outside the scope each time a service provider solicits an authentication of the defined protocols. assertion (as Figure 1 shows) or could authenticate A party A that trusts a party B will believe not only once with the identity provider prior to issuing any that B is nonadversarial but also that B takes reasonable authorization requests. Because service providers inter- measures to prevent adversaries from gaining access to act with identity providers either directly (for exam- privileged information, including precautions to pre- ple, using SOAP) or indirectly (for example, using vent or mitigate against code vulnerabilities, and that HTTP redirects), an identity provider serves as a user B responds to requests by others for such informa- proxy and, therefore, necessarily detects authoriza- tion—for example, legal requests and subpoenas—in tion requests and observes the context in which such a manner A deems reasonable. Trust is not necessarily requests are made. Information gathered in this way permanent; A might cease to trust B if evidence emerges can be valuable (for example, for behavioral advertis- that indicates B might be untrustworthy. ing), so identity providers have an economic incentive to favor an interactive system despite the limited pri- Undetectability of vacy the design offers. Authorization Requests Interactive systems are typically implemented in Because authorization requests involve the user com- one of three ways: authentication assertions can be municating with both an identity provider and a ser- augmented with an HMAC, signed with a private vice provider, the identity provider becomes a proxy key (presumably supported by a public-key certifi- for the user. We identify three possible design choices cate infrastructure), or validated interactively. Existing

40 IEEE Security & Privacy September/October 2013 interactive identity management systems implement one or more of these approaches. For example, Passport Identity provider Service provider authentication assertions are encrypted using a shared 5. Authentication6. Send respons authorizatione assertion Data Encryption Standard key that’s established when 4. Authentication authorizationrequest assertion n service providers register with the Passport service; 3. Request authentication assertions thereafter can be validated without further interaction. Facebook authentication assertions—called access tokens—are digitally signed. 7. Send1. assertion Request servic8.e Provide service Project Liberty and Shibboleth both support two differ- 2. Request authorization assertio ent protocols for a passive client: identity providers can Client either respond to a request with a reference or Security Assertion Markup Language (SAML) artifact that must User be validated interactively, or they can send a digitally signed SAML response using HTTP protocols.OpenID ­ Figure 2. Typical control flow using active-client authentication. The client, also supports two authentication protocols: either an acting on the user’s behalf, interacts with the identity provider and the service identity provider–service provider pair can establish provider, eliminating the need for direct communication between these parties a relation by exchanging a secret key, which is subse- while ensuring fresh authorization assertions. quently used to encrypt and noninteractively validate authentication assertions, or authentication assertions can be validated interactively. partially blind signature scheme—to ensure that an Interactive designs limit exposure to stale attributes. identity provider doesn’t learn unnecessary information Because authentication assertions are issued exclusively about user authorization requests, even if the identity in response to a specific request (typically enforced provider colludes with service providers. Project Liberty using nonces or time stamps), the identity provider can also includes the option of employing an active client; recheck attributes before each authentication assertion however, it uses the active client exclusively to free a ser- is issued. So, the window for stale assertions can be lim- vice provider from the need to identify and locate the ited to the system’s communication delay. However, this correct identity provider. Identity providers still observe doesn’t address problems from cached attribute values the context in which authorization requests are made. or from stale values propagated by service providers. Credential Based Active Client If users are unwilling to trust identity providers with Although users must trust an identity provider with attri- information about authorization requests, including butes, that trust might not extend to arbitrary informa- the existence or frequency of such requests, then such tion about user actions. Active-client systems are similar requests must be undetectable to identity providers. to interactive designs, except users—or Web browsers Undetectable authorization requests can be imple- acting on users’ behalf—implement local functionality, mented using credentials, as Figure 3 illustrates. Creden- including local state information or code for deciding tials are transferrable digital artifacts—issued by identity which messages to send to which parties. Identity pro- providers to authenticated users—that convey authenti- viders can still detect authorization requests, but the cation assertions. Examples of credentials include digi- local functionality can prevent identity providers from tally signed strings,10 X.509 certificates,11 and SAML observing context associated with an authorization assertions. The subject of these authentication assertions request, for example, which service provider is con- is the user or identity to whom the credential was issued. tacted or which attributes are disseminated (see Figure And these authentication assertions might include attri- 2). To adopt this approach with today’s browsers, users butes that uniquely identify the subject of the credential. would have to download a software extension. Credentials can be presented to a service provider at any Identity providers in an active-client system produce time after being issued. The protocol for presenting a authentication assertions only in response to a specific credential varies. In some cases, a user might send a ser- request. So again, the window for stale assertions can be vice provider a copy of the credential; in others, the user limited to the system’s communication delay. proves possession of such a credential. CardSpace and Higgins implement active clients and Identity providers generate credentials without don’t disclose the service provider’s identity to the iden- knowledge of which service providers will receive tity provider that issues an authentication assertion. Cli- them, when, or how many times. Because credentials ent-Side Federation uses an active client together with can be presented at any time after being issued and can a newly defined cryptographic construct—an invariable be validated without identity providers’ participation www.computer.org/security 41 IDENTITY MANAGEMENT SYSTEMS

1. Request credential the subject presents that credential: tying knowledge of 2. Authentication request a secret to an external secret with real-world value, such User 3. Authentication response Identity provider 4. Send credential as bank account information, or ensuring that a user U′ (a) who knows U’s secret SU can use all of U’s credentials, including, for example, the credentials for accessing U’s 1 Request service bank account. These techniques work because users 2. Request credentials are generally unwilling to share valuable information User 3. Send credentials Service provider 4. Provide service and, therefore, won’t reveal the secret SU. Nontechnical (b) means, such as user contracts and legal accountability, can also discourage users from sharing credentials. Figure 3. Typical control flow using credential-based authentication. (a) Because credentials can be presented long after Credential issue and (b) credential presentation. Because the two phases occur being issued, identity management systems that employ independently, this design minimizes the information about authorization credentials must address the issue of stale credentials. requests that is detectable by the identity provider. Several approaches have been suggested, including expiration dates and revocation lists,13,14 but they either require users to place additional trust in another party (although interaction with a certificate authority (for example, checking a submitted credential against or other components of a trust hierarchy might be an identity provider–maintained stale blacklist, which required), identity providers can’t detect an authoriza- could render authorization requests detectable) or tion request or observe information about the context require some party to incur significant delay. in which the authorization request occurs. Some types of credentials let users selectively release attributes by Unlinkability eliminating certain attributes from a credential or by Unlinkability is a privacy property that concerns per- replacing attributes with coarser values—for example, manently or temporarily hiding correlations between replacing U.age = 25 with U.age > 18.3,5,12 combinations of actions and identities. For each type If credential transfer and delegation are undesirable, of linking—between two identities, between an action then it is necessary to ensure that credentials are vali- and an identity, or between two actions—the level of dated only when presented by the user to whom they trust that users place in other parties determines the were issued. Existing identity management systems that most appropriate design choice. implement credentials use cryptography to ensure that only a party with knowledge of a particular secret—pre- Identities Linked with Other Identities sumably the subject of the credential—can present a The first question is whether users trust identity provid- credential in a manner that will be validated. The secret ers with knowledge about connections between differ- isn’t revealed during the presentation of a credential. In ent identities and, if not, how to prevent such linking. Idemix, a user U has a master secret SU used during the Note that providing users with unlinkable identities creation of pseudonyms and credentials issued to U. To implicitly relies on the assumption that trusted identity present a credential, U proves knowledge of a secret SU providers don’t collude with one another to link distinct and a credential generated using SU that contains the identities. Today’s identity management systems don’t appropriate attributes. attempt to prevent such collusion. PRIME uses Idemix credentials; U-Prove uses a sim- ilar approach, except it employs per-credential secrets Centralized. If identity providers can be trusted with instead of a single master secret for each user. The proto- identity linking, then a centralized identity management col for generating U-Prove credentials returns two out- system—one in which a single, dedicated identity pro- puts to the user U: a credential c and a corresponding vider manages all identities for all users—is a sensible secret sc, which is revealed only to the user. When pre- design choice. Users who opt in must trust the identity senting the credential c, U proves knowledge of secret sc. provider and disclose all user attributes to this iden- P-IMS uses blind signatures to produce credentials; the tity provider. Even when users choose to create multi- credential itself is therefore known to the user only and ple distinct identities (for example, personal and work can be used as the secret. To present a P-IMS creden- identities), patterns in attribute value or use could allow tial, the user proves knowledge of a credential satisfying the identity provider to link multiple identities to the appropriate requirements. same individual because all identities are stored by the Secrets alone can’t prevent users from delegating same identity provider. Because information that links credentials to other parties. Idemix employs two tech- user identities and actions performed under those iden- niques to ensure that a credential is accepted only when tities is economically valuable, identity providers have

42 IEEE Security & Privacy September/October 2013 an incentive to favor a centralized identity management with a unique identifier orpseudonym . Pseudonyms are system. Passport and Facebook Single Sign-On are typically opaque, globally unique identifiers. They’re examples of centralized systems. commonly used to facilitate single sign-on. Permanent or long-lived pseudonyms enable linking, so identity Federated. A federated identity management system providers and service providers have an economic instantiates an intermediate design point in which users incentive to favor pseudonymous authorization. choose which identity providers to trust with links Pseudonymous authorization is implemented by between certain identities associated with them. Proj- Passport, Project Liberty, OpenID, and Client-Side ect Liberty supports this: identity providers with estab- Federation. Passport credentials all contain an opaque, lished business relations form circles of trust. Within a globally unique identifier (PUID). In Project Liberty, circle of trust, a user can opt to federate two identities, federated parties exchange locally unique user handles. in which case, the identity providers exchange informa- OpenID users submit a globally unique identifier (for tion and the identities are linked. Client-Side Federa- example, [email protected]) to the service pro- tion is also a federated identity management system, but vider to initiate authorization. Client-Side Federation it’s designed to ensure that local handles are known only uses local handles that are known only to the user and to the user, not the identity provider, thereby guarantee- the service provider. ing privacy against identity providers that collude with service providers. Anonymous authorization. If service providers aren’t trusted with links between authorization requests and Decentralized. If identity providers can be trusted only identities, then an identity management system can with attributes that are specifically released to them and employ anonymous authorization. Anonymous authori- not trusted with identity linking, then the most appro- zation doesn’t ensure that a service provider never links priate choice is a decentralized identity management sys- an authorization request to information that uniquely tem in which multiple, distinct identity providers each identifies the identity (for example, a particular com- function separately—possibly using different proto- bination of attributes); it ensures only that such link- cols—and might not even be aware of each other. Users ing can’t occur unless the service provider explicitly can create one or more identities with any identity pro- requires such a combination of attributes. vider in the system. This architecture lets users not only Anonymous authorization can be implemented choose which identity providers to trust with which simply by eliminating from messages or credentials attributes but also distribute sensitive attributes across all unique identifiers that the service provider doesn’t distinct identity providers, thereby ensuring unlinkabil- explicitly require. For example, Shibboleth supports ity of distinct identities. Most existing identity manage- anonymous authorization, although users can choose to ment systems, including Idemix, Shibboleth, Higgins, reveal a persistent identifier. Project Liberty lets a service PRIME, OpenID, CardSpace, U-Prove, and P-IMS, provider request an anonymous, temporary, identifier have adopted this approach. for a user if the service provider elects to support anony- mous authorization. U-Prove credentials have unique Identities Linked with Actions identifiers; however, the identifier is tied to the creden- Another question is whether service providers can be tial and not the identity, so avoiding reuse of a credential trusted with information that links an authorization with the same service provider is sufficient to achieve request to information that uniquely identifies the anonymous authorization. Idemix and P-IMS both issuer of that request or to an identity associated with employ zero-knowledge proofs to let users demonstrate the issuer. Of course, support for anonymous actions a credential’s existence. A zero-knowledge proof, by implicitly relies on the cooperation of the service pro- definition, reveals nothing other than the veracity of the viders in the system. Service providers always can claim—in this case, knowledge of a valid credential— request uniquely identifying attributes, thus undermin- and, therefore, supports anonymous authorization. ing efforts to create anonymity. Ensuring that service Anonymous authorization interferes with stan- providers support anonymous users—by making attri- dard notions of accountability, and many communi- bute-based authorization decisions rather than requir- ties believe that individuals should be held accountable ing a unique identifier—is a significant problem beyond for unacceptable online behaviors, such as fraud or the scope of today’s identity management systems. accessing illegal materials. To support both anonymous authorization and accountability, a deanonymizing party Pseudonymous authorization. If service providers are can be implemented. Only under certain circumstances trusted to link authorization requests to identities, then does it link an action to the identity behind it. So, users all such requests for a given identity could be issued are anonymous under normal circumstances, but an www.computer.org/security 43 IDENTITY MANAGEMENT SYSTEMS

authorized agency can, when necessary, determine the Linking credential issue with credential presentation. individual responsible for an online action. Identity Another type of action linking is feasible if a service management systems can employ cryptographic tech- provider and an identity provider can cooperate to link niques to ensure that a deanonymizing party can’t create a credential issued by the identity provider to its use in conditions under which links might be reestablished, so an authorization request. Credentials for which these such systems can be made resilient against deanonymiz- actions can’t be linked are sometimes called untrace- ing parties that are bribed or corrupted. able. In systems that employ interactive or active-client In Shibboleth, identity providers observe and log authentication, such links can be established. Even if all user actions, so they can act as the deanonymizing the authorization is anonymous, the link can typically party. In P-IMS, authorization is granted to a partic- be established by comparing time stamps. Because the ular persona. Identity providers that issue a creden- same persona is used during the issuing protocol and tial or persona can determine the identity or persona the use protocol, identity providers and service provid- to which it was issued; therefore, identity providers ers can also establish this link in P-IMS. However, both collectively perform the functionality of the deano- U-Prove and Idemix implement untraceability. nymizing party. Deanonymization is more difficult in Idemix, in which credential presentation consists of Confidentiality in Identity Management a zero-knowledge proof, and U-Prove, in which the Identity management systems should let users control issuing identity providers don’t learn the credential which parties learn specific attributes. Three channels identifier. However, users in either system can choose could allow a party P to learn attributes about a userU : to include identifying information encrypted under the public key of a designated deanonymizing party ■■ intentional channels—P receives the attributes directly (and a proof that the ciphertext was correctly gen- from U or from an identity provider acting on U’s erated), so that accountability can be enforced by a behalf, third-party deanonymizer. ■■ attribute forwarding—P acquires the attributes from another party P′, and Actions Linked with Other Actions ■■ attribute inference—P deduces the attributes from A final dimension to linking concerns whether service other known or observed information. providers, either alone or in cooperation with an iden- tity provider, are trusted with information that links var- Design choices here focus on how users control ious actions attributed to the same identity or credential which attributes to release, when, and to which parties and, if not, how such linking can be prevented. over intentional channels—those instigated by users. Users don’t control attribute forwarding and attribute Linking multiple authorization requests. If a service inference, so design choices concern whether and provider can link authorization requests to an identity how to control or prevent attribute release over these (or an identifier for an identity, as with pseudonymous channels. authorization), then by transitivity, it can link all the authorization requests issued using the same identity. If Release over Intentional Channels the system instead employs anonymous authorization, We begin with different types of user control over the the service provider’s ability to link multiple authoriza- dissemination of attributes over intentional channels. tion requests to each other depends on the implemen- These design choices can be applied to both direct tation. Existing interactive, anonymous authorization release of attributes and dissemination of attributes by protocols (for example, Shibboleth) provide no per- an identity provider acting on a user’s behalf. Of course, sistent identifier across authentication assertions, so the user must trust the service provider with all dissemi- actions can’t be linked to each other. To show an Idemix nated attributes. credential, users employ a zero-knowledge proof, so two authorization requests can’t be linked, even when issued Instance-based attribute release. Under this approach, using the same credential. However, U-Prove creden- users explicitly specify parties to which each attribute tials have a unique identifier, so requests containing the might be released. Instance-based attribute release is same credential can be linked, although requests issued extremely flexible. However, the approach can be incon- with different credentials can’t. And P-IMS authoriza- venient because it requires users to make many deci- tion protocols require users to reveal the claimed per- sions and because determining which service providers sona, so requests issued with the same persona can be to trust can be difficult. linked, although, again, requests issued with different Nonetheless, many existing identity management personae can’t. systems provide instance-based attribute release to

44 IEEE Security & Privacy September/October 2013 control attribute dissemination to service providers. policy rule consists of a single requirement rule, which CardSpace and Higgins service providers send users a determines whether the policy rule is binding for a par- policy (described using HTML or WS-Security­Policy) ticular interaction, and zero or more attribute rules, specifying required attributes and authentication which specify the attributes governed by the policy assertion types. Users must then interactively decide rule and whether those attributes will be released. Each whether to share the requested attributes with the cor- policy rule is expressed using a flexible policy language responding service providers and, if so, which available and can depend on each of the parties involved as well identity to use. as attribute type and value. Depending on the identity management system’s PRIME makes extensive use of policies that govern other design choices, the choice of identity could deter- data access, data release, and data handling. Users and mine what information various identity providers can service providers both define policies. Starting from observe and which attributes the service providers these, the system automatically negotiates conditions receive. Facebook Single Sign-On presents users with of data release; this negotiation can but doesn’t neces- permissions requested by the service providers, which sarily include active user input. A successful negotiation users must accept or deny. Mechanisms for controlling finds a solution that satisfies both parties’ policies; such attribute release are beyond the OpenID specification’s a solution is required before any attribute is disclosed. scope, but the OpenID Attribute Exchange protocol PRIME software, running locally at the service pro- specification does permit responses that indicate an vider, is designed to automatically enforce any condi- attribute isn’t available (usingattribute.count = 0). The tions that are agreed on during the negotiation. Google OpenID identity provider leverages this capa- bility and gives users an option to permit or deny the Release by Attribute Forwarding release of each attribute required by a service provider, Attribute forwarding occurs when a partyP acting on with an option to remember selected permissions for its own initiative discloses an attribute to another party future interactions with the same service provider. P′. For example, a service provider that sells goods Existing credential-based identity management sys- might forward a user’s address to a service provider that tems, such as Idemix, U-Prove, and P-IMS, leave the arranges delivery. Attribute forwarding is invisible to approach to attribute release unspecified; some of these the user; however, some identity management systems systems let users share either an entire credential or introduce mechanisms that let users prevent or control derived credentials that convey subsets of the attributes such disclosures. and coarser attribute values. Deniable attributes. Deniable attributes can’t be validated Policy-based attribute release. With this approach, users without identity provider or user cooperation. This define a policy, and an attribute is released to service pro- embodies the philosophy that the significant concern viders if and only if the specified policy is satisfied for about attribute release is whether parties can prove to that attribute. The policy can involve attribute type, attri- others that a user satisfies some particular attribute— bute value, party identity, or properties of the party when not whether those parties can merely learn or claim the defining the conditions for attribute release. In a typical user satisfies those attributes. The approach is widely implementation, the software (for example, the Web adopted in existing identity management systems. browser) will automatically determine which parties Systems that employ interactive authentication should receive specific attributes on the basis of user pol- implement deniable attributes by encrypting asser- icies. Although policy-based attribute release is typically tions with a shared secret key (Passport and OpenID) less expressive than instance-based release (depending or by sending service providers a reference that will be on the language in which policies are written), policy- validated interactively only with explicit user permis- based release simplifies the user experience by automat- sion (Project Liberty and Shibboleth). Systems that ing attribute dissemination. Passport, Shibboleth, and employ credential-based authentication can implement PRIME employ policy-based attribute release. deniable attributes by requiring the presenting party Passport employs a very restrictive language for to know a particular secret for the credential to be vali- expressing user policies. Users tag each attribute with a dated (Idemix, U-Prove, and P-IMS). label, “public” or “private.” Attributes are then automati- cally released to other parties on the basis of these tags. Obligations. Another approach to control attribute for- Specifically, Passport sends attributes tagged “public” to warding involves tagging released attributes withobli - any service provider with which users choose to interact. gations that describe if and how the attribute can be In Shibboleth, attribute release is controlled by an used. For example, an obligation could describe circum- attribute filter, which is a collection of policy rules. Each stances under which the attribute may be forwarded www.computer.org/security 45 IDENTITY MANAGEMENT SYSTEMS

to a third party. To be an effective control, the tagged management systems intended to serve public policy attributes’ recipients must obey these obligations. Thus, goals. We illustrate this value using the current National users must trust those recipients; such trust can be Strategy for Trusted Identities in Cyberspace (NSTIC), developed on the basis of previous experience or repu- initiated by the US federal government in April 2011. tation, assertions generated by trusted hardware, or (if NSTIC is intended to foster the development of an deviations are detectable) legal accountability. identity ecosystem that makes online transactions more PRIME supports obligations to implement control secure, enhances consumer privacy, and encourages the over data use, including attribute forwarding; a policy development of future, identity-driven online services. negotiation phase occurs prior to attribute release, The NSTIC document (www.whitehouse.gov/sites/ and all released attributes are tagged with obligations default/files/rss_viewer/NSTICstrategy_041511. that are mutually agreed on during that phase. Obliga- pdf) highlights the need for new, secure, and private tions can specify notification requirements, deletion solutions to enable validation, authentication, authori- requirements, and limitations on forwarding or other zation, and accountability. It identifies four principles to uses of attributes. PRIME relies on a combination of guide identity ecosystem design; these systems should legal accountability and secure hardware as the basis be privacy enhancing, secure and resilient, interopera- for users to trust that obligations are enforced; legal ble, and easy to use. We show how the design choices we accountability ensures service providers use correctly described can inform the technical aspects of the design installed, trusted hardware modules. The trusted hard- of such systems. ware generates cryptographic assertions that tagged Noting that people currently use drivers’ licenses attributes are accessed only by PRIME software. Legal as a real-world assertion without the Department of accountability can be invoked if correct assertions Motor Vehicles or the state government being aware aren’t received. of their actions, NSTIC recommends implementing a system in which user actions are undetectable by iden- Attribute Inference tity providers. Undetectable actions are also consistent Attribute inference occurs when a partyP can deduce with NSTIC’s articulated goal of enhancing user privacy an attribute’s value from other information known toP . by minimizing the release of user information. As we Attributes can be inferred from user behavior, including noted, credential-based systems implement undetect- websites visited and items viewed or purchased, or from able actions, but no other design choice does. Creden- other attributes. tials are employed by all existing identity management Preventing attribute inference is related to the prob- systems that focus on anonymity—a feature that lem of privacy-conscious information disclosure. There NSTIC recommends identity management systems has been extensive work on this subject in the context of support. Thus, we shouldn’t be surprised to find that databases, culminating in the notion of differential pri- an NSTIC-compliant ecosystem explicitly embraces vacy15 for database queries—the goal of which is to pre- credential-based authentication on technical grounds. vent adversaries from inferring attributes that couldn’t NSTIC advocating for a credential-based system is be deduced from previously available information. consistent with other goals espoused by the strategy One standard defense against attribute inference is document. It stipulates that user privacy be enhanced to minimize the amount of information that P learns. by releasing minimal information about attributes and This can be done by limiting the types of user behav- that the system be easy to use. This balance between ior that P can detect or observe as well as limiting the expressiveness and convenience would best be mate- attributes thatP can learn over other channels. If a rialized with a system that uses policy-based attribute party has prior access to information about a particu- release. Because it’s possible to implement credentials lar user action or attribute, then it’s impossible to pre- that permit selective release of attributes and support vent that party from learning whatever attributes can arbitrary claims about attributes (for example, Idemix be inferred from that information alone. However, in credentials), policy-based access control can be incor- many cases, accurate attribute inference requires link- porated into a credential-based system, although no ing many different pieces of information and even system currently combines these two design choices. performing statistical analysis. Therefore, a second Moreover, the privacy enhancement and release mini- standard defense is to prevent linking using one of the mization goals imply that these techniques should be techniques we discussed. employed to control or minimize the release of infor- mation through invisible channels; these techniques The Framework Applied to Public Policy also are consistent with a credential-based system. This taxonomy of design choices is not only descrip- NSTIC envisages a system in which multiple identity tive; it has analytic value in the design of identity management technologies issued by multiple identity

46 IEEE Security & Privacy September/October 2013 providers are recognized and accepted interoperably by compatibility with the other design choices implied service providers in the system; this implicitly assumes by NSTIC’s goals and discussion. a decentralized system. NSTIC also specifically asserts that anonymous authorization should be supported and that linking between actions should be minimized. A he goals NSTIC outlined imply that active-client credential-based system can support these goals as well. T systems—and the software to support them— However, the NSTIC documentation asserts that an would be a profitable focus for future research on pri- identity ecosystem should be resilient to credential loss, vate, secure, interoperable, and easy-to-use identity compromise, and theft. This goal is difficult to achieve management systems. in a credential-based system because it requires a means to revoke credentials, and existing approaches to revo- Acknowledgments cation conflict with NSTIC’s other goals. If credentials We’re grateful to Donna Dodson, Jeff Friedberg, Susan Lan- are issued for a specific service provider, then they can dau, Naomi Lefkovitz, and Deirdre Mulligan for many helpful be revoked by contacting that service provider. How- comments on an earlier version of this article. The final ver- ever, such a design requires contact between service sion of the article was also much improved from comments providers and identity providers every time a creden- provided by editor Shari Lawrence Pfleeger and the review- tial is validated, which is inefficient, at best. Moreover, ers. Birrell is supported by a National Science Foundation current implementations either allow identity provid- Graduate Research Fellowship. Schneider is supported in part ers to learn information about user actions that could by AFOSR grants F9550-06-0019 and FA9550-11-1-0137, violate system privacy goals or rely on computationally National Science Foundation grants 0430161, 0964409, and expensive cryptographic techniques to enforce private CCF-0424422 (TRUST), ONR grants N00014-01-1-0968 information retrieval, further violating the efficiency and N00014-09-10652, and grants from Microsoft. requirement. If credentials are instead issued with short expiration dates, then credential loss is only a References vulnerability for a short interval. However, this allows 1. E. Birrell and F.B. Schneider, Federated Identity Manage- identity providers to observe some information about ment Systems: A Privacy-Based Characterization, tech. patterns in user authorization or requires significant report 30471, Computing and Information Science, Cor- computational overhead. If neither of these approaches nell University, Oct. 2012. is adopted, then the inability to revoke credentials 2. S. Canard, E. Malville, and J. Traoré, “Identity Federation requires users to contact all service providers to ensure and Privacy: One Step Beyond,” Proc. ACM Workshop that lost or stolen credentials aren’t fraudulently used. Digital Identity Management, ACM, 2008, pp. 25–32. Such a task is infeasible and certainly violates the ease- 3. J. Camenisch and A. Lysyanskaya, “An Efficient System for of-use goal. Given current capabilities, implementing a Non-Transferable Anonymous Credentials with Optional credential-based system that’s efficient, easy to use, and Anonymity Revocation,” Advances in Cryptology (EURO- resilient to the loss of user credentials isn’t possible. CRYPT 01), LNCS 2045, Springer, 2001, pp. 93–118. Moreover, to support flexible credentials that enable 4. J. Camenisch and E. Van Herreweghen, “Design and partial release of identities, users must perform some Implementation of the Idemix Anonymous Credential computations, such as selective release, locally. Given System,” Proc. 9th ACM Conf. Computer and Communica- current Web browsers’ limitations, this implies down- tions Security (CCS 02), ACM, 2002, pp. 21–30. loading and installing specialized software, a technical 5. M. Hussain and D. Skillicorn, “Persona-Based Identity requirement that conflicts with NSTIC’s nontechnical Management: A Novel Approach to Privacy Protection,” goals of facilitating deployment and ensuring ease of use. Proc. 13th Nordic Workshop Secure IT Systems (WWSecIT However, if system designers are resigned to 08), Technical Univ. of Denmark, 2008, pp. 201–212. deploying a system that makes certain decisions 6. D. Skillicorn and M, Hussain, Personas: Beyond Identity locally, as well as the difficulties that accompany this Protection by Information Control, A Report to the Privacy choice, then they can abandon the credential-based Commissioner of Canada, Mar. 2009. approach in favor of an active-client system. Although 7. A. Pfitzmann and M. Hansen,A Terminology for Talking this makes user actions detectable to identity provid- about Privacy by Data Minimization: Anonymity, Unlink- ers, active-client systems can ensure that the context ability, Undetectability, Unobservability, Pseudonymity, and and details of those actions are still unobservable, a Identity Management, tech. report, TU Dresden, Apr. 2010. standard that appears consistent with NSTIC’s stated 8. M. Deng et al, “A Privacy Threat Analysis Framework: goals. Moreover, an active-client system would ame- Supporting the Elicitation and Fulfillment of Privacy liorate the security and resiliency concerns that arise Requirements,” Requirements Eng., vol. 16, no. 1, 2011, from a credential-based system while maintaining pp. 3–32. www.computer.org/security 47 IDENTITY MANAGEMENT SYSTEMS

9. Committee on Authentication Technologies and Their 15. C. Dwork, “Differential Privacy,”Automata, Languages Privacy Implications, Who Goes There?: Authentication and Programming, LNCS 4052, Springer, 2006, pp. through the Lens of Privacy, S.T. Kent and L.I. Millett, eds., 1–12. Nat’l Academies Press, 2003. 10. L.M. Kornfelder, “Towards a Practical Public-Key Cryp- Eleanor Birrell is a PhD student in computer science tosystem,” bachelor’s thesis, Dept. Electrical Engineering, at Cornell University. Her research interests include Massachusetts Inst. Technology, 1978. principles of systems security and theoretical cryp- 11. C. Adams and S. Farrell, Internet X.509 PKI Certificate tography. Birrell received a BA in computer science Management Protocols, RFC 2510, Internet Eng. Task and mathematics from Harvard University. Contact Force, Mar. 1999. her at [email protected]. 12. D. Bauer, D. Bloguh, and D. Cash, “Minimum Informa- tion Disclosure with Efficiently Verifiable Credentials,” Fred B. Schneider is the Samuel B. Eckert Professor of Proc. 4th ACM Workshop Digital Identity Management, Computer Science at Cornell University. His research ACM, 2008. interests include trustworthy computing systems. 13. S. Brands, L. Demuynck, and B. De Decker, “A Practi- Schneider received a Doctor of Science honoris causa cal System for Globally Revoking the Unlinkable Pseud- from the Newcastle University upon Tyne. He’s a onyms of Unknown Users,” Proc. 12th Australasian Conf. member of the US National Academy of Engineering Information Security and Privacy (ACISP 07), Springer, and a foreign member of its Norwegian counterpart 2007, pp. 400–415. (NTKV). Schneider is a Fellow of AAAS, ACM, and 14. J. Lapon et al., “Analysis of Revocation Strategies for IEEE. Contact him at [email protected]. Anonymous Idemix Credentials,” Proc. 12th Int’l Conf. Communications and Multimedia Security, Springer-Verlag, Selected CS articles and columns are also available for free 2011, pp. 3–17. at http://ComputingNow.computer.org. IEEE_half_horizontal_Q6:Layout 1 4/21/11 4:21 PM Page 1

Experimenting with your hiring process? Finding the best computing job or hire shouldn’t be left to chance. IEEE Computer Society Jobs is your ideal recruitment resource, targeting over 85,000 expert researchers and qualified top-level managers in software engineering, robotics, programming, artificial intelligence, networking and communications, consulting, modeling, data structures, and other computer science-related fields worldwide. Whether you’re looking to hire or be hired, IEEE Computer Society Jobs provides real results by matching hundreds of relevant jobs with this hard-to-reach audience each month, in Computer magazine and/or online-only!

http://www.computer.org/jobs

The IEEE Computer Society is a partner in the AIP Career Network, a collection of online job sites for scientists, engineers, and computing professionals. Other partners include Physics Today, the American Association of Physicists in Medicine (AAPM), American Association of Physics Teachers (AAPT), American Physical Society (APS), AVS Science and Technology, and the Society of Physics Students (SPS) and Sigma Pi Sigma.

48 IEEE Security & Privacy September/October 2013