Economics of Identity Management Systems - Towards an Economically Adaptive User-Centric IdMS. Mohammed H. Almeshekah

Transcription

1 Economics of Identity Management Systems - Towards an Economically Adaptive User-Centric IdMS Mohammed H. Almeshekah Supervisor: Dr. Geraint Price Submitted as part of the requirements for the award of the MSc in Information Security at Royal Holloway, University of London 2010 I declare that this assignment is all my own work and that I have acknowledged all quotations from the published or unpublished works of other people. I declare that I have also read the statements on plagiarism in Section 1 of the Regulations Governing Examination and Assessment Offences and in accordance with it I submit this project report as my own work. Signature: Date:

2 To my wife, Asma, and my son, Abdullah ii

3 Acknowledgments I would like to express my heartfelt thanks to my supervisor, Dr. Geraint Price, for his time, efforts and invaluable comments throughout my work in this dissertation. Special gratitude to Professor Kenny Paterson for his invaluable advice and help during my Masters program, and to my dear friend Dr. Waleed Alrodhan for his endless endorsement and support. I am also extremely grateful for my beloved wife, Asma, for her continuing encouragement and sacrifices, I would not have finished this dissertation without her by my side. I am also grateful for my father, Dr. Hamoud, and my mother, Aljowharah, for their unwavering support and unforgettable endorsement. Finally, I would like to thank all the Information Security Group members; they provided me with one of the best academic environments in the world during my Masters. iii

4 Abstract The ubiquity of identity management systems in people's online activities has lead to a significant growth in the number of identity management solutions. These systems have been designed to help users manage their digital identities and, at the same time, give online service providers the ability to control users' access to their services. Because these systems handle users' personal information, privacy and security issues are of great importance. However, since service providers usually favour systems that lead to maximize their profits more than systems with advanced security and privacy features, studying the economics of identity managements systems is an important subject. In order to drive service providers to adopt more secure and privacy enhanced identity management systems, these systems should appeal to them, not only for their technological advancements, but more importantly, for their economic value. In this dissertation, we aim to provide new and profound insights into the economics of identity management systems by applying several well-known economic theories such as network externalities and information asymmetry. In addition, we examine the economics of some widely deployed identity management systems such as OpenID, Microsoft Passport and Microsoft CardSpace. Moreover, we propose a novel scheme for making the current user-centric identity management systems more economically incentivized. We do this by integrating the concept of web metering, which is widely used in the Internet advertisement market, into the user-centric identity management systems. We also provide a proof of concept of this integration within the CardSpace's framework. iv

5 Contents 1. Introduction Motivation Goals Structure of the Dissertation Identity Management Digital Identities and Related Concepts Identity Management and Privacy Identity Management Models Isolated Identity Management System Federated Identity Management System User-Centric Identity Management System Other Models Summary Microsoft CardSpace The Laws of Identity CardSpace Framework CardSpace Limitations v

6 Shared Limitations CardSpace Specific Limitations Summary Economics of Information Security and Identity Management Information Security Economics Economics of Identity Management Previous Work New insights Web Metering Web Metering Model and Requirement Web Metering Schemes Web Metering using User-Centric IdMSs Summary Economically Adaptive User-Centric Identity Management System User-Centric IdMSs Built-in Incentives Integrating the Web Metering Scheme with CardSpace Analysis of the Integration Summary Conclusion Summary Future Work Bibliography vi

7 List of Figures Figure 1: Relationship between Entities, Identities, Attributes and Identifiers... 6 Figure 2: Isolated Identity Management System Figure 3: Federated Identity Management System Figure 4: User-Centric Identity Management System Figure 5: CardSpace Parties Interaction Figure 6: Identity Selector Prompting the User to Select an InfoCard Figure 7: Messages Flow in CardSpace Figure 8: Highly Assured Relaying Party Digital Certificate Figure 9: Web Metering Scheme Using User-Centric IdMS Figure 10: XML Schema for the Metering Token Figure 11: RSTR Message Including the Metering Token vii

8 Glossary CA CIFAS DNS EMEA IAB ID ID-FF IdM IdMS IdP IdS ID-SIS ID-WSF IEEE IFSC InfoCard IP Certification Authority Credit Industry Fraud Avoidance System Domain Name System Europe, the Middle East and Africa The Interactive Advertising Bureau Identity Identity Federation Framework Identity Management Identity Management System Identity Provider Identity Selector Identity Service Infrastructure Framework Identity Web Services Framework Institute of Electrical and Electronics Engineers Identity Fraud Steering Committees Information Card Internet Protocol viii

9 NGN OASIS OECD P3P PII PoP PPID PRIME PwC RFC RP RSA RST RSTR SAML SHA SOAP SP SR SSO STS UK URI Next Generation Network Organization for the Advancement of Structured Information Standards Organisation for Economic Co-operation and Development Platform for Privacy Preferences Personal Identifiable Information Proof of Possession Private Personal Identifier Privacy and Identity Management for Europe PricewaterhouseCoopers Request For Comments Relaying Party Rivest, Shamir, & Adleman (Public Key Encryption Algorithm) Request Security Token Request Security Token Response Security Assertion Markup Language Secure Hash Algorithm Simple Object Access Protocol Service Provider Service Requester Single Sign-On Security Token Service United Kingdom Uniform Resource Identifier ix

10 W3C WS XML World Wide Web Consortium Web Services Extensible Markup Language x

11 Chapter 1: Introduction Chapter 1 1. Introduction In the last two decades, the Internet has grown exponentially and the number of online services has risen dramatically, ranging from e-government and e-banking services to social networking and file sharing. Similar to the brick and mortar world, online service providers (henceforth denoted as SPs) need a way to manage the access to their services by which only authorised users are allowed. In traditional settings, each user needs to register with every SP they are interacting with, where they usually have to create at least one username/password pair as their log-in credentials for each SP. On the other hand, each SP has to maintain a system to authenticate/authorize their users and to manage the users' credentials effectively and securely. As the number of SPs and users grows rapidly and the sensitivity and criticality of these services increases, the management of these identities is becoming a serious challenge for both users and the SPs Motivation The number of identity theft incidents have been exponentially increasing over the past few years. In July 2010, the UK's fraud prevention service CIFAS (Credit Industry Fraud Avoidance System) 1 reported that there had been a 14% jump in identity fraud incidents within its 265 member organizations during the first half of 2010, compared to the same 1 1

12 Chapter 1: Introduction period in This is an alarming fact, as in 2007 the Identity Fraud Steering Committees (IFSC), which was set by the UK's Home Office, estimated that the cost of identity fraud to the UK economy was 1.2 billion 2. As a result, to mitigate these problems, many identity management systems (henceforth denoted as IdMS) have been proposed, and a number of initiatives have been introduced to help the users and the SPs in managing the users' digital identities. For example, Liberty Alliance Project, Microsoft Passport, Microsoft CardSpace, OpenID, Shibboleth and many others are all systems developed to overcome the challenges of managing the users digital identities. Initiatives such as PRIME 3 (Privacy and Identity Management for Europe) and the Kantara Initiative 4 have been formed to discuss and develop the specifications for a secure and trustworthy identity management system. Finally, the market research company RNCOS 5 estimated in their report [73] that the global Identity and Access Management market worth approximately US$3.8 billion by the end of In addition, they projected an increase in this figure at a compound annual growth rate of almost 13% between 2010 and They have also anticipated that the EMEA (Europe, the Middle East and Africa) region will dominate the market with over 40% of share closely followed by the Americas and the Asia-Pacific region Goals Despite the fact that many of the proposed identity management systems have been successfully engineered, none of these systems have received major take-up or have been widely deployed. On the other hand, we see other IdMS with well-known design flaws receiving an increasing worldwide adoption. We believe that this lack of deployment of many IdMSs is partly due to the fact that these systems did not get the economics right. In

13 Chapter 1: Introduction other words, in these systems the online SPs do not have strong economic incentives driving them to adopt these well-engineered IdMSs and replacing their existing systems. In this dissertation we aim to provide new insights to the economics of identity management systems discussing some of the reasons behind the success and failures of many well-known IdMSs such as Microsoft Passport and OpenID. Furthermore, we interpret some of the phenomena that affects the development and adaptation of IdMSs by using well-known economic theories such as network externalities and information asymmetry. Moreover, in the dissertation we propose a novel way that would potentially facilitate the adoption of user-centric IdMS by integrating the concept of web metering within current user-centric IdMSs. We also highlight some of the built-in incentives that already exist in many user-centric IdMSs that would bring additional benefits to both SPs and users. By enhancing the economics of user-centric systems we believe that this would be the first step in driving service providers around the world to adopt more secure and privacy enhanced identity management system Structure of the Dissertation The remainder of the dissertation is structured as follows. In the second chapter, the concept of digital identity, identity management and identity privacy is investigated. Moreover, an overview will be provided of the major conceptual models of identity management systems. Next, in the third chapter, Microsoft CardSpace identity management system is discussed as it will be used as a case study with regard to which the proposed economic incentives will be integrated. The chapter will start by going through the Laws of Identity, which have been developed by Microsoft to form the basis of CardSpace. Then, CardSpace's framework will be illustrated, and its security and privacy features will be examined. Finally, the chapter will conclude by discussing the limitations of the CardSpace 3

14 Chapter 1: Introduction framework, highlighting which of these limitations are special to Microsoft and which are shared with other IdMSs. The fourth chapter investigates the economics of information security and identity management. It starts by going through the most commonly discussed economic theories in the information security literature. After that we examine and analyse some of the previous attempts to address the economics of identity management systems. Moreover, a major part of the chapter focuses on providing new insights to the economics of identity management systems expressing that using well-known economic phenomena such as network externalities and information asymmetry. After that, the concept of web metering will be discussed as it will be proposed as one of the strong economic incentive that can enhance the adaptability of the current IdMSs. Finally we conclude the chapter by proposing a novel scheme of integrating the feature of web metering into the current usercentric IdMSs. In the fifth chapter, we will provide a proof of concept of our novel scheme integrating it into one of the major user-centric IdMSs; namely CardSpace. Before that, we give a general overview of the built-in economic incentives in the current user-centric IdMSs referring to real examples in Microsoft CardSpace. At the end of the chapter, we will provide an analysis of the proposed integration highlighting some of the limitations of our work. Finally, the sixth chapter will conclude the dissertation by summarising our contribution and pointing out to some of the potential areas of future work. 4

15 Chapter 2: Identity Management Chapter 2 2. Identity Management Identities are an essential human need which defines who we are and how we are perceived. According to the OECD paper [68], identities are contextual and subjective; a person can have multiple identities in different contexts and these identities are preserved in different ways. In this chapter we will discuss the concept of identities and how they can be managed in the digital world. The chapter is divided into four main sections. The first section starts by illustrating what constitutes a digital identity, and how it relates to the user's real world identity. In addition, the section investigates other identity-related concepts such as entities, identifiers and pseudonyms. The second section examines the notion of identity management and how can we manage identities in the digital realm. Moreover, the section investigates the privacy issues related to managing the users' digital identities. In the third section we give an overview to the three major conceptual models of identity management systems; namely isolated, federated and user-centric IdMSs. In addition, we refer to other models that are discussed in the literature such as the "silo" systems. Finally, we conclude by summarising the main points discussed in the chapter Digital Identities and Related Concepts The recent ITU-T X.1250 standard [36] defines identity as "The representation of an entity in the form of one or more information elements which allow the entity(s) to be sufficiently 5

16 Chapter 2: Identity Management distinguished within context". In this definition it can be seen that there are four related concepts: entity, identity, identifier and information elements or attributes: Entity. An entity can be defined as anything that has a distinct existence within a given domain [36]. This can include a person, an organization, a device or anything that has a separate existence. Any entity can be represented by one or more identities within a specific domain. Attribute. An attribute is defined as a characteristic that is used to identify an entity within a context. A given identity may consist of one or more attribute(s). Identifier. If an attribute is unique within a given domain, it is called an identifier and any identity can consist of one or more identifiers. To clarify the relationship between these notions, we will consider the following example. A person called Alice is an entity who can have two identities within a company; she can be both an employee and a customer buying the company's products. Alice has several attributes such as her name, social security number, date of birth, etc. Either of Alice's identities can include all or part of her attributes. The social security number attribute is considered to be an identifier as it is unique within the company's domain. Entities Identities Attributes & Identifiers Figure 1: Relationship between Entities, Identities, Attributes and Identifiers 6

17 Chapter 2: Identity Management An illustration of the relationship between entities, identities, attributes and identifiers is given in Figure 1, which is based on a figure taken from [40]. It shows that an entity, which has a distinct existence, can be mapped to one or more identities. In addition, an identity can consist of one or more identifiers or attributes. Another concept related to identities are pseudonyms. A pseudonym can be thought of as a special kind of identifier that cannot be linked back to an entity, or can be linked only by a limited number of parties [36]. Different user's pseudonyms should be unlinkable, which means that a third party cannot tell whether or not any two pseudonyms are related to the same identity [71]. This is an essential concept in identity management that allows a user to have a single identity that can be shared with multiple parties, without needing to reveal the user's unique identifiers to these parties. Instead, the user will have a different pseudonym with each party s/he is interacting with, which refers to the user's unique identifier, and these pseudonyms should be unlinkable. This can enhance the user's privacy. We will discuss the concept of unique identifiers further in the next section when we discuss privacy issues in identity management. In addition, the concept of using pseudonyms in identity management systems is investigated further in Section 2.3 when we discuss federated IdMSs Identity Management and Privacy The ITU-T X.1250 standard defines identity management in [36] as "A set of functions and capabilities (e.g. administration, management and maintenance, discovery, communication exchanges, correlation and binding, policy enforcement, authentication and assertions) used for: assurance of identity information (e.g., identifiers, credentials, attributes); assurance of the identity of an entity (e.g., users/subscribers, groups, user devices, organizations, network and service providers, network elements and objects, and virtual objects); and 7

18 Chapter 2: Identity Management supporting business and security applications." In any IdMS there are usually three main parties interacting with each other [36]: 1. Identity Provider (IdP); who creates the user's identity and assures its truthfulness. 2. Service Provider (SP); who needs to identify the user in order to be able to provide him/her with the requested services. 3. User; who requests the services from the SP. From the definition, it can seen that any IdMS should give the IdP the capability to administrate and manage the users' attributes/identifiers, and provide the SP with an assurance of the user's identity information. Also, the IdP must be trusted by both the SPs and the users of the system, to securely manage and ensure the trustworthiness of the users' identity information. In addition, the IdMS should give the SP the ability to identify its users and provide them with the requested services. Finally, within the IdMS users should be able to register and authenticate him/herself to an IdP in order to gain access to the SP's requested service. It is vital that IdMS needs to create, manage, process and transport users' identifiable information throughout the system, in order to support different functionalities such as registration, authentication and authorization. However, this has to be done with care as it is directly related to handling the users' privacy-sensitive information. Therefore, there is a need to require all IdMSs to adhere to common privacy guidelines to assure the protection of the user's privacy. In this dissertation we will use the OECD published guidelines on the protection of privacy and the transborder flow of personal data [69], as the common privacy guidelines to be adhered to by all IdMSs. These guidelines were developed in 1980 by a group of government experts from 25 countries from around the world under the chairmanship of the Chairman of the Australian Law Reform Commission. In addition, many privacy legislations around the world have been derived from these guidelines as they have gained wide acceptance in many countries [69]. These guidelines are as listed below: 8

19 Chapter 2: Identity Management 1. "Collection Limitation Principle: There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject. 2. Data Quality Principle: Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date. 3. Purpose Specification Principle: The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfilment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose. 4. Use Limitation Principle: Personal data should not be disclosed, made available or otherwise used for purposes other than those specified in accordance with the third principle except with the consent of the data subject or by the authority of law. 5. Security Safeguards Principle: Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorised access, destruction, use, modification or disclosure of data. 6. Openness Principle: There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller, who is a party who is competent to decide about the contents and use of personal data. 7. Individual Participation Principle: An individual should have the right: a. To obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to her; 9

20 Chapter 2: Identity Management b. To have communicated to her, data relating to her within a reasonable time; at a charge, if any, that is not excessive; in a reasonable manner; and in a form that is readily intelligible to her; c. To be given reasons if a request made under subparagraphs (a) and (b) is denied, and to be able to challenge such denial; and d. To challenge data relating to her and, if the challenge is successful to have the data erased, rectified, completed or amended. 8. Accountability Principle: A data controller should be accountable for complying with measures which give effect to the principles stated above." The World Wide Web Consortium (W3C) Platform for Privacy Preferences (P3P) working group has been working on standard specifications that allow different SPs to express their privacy practices in a way that can be processed and interpreted automatically by users' agents [80]. They have published a standard format [80], where they identify 16 categories of the users' sensitive information that can be collected by any website they visit. These categories are: 1. Physical Contact Information. 2. Online Contact Information. 3. Unique Identifiers. 4. Purchase Information. 5. Financial Information. 6. Computer Information; e.g. IP address, browser type, operation system, etc. 7. Navigation and Click-Stream Data; e.g. visited web pages, and how long the user stayed there. 8. Interactive Data; such as search engine queries and logs. 9. Demographic and Socioeconomic Data; e.g. gender, age, income, etc. 10. Content; e.g. the text of or chat room communications. 11. State Management Mechanisms; e.g. HTTP cookies. 12. Political Information; e.g. membership in, or affiliation to, religious organizations, trade unions, professional associations, political parties, etc. 10

21 Chapter 2: Identity Management 13. Health Information. 14. Preference Data. 15. Location Data. 16. Government-Issued Identifiers. Since we are adhering to the OECD privacy guidelines in this dissertation, the collection of any information from the previous 16 categories has to be done in accordance to these principles. For example, from the first OECD principle we can say that any IdMS should minimize the amount of information collected about a specific user from the previous P3P list. In addition, it advisable not to link this data, when collected, directly with the user's identity, but to use a pseudonym instead. This will minimize the harm of any privacy violation when there is a data leak, as this sensitive data cannot be linked back to the user's identity Identity Management Models Based on the nature of the relationships between the three IdMS parties we specified in section 2.2, namely, the IdP, SP and user, the IdMSs can be classified into three conceptual models: Isolated Identity Management Systems. Federated Identity Management Systems. User-Centric Identity Management Systems. During the early days of the Internet evolution, there were very few online service providers which provided services to general users. Each of these SPs had built their own systems to authenticate/authorize their users and manage their identities. Nevertheless, the number of SPs has grown significantly, and the process of managing the users' identities has become an increasingly challenging task for both SPs and for users [40] [72]. As a result, many new models of identity management have been proposed to ease the process of managing these identities for both users and SPs. One of the major proposals was 11

22 Chapter 2: Identity Management federated IdMSs [72] which are based on the idea of federating users' identities across domains and different IdPs and SPs. This federation gives the user the ability to sign once and then access many services seamlessly, which is referred to as Single Sign-On (SSO) [70]. Federated systems also helps to avoid many redundant processes undertaken by different SPs as part of managing the user's identities, such as storing and processing the users' authentication credentials [72]. However, the model of federated IdMS is a model which focuses on the SP, and by which the user has less control over his/her identities [40]. For this reason, in the last few years a new paradigm of IdMSs has been proposed, placing the user in control of his/her digital identities. This model is called a user-centric IdMS [25]. In the remainder of this section we discuss the basic features of each of these three models in detail Isolated Identity Management System This is the traditional and most common model of IdMSs. Basically, there are only two parties in this model; a service provider, acting as an SP and an IdP at the same time, and a user. Every user will have a one-to-one relationship with every SP they are interacting with. Therefore, every user has to have a separate unique identifier and secure credential with every SP they are using. The most common form of credential is a username and a password, where every user must create a unique username and a secret password with each SP. Figure 2, which is based on a figure in [40], demonstrates the basic component of any isolated IdMS. The user has a separate identifier and credentials for each SP. In addition, there is no cooperation between different SPs for the purpose of user identification. 12

23 Chapter 2: Identity Management SP & IdP SP/IdP 1 SP/IdP 2 SP/IdP Identifier Credentials User Figure 2: Isolated Identity Management System A report by Adams and Sasse showed that the average user can usually manage four to five unrelated passwords effectively, and this number will drop if these passwords are used less frequently [3]. Due to the rapid growth in the number of online services, many users will have far more than five passwords and they will tend to repeat these passwords within different SPs 6, write them down or use easy passwords to ease the difficulty of remembering them. If the user repeats his/her password within different SPs, there is a serious potential risk that any of these SP can easily impersonate him/her to other SPs by simply using this repeated password. Furthermore, if a malicious SP can convince the user to register with it, it can then use the user's repeated password that has been used to create this account, to impersonate him/her to other SPs. On the other hand, when the user writes the password down or uses an easy password, this password can be easily stolen or cracked by the attacker via guessing, dictionary attack or even brute force attack. The isolated model is designed to be solely SP focused [40] and requires the user to do all the work. It is a simple model that is easily deployed by SPs. However, it is getting more and more challenging for the users. Nevertheless, this model can also cost the SPs in the long term, especially in relation to the problem of forgotten or repeated passwords. In the former case, it will cause the system to run the process of recovering the user's password, which could be complicated, especially in sensitive applications such as e-banking. In the 6 There are even tools to synchronize the user's passwords within different SPs such as passwordmanager.hitachi-id.com/ 13

24 Chapter 2: Identity Management latter case, the SP may fall into the trap of authenticating an imposter who has managed to steal the user's password, which they commonly repeat across many websites. Overall, it is clear that the isolated IdMS model has many problems, and the process of managing users' identities is getting more challenging for both SPs and users. However, we still see these systems being widely deployed all around the Internet, while only a few organizations are starting to change their legacy systems. In this dissertation we are trying to address one facet of this problem; namely by discussing the economic benefits the SPs can obtain by adopting the new IdMS models, and even more on how to make these models more economically incentivized and more attractive to the online service providers Federated Identity Management System Federated IdMS models have been proposed to address some of the limitations of the isolated model discussed in the previous section. Projects such as Liberty Alliance 7 and Shibboleth 8 have developed standards and specifications on how to implement a federated IdMS. Liberty introduced the notion of Circle of Trust in federated systems which can be defined as a collaboration between a set of identity providers and service providers having a business and trust relationship with each other [46]. A typical Circle of Trust will consist of one IdP and a number of SPs who trust this IdP. The process of identity federation within a Circle of Trust should link all the user's SP-specific identities with his/her IdPspecific identity using pseudonyms [46]. Every user should have one identity with the IdP and at least one identity with each SP with which they are interacting

25 Chapter 2: Identity Management Circle of Trust SP & IdP Identifier 1 IdP Federation 2 3 Federation SP1 SP2 Credentials User & 2 Authentication 1 2 Singed Assertion Figure 3: Federated Identity Management System Figure 3 demonstrates the basic features and components of a typical federated IdMS. There is one Circle of Trust which consists of one IdP and two SPs; namely SP1 and SP2. The user has federated his/her IdP-specific identity with his/her identities at SP1 and SP2. Whenever the user accesses an SP within this Circle of Trust, s/he will be redirected to his/her IdP where s/he should authenticate him/herself. After a successful authentication, the IdP will provide the user with a signed authentication assertion that should be given to the SP where it should be validated. Finally, the user must prove his/her possession of this assertion to the SP by using one of the proof of possession (PoP) methods defined in the token, after which an access will be granted [61]. In the above figure it is assumed that the process of identity federation has already taken place. This process, identity federation, should only take place with the user's full consent during all its steps at both the IdPs and the SPs. In addition, when the user's identities are federated, the SPs and IdPs must not exchange the real user's identities. Instead, pseudonyms will be used for this purpose and these pseudonyms must be unlinkable by any third party or between different SPs [70]. Federated IdMSs bring additional features to both SPs and the users. When a user uses a federated IdMS s/he has the benefit of enjoying the Single Sign-On (SSO) feature. In other words, once the user authenticates him/herself to an IdP, s/he does not have to execute the authentication process again when s/he accesses another SP within the circle of trust in the 15

26 Chapter 2: Identity Management current working session. Furthermore, federated IdMSs avoid the need to have a global identifier for every user. Instead, the system uses a pseudonym to refer to the user between different IdPs and SPs. This privacy feature adheres to the OECD first principle, discussed in section 2.2, which recommends limiting the collection of users' private data. Since the unique identifier is one of the users' private information, as specified in the P3P list discussed in section 2.2, the federated systems avoid using such sensitive information. This issue of using unique identifiers will be discussed further in chapter four when discussing the economics of identity management. Nevertheless, the design of federated systems is more SP-focused rather than user-focused [40]. In other words, every user still has to manage his/her credentials manually, while the system automates this process on the SP side. In addition, in reality, there will be more than one circle of trust and the user will have to maintain different credentials and identities manually with each circle of trust. Furthermore, within a circle of trust, different SPs may have different security and assurance requirements, and a single type of authentication mechanism or identity information will not satisfy them all. For these reasons, a new paradigm of IdMS has emerged, aiming to empower users and to give them control when it comes to managing their digital identities; this is called user-centric IdMS. In addition, these systems aim to facilitate the diversity of SPs' requirements within a domain by allowing them to express their security policies and assurance requirements in a standard way that can be easily understood and fulfilled by the user's agents. Finally, it is worth noting that the federated IdMSs are based on a wide range different standards and specifications such as OASIS Security Assertion Markup Language (SAML) [61], Identity Federation Framework (ID-FF) [46], Identity Web Services Framework (ID- WSF) [47] and Identity Service Infrastructure Framework (ID-SIS). The last three specifications were all developed by the Liberty Alliance Project team. The SAML standard is used to specify the structure of the signed authentication assertion which is provided by the IdP after a successful user authentication [61]. 16

27 Chapter 2: Identity Management User-Centric Identity Management System. A new emerging paradigm of IdMSs is the user-centric IdMS, which is defined by the ITU-T X.1250 standards as "An IdM system that can provide the (IdM) user with the ability to control and enforce various privacy and security policies governing the exchange of identity information, including PII, between entities" [36]. The Personal Identifiable Information (or PII) is any information that can be used to identify the user by itself, or when combined with other information [38]. As an example, PII would include all 16 P3P categories discussed in section 2.2. SP & IdP Identity IdP 1 2 SP1 SP2 Credentials User 1 & 2 Authentication 1 2 Security Token User Agent User Claims Figure 4: User-Centric Identity Management System The exact user-centric IdMS model is still unclear in the identity management research community and in the literature [18]. In Figure 4 we illustrate the basic model of a usercentric IdMS that is embraced by most of the well-know user-centric IdMS such as CardSpace [53] and Higgins Open Source Identity Framework 9. In this model it can be seen that the user-centric systems add a fourth party to the general identity management model where there are three parties as defined in section 2.2. This party is known as the User Agent. This agent is a trusted application that resides on the user's machine and manages his/her digital identities. The agent does not have to be a desktop application. It can be a dedicated hardware or even a mobile application [40]

28 Chapter 2: Identity Management When the user requests a service from an SP in the user-centric model, that is shown in Figure 4, the SP will reply by asking the user to authenticate him/herself by supplying an appropriate security token asserting certain claims. A claim is defined in the ITU-T X.1250 standard as "An assertion made by a claimant of the value or values of one or more identity attributes of a digital subject, typically an assertion which is disputed or in doubt" [36]. These SP's required claims and other requirements will be sent to the user's agent, usually as a security policy. The user agent, in turn, will give the user the ability to choose from the list of IdPs who that can assert these claims and match the SP's requirements. Next, the user agent will initiate a connection with the selected IdP, asking it to generate the requested authentication token. The IdP in turn will require the user to authenticate him/herself before generating such a token. This authentication can be done by using any authentication mechanism supported by the IdP. For example, the user can authenticate using a Kerberos ticket [60], a SAML assertion [61], an X.509 certificate [37], a one-time password [33] or even a username/password. After a successful authentication, the IdP will generate the required token and send it back to the user agent, which will forward it to the SP in order to gain access. Finally, the user must prove his/her rightful possession of the supplied token before gaining access. This PoP can be done using different mechanisms, as we will discuss in section Other Models We have recognized that there is another model that is widely discussed in the literature called the "Silo" identity management system [72]. Silo IdMSs are systems that are used to manage a closed group of users' identities in a closed domain, where there can be more than one service provider the user can access. The management of these identities is controlled within the domain by one single entity, and these identities cannot be used to access any services outside the scope of the domain. The Silo systems model is quite similar to the isolated systems we have discussed above. However, using the "Silo" terminology can sometimes be ambiguous, as it can include 18

29 Chapter 2: Identity Management federated IdMSs that have only one IdP and are applied within a closed domain where the users can access different SPs only within this domain. Therefore, we have based our taxonomy on the terminology provided by Jøsang and Pope in [40]. In addition, there are many proposals in the identity management literature discussing different taxonomies of identity management models, for example, see [18], [40] and [70]. However, in this dissertation we do not aim to provide a comprehensive taxonomy of IdMS models. Instead, we aim to provide only an overview of the major identity management models in that we focus on user-centric IdMSs Summary After examining the three major IdMS models, it is clear that there are some similarities between the federated systems and the user-centric systems. However, we recognize that there are also some differences between these two models. In a federated IdMS, the user must have a separate account and identities with the IdP and each SP that s/he is interacting with, and these identities will be federated. On the other hand, user-centric systems do not require the user to have a separate account with each SP. Instead, the user can authenticate him/herself to an SP by only providing an assertion of the truth of her claims from an IdP. For example, an SP might require the user to be above a certain age to view a specific film. A new user can place a request to view this film and supply an assertion from an IdP, who is trusted by this SP, asserting the truth of her age without requiring the user to register with this SP and create a new account. This feature will rapidly increase the usability and flexibility of the IdMS. Moreover, another major difference between federated and user-centric IdMSs is the information that is carried in the security token generated by the IdP. In federated systems, the security token is a token that provides an authentication statement stating that the user has been successfully authenticated. On the other hand, in user-centric IdMSs, the security token will contain the asserted claims that the SP has requested. This information is privacy sensitive information that contains some of the user's PII. 19

30 Chapter 2: Identity Management In this chapter we have defined the different concept associated with digital identity management such as identities, entities and pseudonyms. We have also discussed the issue of users' privacy in identity management systems and how can it be preserved. In addition, we have concluded the chapter by providing a general overview of the major identity management models; namely isolated, federated and user-centric IdMSs. In the next chapter we will discuss Microsoft CardSpace IdMS as one of the most wellknown examples of user-centric IdMS. In addition, the chapter discusses the major limitations in CardSpace from a security and privacy perspective. 20

31 Chapter 3: Microsoft CardSpace Chapter 3 3. Microsoft CardSpace Back in 1999, Microsoft introduced its identity management system.net Passport as the world's global identity management system [54]. In early 2000, Passport had been widely adopted by many well-know organizations such as ebay, PayPal and VISA. Nevertheless, many security and privacy problems emerged in Passport, and these organizations started withdrawing from the Passport scheme. Later, in 2005, Microsoft announced its failure in establishing a sound IdMS and published two white papers discussing the reasons of this unsuccessful experience [23] [55]. This project influenced Microsoft's view of digital identity management leading them to publish seven Laws of Identity that should be obeyed when developing an IdMS [23]. In addition, Microsoft announced it new system, CardSpace, which they claim is based on these Laws of Identity [24]. In this chapter we will discuss Microsoft's contribution to the area of identity management, specifically their successor IdMS CardSpace. This chapter is divided into four sections. It starts by examining the Laws of Identity, discussing their meaning and acceptance in the research community. Then, the CardSpace framework will be discussed, highlighting its new approach to represent users' digital identities and the concept of InfoCards. In addition, an overview will be provided to the system's protocol and its main security and privacy features. The third section investigates some of the limitations of CardSpace, where we highlight which of these limitation is special to CardSpace and which are shared 21

32 Chapter 3: Microsoft CardSpace with other IdMSs. Finally, we conclude by summarizing the main points discussed in this chapter The Laws of Identity Kim Cameron, the chief architect of Identity at Microsoft, ran a wide-ranging discussion in his blog 10 with experts around the world on the properties that cause an IdMS to succeed or fail. In 2005, he expressed this new vision of digital identity management, which is embraced by Microsoft, in the following seven Laws of Identity [23]. First Law: User Control and Consent. In order to have a good IdMS, the users must be in control of their digital identities. In addition, the system must not reveal any of the users' personal identifying information (PII) without their explicit permission. Second Law: Minimal Disclosure for a Constraint Use. This law points out that the system must minimize the disclosure of users PII to only what is mandatory to complete the current process; that is, to minimize the amount of information that any party has about the system's users. Third Law: Justifiable parties. This law indicates that the IdMS must give its users PII only to trusted and justifiable third parties with the users' consent and permission, as mandated by the first law. Fourth Law: Directed Identity. Any IdMS should support two different kinds of identity; unidirectional (one-to-one) identities and omni-directional (one-to-many) identities. The former type is used in the private interactions between any two parties within a system. The latter should be used only as public identifier to enable the discovery of any entity. Fifth Law: Pluralism of Operators and Technologies. This law emphasizes the fact that a successful IdMS must support the different technologies that is be used by the system's different parties. The importance of this law can be seen when dealing with identities in different contexts, where each context has specific requirements

33 Chapter 3: Microsoft CardSpace Sixth Law: Human Integration. Users must be one of the essential components of any successful IdMS where s/he should be integrated in a simple and clear way. Seventh Law: Consistent Experience across Contexts. A good IdMS must integrate the user by offering a consistent user experience regardless of the application context. This should be done by separating the user experience from the underlying contexts, and unifying this experience in one user-friendly way. It is clear that these laws support the concept of user-centricity in IdMSs, discussed in section The first and the last two laws are directly related to the user in that they give him/her control, facilitate his/her integration and mandate that the focus should be on increasing the systems' usability using a consistent user-friendly experience. Furthermore, the user is involved in the four other laws in an indirect way. For example, the exposure mentioned in the second law should not be allowed without the user's consent. Despite the novelty of these laws, especially in the context of identity management, some of them have been discussed before in different contexts. For example, it can be seen that there are some similarities between the OECD principles discussed in section 2.2 and Laws of Identity. For instance, the first law, user control and consent, is very similar to the seventh OECD principle, individual participation principle. Moreover, the second and third laws are almost a rephrasing of the combination of the first four OECD principles. However, these laws have gained acceptance from many experts around the world, and they have been extensively refined through the blogosphere discussion. Although these laws have earned a good deal of respect within the IdMS research community, some of them have been challenged. Rachna and Lisa have argued in their paper [29], that giving the users greater control will not necessary minimize the disclosure of their PII [29]. They claimed that presenting the users with more decisions and choices tends to overwhelm them where they become habituated to these warnings and therefore ignore them. This may lead to a system that maximises the disclosure rather than minimizing it by giving the users more control. Since users usually use the simplest and 23

34 Chapter 3: Microsoft CardSpace most convenient way to reach their goals, this can be easily done by allowing everything [29]. This previous problem, which is basically relying on the users to make decisions, is one of the limitations of CardSpace, along with other IdMSs. For example, in any IdMS it is the user's responsibility of the user to judge the trustworthiness of the service providers before authenticating to them, while the typical user is usually not qualified to make such a decision. This limitation will be discussed further in section 3.3 where there are some proposals which aim to address this problem [8] CardSpace Framework CardSpace is Microsoft's successor IdMS which was developed after the failure of Passport. Microsoft claims that CardSpace is based on the Laws of Identity discussed in the previous section [24]. CardSpace is classified as a user-centric IdMS which tries to mimic the real world management of identities by introducing the concept of virtual digital identity cards, referred to as InfoCards [23]. In this section an overview will be provided of the CardSpace's framework, highlighting its novel approach in placing the user to control his/her digital identities. In CardSpace, Microsoft have taken a slightly different approach in defining the system's parties as follows: 1. The User, who is the real world existing entity that interacts with the system. 2. The User Agent, which consists of two different components: a. The Identity Selector (IdS), which is a special trusted application that gives the users the ability to manage their InfoCards. b. The Service Requester (SR), which is a user application that provides an interface to the SP services, e.g. a CardSpace-enabled web browser. 24

35 Chapter 3: Microsoft CardSpace 3. The Identity Provider (IdP), the IdP has two basic roles - creating the user's InfoCard that represent his/her identity with this IdP, and authenticating the user upon giving him/her the authentication assertion required to gain access to an RP. 4. The Relaying Party (RP): this is essentially the service provider (SP) that provides an accessible service to the user. Since we are discussing Microsoft's system, we will denote the service provider as an RP rather than an SP in this chapter. CardSpace defines digital identities as "A set of claims made by one digital subject about itself or another digital subject", where they define the claim is "an assertion of the truth of something, typically one which is disputed or in doubt" [23]. These claims, in Microsoft's definition will include both the user's identifiers and attributes discussed in section 2.1. In CardSpace, the user's identities will be represented by an InfoCard stored on the his/her machine. An InfoCard is an XML-based document that can be stored in any storage device where it consists of relatively non-sensitive data. There are two types of InfoCards; managed cards and self-issued cards. The managed InfoCards can be issued by any IdP the user registers with. These InfoCards have to be signed by the IdP and then stored on the user's machine. The self-issued InfoCards can be issued by the local IdP, which is part of the IdS trusted program, and also stored on the user's machine. A typical InfoCard should contain the following information in an XML format [53]: <InformationCardReference>: which includes an IdP-specific reference to the card and the card version. <CardName>: stores the card's name. <CardImage>: stores the card's image that get shown to the user. <Issuer>: can be expressed as a URI [17] pointing to the IdP name. <TimeIssued>: saves the time and date when the card has been issued. <TimeExpires>: includes the time and date where the card expires. 25

36 (7) (9) Chapter 3: Microsoft CardSpace <TokenServiceList>: offers a list of one or more URIs pointing to the IdP Security Token Service (STS) where the IdP security policy can be retrieved from. For each URI it should specify the authentication mechanism(s) that have to be used to obtain the security token. <SupportedTokenTypeList>: a list of the supported security tokens provided by this IdP, e.g. SAML 2.0. <SupportedClaimTypeList>: a list of the claim types that an IdP can assert, e.g. given name, last name, etc. <PrivacyNotice>: points to the location of the IdP privacy policy. When a user requests a service from an RP s/he must provide an authentication assertion that satisfies the RP's security policy. The RP, in turn, will validate this assertion, and eventually an access will be granted. Figure 5 illustrates the interaction steps between CardSpace's different parties for the purpose of authenticating the user to the RP. In this figure it is assumed that the user has already obtained the InfoCards and has downloaded the RP log-in page using his/her CardSpace enabled client; namely the SR. STS STS IdP RP (5) (6) (3) IdS (1) (11) (8) (6) (4) 10 2 User (1) SR Optional step Figure 5: CardSpace Parties Interaction 26

37 Chapter 3: Microsoft CardSpace In the first step, the user clicks on the RPs log-in button requesting access to its services, via his/her SR. The RP in turn responds by sending its X.509 certificate, its security policy and some special code tags invoking the user's IdS. The RP's digital certificate is used by the user to examine the RP's identity and judge its trustworthiness. The RP's security policy will include a variety of information, and it will be retrieved and expressed using some web services protocol (WS-*) that will be discussed later in this section. In step 2, the IdS will be triggered and asked to provide a security token that matches the RP's security policy. This token can be issued either by the user's appropriate IdP or, optionally, the RP can delegate the authentication/authorization process to its Security Token Service (STS), where the IdP security token will be verified. If the RP chooses the former option, steps number 3 and 9 will not take place [53]. During step 3, the IdS will retrieve the security policy of the RP's STS to provide a security token that matches this policy. Step 3 will only take place if the RP delegates the authentication/authorization process to its STS server. Next, in step 4, the IdS will display all the user's InfoCards that match the RP's security policy, or the STS's security policy in the case of delegation. The IdS will also highlight the InfoCards that have been previously used to authenticate to this particular RP. A window, similar to the one shown in Figure 6, will prompt the user to select one of these cards and submit it. Then, the IdS will initiate a connection with the IdP who issued this card [53]. 27

38 Chapter 3: Microsoft CardSpace Figure 6: Identity Selector Prompting the User to Select an InfoCard In step 5, the IdS will retrieve the IdP's security policy by contacting the appropriate STS; and when the policy is received the user must authenticate him/herself to the IdP via his/her IdS. The current version of CardSpace, version 1.5, supports four different authentication mechanisms: namely username/passwords; Kerberos V5 service tickets [60]; X.509v3 certificates (software or hardware based tokens) [37]; and self-issued SAML tokens. After a successful authentication to the IdP, the user's IdS will request a security token from the IdP's STS asserting the claims requested by the RP's security policy; this request is sent as a Request Security Token (RST) message. The IdP will check its security policy to ascertain whether or not it is allowed to assert such claims. If so, the security token will be generated and sent back to the IdS within a Request Security Token Response (RSTR). These RST and RSTR messages will be exchanged during step 7 in the protocol. In step 8, the IdS will, optionally, prompt the user with the contents of the security token before sending it to the RP [53]. 28