Identity Management
Dr. Jean-Marc Seigneur, University of Geneva
Dr. Tewfiq El Maliki, University of Applied Sciences of Geneva
Digital identity lays the groundwork necessary to guarantee that the Internet infrastructure is strong enough to meet basic expectations for security and privacy. “Anywhere, anytime” mobile computing is becoming real; in this ambient intelligent world, the choice of identity management mechanisms will have a large impact on social, cultural, business, and political aspects of our lives. Privacy is a human need, and all of society would suffer from its demise; people have hectic lives and cannot spend all their time administering their digital identities. The choice of identity mechanisms will change the social, cultural, business, and political environment. Furthermore, identity management is also a promising topic for modern society.
Recent technological advances in user identity management have highlighted the paradigm of federated identity management and user-centric identity management as improved alternatives. The first empowers the management of identity; the second allows users to actively manage their identity information and profiles. It also allows providers to easily deal with privacy aspects regarding user expectations. This problem has been tackled with some trends and emerging solutions, as described in this chapter. First, we provide an overview of identity management from Identity 1.0 to 2.0, with emphasis on user-centric approaches. We survey how the requirements for user-centric identity management and their associated technologies have evolved, with emphasis on federated approaches and user-centricity. Second, we focus on related standards XRI and LID, issued from the Yadis project, as well as platforms, mainly ID-WSF, OpenID, CardSpace, Sxip, and Higgins. Finally, we treat identity management in the field of mobility and focus on the future of mobile identity management.
1. Introduction
Anytime, anywhere mobile computing is becoming easier, more attractive, and even cost-effective: Mobile devices carried by roaming users offer more and more computing power and functionalities, including sensing and providing location awareness.1 Many computing devices are also deployed in the environments where the users evolve—for example, intelligent home appliances or RFID-enabled fabrics. In this ambient intelligent world, the choices of identity mechanisms will have a large impact on social, cultural, business and political aspects. Moreover, the Internet will generate more complicated privacy problems.2
Identity has become a burden in the online world. When it is stolen, it engenders a massive fraud, principally in online services, which generates a lack of confidence in doing business with providers and frustration for users.
Therefore, the whole of society would suffer from the demise of privacy, which is a real human need. Because people have hectic lives and cannot spend their time administering their digital identities, we need consistent identity management platforms and technologies enabling usability and scalability, among other things.3 In this chapter, we survey how the requirements have evolved for mobile user-centric identity management and its associated technologies.
2. Evolution of Identity Management Requirements
First, we define what we mean by a digital identity. Later, we summarize all the various requirements and detail the most important ones: namely, privacy, usability, and mobility.
Digital Identity Definition
A digital identity is a representation of an entity in a specific context.4 For a long time, a digital identity was considered the equivalent of a user’s real-life identity that indicates some of our attributes:
• Who we are: Name, citizenship, birthday
• What we like: Our favorite reading, food, clothes
• What our reputation is: Whether we are honest, without any problems
A digital identity was seen as an extended identity card or passport containing almost the same information.
However, recent work5 has argued that the link between the real-world identity and a digital identity is not always mandatory. For example, on eBay, what matters is to know whether the seller’s digital reputation has been remarkable and that the seller can prove that she controls that digital identity. It is less important to know that her real-world national identity is the Bermuda Islands, where suing anybody is rather unlikely to succeed. It should be underlined that in a major identity management initiative,6 a digital identity is defined as “the distinguishing character or personality of an individual. An identity consists of traits, attributes, and preferences upon which one may receive personalized services. Such services could exist online, on mobile devices at work, or in many other places”—that is, without mentioning a mandatory link to the real-world identity behind the digital identity.
The combination of virtual world with ubiquitous connectivity has changed the physical constraints to an entirely new set of requirements as associated security issues such as phishing, spam, and identity theft have emerged. They are aggravated by the mobility of the user and the temporary anonymity of cyberrelationships. We are going toward a new, truly virtual world, always with the implication of humanity. Therefore, we are facing the problem of determining the identity of our interlocutors and the accuracy of their claims. Simply using strong authentication will not resolve all these security issues.
Digital identity management is a key issue that will ensure not only service and functionality expectations but also security and privacy.
Identity Management Overview
A model of identity7 can been as follows:
• A user who wants to access to a service
• Identity Provider (IdP), the issuer of user identity
• Service Provider (SP), the relay party imposing an identity check
• Identity (Id), a set of user attributes
• Personal Authentication Device (PAD), which holds various identifiers and credentials and could be used for mobility
Figure 17.1 lists the main components of identity management.
Figure 17.1 Identity management main components.
The relationship between entities, identities and identifiers are shown in Figure 17.2 which illustrates that an entity, such as a user, may have multiple identities, and each identity may consist of multiple attributes that can be unique or non-unique identifiers.
Figure 17.2 Relationship among identities, identifiers, and entity.
Identity management refers to “the process of representing, using, maintaining, deprovisioning and authenticating entities as digital identities in computer networks.”8
Authentication is the process of verifying claims about holding specific identities. A failure at this stage will threaten the validity of the entire system. The technology is constantly finding stronger authentication using claims based on:
• Something you know (password, PIN)
• Something you have (one-time-password)
• Something you are (your voice, face, fingerprint [biometrics])
The BT report9 has highlighted some interesting points to meet the challenges of identity theft and fraud:
• Developing risk calculation and assessment methods
• Monitoring user behavior to calculate risk
• Building trust and value with the user or consumer
• Engaging the cooperation of the user or consumer with transparency and without complexity or shifting the liability to the consumer
• Taking a staged approach to authentication deployment and process challenges using more advanced technologies
Digital identity should manage three connected vertexes: usability, cost, and risk, as illustrated in Figure 17.3.
Figure 17.3 Digital identity environment to be managed.
The user should be aware of the risk she is facing if her device’s or software’s security is compromised. Usability is the second aspect that should be guaranteed to the user unless he will find the system difficult to use, which could be the source of a security problem. Indeed, many users, when flooded with passwords to remember, write them down and hide them in a “secret” place under their keyboard. Furthermore, the difficulty of deploying and managing a large number of identities discourages the use of an identity management system. The cost of a system should be well studied and balanced related to risk and usability. Many systems such as one-time password tokens are not widely used because they are too costly for widespread deployment in large institutions. Traditionally, identity management was seen as being service provider-centric because it was designed to fulfill the requirements of service providers, such as cost effectiveness and scalability. Users were neglected in many aspects because they were forced to memorize difficult or too many passwords.
Identity management systems are elaborated to deal with the following core facets10:
• Reducing identity theft. The problem of identity theft is becoming a major one, mainly in the online environment. Providers need more efficient systems to tackle this issue.
• Management. The number of digital identities per person will increase, so users need convenient support to manage these identities and the corresponding authentication.
• Reachability. The management of reachability allows a user to handle their contacts to prevent misuse of their email address (spam) or unsolicited phone calls.
• Authenticity. Ensuring authenticity with authentication, integrity, and nonrepudiation mechanisms can prevent identity theft.
• Anonymity and pseudonymity. Providing anonymity prevents tracking or identifying the users of a service.
• Organization personal data management. A quick method to create, modify, or delete work accounts is needed, especially in big organizations.
Without improved usability of identity management11—for example, weak passwords used on many Web sites—the number of successful attacks will remain high. To facilitate interacting with unknown entities, simple recognition rather than authentication of a real-world identity has been proposed, which usually involves manual enrollment steps in the real world.12 Usability is indeed enhanced if no manual task is needed. There might be a weaker level of security, but that level might be sufficient for some actions, such as logging to a mobile game platform. Single Sign-On (SSO) is the name given to the requirements of eliminating multiple-password issues and dangerous passwords. When we use multiple user IDs and passwords just to use email systems and file servers at work, we feel the inconvenience that comes from having multiple identities. The second problem is the scattering of identity data, which causes problems for the integration of IT systems. SSO simplifies the end-user experience and enhances security via identity-based access technology.
Microsoft’s first large identity management system was the Passport Network. It was a very large and widespread Microsoft Internet service, an identity provider for the MSN and Microsoft properties and for the Internet. However, with Passport, Microsoft was suspected by many of intending to have absolute control over the identity information of Internet users and thus exploiting them for its own interests. Passport failed to become “the” Internet identity management tool.
Since then, Microsoft has clearly come to understand that an identity management solution cannot succeed unless some basic rules are respected.13 That’s why Microsoft’s Identity Architect, Kim Cameron, has stated the seven laws of identity. His motivation was purely practical in determining the prerequisites of creating a successful identity management system. He formulated these essential principles to maintain privacy and security;
• User control and consent over the handling of their data
• Minimal disclosure of data, and for a specified purpose
• Information should only be disclosed to people who have a justifiable need for it
• The system must provide identifiers for both bilateral relationships between parties and for incoming unsolicited communications
• It must support diverse operators and technologies
• It must be perceived as highly reliable and predictable
• There must be a consistent user experience across multiple identity systems and using multiple technologies.
Most systems do not fulfill several of these tests; they are particularly deficient in fine-tuning the access control over identity to minimize disclosure of data.
Cameron’s principles are very clear but they are not explicit enough to compare identity management systems. That’s why we will explicitly define the identity requirements.
Privacy Requirement
Privacy is a central issue due to the fact that the official authorities of almost all countries have strict legal policies related to identity. It is often treated in the case of identity management because the management deals with personal information and data. Therefore, it is important to give a definition. Alan F. Westin defines privacy as “the claim of individuals, groups and institutions to determine for themselves, when, how and to what extent information about them is communicated to others.”14 However, we will use Cooley’s broader definition of privacy15: “the right to be let alone,” because it also emphasizes the problems related to disturbing the user’s attention, for example, with email spam.
User-Centricity
The evolution of identity management systems is toward the simplification of the user experience and reinforcing authentication. It is well known that poor usability implies a weakness in authentication. Mainly federated management has responded to some of these requirements by facilitating the use and the managing of identifiers and credentials in the boundary of a federated domain. Nevertheless, it is improbable that only one federated domain will subsist. Moreover, different levels of sensitivity and risks of various services will need different kinds of credentials. It is obvious that we should give support and atomization of identity management on the user’s side.
A new paradigm must be introduced to solve the problems of usability, scalability, and universal SSO. A user-oriented paradigm, called user-centric identity management, has emerged. The expression user-controlled management16 was the first used to explain the user-centric management model. Recent federated identity management systems keep strong end-user controls over how identity information is disseminated among members of the federation. This new paradigm gives the user full control over his identity by notifying him of the information collected and by guaranteeing his consent for any type of manipulation of collected information. User control and consent is also defined as the first law in Cameron’s Laws of Identity.17 A user-centric identity management system supports the user’s control and considers user-centric architecture and usability aspects.
There is no uniform definition, but one is “User-centric identity management is understood to mean digital identity infrastructure where an individual end-user has substantially independent control over the dissemination and use of their identifier(s) and personally identifiable information (PII).”18 See Figure 17.4.
Figure 17.4 IdP-centric and user-centric models.
We can also give this definition of user centricity: “In user-centric identity management, the user has full control over her identity and consistent user experience during all transactions when accessing her services.”
In other words, the user is allowed to keep at least some or total control over his personal data.
One of the principles of a user-centric identity is the idea that the user of a Web service should have full control over his identity information. A lot of technology discussion and solutions have focused on service provider’s and rarely on user’s perspectives. The user-centric identity paradigm is a real evolution because it moves IT architecture forward for users, with the following advantages:
• Empowering users to have total control over their privacy
• Usability, as users are using the same identity for each identity transaction
• Consistent user experience, thanks to uniformity of the identity interface
• Limiting identity attacks, such as phishing
• Limiting reachability/disturbances, such as spam
• Reviewing policies on both sides, both identity providers and service providers (Web sites), when necessary
• Huge scalability advantages, since the identity provider does not need any prior knowledge about the service provider
• Assuring secure conditions when exchanging data
The user-centric approach allows users to gain access anonymously because they retain full control over their identities. Of course, full anonymity19 and unlinkability may lead to increased misuse by anonymous users. Then, pseudonymity is an alternative that is more suitable to the ecommerce environment. In this regard, anonymity must be guaranteed at the application and network levels. Some frameworks have been proposed to ensure user-centric anonymity using the concepts of one-task authorization keys and binding signatures.20
Usability Requirement
Security is compromised with the proliferation of user passwords and even by their weakness. Indeed, some users note their passwords on scratchpads because their memorization poses a problem. The recent FFIEC guidelines on authentication in online banking reports state that “Account fraud and identity theft are frequently the result of single-factor (e.g., ID/password) authentication exploitation.”21 From then on, security must be user oriented because the user is the effective person concerned with it, and many recent attacks take advantage of users’ lack of awareness of attacks (such as spoofing, pharming, and phishing).22 Without strong control and improved usability23 of identity management, some attacks will always be possible. To facilitate interacting with unknown entities, simple recognition rather than authentication of a real-world identity, which usually involves manual enrollment steps in the real world, has been proposed.24 Usability is indeed enhanced if no manual task is needed. A weaker level of security might be reached, but that level might be sufficient for some actions, such as logging to a mobile game platform.
As we’ve seen, SSO is the name given to the requirements of eliminating multiple password issues and dangerous passwords. When we use multiple user IDs and passwords to use the email systems and file servers at work, we feel the pain that comes from having multiple identities. The second problem is the scattering of identity data, which causes problems for the integration of IT systems. Moreover, it simplifies the end-user experience and enhances security via identity-based access technology.
Therefore, we offer these features:
3. The Requirements Fulfilled by Current Identity Management Technologies
This part of the chapter provides an overview of identity management solutions from Identity 1.0 to Identity 2.0 and how they address the requirements introduced earlier. We focus on related standards XRI and LID, issued from the Yadis project, and platforms, mainly ID-WSF, OpenID, Higgins, CardSpace, and Sxip. Then we discuss identity management in the field of mobility.
Evolution of Identity Management
This part of the chapter provides an overview of almost all identity management 1.0 (see Figure 17.5). We begin by describing the silo model, then different kinds of centralized model and federated identity management.
Figure 17.5 Identity 1.0 principle.
Identity Management 1.0
In the real world I use my identity card to prove who I am. How about in the online world?
The first digital identity appeared when a user was associated with the pair (username, password) or any other shared secret. This method is used for authentication when connecting to an account or a directory. It proves your identity if you follow the guidelines strictly; otherwise there is no proof.
In fact, it is a single authority using opaque trust decisions without any credentials (cryptographic proofs), choice, or portability.
In the context of Web access, the user must enroll for every unrelated service, generally with different user interfaces, and follow diverse policies and protocols. Thus, the user has an inconsistent experience and deals with different identity copies. In addition, some problems related to privacy have also emerged. Indeed, our privacy was potentially invaded by Web sites. It is clear that sites have a privacy policy, but there is no user control over her own identity. What are the conditions for using these data? How can we improve our privacy? And to what granularity do we allow Web sites to use our data?
The same problem is revealed when we have access to resources. The more resources, the more management we have to perform. It is an asymmetric trust. And the policy decision may be opaque.
It allows access with an opaque trust decision and a single centralized authority without a credentials choice. It is a silo model25 because it is neither portable nor scalable. This is Identity 1.0.
Identity management appeared with these problems in the 1980s. The first identity management system was the Rec. X.500, developed by the ITU26 and covering directory services such as Directory Access Protocol (DAP). The ISO was also associated with development of the standard. Like a lot of ITU standards, this one was very heavy and complex. A light version appeared in the 1990s for DAP. It was LDAP, which was standardized by the IETF and became widespread and adopted by Netscape. Microsoft has invented an equivalent Active Directory, and for users it introduced Passport. It is also the ITU that standardized X.509 for identities related to certificates and it is the format currently recognized. It is a small file, generated by an authority of certification. If there is a loss or a usurpation of the certificate, it can always be revoked by the authority of certification.
This is for single users; what about business corporations that have automated their procedures and have a proliferation of applications with deprovisioning but still in a domain-centric model? What about resources shared between domains?
Silo Model
The main identity management system deployed currently on the Internet is called the silo model, shown in Figure 17.6. Indeed, the identity provider and service provider are mixed up and they share the same space. The identity management environment is put in place and operated by a single entity for a fixed user community.
Figure 17.6 Identity silo model.
Users of different services must have different accounts and therefore reenter the same information about their identity which increases the difficulty of management. Moreover, the users are overloaded with identities and passwords to memorize, which produce a significant barrier to usage.
A real problem is the “forgetability” of passwords due to the infrequent use of some of these data. This can obviously lead to a higher cost of service provisions.
This is for single users. What about enterprises that have automated their procedures and have a proliferation of applications with deprovisioning but are still in a domain-centric model? What about resources shared between domains?
The silo model is not interoperable and is deficient in many aspects. That’s why the federated identity management model is now emerging, and it is very appreciated by enterprises. A federated identity management system consists of software components and protocols that handle in a decentralized manner the identity of individuals throughout their identity life-cycle.27
Solution by Aggregation
Aggregating identity information and finding the relationship between identity records is important to aggregating identity. There are some alternatives:
• The first approach consolidates authentication and attributes in only one site and is called a centralized management solution, such as Microsoft Passport. This solution avoids the redundancies and inconsistencies in the silo model and gives the user a seamless experience.28 The evolution29,30 was as follows:
– Building a single central identity data store, which is feasible only for small organizations
– Creating a metadirectory that synchronizes data from other identities, data stored elsewhere
– Creating a virtual directory that provides a single integrated view of the identity data stored
– An SSO identity model that allows users to be authenticated by one service provider
• The second approach decentralizes the responsibility of IdP to multiple such IdPs, which can be selected by end users. This is a federate system whereby some attributes of identity are stored in distributed IdPs. A federated directories model, by linking identity data stored together, has emerged. Protocols are defined in several standards such as Shibboleth,31 Web services federation language 2003.
Centralized versus Federation Identity Management
Microsoft Passport is a centralized system entirely controlled by Microsoft and closely tied to other Microsoft products. Individuals and companies have proven reluctant adopters of a system so tightly controlled by one dominant company.
Centrally managed repositories in centralized identity infrastructures can’t solve the problem of cross-organizational authentication and authorization. This approach has several drawbacks because the IdP not only becomes a single point of failure, it may also not be trusted. That’s why Microsoft Passport was not successful. In contrast, the federation identity will leave the identity resources in their various distributed locations but produce a federation that links them to solve identity duplication, provision, and management.
A Simple Centralized Model
A relatively simple centralized identity management model is to build a platform that centralizes identities. A separate entity acts as an exclusive user credentials provider for all service providers. This approach merges both authentication and attributes in only one site. This architecture, which could be called the common user identity management model, is illustrated in Figure 17.7. All identities for each SP are gathered to a unique identity management site (IdP). SPs have to provide each identity to the IdP.
Figure 17.7 Simple centralized identity management.
In this environment, users can have access to all service providers using the same set of identifiers and credentials. A centralized certificate (CA) could be implemented with a Public Key Infrastructure (PKI) or Simple Public Key Infrastructure (SKPI).32 This architecture is very efficient in a close domain where users could be identified by a controlled email address. Although such architecture seems to be scalable, the concentration of privacy-related information has a great deal of difficulty in terms of social acceptance.33
Metadirectories
SPs can share certain identity-related data on a meta level. This can be implemented by consolidating all service providers’ specific identities to a meta-identifier linked to credentials.
There are collections of directory information from various directory sources. We aggregated them to provide a single view of data. Therefore, we can show these advantages:
• A single point of reference provides an abstraction boundary between application and actual implementation. A single point of administration avoids multiple directories, too.
• Redundant directory information can be eliminated, reducing administration tasks.
This approach can be seen from the user’s point of view as password synchronization across multiple service providers. Thus, the password is automatically changed with all the others.
This architecture can be used in large enterprises where all services are linked to a metadirectory, as shown in Figure 17.8. In this case, the ease of use is clear because the administration is done by a single authority.
Figure 17.8 Metadirectory model.
Virtual Directories
Virtual directories (VDs) are directories that are not located in the same physical structure as the Web home directory but look as though they are to Web clients. The actual directories may be at a completely different location in the physical directory structure—for example, on another hard disk or on a remote computer. They are similar in concept to metadirectories in that they provide a single directory view from multiple independent directories. They differ in the means used to accomplish this goal. Metadirectories (MD) software agents replicate and synchronize data from various directories in what might be batch processes. In contrast, Various Directories (VDs) provide a single view of multiple directories using real-time queries based on mapping from fields in the virtual scheme to fields in the physical schemes of the real directories.
Single Sign-On (SSO)
Single sign-on, or SSO (see Figure 17.9), is a solution proposed to eliminate multiple password issues and dangerous passwords. Moreover, it simplifies the end-user experience and enhances security via identity-based access technology.
Figure 17.9 Single sign-on model.
Therefore, it offers these features:
Federated Identity Management
We have seen different approaches to manage user identity; they are not clearly interoperable and are deficient in unifying standard-based frameworks. On one hand, maintenance of privacy and identity control are fundamental when offering identity to users; on the other hand, the same users ask for more easy and rapid access. The balance of the two sides leads to federated network identity. That’s why these environments are now emerging. A federated identity management system (see Figure 17.10) consists of software components and protocols that handle the identity of individuals throughout their identity life cycle.
Figure 17.10 Federated identity management model.
This architecture gives the user the illusion that there is a single identifier authority. Even though the user has many identifiers, he doesn’t need to know all of them. Only one identifier is enough to have access to all services in the federated domain.
Each SP is responsible for the namespace of his users, and all SPs are federated by linking the identity domains. Thus, the federated identity model is based on a set of SPs, called a circle of trust by the Liberty Alliance. This set of SPs follows an agreement on mutual security and authentication to allow SSO. Indeed, the federated identity management combines SSO and authorization tools using a number of mutual SPs’ technologies and standards. This practice makes the recognition and entitlement of user identities by other SPs easy. Figure 17.10 shows the set of federated domains and the possibility for other SPs to have access to the same user with different identifiers.
The essential difference between federated identity systems and centralized identity management is that there is no single entity that operates the identity management system. Federated systems support multiple identity providers and a distributed and partitioned store for identity information. Therefore, a federated identity network allows a simplified sign-on to users by giving rapid access to resources, but it doesn’t require the user’s personal information to be stored centrally. With this identity network approach, users authenticate themselves once and can control how their personal information and preferences are used by the service providers.
Federated identity standards, like those produced by the Liberty Alliance, provide SSO over all offered services and enable users to manage the sharing of their personal information through identity and service providers as well as the use of personalized services to give them access to convergent services. The interoperability between disparate security systems is assumed by an encapsulation layer through a trust domain, which links a set of trusted service providers.
However, there are some disadvantages with federated identity management. The first is the user’s lack of privacy, because his personnel attributes and information can be mapped using correlation between identifiers. Anonymity could be violated. The second is the scalability of users because they have access to the network from different domains by authentication to their relative IdPs. Therefore, the problem of passwords will continue across multiple federated domains.
A major challenge is to integrate all these components into a distributed network and to deal with these drawbacks. This challenge cannot be taken up without new paradigms and supported standards.
The evolution of identity management systems is toward simplification of user experience and reinforcing authentication. It is very known that poor usability implies the weakness of authentication. A new paradigm should be introduced to solve those problems while still being compatible at least with federated identity management.
That is why user-centric identity management has emerged.34,35 This paradigm is embraced by multiple industry products and initiatives such as Microsoft CardSpace,36 Sxip,37 and Higgins Trust Framework.38 This is Identity 2.0.
Identity 2.0
The user of Internet services is overcome with identities. She is seldom able to transfer her identity from one site to another. The reputation that she gains in one network is useful to transfer to other networks. Nevertheless, she cannot profit from her constructed reputation, and she must rebuild her identity and reputation time and again. The actual systems don’t allow users to decide about the sharing of their attributes related to their identity with other users. This causes a lack of privacy control. Some solutions propose an advanced social system that would model the social interaction after the real world.
The solutions must be easy to use and enable users to share credentials among many services and must be transparent from the end-user perspective.
The principle of modern identity is to separate the acquisition process from the presentation process. It is the same for the identification process and the authorization process. Moreover, it provides scalability and privacy. Doing so, we can have more control over our identities.
The scale, security, and usability advantages of user-centric identity make it the underpinning for Identity 2.0. The main objective of the Identity 2.0 protocol is to provide users with full control over their virtual identities. An important aspect of Identity 2.0 is protection against increasing Web attacks such as phishing as well as the inadvertent disclosure of confidential information while enabling convenient management.
Identity 2.0 would allow users to use one identity respecting transparency and flexibility. It is focused around the user and not around directory or identity providers. It requires identified transactions between users and relaying party using credentials, thus providing more traceable transactions. To maximize the privacy of users, some credentials could be given to the users in advance. Doing so, the IdP could not easily know when the user is utilizing the credentials.
The Identity 2.0 (see Figure 17.11) completely endorses the paradigms of user-centric identity management, enabling users’ full control over their identities. Service providers will therefore be required to change their approaches by including requests for and authentication of users’ identity. Identity 2.0 systems are interested in using the concept of a user’s identity as credentials for the user, based on attributes such as user name and address to less traditional things such as their desires, customer service history, and other attributes that are usually not so associated with a user identity.
Figure 17.11 URL-based Id 2.0.
Identity 2.0 initiatives
When a Web site collects data from users, it cannot confirm whether or not the collected data is pertinent and reliable, since users often enter nonsense information into online forms. This is due to the lack of Web sites to control and verify users’ data. Furthermore, due to the legal limitation on requested data, a Web site cannot provide true customized services, even though users require them. On the other side, users have no direct control over what the Web site will do with their data. In addition, users enter the same data many times when accessing Web sites for the first time. Doing so, they have a huge difficulty in managing their large numbers of identities.
To mitigate these problems, various models of identity management have been considered. One such model, Identity 2.0, proposes an Internet-scalable and user-centric identity architecture that mimics real-world interactions.
Many research labs have collaborated to develop the Identity 2.0 Internet-based Identity Management services. They are based on the concept of user-centric identity management, supporting enhanced identity verification and privacy and user consent and control over any access to personal information for Internet-based transactions.
There are various Identity 2.0 initiatives:
LID
Like LDAP, Light-Weight Identity (LID) is based on the principle of simplicity, since many existing identity schemes are too complicated to be largely adoptable. It simplifies more complex protocols; but instead of being less capable due to fewer features, it has had success that more complex predecessors lacked. This was because their simplification reduced the required complexity to the point where many people could easily support them, and that was one of the goals of LID.
LID is a set of protocols capable of representing and using digital identities on the Internet in a simple manner, without relying on any central authority. LID is the original URL-based identity protocol, part of the OpenID movement.
LID supports digital identities for humans, human organizations, and nonhumans (such as software agents, and Web sites). It implements Yadis39, a metadata discovery service, and is pluggable on all levels.
XRI/XDI
The XRI EXtensible Resource Identifier (see Figure 17.12) and XDI40 represent the fractional solution without the integration of Web services. They are open standards and royalty-free. XRI is about Addressing, whereas XDI is a Data Sharing protocol that uses XRI. Both XRI and XDI are being developed under the support of OASIS. I-name and I-number registry services for privacy-protected digital addressing use XRI. It can be used as an identifier for persons, machines and agents.
Figure 17.12 XRI layers.
XRI offers a human-friendly form of persistent identifier. That’s why it is a convenient identifier for SSO systems. It supports both persistent and reassignable identifiers in the same syntax and establishes global context symbols. Moreover, it enables identification of the same logical resource across multiple contexts and multiple versions of the same logical resource.
XDI is a Secure Distributed Data Sharing Protocol. It is also an architecture and specification for privacy-controlled data exchange in which all data is identified using XRIs. The XDI platform includes explicit specification for caching with both push and pull synchronization. XDI universal schema can represent any complex data and have the ability to do cross-context addressing and linking.
SAML
The Security Assertion Markup Language (SAML) is an OASIS specification41 that provides a set of rules for the structure of identity assertions, protocols to move assertions, bindings of protocols for typical message transport mechanisms, and profiles. Indeed, SAML (see Figure 17.13) is a set of XML and SOAP-based services and formats for the exchange of authentication and authorization information between security systems.
Figure 17.13 SAML token exchange.
The initial versions of SAML v1.0 and v1.1 define protocols for SSO, delegated administration, and policy management. The most recent version is SAML 2.0. It is now the most common language to the majority of platforms that need to change the unified secure assertion. It is very useful and simple because it is based on XML.
An assertion is a datum produced by a SAML authority referring to authentication, attribute information, or authorizations applying to the user with respect to a specified resource.
This protocol (see Figure 17.14) enables interoperability between security systems (browser SSO, Web services security, and so on). Other aspects of federated identity management as permission-based attribute sharing are also supported.
Figure 17.14 SAML assertion.
SAML is sometimes criticized for its complexity of the specifications and the relative constraint of its security rules. Recently, the SAML community has shown significant interest in extending SAML to reach less stringent requirements for low-sensitivity use cases. The advantages of SAML are robustness of its security and privacy model and the guarantee of its interoperability between multiple-vendor implementations through the Liberty Alliance’s Conformance Program.
Shibboleth
Shibboleth42 is a project for which the goal is to allow universities to share Web resources subject to control access. Thereafter, it allows interoperation between institutions using it. It develops architectures, policy structure, practical technologies, and an open-source implementation. It is building components for both the identity providers and the reliant parties. The key concept includes “federated” management identity, the meaning of which is almost the same as the Liberty term’s.43 Access control is fundamentally based on user attributes, validated by SAML assertions. In Figure 17.15, we can see the evolution of SAML, Shibboleth, and XACML.44
Figure 17.15 Convergence between SAML and Shibboleth.
ID-WSF
In 2001, a business alliance was formed to serve as an open standards organization for federated identity management; it was named the Liberty Alliance.45 Its goals are to guarantee interoperability, support privacy, and promote adoption of its specifications, guidelines, and best practices. The key objectives of the Liberty Alliance (see Figure 17.16) are to:
• Enable users to protect their privacy and identity
• Enable SPs to manage their clients
• Provide an open, federated SSO
• Provide a network identity infrastructure that supports all current emerging network access devices
Figure 17.16 High-level overview of the Liberty Alliance architecture.
The Liberty Alliance’s work in the first phase is to enable federated network identity management46. It offers, among other things, SSO and linking accounts in the set of SPs in the boundary of the circle of trust. The work of this phase is referred to as the Identity Federation Framework (ID-FF).
In the second phase, the specifications offer enhancing identity federation and interoperable identity-based Web services. This body is referred to as the Identity Web Services Framework (ID-WSF). This framework involves support of the new open standard such as WS-Security developed in OASIS. ID-WSF is a platform for the discovery and invocation of identity services—Web services associated with a given identity. In the typical ID-WSF use case, after a user authenticates to an IdP, this fact is asserted to an SP through SAML-based SSO. Embedded within the assertion is information that the SP can optionally use to discover and invoke potentially numerous and distributed identity services for that user. Some scenarios present an unacceptable privacy risk because they suggest the possibility of a user’s identity being exchanged without that user’s consent or even knowledge. ID-WSF has a number of policy mechanisms to guard against this risk, but ultimately, it is worth noting that many identity transactions (such as automated bill payments) already occur without the user’s active real-time consent—and users appreciate this efficiency and convenience.
To build additional interoperable identity services such as registration services, contacts, calendar, geolocation services, and alert services, it’s envisaged to use ID-WSF. This specification is referred to as the Identity Services Interface Specification (ID-SIS).
The Liberty Alliance specifications define the protocol messages, profiles, and processing rules for identity federation and management. They rely heavily on other standards such as SAML and WS-Security, which is another OASIS specification that defines mechanisms implemented in SOAP headers.
These mechanisms are designed to enhance SOAP messaging by providing a quality of protection through message integrity, message confidentiality, and single message authentication. Additionally, Liberty has contributed portions of its specification back into the technical committee working on SAML. Other identity management enabling standards include:
• Service Provisioning Markup Language (SPML)
• XML Access Control Markup Language (XACML)
The WS-∗ (the Web Services protocol specifications) are a set of specifications currently under development by Microsoft and IBM. It is part of a larger effort to define a security framework for Web services; the results of proposals are often referred to as WS-∗. It includes such specifications as WS-Policy, WS-Security Conversation, WS-Trust, and WS-Federation. This last one has functionality for enabling pseudonyms and attribute-based interactions. Therefore, WS-Trust has the ability to ensure security tokens as a means of brokering identity and trust across domain boundaries.47
The Liberty Alliance is developing and delivering a specification that enables federate network identity management. Figure 17.16 shows an overview of the Liberty Alliance architecture as described in the introduction to the Liberty Alliance identity architecture.
OpenID 2.0
Brad Fitzpatrick is at the origin of the development of OpenID 1.0. The intent of the OpenID framework is to specify layers that are independent and small enough to be acceptable and adopted by the market.48 OpenID is basically providing simple attribute sharing for low-value transactions. It does not depend on any preconfigured trust model. Version 1.0 has a deal with an HTTP-based URL authentication protocol. OpenID authentication 2.0 is becoming an open platform that supports both URL and XRI user identifiers. In addition, it would like to be modular, lightweight, and user oriented. Indeed, OpenID auth. 2.0 allows users to choose, control and manage their identity addresses. Moreover, the user chooses his identity provider and has a large interoperability of his identity and can dynamically use new services that stand out, such as attribute verification and reputation, without any loss of features. No software is required on the user’s side because the user interacts directly with the identity provider’s site. This approach jeopardizes the user identity because it could be hacked or stolen. Also, the user has no ability to examine tokens before they are sent.
At the beginning of identity management, each technology came with its own futures, without any interest in others. Later, the OpenID 1.0 community realized the importance of integrating other technologies as OASIS Extensible Resource Description Sequence (XRDS), which is useful for its simplicity and extensibility.
OpenID Stack
The first layer is for supporting users’ identification. Using URL or XRI forms, we can identify a user. URLs use IP or DNS resolution and are unique and ubiquitously supported. They can be a personal digital address as used by bloggers, even though these are not yet widely used.
XRI is being developed under the support of OASIS and is about addressing.
I-names are a generic term for XRI authority names that provide abstract identifiers for the entity to which they are assigned. They can be used as the entry point to access data under the control of that authority. Like a domain name, the physical location of the information is transparent to the requester.
OpenID 2.0 provides a private digital address to allow a user to be identified only in specific conditions. This guarantees the user privacy in a public domain.
Discovery
Yadis is used for identity service discovery for URLs and XRI resolution protocol for XRIs. They both use the OASIS format XRDS. The protocol is simple and describes any type of service.
Authentication
This service lets a user prove his URL or I-name using credentials (cryptographic proof). This protocol is explained in Figure 17.17. The OpenID doesn’t need a centralized authority for enrollment and it is therefore a federated identity management. With OpenID 2.0 the IdP offers the user the option of selecting a digital address to send to the SP. To ensure anonymity, IdP can randomly generate a digital address used specially for this SP.
Figure 17.17 OpenID protocol stack.
Data Transport
This layer ensures data exchange between the IdP and SP. It supports push and pull methods and it is independent from authentication procedures. Therefore, the synchronization of data and secure messaging and other services will be enabled. The data formats are those defined by SAML, SDI (XRI Data interchange), or any other data formats. This approach will enable evolution of the OpenID platform.
The four layers construct the foundation of the OpenID ensuring user centricity (see Figure 17.18). There are three points to guarantee this paradigm:
Figure 17.18 OpenID 1.1 protocol flow.
OpenID is decentralized and well founded and at the same time simple and easy to use and to deploy. It provides an open development process and SSO for the Web and ease of integration into scripted Web platforms (such as Drupal and WordPress). Thus it has a great future. You can learn about OpenID at www.openidenabled.com or join the OpenID community www.openid.net.
CardSpace
Rather than invent another technology for creating and representing digital identities, Microsoft has adopted the federated user-centric identity meta-system. This is a serious solution that provides a consistent way to work with multiple digital identities. Using standard protocols that anyone can implement on any platform, the identity meta-system allows the acquisition and use of any kind of security tokens to convey identity.
CardSpace is Microsoft’s code name for this new technology that tackles the problem of managing and disclosing identity information. CardSpace implements the core of the identity meta-system, using open standard protocols to negotiate, request, and broker identity information between trusted IdPs and SPs. CardSpace is a technology that helps developers integrate a consistent identity infrastructure into applications, Web sites, and Web services.
By providing a way for users to select identities and more, Windows CardSpace49 plays an important part in the identity meta-system. It provides the consistent user experience required by the identity meta-system. It is specifically hardened against tampering and spoofing, to protect the end user’s digital identities and maintain end-user control. Windows CardSpace enables users to provide their digital identities in a familiar, secure, and easy way.
In the terminology of Microsoft, the relying party is in the model service provider (SP).
To prove an identity over a network, the user gives credentials, which are some proofs about her identity. For example, in the simplest digital identity the username is the identity whereas the password is said to be the authentication credential. In the terminology of Microsoft and others, these are called security tokens and contain one or more claims. Each claim contains information about the user, such as username or home address. In addition, the security token proves that the claims are correctly emitted by the real user and are belonging to him. This could be done cryptographically using various forms such as X.509 certificates and Kerberos tickets, but unfortunately these are not practical to convey some kinds of claims. The standard SAML as seen before is indicated for this purpose because it can be used to define security tokens. Indeed, SAML tokens could enclose any desired information and thus become as largely useful in the network to show and control digital identity.
CardSpace runs on Windows Vista, XP, Server 2003, and Server 2008, based on .NET3, and uses Web service protocols:
CardSpace runs in a virtual desktop on the PC, thereby locking out other processes and reducing the possibility of spyware intercepting information.
Figure 17.19 shows that the architecture exactly fits the principle of Identity 2.0. The user accesses one of any of his relying parties (SPs) using an application that supports CardSpace.
Figure 17.19 Interactions among the users, identity providers, and relying party.
When the choice is made, the application asks for the requirement of a security token of this specific SP that will answer with SP policy. It really contains information about the claims and the accepted token formats.
Once this is done, the application passes these requirements to CardSpace, which asks for the security token from an appropriate identity provider.
Once this security token has been received, CardSpace transmits via application to the relying party. The relying party can then use this token to authenticate the user.
Note that each identity is emitted by an identity provider and is stored on the user side. It contains the emitter, the kind of security token the user can issue and the details about the identity claims. All difficulties are hidden from the user; he has only to choose one CardSpace when the process of authentication is launched. Indeed, once the required information is returned and passed to CardSpace, the system displays the card selection matching the requirements on screen. In this regard, the user has a consistent experience, since all applications based on CardSpace will have the same interface, and the user does not have to worry about the protocol used to express his identity’s security token. The PIN is entered by the user and the choice of his card is done in a private Windows desktop to prevent locally running processes.
SXIP 2.0
In 2004, SXIP 1.0 grew from efforts to build a balanced online identity solution that met the requirements of the entire online community. Indeed, SXIP 2.0 is the new generation of the SXIP 1.0 protocol, a platform that gives users control over their online identities and enables online communities to have richer relationships with their members. SXIP 2.0 defines entities’ terminology as:
The Simple eXtensible Identity Protocol (SXIP)50 was designed to address the principles defined by the Identity 2.0 model (see Figure 17.20), which proposes an Internet-scalable and user-centric identity architecture that mimics real-world interactions.
Figure 17.20 SXIP entity interactions.
If an SP has integrated an SXIP to its Web site, which is easily done using SDKs, it is a Membersite. When a subscriber of SXIP would like to access this Membersite:
1. He types his URL address and clicks Sxip in.
2. He types his URL identity issued by IdP (called the Homesite).
3. The browser is redirected to the Homesite.
4. He enters his username and password and is informed that the Membersite has requested data, selects the related data, verifies it and can select to automatically release data for other visits to this Membersite, and confirms.
SXIP 2.0 is a platform based on a fully decentralized architecture providing an open and simple set of processes for exchanging identity information. SXIP 2.0 has significantly reduced the problems resulting from moving identity data from one site to another. It is a URL-based protocol that allows a seamless user experience and fits exactly the user-centric paradigm. In that sense, the user has full control of her identity and has an active role in the exchange of her identity data. Therefore, she can use portable authentication to connect to many Web sites. Doing so, the user has more choice and convenience when exchanging her identity data; this method also indirectly enables Web sites to offer enhanced services to their subscribers.
SXIP 2.0 provides the following features:
• Decentralized architecture. SXIP 2.0 is completely decentralized and is a federated identity management system. The online identity is URL-based and the user identity is separated from the authority that issues the identifiers for this identity. In this regard, we can easily move the location of the identity data without losing the associated identifier.
• Dynamic discovery. A simple and dynamic discovery mechanism ensures that users are always informed online about the Homesite that is exporting their identity data.
• Simple implementation. SXIP 2.0 is open source using various high-level development languages such as Perl, Python, PHP, and Java. Therefore, the integration of SXIP 2.0 into a Web site is effortless. It does not require PKI, because it uses a URL-based protocol.
• Support for existing technologies. SXIP 2.0 uses simple Web browsers, the primary client and means of data exchange, providing users with choices in the release of their identity data.
• Interoperability. SXIP 2.0 can coexist with other URL-based protocols.
• Richer data on an Internet scale. SXIP 2.0 messages consist of lists of simple name value pairs. It can exchange simple text, claims using SAML, and third-party claims in one exchange and present them in many separate exchanges. In addition, the identity provider is not bothersome every time an identity is requested.
Finally, using SXIP 2.0, Web sites can also be authoritative about users regarding data, such as third-party claims. Those are keys to build an online reputation, further enriching the online exchange of identity data.
Higgins
Higgins51 is a project supported principally by IBM and it is a part of IBM’s Eclipse open-source foundation. It will also offer libraries for Java, C, and C++ as well as plug-ins for popular browsers. It is really an open-source trust framework, the goals of which are to support existing and new applications that give users more convenience, privacy, and control over their identity information. The objective is to develop an extensible, platform-independent, identity protocol-independent software framework that provides a foundation for user-centric identity management. Indeed, it enables applications to integrate identity, profiles, and relationships across heterogeneous systems.
The main goals of Higgins as an identity management system are interoperability, security, and privacy in a decoupled architecture. This system is a true user-centric one based on federated identity management. The user has the ability to use a pseudonym or simply reply anonymously.
We use the term context to cover a range of underlying implementations. A context can be thought of as a distributed container-like object that contains digital identities of multiple people or processes.
The platform intends to address four challenges:
• The need to manage multiple contexts
• The need for interoperability
• The need to respond to regulatory, public, or customer pressure to implement solutions based on trusted infrastructure that offers security and privacy
• The lack of common interfaces to identity/networking systems
Higgins matches exactly the user-centric paradigms because it offers a consistent user experience based on card icons for management and release of identity data. Therefore there is less vulnerability to phishing and other attacks. Moreover, user privacy is enabled by sharing only what is needed. Thus, the user has full control over his personal data. The Identity Attribute Service enables aggregation and federation of identity systems and even silos.
For enterprises, Higgins integrates all data related to identity, profile, reputation, and relationship information across and among complex systems.
Higgins is a trust framework that enables users and enterprises to adopt, share across multiple systems, and integrate to new or existing applications digital identity, profiles, and cross-relationship information. In fact, it facilitates as well the integration of different identity management systems in the management of identity, profile, reputation and relationship data across repositories. Using context providers, directories and communications technologies (such as Microsoft/IBM WS-∗, LDAP, email, etc.) can be plugged into the Higgins framework. Higgins has become an Eclipse plug-in and is a project of the Eclipse Foundation. Any application developed with Higgins will enable users to share identities with other users, under strict control.
Higgins is beneficial for developers, users, and enterprise. It relieves developers of knowing all the details of multiple identity systems, thanks to one API that supports many protocols and technologies: CardSpace, OpenID, XRI, LDAP, and so on. An application written to the Higgins API can integrate identity, profile, and relationship information across these heterogeneous systems. The goal of the framework is to be useful in the development of applications accessed through browsers, rich clients, and Web services. Thus, the Higgins Project is supported by IBM and Novell and attempts to thwart CardSpace, Microsoft’s project.
The Higgins framework intends to define, in terms of service descriptions, messages and port types consistent with an SOA model and to develop a Java binding and implementation as an initial reference.
Applications can use Higgins to create a unified, virtual view of identity, profile, and relationship information. A key focus of Higgins is providing a foundation for a new “user-centric identity” and personal information management applications.
Finally, Higgins provides virtual integration, a user-centric federated management model and trust brokering that are applied to identity, profile, and relationship information. Furthermore, Higgins provides common interfaces to identity and, thanks to data context, it includes an enhanced automation process. Those features are also offered across multiple contexts, disparate systems, and implementations. In this regard, Higgins is a fully interoperable framework.
The Higgins service acts together with a set of so-called context providers that can represent a department, association, informal network, and so on. A context is the Higgins environment and digital identities, the policies and protocols that govern their interactions. Context providers adjust existing legacy systems to the framework or implement new ones; context providers may also contain the identities of a machine or a human. A context encloses a group of digital identities and their related claims and links. A context maintains a set of claims about properties and values (name, address, etc.). It is like a security token for CardSpace. The set of profile properties, the set of roles, and the access rights for each role are defined by and controlled by the context provider.
Context providers act as adapters to existing systems. Adapter providers can connect, for example, to LDAP servers, identity management systems like CardSpace, or mailing list and social networking systems. A Higgins context provider (see Figure 17.21) has the ability to implement the context interface and thus empower the applications layered on top of Higgins.
Figure 17.21 The Higgins Trust Framework and context.52
The 10 requirements at the top of Table 17.1 are those discussed earlier in the chapter. In the table, black means that the requirement is not covered, and gray that it’s fully fulfilled.
Table 17.1
Evaluating identity 2.0 technologies
At the moment, service providers have to choose between many authentications and identity management systems and users are left to face the inconvenience of carrying a variety of digital identities. The main initiatives have different priorities and some unique advantages while overlapping in many areas. The most pressing requirements for users are interoperability, usability, and centricity. Thanks to Higgins, the majority of identity requirements are guaranteed. Therefore, using Higgins the user is free to visit all Web sites without worrying about the identity management system used by the provider.
4. Identity 2.0 for mobile users
Now let’s talk about mobility, its evolution and its future.
The number of devices such as mobile phones, smart cards, and RFIDs53 is increasing daily and becoming huge. Mobile phones have attracted particular interest because of their large penetration and pervasiveness that exceeds that of personal computers. Furthermore, the emergence of both IP-TV and wireless technology has facilitated the proliferation of intelligent devices, mobile phones, RFIDs, and other forms of information technology that are developing at a rapid speed. These devices include a fixed identifier that can be linked to a user’s identity. This identifier provides a mobile identity that takes into account information about the location and the mobile user’s personal data.54
Mobile Web 2.0
Mobile Web 2.0 as a content-based service is an up-to-date offering of services within the mobile network. As the number of people with access to mobile devices exceeds those using a desktop computer, mobile Web will be a key factor for the next-generation network. At the moment, mobile Web suffers from lack of interoperability and usability due to the small screen size and lower computational capability. Fortunately, these limitations are only temporary, and within five years they will be easily overcome. The next-generation public networks will converge toward the mobile network, which will bring mobility to the forefront. Thus, mobile identity management will play a central role in addressing issues such as usability, privacy, and security, which are Wkey challenges for researchers in the mobile network. Since the initial launch of mobile Web services, customers have increasingly turned to their wireless phones to connect with family and friends and to obtain the latest news and information or even to produce content with their mobiles and then publish it. Mobile Web 2.055 is the enforcement of evolution and will enhance the user experience by providing connections in an easier and more efficient way. For this reason, it will be welcomed by the key actors as a well-established core service identity management tool for the next-generation mobile network. This mobile identity management will be used not only to identify, acquire, access, and pay for services but also to offer context-aware services as well as location-based services.
Mobility
The mobile identity may not be stored in one location but could be distributed among many locations, authorities, and devices.
Indeed, identity is mobile in many respects56:
• There is device mobility, where a person is using the same identity while using different devices
• There is location mobility, where a person is using the same devices while changing location.
• There is context mobility, where a person is receiving services based on different societal roles: as a parent, as a professional, and so on.
The three kinds of mobility are not isolated; they interact often and became concurrently modified, creating much more complex situations than that implied from single mode. Mobile identity management addresses three main challenges: usability via context awareness, trust based on the perception of secure operation, and privacy protection.57
Evolution of Mobile Identity
Mobile identity management is in its infancy. GSM networks, for example, provide management of Subscriber Identity Module (SIM) identities as a kind of mobile identity management, but they do not meet all the requirements for complete mobile identity management.
Unlike static identity, already implemented in the Web 2.0 identity, dynamic aspects, such as the user’s position or the temporal context, gain increasing importance for new kinds of mobile applications.58
Mobile identity (MId) infrastructure solutions have evolved over time and can be classified into three solutions. The first is just an extension of wired identity management to the mobile Internet. This is a widespread solution that is limited to the users of mobile devices running the same operating system as wired solutions. This limitation is expected to evolve over time, mainly with the large deployment of Web services. Some specifications, such as Liberty Alliance specifications, have been developed for identity management, including mobility. However, several limitations are observed when the MId system is derived from a fixed context. These limitations are principally due to the assumptions during their design and they do not match well with extra requirements of mobility.59
Many improvements such as interoperability, privacy, and security are to come, and also older centralized PKI must be replaced by modern trust management systems, or at least a decentralized PKI.
The second solution is capable of providing an alternative to the prevalent Internet-derived MId infrastructure consisting of either connected (cellular phones) or unconnected (smart cards) mobile devices. The third consists of using implantable radiofrequency identifier (RFID) devices. This approach is expected to increase rapidly, even if the market penetration is smaller than that of cellular phones.
In addition, the sensitivity risk of data related to different applications and services is seldom at the same level, and the number of identifiers used by a person is constantly increasing. Thus, there is a real need of different kinds of credentials associated with different kinds of applications. Indeed, a tool on the user side that’s capable of managing user credentials and identities is inevitable. With the increasing capacity of CPU power and the spreading number of mobile phones with SIM cards, a mobile phone can be considered a personal authentication device (PDA). Cell phones can securely hold user credentials, passwords, and even identities. Therefore we introduce a new, efficient identity management device on the user side that’s able to on one hand facilite memorization and on the other hand, strengthen security by limiting the number of passwords and their weaknesses. All wired identity management can be deployed using PADs. In addition, many different authentication architectures, such as dual-channel authentication, become possible and easy to implement.
PADs as a Solution to Strong Authentication
A PAD60 is a tamper-resistant hardware device that could include smart cards and sensors or not. This term was used early in the context of security by Wong et al.61 The approach is the same; the only thing changed so far is that the performance of the mobile device has radically changed. This is the opportunity to emphasize the user centricity, since the PAD can strengthen the user experience and facilitate the automation and system support of identity management on the user side. Figure 17.22 illustrates the combination of the PAD and silo model. The user stores his identity in the PAD; whenever he would like to connect to a service provider:
1. He authenticates himself with a PIN code to use the PAD.
2. He chooses the password to be used for his connection to the specific service provider.
3. He launches and logs in to the specific service provider by entering his username and password.
Figure 17.22 Integration of a PAD in the silo model.
The PAD is a good device to tackle the weakness and inconvenience of password authentication. It provides a user-friendly and user-centric application and even introduces stronger authentication. The fundamental advantage of PADs compared with common PCs using common operating systems such as Windows or Linux is that PADs have a robust isolation of processes. Therefore, compromising one application does not compromise all the applications. This advantage is becoming less important for mobile phones; as manufacturers introduce flexibility, many vulnerabilities are also introduced. We have seen many viruses for mobile phones and even nowadays we have viruses for RFID. This vulnerability can compromise authentication and even biometrics authentication. That’s why we should be very vigilant in implementing security in PAD devices. An ideal device is the USB stick running a standalone OS and integrating a biometric reader and mobile network access. You can find some of these with fingerprint readers for a reasonable price.
Two main categories can group many authentication architectures that could be implemented in a PAD. They are single- and dual-channel authentications. Thereby, the cost, risk, and inconvenience can be tackled at the same time.
Figure 17.23 illustrates the principle of single-channel authentication, which is the first application of the PAD. Figure 17.24 illustrates the second principle of dual-channel authentication, which is more secure.
Figure 17.23 Single-channel authentication.
Figure 17.24 Dual-channel authentication.
Types of Strong Authentication Through Mobile PADs
The mobile network, mainly GSM, can help overcome many security vulnerabilities, such as phishing or man-in-the-middle (MITM) attacks. It attracts all businesses that would like to deploy dual-channel authentication but worry about cost and usability. The near-ubiquity of the mobile network has made feasible the utilization of this approach, which is even being adopted by some banks.
SMS-Based One-Time Password (OTP)
The main advantages of mobile networks are the facility and usability to send and receive SMSs. Moreover, they could be used to set up and easily download Java programs to a mobile device. In addition, mobile devices are using smart cards that can securely calculate and store claims.
The cost is minimized by adopting a mobile device using SMS to receive OTP instead of special hardware that can generate OTP.
The scenario implemented by some banks is illustrated in Figure 17.25 and described as follows. First, the user switches on her mobile phone and enters her PIN code. Then:
1. The user logs in to her online account by entering her username and password (U/P).
2. The Web site receives the U/P.
3. The server verifies the U/P.
4. The server sends an SMS message with OTP.
5. The user reads the message.
Figure 17.25 A scenario of SMS double-channel authentication.
The problem with this approach is the fact that the cost is assumed by the service provider. In addition, some drawbacks are very common, mainly in some developing countries, such as lack of coverage and SMS latency. Of course, the MITM attack is not overcome by this approach.
Soft-Token Application
In this case, the PAD is used as a token emitter. The application is previously downloaded. SMS could be sent to the user to set up the application that will play the role of soft token.
The scenario is identical to the SMS, only the user generates her OTP using the soft token instead of waiting for an SMS message. The cost is less than the SMS-based OTP. This approach is a single-channel authentication that is not dependent on mobile network coverage nor latency. Furthermore, the MITM attack is not tackled.
Full-Option Mobile Solution
We have seen in the two previously scenarios that the MITM attack is not addressed. There exists a counterattack to this security issue consisting of using the second channel to completely control all the transactions over the online connection. Of course, the security of this approach is based on the assumption that it is difficult for an attacker to steal a user’s personal mobile phone or attack the mobile network. Anyway, we have developed an application to crypt the SMS message, which minimizes the risk of attacks. The scenario is illustrated in Figure 17.26 and is as follows:
1. The user logs in to his online account using a token.
2. The server receives the token.
3. The server verifies the token.
4. Access is given to the service.
5. The user requests a transaction.
6. An SMS message is sent with the requested transaction and a confirmation code.
7. The user verifies the transaction.
8. He enters the confirmation code.
Figure 17.26 Secure transaction via SMS.
The Future of Mobile User-Centric Identity Management in an Ambient Intelligence World
Ambient intelligence (AmI) manifests itself through a collection of everyday devices incorporating computing and networking capabilities that enable them to interact with each other, make intelligent decisions, and interact with users through user-friendly multimodal interfaces. AmI is driven by users’ needs, and the design of its capabilities should be driven by users’ requirements.
AmI technologies are expected to combine concepts of ubiquitous computing and intelligent systems, putting humans in the center of technological developments. Indeed, with the Internet extension to home and mobile networks, the multiplication of modes of connection will make the individual the central point. Therefore, user identity is a challenge in this environment and will guarantee infatuation with AmI. Moreover, AmI will be the future environment where we will be surrounded by mobile devices that will be increasingly used for mobile interactions with things, places, and people.
The low cost and the shrinking size of sensors as well as the ease of deployment will aid AmI research efforts for rapid prototyping. Evidently, a sensor combined with unique biometric identifiers is becoming more frequently utilized in accessing systems and supposedly provides proof of a person’s identity and thus accountability for subsequent actions.
To explore these new AmI technologies, it is easiest to investigate a scenario related to ubiquitous computing in an AmI environment.
AmI Scenario
A person with a mobile device, GPS (or equivalent), and an ad hoc communication network connected to sensors visits an intelligent environment supermarket and would like to acquire some merchandise. Here we illustrate how this person can benefit from a mobile identity.
When she enters the supermarket, she is identified by means of her mobile device or implemented RFID tag, and a special menu is displayed to her. Her profile, related to her context identity, announces a discount on goods, if there is one.
The members of her social network could propose a connection to her, if they are present, and could even guide her to their location. Merchandise on display could communicate with her device to show prices and details. Location-based services could be offered to quickly find her specific articles.
Her device could help her find diabetic foods or any restrictions associated with specific articles. A secure Web connection could be initiated to give more information about purchases and the user account. The supermarket could use an adaptive screen to show her information that is too extensive for her device screen.
Payment could be carried out using the payment identity stored in the user’s device, and even a biometric identity to prevent identity theft. Identity information and profiling should be portable and seamless for interoperability. The identity must be managed to ensure user control. Power and performance management in this environment is a must. The concept of authentication between electronic devices is also highlighted.
To use identity management, the user needs an appropriate tool to facilitate managing disclosure of personal data. A usable and secure tool should be proposed to help even inexperienced users manage their general security needs when using the network.
We need mobile identity management, which is a concept that allows the user to keep her privacy, depending on the situation. By using identity management, the user’s device acts in a similar way to the user. In different contexts, the user presents a different appearance. Devices controlled by identity management change their behavior, similar to the way a user would.
Requirements for Mobile User-Centric Identity Management in an AmI World
As the network evolution is toward mobility with the proliferation of ubiquitous and pervasive computing systems, the importance of identity management to build trust relationships in the context of electronic and mobile (e/m) government and business is evident.62,63 All these systems require advanced, automated identity management processes to be cost effective and easy to use.
Several mobile devices such as mobile phones, smart cards, and RFID are used for mobility. Because mobile devices have fixed identifiers, they are essentially providing a mobile identity that can be likened to a user. Mobile identity takes into account location data of mobile users in addition to their personal data. A court decision in the United Kingdom established, as proof of location of the accused, the location trace of his mobile phone, which implies a de facto recognition of the identity of a citizen as the identity of his mobile telephone.64
That is why mobile identity management (MIdm) is necessary to empower mobile users to manage their mobile identities, to enforce their security and privacy interests. Mobile identity management is a special kind of identity management. For this purpose, mobile users must be able to control the disclosure of their mobile identities, dependent on the respective service provider, and their location via mobile identity management systems.
Ambient intelligence emphasizes the principles of secure communication anywhere, anytime, with anything. The evolution of AmI will directly influence identity management with this requirement to ensure mutual interaction between users and things. Being anywhere will imply more and more mobility, interoperability, and profiling. At any time will imply that online as well as offline connection because the network does not have 100% coverage and will imply power as well as performance management to optimize battery use. With anything will imply sensor use, biometrics, and RFID interaction; and securely implies more and more integration of privacy, authentication, anonymity, and prevention of identity theft.
From multilateral security,65,66 Jendricke67 has derived privacy principles for MIdm; we have completed them below with a few other important principles.
Management systems:
• Protection of location information
• Segregation of power, separating knowledge, integrating independent parties
• Trusted seals of approval seal
• Comfortable and informative user interfaces
• Reduction of system complexity
• Power of market: Produce Mobile Identity Management Systems (MIMS) that are competitive and are able to reach a remarkable penetration of market
• Using open-source building blocks
• Subsidies for development, use, operation, etc.
9. Power management: the energy provided by the batteries of mobile devices is limited and that energy must be used with care on energy-friendly applications and services
10. Online and offline identity proof
11. Small screen size and lower computational capability
• Identity needs to be portable to be understood by any device
Research Directions
Future identity management solutions will play a more central role in the IT industry due to the pervasiveness and increased presence of identity information in all components of the IT stack. The Liberty Alliance specifications provide a standardized solution to the problem of lack of capability for mobile identity. The specified architecture will have an impact on the architecture of mobile services. However, many open issues remain to be considered.
There will be many issues raised concerning identity and mobility. All strong platforms combining identity management and mobility play a central role and will be key elements for the progress of the ambient intelligence network; they will also represent the main vehicle for the information society.
Here we list a few of the most important research questions in the field of mobile user-centric identity management:
• Requirements. How can we satisfy the requirements of mobile identity management in mobile systems and devices?
• Mobility. How can we manage identity when the device is offline? How can we manage biometric information? How can mobility and biometrics help in authentication?
• Privacy. What are the needed identity management controls to preserve individual privacy? How can we guarantee anonymity? How can we protect the user from location/activity tracking?
• Forensic science. What is the reliability of the identity management system, and how can evidence extracted from the system be used in court? What protections are in place for the identity holder or for the relaying party?
• Costs of infrastructure. How can we limit the cost of mobile identity management?
• Interoperability. How can we evolve toward higher levels of interoperability?
• Efficiencies. How can we efficiently integrate sensors, RFIDs, and biometrics into mobile identity management systems? How can we manage performance of mobile devices? How can we integrate usability into mobile identity usage?
• Identity theft. Does large-scale deployment of identity management systems make it easier or harder to perpetrate identity theft or identity fraud? How can we deal with theft of devices or identities?
• Longevity of information. Do mobile identity management systems provide adequate care in tracking changes in identity information over time?
• Authenticity of identity. What are the trust services that must be in place to generate confidence in the identity management service?
5. Conclusion
The Internet is increasingly used, but the fact that the Internet has not been developed with an adequate identity layer is a major security risk. Password fatigue and online fraud are a growing problem and are damaging user confidence.
Currently, major initiatives are under way to try to provide a more adequate identity layer for the Internet, but their convergence has not yet been achieved. Higgins and Liberty Alliance seem to be the most promising ones.
In any case, future identity management solutions will have to work in mobile computing settings, anywhere and anytime.
This chapter has underlined the necessity of mobility and the importance of identity in future ambient intelligent environments. Mobile identity management will have to support a wide range of information technologies and devices with critical requirements such as usability on the move, privacy, scalability, and energy-friendliness.
1G. Roussos and U. Patel, “Mobile identity management: An enacted view,” Birkbeck College, University of London, 2003.
2A. Westin, Privacy and Freedom, Athenaeum, 1967.
3J. Madelin et al., BT report, “Comprehensive identity management balancing cost, risk and convenience in identity management,” 2007.
4T. Miyata et al., “A survey on identity management protocols and standards,” IEICE TRANS. INF & SYST, 2006.
5J.-M. Seigneur, “Trust, security and privacy in global computing,” Ph. D. thesis, Trinity College Dublin, 2005.
6Introduction to the Liberty Alliance Identity Architecture, Rev. 1.0, March 2003.
7A.B. Spantzel et al., “User centricity: A taxonomy and open issues,” IBM Zurich Research Laboratory, 2006.
8Phillip J. Windley : “Unmasking identity management architecture: digital identity” O’Reilly, August 2005.
9J. Madelin et al., BT report, “Comprehensive identity management Balancing cost, risk and convenience in identity management,” 2007.
10Independent Center for Privacy Protection (ICPP) and Studio Notarile Genghini (SNG), “Identity management systems (IMS): Identification and comparison study,” 2003.
11Independent Center for Privacy Protection (ICPP) and Studio Notarile Genghini (SNG), “Identity management systems (IMS): Identification and comparison study,” 2003.
12J.-M. Seigneur, “Trust, security and privacy in global computing,” Ph. D. thesis, Trinity College Dublin, 2005.
13K. Cameron, “Laws of identity,” May, 2005.
14A. Westin, Privacy and Freedom, Athenaeum, 1967.
15T. M. Cooley, “A treatise on the law of torts,” Callaghan, Chicago, 1888.
16Independent Center for Privacy Protection (ICPP) and Studio Notarile Genghini (SNG), “Identity management systems (IMS): identification and comparison study,” 2003.
17K. Cameron, “Laws of identity,” May, 2005.
18David Recordon VeriSign Inc, Drummond Reed, “OpenID 2.0: A platform for user-centric identity management”, 2006.
19R. Au, H. Vasanta, K. Kwang, R. Choo, M. Looi, “A user-centric anonymous authorisation framework in ecommerce, environment information security research centre,” Queensland University of Technology, Brisbane, Australia.
20R. Au, H. Vasanta, K. Kwang, R. Choo, M. Looi, “A user-centric anonymous authorisation framework in ecommerce, environment information security research centre,” Queensland University of Technology, Brisbane, Australia.
21Federal Financial Institutions Examination Council, authentication in an internet banking environment, October 2005, www.ffiec.gov/press/pr101205.htm.
22A. Erzberg and A. Gbara, TrustBar: protecting even Naïve) web users from spoofing and phishing attacks, www.cs.biu.ac.il/~erzbea/papaers/ecommerce/spoofing.htm, 2004.
23Introduction to usability, www.usabilityfirst.com/intro/index.tx1, 2005.
24J.-M. Seigneur, “Trust, security and privacy in global computing,” Ph. D. thesis, Trinity College Dublin, 2005.
25A. Jøsang and S. Pope, “User-centric identity management,” AusCERT Conference 2005.
26International telecommunication union (ITU), Geneva, www.itu.org.
27A. Jøsang et al., “Usability and privacy in identity management architectures,” (AISW2007), Ballarat, Australia, 2007.
28A.B. Spantzel et al., “User centricity: A taxonomy and open issues,” IBM Zurich Research Laboratory, 2006.
29A. Jøsang and S. Pope, “User-centric identity management,” ausCERT conference 2005.
30A. Jøsang et al., “Usability and privacy in identity management architectures,” (AISW2007), Ballarat, Australia, 2007.
31Internet2, Shibboleth project, http://shibboleth.Internet2.edu.
32C. Esslison et al., RFC 2693- SPKI Certification Theory. IETF, Sep. 1999, www.ietf.org/rfc/rfc2693.txt.
33T. Miyata et al., “A survey on identity management protocols and standards,” IEICE TRANS. INF & SYST, 2006.
34A.B. Spantzel et al., “User centricity: A taxonomy and open issues,” IBM Zurich Research Laboratory, 2006.
35A. Jøsang and S. Pope, “User-centric identity management,” AusCERT Conference 2005.
36Microsoft, A technical ref. for InfoCard in Windows, http://msdn.microsoft.com/winfx/reference/infocard/ 2005.
37G. Roussos and U. Patel, “Mobile identity management: An enacted view,” Birkbeck College, University of London, 2003.
38Higgins Trust Framework project, www.eclipse.org/higgins/, 2006.
39Yadis, “Yadis specification 1.0,” released March 2006, http://yadis.org.
40OASIS Working Draft Version 04, “An Introduction to XRIs,” March 14, 2005.
41OASIS, “Conformance requirements for the OASIS Security Assertion Markup Language (SAML),” Vol. 20, 2005.
42Internet2, Shibboleth project, http://shibboleth.Internet2.edu.
43Liberty Developer Tutorial, www.projectliberty.org/resources/ LAP_ DIDW_Oct-15_2003_jp.pdf.
44SACML, www.oasis-open.org/committees/tc_home.php?wg_ abbrev=xacml.
45Liberty Alliance, “Liberty ID-FF architecture overview,” Liberty Alliance Project, 2005.
46Liberty Alliance, “Liberty developer tutorial,” http://www.projectliberty.org www.projectliberty.org.
47T. Miyata et al., “A survey on identity management protocols and standards,” IEICE TRANS. INF & SYST, 2006.
48David Recordon VeriSign Inc, Drummond Reed, “OpenID 2.0: A platform for user-centric identity management”, 2006.
49Microsoft, “A technical ref. for InfoCard in Windows,” http://msdn.microsoft.com/winfx/reference/infocard/, 2005.
50J. Merrels, “SXIP identity. DIX: Digital Identity Exchange protocol.” Internet draft, March 2006.
51U. Jendricke et al., Mobile Identity Management, UBICOMP 2002.
52Higgins Trust Framework project, www.eclipse.org/higgins/, 2006.
53S. Garfinkel and B. Rosenberg, RFID, Applications, Security and Privacy, Addison-Wesley, 2006.
54S. A. Weis et al., “Security and privacy aspects of low-cost radio frequency identification systems,” Proc. Of First International Conference on Security in Pervasive Computing, March 2003
55A. Jaokar and T. Fish, Mobile Web 2.0, A book, 2007.
56G. Roussos and U. Patel, “Mobile identity management: An enacted view,” Birkbeck College, University of London, 2003.
57G. Roussos and U. Patel, “Mobile identity management: An enacted view,” Birkbeck College, University of London, 2003.
58M. Hoffmann, “User-centric identity management in open mobile environments,” Fraunhofer-Institute for Secure Telecooperation (SIT).
59G. Roussos and U. Patel, “Mobile Identity Management: An enacted view,” Birkbeck College, University of London, 2003.
60A. Jøsang et al., “Trust requirements in identity management,” AISW 2005.
61Wong et al. “Polonius: an identity authentication system,” Proceedings of the 1985 IEEE Symposium on Security and Privacy.
62MyGrocer Consortium, “MyGrocer white paper,” 2002.
63M. Wieser, “The computer for the twenty-first century,” Scientific American, 1991.
64G. Roussos and U. Patel, “Mobile identity management: An enacted view,” Birkbeck College, University of London, 2003.
65K. Rannenberg, “Multilateral security? A concept and examples for balanced security,” Proc. 9th ACM New Security Paradigms Workshop, 2000.
66K. Reichenbach et al. “Individual management of personal reachability in mobile communications,” Proc. IFIP TC11 (September ‘97).
67U. Jendricke et al., “Mobile identity management,” UBICOMP 2002.