Economic tussles in federated identity management
First Monday

Economic tussles in federated identity management by Susan Landau and Tyler Moore



Abstract
Federated identity management (FIM) enables a user to authenticate once and access privileged information across disparate domains. FIM’s proponents, who see the technology as providing security and ease of use, include governments and leaders in the IT industry. Indeed, a cornerstone of the current U.S. government’s efforts to secure cyberspace is its “National Strategy for Trusted Identities in Cyberspace” (U.S. Department of Commerce, 2011). Yet adoption of federated identity management systems has been slow.

From disputes over liability assignment for authentication failures to concerns over privacy, there have been many explanations for the slow uptake of federated identity management systems. We believe the problem is embedded in stakeholder incentives. We present an economic perspective of stakeholder incentives that sheds light on why some applications have embraced FIM while others have struggled. To do so, we begin by briefly analyzing seven use cases of successful and unsuccessful FIM deployments. From this we identify four critical tussles that may arise between stakeholders when engineering a FIM system. We show how the successful deployments have resolved the tussles, whereas the unsuccessful deployments have not. We conclude by drawing insights on the prospects of future FIM deployments.

Contents

Introduction
1. Players in federated identity management systems
2. Federated identity management systems: Use case successes and failures
3. Empirical analysis of online authentication
4. Tussles in federated identity management
5. Federated identity use cases revisited
6. Insights and concluding remarks

 


 

Introduction

Federated identity management (FIM) provides a way to share user authentication information across a variety of domains [1]. Such systems allow a user to authenticate once — single sign–on (SSO) — and then use that identity to access information across multiple security domains. Data sharing across domains creates efficiencies, and FIM is potentially powerful. By authenticating an individual in a new domain as a member of a group authorized for access, FIM can even provide increased privacy for the user. But federated identity management also creates complexities. In blurring security boundaries, FIM creates potential liabilities and privacy risks.

In 2001, industry began developing federated identity systems for “single sign–on” online identity management. These early systems had problems. Microsoft’s centralized system, Passport, had privacy and security risks, and was eventually abandoned. Meanwhile the inter–industry Liberty Alliance effort was designed to satisfy the needs of the enterprise environment. While the Liberty Alliance standards gained traction in the enterprise market, the system was not broadly adopted.

As the Internet changed, user authentication needs shifted. On the one side, with blogging and its associated commenting, sites sought a lightweight identity system in order to avoid spam and exercise a modicum of control over commenters. OpenID, whose mechanisms were based on e–mail addresses and were easy to use, filled this need. But the OpenID mechanisms came at a cost of being quite a bit less than secure. There was simultaneously a pull for increased security. With critical infrastructure increasingly being brought online, and high–level cyber exploitations of U.S. industry occurring, the need for robust online authentication had increased. OpenID did not fill this need.

The U.S. government has long perceived federated identity to be a crucial component of e–government. In 2002 the government developed a prototype federated PKI bridge for cross–department authentication (U.S. General Accounting Office, 2003). But e–government solutions did not emerge. Indeed, even with increased demands for secure online authentication from both the public and private sectors, no simple, easy, secure, privacy–preserving online authentication system for everyday use appeared. Instead, a host of explanations for its failure did.

Outstanding technical issues included the assignment of levels of assurance on authentication, the types of authentication technologies to be used, and agreement on policies for issuing, retaining, and revoking authentication [2]. Privacy was a big issue; policies for data privacy were not sufficiently settled (Camp, 2010). The U.K.’s recent experience with identity cards demonstrates that if private data is not protected, the system may not be adopted; public concerns over the retention of transactional information into large databases (Anderson, et al., 2009) helped derail the U.K. government’s planned identity card scheme [3]. Interoperability between the private–sector systems was lacking [4]. Furthermore, liability was seen to be a big stumbling block. Thus when Wells Fargo finally agreed to serve as an identity credentialer, it was only under a liability “holds harmless” arrangement for any resulting damages (U.S. Federal Public Key Infrastructure Authority, 2008).

The FIM experience of the last decade was not entirely negative, however. There were successful FIM deployments, including Shibboleth (http://shibboleth.net/) in higher education, Liberty Alliance protocols (later SAML) in enterprises, and the National Institutes of Health federated identity management program. The real issue is that federated identity management has not been broadly deployed in the wider Internet. Federated identity management has functioned well in sectors in which the parties had first established contracts. On the “open” Internet, where Identity Providers (IdPs) and Service Providers (SPs) might not previously have had a relationship, uptake on federated identity management has been very slow. It is widely believed that the inability to solve the liability issue — who would bear the costs when federated systems inappropriately shared information or incorrectly authenticated a user — is at the root of the issue (Camp, 2010; U.S. Department of Commerce, 2011).

We believe liability is just one piece of a problem whose root lies in a more complex tangle of economic issues. The design of federated identity management systems is a classic case of economic tussle. Where systems have been successful, it has been because benefits accrue to both sides. Where such systems have so far failed to achieve traction has been when the systems are weighted so that the benefits largely accrue to only one side. Rather than liability alone, the problem is actually one of maladjustment to the economic tussle. Consequently, if one can readjust the values in those systems so as to provide clear — and relatively balanced — benefits to all parties, then the federated system is much more likely to succeed.

We begin in the next section with a brief description of the players in a federated system. We continue in Section 2 with an examination of a number of use cases in federated identity management, both failures and successes. In Section 3, we present empirical evidence that lends support to the claim that a key reason why Facebook’s Web authentication mechanism has attracted more adoption than OpenID is that Facebook shares more extensive user information than OpenID identity providers. In Section 4, we consider the tussles that may arise. In Section 5, we re–examine the use cases with those tussles in mind. Finally in the last section, we close with a discussion of the insights made possible by examining federated identity management through the lens of economic tussle.

 

++++++++++

1. Players in federated identity management systems

Federated identity management systems have four main components:

  • The user (or user agent such as a browser) who has a particular digital identity that interacts with a network application;

  • The Identity Provider (IdP), whose role is to authenticate the user and that may store attributes about the the user;

  • The Service Provider (SP), an application which provides services to the user and which relies on the Identity Provider to perform user authentication; and,

  • The Identity Management Platform, a framework or set of rules defining how IdPs, SPs and users interact.

Note that the Service Provider is sometimes also called the Relying Party (RP).

The classic use case, described by the Liberty Alliance Project (2002), is of a user logging into an airline reservation system, authenticating himself, making bookings for a flight, then visiting car rental and hotel sites. If these sites are federated with the airline as an Identity Provider, the user is able to make reservations at the car rental and hotel sites using the airline system’s authentication system without any need for reauthentication. Another example is that of a user at a corporation who has authenticated herself to the corporate system and then accesses an outsourced online service, such as a travel agent or health insurance provider. The user is able to access the outsourced services without further authentication. This is the single sign–on provided by federated identity management. Depending on arrangements, the services themselves may themselves be able to access protected corporate resources.

The method for authentication varies: the SP can initiate the authentication request to an IdP that the user designates when signing onto the SP, or the user may first authenticate herself at the IdP and then access an SP. In either case, the technology enables single sign–on (SSO), in which the IdP authenticates the user, thus allowing her access to protected resources at an SP.

 

Federated identity management
 
Figure 1: Federated identity management.

 

Federated identity management is an example of a two–sided market (Rochet and Tirole, 2003), where two types of users are served by a common platform. As shown in Figure 1, the two sides in federated identity management are Identity Providers and Service Providers. Two–sided markets exhibit cross–side network effects: the value of the platform to one type of user depends on the number of users of the other type. This effect tends to yield very dominant platforms. Other examples of two–sided markets include payment–card networks (card–holders and merchants), newspapers (advertisers and subscribers), and operating systems for both PCs and phones (users and application developers).

One crucial aspect of identity management is the level of trust that can be placed in the identity claims. How much can the Service Provider rely on the assertions made by the Identity Provider? The degree of certainty a Service Provider has regarding an authentication after receiving after receiving an identity assertion from the Identity Provider is called “assurance.” Now authentication is a multi–step process that starts with a proofing mechanism that binds an identity (e.g., an e–mail address or a user name) to a token (e.g., a hardware token or a password), uses a remote mechanism for authenticating, and has a mechanism for communicating the results of the remote authentication [5]. Building on that, the U.S. National Institute of Standards and Technology (NIST) developed a set of four identity “Assurance Levels” [6]:

  • Level 1: At level 1, there is no identity proofing; names are assumed to be pseudonyms. Authentication requires that the user demonstrate that she controls the token. The sole protection of user secrets comes from the requirement that user proofing data not travel in the clear. All that level 1 mechanisms do is provide some assurance that it is the same user who is accessing the protected data [7].

  • Level 2: At level 2, some identity proofing is required. (There are different requirements depending on whether the identity proofing is in person or remote; if in person, the user must show a valid current government identity document that has a picture as well as either nationality or address of record, while if remote, a financial account number is also required [8].) Passwords and PINs are allowed for authentication, as are more secure forms of authentication such as hardware tokens. There are system security requirements, e.g., there must be mechanisms to handle revocation of credentials, passwords must be a certain strength, etc. [9].

  • Level 3: At level 3, the identity documents must be verified, with a higher level of proofing on the identity than for level 2, and two–factor authentication is required [10]. In addition, the level 3 authentication mechanisms require cryptographic–strength protection of the primary authentication token [11]; this token can be unlocked through a key or biometric [12].

  • Level 4: At level 4, identity proofing can only occur in person; the government ID is to be verified with the issuing agency [13]. The assertion mechanism is “hardened,” that is, only “hard” cryptographic tokens can be used, the FIPS 140–2 cryptographic module validation requirements are strengthened, and all critical data transfers are authenticated through a key bound to the authentication process. The user must prove that they control the hardware token [14]. The NIST assurance levels have also been adopted by other governments for providing e–government services, including the U.K. and Canada, as well as for many other identity management systems.

The value of federated identity management is its simplification of function: authentication is separated from the process of accessing resources. Everyone — the user, IdP and SP — can benefit [15]. The user only has to log in once with a single set of credentials. The Identity Provider can focus on improving the process of authentication, perhaps providing different modes of strengths of authentication, perhaps providing other services. The Service Provider no longer has to handle authentication — a messy, problematic business — and can focus instead on the provision of services. It would seem as if everyone benefits by this simplifying of roles. That is exactly the issue we wish to study further, so with this brief introduction, we turn to examining specific use cases.

 

++++++++++

2. Federated identity management systems: Use case successes and failures

Tolstoy wrote, “Happy families are all alike but every unhappy family is unhappy after its own fashion.” [16] Federated identity management are the reverse. Successful deployments are all alike in their technology, but differ in what enables their success; unsuccessful deployments are all alike in their cause for failure to overcome economic tussles.

We examine four successful federated deployments: InCommon, a higher education–based resource–sharing system, the National Institutes of Health efforts in federated identity management with research institutions, Sun’s federation with its outsourced human resources partner, Hewitt, and Aetna’s system for managing medical billing. We then consider two less successful efforts: a federal government effort to promote information sharing across law–enforcement agencies and the OpenID framework for online authentication. We conclude this section by describing payment–card networks, which, while not strictly an FIM deployment, authenticate payments by individuals and have underpinned the successful rise of electronic commerce.

2.1. InCommon and online sharing of resources

Even in the Internet age, sharing of information resources form an integral part of universities’ fundamental mission. The question arose of how to build an infrastructure supporting relatively frictionless information–sharing resource sharing between higher education institutions.

One solution was InCommon. As of January 2011, InCommon serves 189 higher education institutions, eight government and non–profit research labs, centers, and agencies, and 69 “sponsored partners,” including publishers, and medical libraries (InCommon, 2011). InCommon vets each institution’s credential–provisioning system: who provides them, how they are given out, how long they last, what information is made public in the identity database, what is kept private, and so on. Shibboleth [17] is the technology used for sharing secured Web resources and services among InCommon members. Identity Providers are typically higher education institutions, while the Service Providers are libraries, commercial information providers (e.g., LexisNexis), and even individual labs and research groups.

For Shibboleth, privacy was central from the beginning. This was partially because the U.S. Family Educational Rights and Privacy Act [18] protects the privacy of student educational records, possibly including library records. Second, librarians regard user privacy as inherent to the library’s mission [19]. Shibboleth was developed so that “the users should control what personal information is released and to whom, and the resource provider should only receive as much user information as needed to make access control decisions unless the user chooses to release more.” [20].

Privacy is thus protected. User login, which frequently functions as a user ID, is just an attribute in the Shibboleth design. Users are identified by their rights to the resources: as a member of a campus, as a member of a course, as a member of a cross–institution research group accessing shared resources. The user ID is to be shared only if access to the resource requires it [21]. The benefits to the user are clear: simple privacy–protecting access to information resources.

The benefits to the Identity Providers are also clear, for InCommon broadens access to resources in a privacy–preserving and extensible manner. IdPs do not need to build pair–wise relationships with each of the SPs; the Shibboleth infrastructure takes care of that.

There is also clear benefit to the Service Providers. One aspect of this is that SPs only have to handle authorizing groups of users from <this campus, that research group, this course>. Thus SPs are no longer responsible for authenticating users outside their own domain.

In addition, Shibboleth provides better security than previous solutions for such remote access. Morgan, et al. [22] describe how JSTOR (http://www.jstor.org/), a non–profit organization maintaining an archive of scholarly journals, had used a system of allowing access from a block of IP addresses allocated to an institution. This was problematic in several ways: users not on campus could not easily access JSTOR resources, while a sub–block of addresses might incorrectly indicate a university site (e.g., if they belonged to a private contractor). But the interactive authentication system afforded by Shibboleth provided more nuanced and far better security. An interesting benefit is that use of Shibboleth enables JSTOR to personalize services to the user — even though it doesn’t necessarily know whom the user is!

In sum, the InCommon system is a clear win for all participants: Identity Providers, Service Providers, and users.

A very similar project is the Nordic Where Are You From (WAYF) effort, which provides federated identity management support for higher education and research institutions. Founded by institutions in Norway, Denmark, and Finland, WAYF currently has 110 identity providers and 50 service providers (WAYF, 2011). The model for WAYF is a federation of “national federations” from Denmark, Finland, Norway, and Sweden. A particularly interesting aspect about WAYF is that it handles cross–border authentication. All applications are authenticated at least to level of assurance 2. Another interesting aspect of the federation is that there is bank participation in WAYF as an IdP. However, that is an outgrowth of banks running the Danish NemLog–in, a single sign–on system for citizen access to public services (banks won the contract to run the service). NemLog–in operates as an IdP for WAYF. There is currently no other role for banks with WAYF. While there is no objection to banks functioning as IdPs, thus far a business case has not been made for doing so (Simonsen, 2011).

2.2: InCommon and the National Institutes of Health

The National Institutes of Health (NIH, http://www.nih.gov/) is the premier U.S. government agency performing biomedical research. Or, from the point of view of some of its employees, NIH is a government institution, a set of research laboratories, and, on occasion, a patient–facing organization. These multiple roles mean that there are a plethora of requirements for NIH researchers to follow. This includes U.S. government regulations that applications and services should be online and that these should satisfy appropriate authorization requirements on secure identity management. If the application or service does not comply with federal requirements, research funding can be taken away (which has happened) [23].

NIH researchers also often collaborate with researchers from universities and national laboratories both in the U.S. and abroad. This results in a remarkable array of differing authentication requirements that are quite difficult for an individual researcher to satisfy. NIH uses federated identity management to manage this access to resources.

NIH relies on InCommon to vet member institutions but adopts a finer grained vetting of departments within a member institution (e.g., Duke Medical School, rather than Duke University). The NIH system relies on the application to determining the level of assurance (as outlined in Section 2) required. The NIH Login system manages the technology for accomplishing the login, while the NIH Chief Information Office manages the trust relationships (e.g., InCommon, relationships with the FDA and CDC, etc.) underlying the technologies [24].

The result: the researcher tells NIH Login who her users are; the users authenticate with their home institution; the NIH federated login maintains a list of institutions trusted to perform authentication (this may be accomplished through the use of InCommon). It is a system in which, again, everyone benefits. The researcher focuses on research, and her lab resources are not spent on vetting remote users; the Identity Providers vet their own participants, and the Service Providers are able to trust those vettings (and the Identity Providers and Service Providers often change roles in this system).

2.3: Sun Microsystems outsourced services

Sun Microsystems Inc. was one of the original leaders on the Liberty Alliance effort. In Silicon Valley fashion, Sun elected to implement federation identity management in some of its outsourced services, a way of testing the feasibility of such systems and, in the long term, a way of achieving cost savings.

In this federation model, the user was the Sun employee, the IdP was Sun Microsystems, and SPs were the various outsourced entities, including Hewitt, which handled Sun’s Human Resources, and American Express, which handled Sun employees’ travel arrangements.

The protocols, open standards–based specifications for identity federation, competed with Microsoft’s Passport, which gave Sun a powerful incentive to support the work. On the other side, if Sun’s partners were able to succeed as Service Providers, they could use their experience to expand the effort to other companies. So both sides had strong business reasons for wanting the project to succeed. (The user, as a Sun employee, had little choice in this discussion.)

Much energy was expended on the initial legal contracts. Agreements were carefully drawn up on how to handle adding or withdrawing capabilities in the framework, upgrading authentication requirements in the future, and recovering from failures. The roles and responsibilities of the different institutions were carefully delineated. This included what Sun’s business project’s lead role was, what the SP business project’s lead was, what business support Sun would provide, what the partner would provide, what level of IT support would be expected of each entity, how quickly the parties would respond in case of failures, the process to be followed during security breaches, and penalties for being late or system outages.

In the end, none of this legal infrastructure was important. When problems, such as an employee getting the wrong access, did arise, both companies worked to solve the the problem without raising legal issues. A Sun employee described the tolerance by the fact that as an IT company, Sun knew that “such screw–ups did occur.” The reluctance to seek legal remedy was that Sun understood, “here but for the grace of <deity of choice> go I. We (in IT) well understand that it is difficult to get everything right, especially when you’re doing something for the first time. If the other party agrees to fix the problem, you just move on.” (Wilson, 2010)

The underlying reason for the spirit of cooperation was that Sun and Hewitt were both invested in the success of the project. So when difficulties arose both were motivated to solve the problem rather than to blame the other. Consequently, none of the carefully crafted legal remedies were put to use. There have been numerous Liberty/SAML identity management implementations enterprise settings, and similar motivating factors have contributed to their success. We discuss one such example, the billing system used by Aetna.

2.4: Aetna’s medical billing system

Aetna, the insurance company, has also deployed a federated system to manage the billing of medical practices. Aetna had been building its own identity assurance framework for online billing when the company discovered the NIST authentication guidelines (Burr, et al., 2006). They found that using a common reference model has reduced the cost of deployment, clarified requirements, simplified audit procedures, and has made working with partners more straightforward. Furthermore, Aetna saw using the NIST model as a way to increase identity assurance (Coderre, 2011). In the Aetna federated system, the Service Providers are medical billing offices (ranging from small practices to large). Aetna serves as an Identity Provider for credential provisioning (e.g., “this” practice is within our business network), as does NaviMedix, a provider of software for secure online systems, which manages the credentialing of the offices. The NIST standards for levels of assurance have proved particularly useful for coordinating the procedures used by Aetna and NaviMedix.

Both Aetna and NaviMedix function as IdPs in the Aetna system; Aetna is also a Service Provider, as are the billing offices. The identity system is designed to be compliant with the U.S. Health Information Portability and Accountability Act (HIPAA). Within a particular office, users are granted different access to different types of data based on their roles. Front–office staff can only access appointment and check–in information, while accounting staff can access claim and payment information [25]. Like the InCommon federation, the Aetna system is based on SAML (Security Access Mark–up Language) 2.0, an XML open standard for exchanging authentication and authorization information. SAML 2.0 represents a convergence of standards work in OASIS and the Liberty Alliance.

As of 2008, the Aetna system was used by three hundred thousand providers, with capacity for up to half a million [26]. What enabled success? NIST standards provided a common platform for Aetna and NaviMedix to handle identity credentialing, while SAML provided a robust infrastructure for conducting the online transactions. Just as in the case between Sun and its contractors, existing relationships between insurance companies and medical billing offices removed some natural friction and provided some necessary motivation to make the system work. Finally, government regulation helped. By clarifying the responsibilities of different organizations within the system to protect the privacy of patient information, as well as creating liability for failing to do so, HIPAA regulations provided a forcing function to press the project forward.

2.5: Information sharing across law–enforcement agencies

In the federal government, the post September 11th world heavily relies on “information sharing.” One example is Intellipedia, an information–sharing site for the intelligence community modeled on Wikipedia. The idea, proposed by the CIA Chief Technology Officer, is that any agent with classified clearance should be able to read or contribute relevant knowledge to the site. Another example is the joint Department of Justice and Department of Homeland Security Global Federated Identity and Privilege Management (GFIPM), a federated identity management system for the sharing of secure and trusted information.

GFIPM is a pilot project sponsored by the Criminal Information Sharing Alliance Network (CISA), the Pennsylvania Justice Network (JNET), and the Regional Information Sharing System Network (RISS) and run by the Georgia Institute of Technology. It has been somewhat successful, and numerous state and local agencies elected to participate [27]. But, as in any complicated system, a closer examination reveals some interesting details.

The first issue to note is that the information being shared regards state–level investigations, not federal ones. Thus, while the concerns include both criminal and national security issues, they are more heavily weighted to law enforcement issues. The second issue to note is an observation made by the Georgia Institute of Technology implementers: “IdPs are easier to integrate than SPs.” [28]

We believe that is key to understanding GFIPM’s limited success in deployment. GFPIM clearly provides benefit to users: a single sign on gives access to multiple sites. It also provides clear benefit to the Identity Providers: their users then have access to multiple sites, without any extra work on the side of the IdPs (except for the effort of developing the initial architecture). But the same issue that benefits the IdPs creates a problem for the Service Providers, for in letting users from other domains seamlessly enter into their systems, the SPs lose control.

This is a real deal breaker for handling sensitive information. As Nigriny and Sabett [29] — and numerous others — have observed, in the issue of security clearances, each agency trusts its own vetting process, but doubts the processes of other agencies [30]. They may also object to sharing secret information with outsiders, and resent the imposition from above that they share more extensively.

2.6: OpenID standard for online authentication

As explained earlier, Microsoft devised an identity management system called Passport whose platform was centralized and under its control. Passport was designed so that Microsoft was the sole identity provider. Unsurprisingly, very few Service Providers agreed to such terms.

The appeal of single-sign on for Internet services did not diminish following Passport’s failure, however. OpenID was established in 2005 as a non–profit platform using an open standard for federated identity management. In OpenID, notions of “identity” are very weak — typically, a password–protected user account on a Web–based e–mail service. For many online interactions, such as posting a comment on a blog, such a weak level of authentication is sufficient.

OpenID has recruited many Identity Providers but very few Service Providers. OpenID is attractive to end users, who stand to gain by reducing the number of online accounts they must maintain. The benefits of OpenID to Service Providers are much less obvious. Most Web services are supported by advertising, so collecting targeted demographic information on a Web site’s users is very valuable. While OpenID has developed an attribute exchange mechanism that allows for rich exchange of user demographic information, Identity Providers are free to choose which characteristics to share. To date, most IdPs have elected to share very few user details with service providers. For instance, with user consent, Google will share name, country, e–mail address and language (Google, 2011). Upon request, Yahoo shares name, e–mail address, profile picture and gender (Yahoo, 2009). Given such limited information, many providers would rather use their own registration mechanisms to collect richer user profiles.

Meanwhile, the benefits accrued to OpenID Identity Providers are much clearer than those to Service Providers. OpenID encourages user loyalty to the Identity Provider, who learn quite a bit about the browsing habits of their users. For example, an Identity Provider is informed each time a user authenticates to a Service Provider. This information is valuable to Identity Providers since it can be used to create more tailored user profiles to target advertising better than would be possible without OpenID.

 

Contrast between Google (left) and Facebook (right) request for permission
 
Figure 2: Contrast between Google (left) and Facebook (right) request for permission.

 

Facebook provides an interesting contrast. Facebook provides a centralized system where its users can log in to third–party Web sites using Facebook credentials. To attract wary Service Providers, Facebook shares social network information in addition to demographic information. Figure 2 illustrates the difference between the information shared with Service Providers using Facebook, compared to OpenID. The left screen shot shows the request stackoverflow.com issues for logins using Google credentials via OpenID, while the right screen shot shows the request from nytimes.com when logging in from Facebook. With OpenID, the Service Provider only learns the e–mail address, while with Facebook the Service Provider learns the name, gender, list of friends, and all public information stored by Facebook. All profile information, including birthday, eduction and work history is also shared. With the rich data Facebook offers to SPs, it should be no surprise that the company has succeeded in attracting the participation of many more Service Providers than OpenID has.

In Section 4, we examine quantitatively the adoption of different online authentication mechanisms by top Web sites. The evidence we have collected indicates that IdPs that share the user’s social graph enjoy greater adoption. But first we stop to examine one more system. While not strictly an identity management system, payment–card networks such as MasterCard and Visa share some characteristics with these systems, and have greatly contributed to the success of electronic commerce. They are thus worth examining in this context.

2.7: Payment–card networks and e–commerce

Payment–card networks offer a ready–made solution to processing payments, a prerequisite for many forms of e–commerce. The two sides of payment networks are issuing banks, which issue credit and debit cards to customers, decide when to issue cards to consumers, including verifying the identity of the cardholder and assessing the credit risk, and acquiring banks, which accept payments on behalf of merchants. Thus issuing banks roughly correspond to Identity Providers while acquiring banks correspond to Service Providers.

Payment networks such as MasterCard and Visa set rules for interaction between issuing and acquiring banks. The networks are also responsible for promoting the growth of the overall network, attracting new cardholders and merchants. Payment networks were a natural fit for e–commerce because they provided an existing means of authenticating individual payments for a very large number of consumers. Furthermore, payment networks appealed to existing businesses that already accepted credit–card payments for their traditional off–line interactions.

Consider how the rules of payment networks have been tweaked to fit the context of e–commerce. Rules for assigning responsibility for reimbursing and protecting against fraud have been adapted over time (MacCarthy, 2010). In the U.S., consumers are protected from liability for unauthorized charges on their accounts [31]. Instead, the obligation to repay is allocated between issuing banks and merchants. For frauds occurring in face–to–face transactions, issuing banks normally foot the bill, rather than merchants. The rationale is that most face–to–face fraud cannot easily be prevented by merchants. Abnormally high levels of face–to–face fraud occurring at a single merchant raises suspicions that the merchant may complicit in the fraud, but in other cases payment networks are happy to tolerate isolated incidences of fraud.

Because online transactions where the card is not present are inherently riskier than transactions where the card is physically present, payment network rules often dictate that the merchant pays for fraudulently authorized transactions. Most merchants accept these less favorable terms because payment–card networks are the only viable option for processing payments. A higher fraud bill is preferable to forgoing the opportunities provided by e–commerce. One consequence of this policy, however, is that payments originating from riskier sources (such as international payments) are frequently not authorized.

One might wonder why alternative methods of payment have not arisen to satisfy the particular needs of e–commerce (such as raising the level of authentication of cardholders in order to better mitigate fraud). One explanation is that the success of payment networks — with millions of participating merchants and cardholders — has created a significant barrier to new entrants offering innovations such as a more secure payment alternative. Having already invested heavily in a less secure payment technology and achieved market dominance, existing payment networks may be reluctant to invest further in security.

 

++++++++++

3. Empirical analysis of online authentication

Earlier we argued that the OpenID standard for online authentication has attracted lower adoption rates than Facebook’s offering due to the extensive user information Facebook has been willing to share with service providers as enticement. We now provide empirical support to this claim.

There is no shortage of Web login systems on offer. Table 1 presents 17 such systems, along with additional characteristics gathered from different sources. We manually visited in April–May 2011 each of the 300 most popular Web sites, according to Alexa [32]. We first checked whether the site allowed users to login, and if so, whether they used their own system or allowed users to login using one of the 17 IdPs. We successfully classified 135 Web sites. We excluded from our analysis Web sites run by the IdPs (e.g., google.com and its country–specific variants), pornographic Web sites, and foreign–language Web sites where we could not assess login options. Over one hundred (106) of the 135 Web sites allowed users to login, and 102 of these offered their own login service.

 

Table 1: Observed availability of online authentication mechanisms in the Alexa top 300 sites.
Identity providerLogins on
#
Top 300 sites
%
% Internet usersShares social graph
Facebook3734.940.52True
Google1211.311.07False
Yahoo109.45.03False
MyOpenID54.716.11False
LinkedIn54.74.11True
Twitter1413.29.82True
MySpace54.71.36True
Windows LiveID21.95.30False
AOL43.80.77False
Blogger21.913.09False
Flickr10.92.26False
Hyves00.00.17False
LiveJournal21.91.17False
Netlog00.00.35False
PayPal00.02.35False
Verisign21.90.03False
Wordpress21.94.89False

 

The observations of each outside login service are given in Table 1. Facebook appears most often, in around 35 percent of Web sites with logins. While Google and Yahoo are both OpenID IdPs, we counted separately the times that Google, Yahoo, and OpenID were presented as the login options (since sometimes only Google or Yahoo were given as login options). Twitter was the second–most popular offering, followed by Google and Yahoo.

Table 1 also presents a measure of the popularity of each of the services, here listed as the percentage of Internet users who visit each service’s Web site monthly according to Alexa. For Google, Yahoo and Windows Live ID, we use the estimate for the number of visits to each company’s Webmail service, since these serve as the basis for OpenID credentials. For MyOpenID, we combined the popularity of Google and Yahoo, since these two companies represent the bulk of the number of OpenID users.

The final column in Table 1 indicates whether the service shares its users’ social graph with Web sites. Unsurprisingly, each of the social networks — Facebook, LinkedIn, Twitter and MySpace — do share this information. While OpenID does offer the capability for other sites to share more extensive information, in practice this is usually not shared. For instance, only one site allowing Google logins requested the user’s contact information, while the rest only requested the e–mail address, country and language of the user.

 

Popularity and prevalence of online authentication mechanisms
 
Figure 3: Popularity and prevalence of online authentication mechanisms.

 

Figure 3 presents the data from Table 1 in a more visually accessible way. Each point corresponds to a login service. On the x axis we plot the percentage of Internet users visiting the login service monthly, while on the y axis we plot the percentage uptake each service has on top Web sites. Points in blue circles indicate services where the social graph is not shared, whereas red triangles indicate that the social graph is shared by the service.

We can see there is a strong linear relationship between the popularity of a service and its uptake by other Web sites. This is unsurprising, since programs with more users are more attractive to Web sites as login mechanisms. We can also see that the services which do share the social graph experience high uptake relative to their overall popularity. In contrast, many services that do not share the social graph (e.g., MyOpenID, Blogger) have a lot of users but do not appear on many top Web sites as a login option.

We conclude by noting that while this analysis is consistent with our argument that service providers select identity providers based on how much user information they are given, other explanations are possible. For example, Web sites could offer logins via social networks because they are “hot” right now, or out of a belief that the social features better engage their own users.

 

++++++++++

4. Tussles in federated identity management

In a seminal paper, Clark, et al. (2005) identified a number of so–called “tussles” framing the evolution of the Internet’s design. Tussles occur whenever the stakeholder interests conflict over system design. In a highly distributed and highly valuable network such as the Internet, such conflicting interests are inevitable.

Federated identity management systems are also subject to many tussles. This is due in part to the complex engineering task of designing and deploying a working system. The tussles are compounded by FIM’s two–sided market structure and by government interest in finding an acceptable solution.

We outline key tussles in the design of federated identity management systems, but the basic cause is quite simple. When incentives of stakeholders align on these tussles, then the identity management system has a fighting chance of success. When conflicts arise, then the given application is more likely to fail.

Tussle 1: Who gets to collect transactional data?

Any identity management system generates rich evidence of transactions as a natural byproduct. Which stakeholder (if any) gets access to transactional data can be crucial to the success or failure of an identity management system.

In a few circumstances, user control over transactional data is explicitly guaranteed. For instance, to comply with U.S. federal laws, Shibboleth includes privacy protections for users over what information is shared. Most private companies, however, would demand much weaker privacy guarantees to users in order to participate. Indeed, the tussle most private firms would prefer to engage in is between Identity and Service Providers over who controls transactional data.

Consider Internet single sign–on services. OpenID Identity Providers have largely kept user demographic information away from Service Providers. At the same time Identity Providers are in a position to learn a great deal about user transactions from many Service Providers. This imbalance of transactional data control goes a long way towards explaining why few Service Providers participate in OpenID despite an enormous user base based on Identity Providers. By contrast, Facebook has enjoyed more success attracting Service Providers; Facebook shares more user data (namely the social graph) with its Service Providers.

Government intervention could change the dynamic on the handling of private information. For decades European regulators have used the Fair Information Practice Principles to protect privacy. Thus in the early days of federated identity management systems, Microsoft Passport’s centralized architecture drew significant scrutiny from the Article 29 Data Protection Working Group (a European Commission group whose membership consists of the ‘privacy commissions” of the E.U. member states). The working group requested “radical changes in the information flow data” and set deadlines for implementing various changes to the architecture [33]. By contrast, the group’s response to the Liberty Alliance’s federated architecture was positive: it simply asked to be kept informed of Liberty’s future steps [34].

The efforts of European regulators have not abated. In recent years objection by regulators have affected the amount of time search engines retained cookies (BBC News, 2007), the deployment of Google’s Street View, etc. More importantly, these efforts have impressed on U.S. technologists the need to consider international requirements for protecting privacy, and to design systems accordingly.

An analysis by Bamberger and Mulligan describes a different privacy protection mechanism developing in the U.S. Since 1996 the Federal Trade Commission (FTC) has been using its authority to act against deceptive trade practices to take an active role on privacy protection [35]. Rather than directly issuing regulations, the FTC has chosen a combination of advisory committees, workshops, and reports, to help drive an emerging consumer privacy agenda [36]. The federal agency has been aided by the development of state security breach notification laws and third–party advocates. These have created a dynamic that have caused corporations — at least larger ones — to commit to adopting greater privacy protective stances [37]. These commitments form an important first step. Of course, adherence is key. That is where the FTC has stepped in. The regulatory agency has been willing to take two key steps to improve enforcement: (i) fine for deceptive trade practices and (ii) determine what constitutes “unfair” trade practices. This creates a situation in which companies continually observe activity and act to improve their current practice lest they become the next “poster child” for poor privacy practice [38].

This dynamic should be considered in the context of the U.S. government’s recent efforts on online identity management. In April 2011, the Department of Commerce introduced the National Strategy for Trusted Identities in Cyberspace (NSTIC). This strategy provides a blueprint for private and public sector development of online trusted identities. The document notably strongly emphasizes privacy as a guiding principles [39]. Privacy is, in fact, the leading principle listed and is continually cited throughout the strategy document.

The strategy document emphasizes collecting and distributing only the information necessary for the transaction, and keeping that information for a limited period [40]. In enforcement, the strategy proposes legislation as a possible vehicle for increasing individuals’ privacy protections [41]. Of course, the government already has one privacy enforcement mechanism. Given the FTC’s efforts on privacy protections, the NSTIC commitment to privacy in the development of online identity mechanisms should be taken seriously. In particular, within the U.S. developers of identity management systems should expect enforcement of the type described above.

Tussle 2: Who sets the rules of authentication?

Sometimes it is natural which party should serve as Identity Provider and which should serve as Service Provider. Sometimes, though, multiple parties could serve the roles. The competition to serve as Identity Provider and to determine the framework’s rules can impose unintended consequences on the methods of authentication ultimately adopted.

Identity management platforms offer a substantial first–mover advantage. This implies that getting to market is more important than deploying the most robust technology for authentication. Once an established platform has taken hold, network effects can lead to lock–in.

Payment networks offer an enlightening example of potential consequences. An entrenched payment network may be willing to tolerate a higher level of fraud as long as the costs can be recovered through fees. Once a platform is entrenched, and switching costs for stakeholders have risen, the platform may be tempted to “adjust” the rules to shift liability off of itself and onto others.

Related to this is who selects the appropriate level of authentication. If there is competition among Identity Providers to attract users, ease–of–use and simplicity are likely to be highly valued, even at the expense of more rigorous authentication mechanisms that are inherently less convenient and/or more costly. This was the reason for such broad early adoption of OpenID. In a competitive market for IdPs, security and privacy are initially likely to be less of a priority than growing market share, as in any other market with network effects (Anderson and Moore, 2006). Higher levels of authentication or improved privacy guarantees are only feasible once a dominant IdP emerges.

Because this is a two–sided market, to be successful an IdP also must also attract SPs. The SPs may very well prefer a stronger level of authentication. Consequently, there could be countervailing pressure on IdPs to adhere to a baseline authentication level that is acceptable to prospective SPs but does not hinder adoption by users. Getting the balance right — one that does not favor onerous authentication requirements from SPs or watered–down IdP designs — is difficult. Of course, the reason why different stakeholders are concerned with getting the authentication requirements right is that they worry about what might happen if authentication fails. This leads to our next tussle.

Tussle 3: What happens when things go wrong?

There are two main ways failures can occur for an identity management system. First, a system could become unavailable to authenticate users, causing problems for SPs relying on its operation. Second, authentication itself could fail, and unauthorized users could be incorrectly authenticated as other users. In both cases, rules that determine which party is responsible are a potential source of conflict.

In some cases, it is clear where responsibility for failure should lie. For Shibboleth, the library system serving as IdP is responsible for the consequences of incorrectly authenticating users, as well as for its own users behaving badly. Because in the Shibboleth system, the roles of IdP and SP are symmetrical, responsibility is evenly assessed. For Sun’s outsourced services, the SP and IdP already had an existing business relationship, which simplified the process of handling unexpected situations and as well as providing motivation for its resolution. Both parties want the partnership to succeed, and so the sense of shared responsibility helps resolve the problem, thus avoiding recourse to the courts.

Payment card networks provide an example of how disputes may arise over who is responsible for failures. There have been several attempts to shift liability among the different stakeholders in the payment system. As noted earlier, U.S. regulations severely limit the cardholder liability for fraud, whereas in the U.K. such consumer protections have historically been weaker. Consequently, U.K. banks have attempted to shift responsibility for fraud onto cardholders (Murdoch, et al., 2010) where possible. In the U.S., since cardholders are not responsible for fraudulent activity on their cards, the tussles have arisen between the merchant banks and the issuing banks that represent the payment networks. Merchants blame outdated authentication mechanisms in payment card networks for fraud, while the payment networks blame merchants for lax operational security. The push for PCI compliance of merchants reflects this tussle between merchants and payment networks over who should pay for fraud.

What’s at stake also plays a role. For low levels of risk, clear assignment of liability for failures among players is less essential. Authentication failures for web-based credentials could disrupt access to online resources or leak private user information, but the potential financial impact is minimal. Some types of risk are financially significant but easy to measure, such as payment–card fraud. Here, liability arrangements must be clearly articulated and fairly distributed among stakeholders, but so long as there is an expected positive financial payoff, agreements are likely to be made.

A final class of risk is where the costs of failure are large and poorly understood. Introduction of a federated identity management system could elevate the risk of failure and introduce additional new liabilities for failures. Unfortunately, many of the use cases envisioned by those pushing federated identity management solutions fall into this category. For example, critical infrastructures such as those in the energy sector are perceived to be at an elevated risk for attack by unauthorized insiders. Suppose a federated identity management system is developed to enable utility workers from across the nation to assist a region hit by a natural disaster using credentials issued by their home organization. Suppose furthermore that the credentials of one of the assisting workers is compromised and used by an attacker who prolongs an electricity outage rather than abates it. Might the assisting company be held liable for the actions of the attacker? Liability arrangements have to be drawn up in such a way that take into account these low probability but high impact events. Alternatively, some type of “hold harmless” agreement similar to the one Wells Fargo agreed to before serving as credentialer to the Federal PKI may be required (U.S. Federal Public Key Infrastructure Authority, 2008).

Tussle 4: Who gains and who loses from interoperability?

One of the key advertised benefits of federated identity management systems is that users authenticated by one Identity Provider can be served by multiple Service Providers. The benefit or risk of such increased interoperability can vary by application and by stakeholder. When both Identity Providers and Service Providers see a clear value to increased interoperability, then the platform is more likely to succeed. If either IdP or SP does not view interoperability as beneficial, then the platform may be doomed.

Consider the case of federal security clearances discussed earlier. Policy–makers decided that increased information sharing was important, and so encouraged the adoption of an identity management platform to facilitate sharing. For Identity Providers, this was an easy sell, because it could lead to increased access to intelligence information from other agencies. However, where IdPs saw opportunity, SPs saw risk due to increased access to sensitive information. To Service Providers wary of information leakage, lack of interoperability is a feature, not a bug.

OpenID provides another example of this tussle. End users stand to gain from the convenience of single–sign on, and IdPs gain from collecting more information on user browsing habits. However, SPs do not stand to gain much from interoperability in the OpenID model. They are unlikely to acquire many new customers, only those very marginal customers who are only likely to visit once and not find it worth the effort to register.

 

++++++++++

5. Federated identity use cases revisited

We now return to the use cases outlined earlier in light of the tussles just presented. Table 2 summarizes our findings. For the first three use cases — Shibboleth, Sun outsourcing, and the NIH identity–management platform — none of the four tussles presents an insurmountable obstacle for any of the stakeholders. And indeed, these three cases represent clearly successful applications of federated identity management.

Conflicts appear in the remaining three cases. Tussles 1 and 2 do not present a problem for federal clearances because the rules for transactional data and authentication have been externally imposed on prospective Service Providers and Identity Providers by the government. However, Tussle 3 may be a problem, since authentication failures means that the Service Provider suffers the problems even though it may be the Identity Provider that made the error. Tussle 4 is, however, the biggest roadblock. Organizations may be reluctant to authenticate outside users because they may seek to control how and with whom they share sensitive information.

 

Table 2: Comparing use cases for their susceptibility to the tussles described earlier. A “yes” indicates that stakeholder interests are aligned, while a “no” indicates that the tussle is a source of conflict that may undermine the success of the identity management application.
 Tussle 1
Who collects
trans. data
Tussle 2
Who sets
auth. rules
Tussle 3
When things
fail
Tussle 4
Interoperability
Gains/losses
Success
Shibbolethyesyesyesyesyes
Sun outsourcingyesyesyesyesyes
NIH FIMyesyesyesyesyes
Clearancesyesyesnonono
OpenIDnonoyesnono
Payment networksyesyesyes [42]yesyes

 

For reasons explained in earlier sections, several tussles cause problems for federated identity management on the open Internet. Notably, disagreements over who controls transactional data (Tussle 1) has undermined OpenID. Additionally OpenID’s reliance on very weak authenticators has attracted IdPs but very few SPs (Tussle 3). IdPs also gain more from interoperability than SPs (Tussle 4). In sum, it is not surprising that the OpenID effort has been a commercial failure. Non–federated alternatives such as Facebook may be successful by resolving Tussle 1 through sharing social network data with Service Providers. However, the level of authentication is very weak, well below the level desired by some prospective Service Providers. This limits the range of applications that Facebook’s system can accommodate.

By some measures, payment networks have been a runaway success, with widespread adoption among users and merchants. E–commerce has relied on payment networks to complete most online financial transactions. However, the preceding discussion has also identified several undesirable outcomes of payment networks. Notably, disputes over who should pay for fraud arise frequently and continue to be contested. Additionally, the success of payment networks has created substantial barriers to entry for alternative arrangements in both payments and also identity-management solutions for online transactions.

 

++++++++++

6. Insights and concluding remarks

In seeking to understand why federated identity management systems have not yet succeeded in the broad way anticipated at the beginning of the last decade, many have pointed to the uncertainty surrounding liability as a major obstacle [43]. We believe this mischaracterizes the problem. Instead, we have argued that liability fits within larger set of economic tussles that arise between stakeholders in any engineered system.

In order for a federated identity management system to succeed, all parties in the system must gain. Otherwise at least one has no incentive to participate. A user has to gain through ease of use, access to more services, greater privacy, or improved security. A Service Provider has to gain by acquiring more user data (the Facebook model), in the ability to reach to larger markets, or by insulation from liability for failures (as happens in some instances of credit card usage). An Identity Provider must also gain from the system. The gain in control of user data and of the user authentication process are obvious benefits to the Identity Provider, but those gains must be offset by granting some benefits to the Service Provider and user.

Considering the situation from the economic perspective of gain, it is clear that the early enterprise–oriented systems such as the Liberty Alliance protocols did not provide sufficient value to the individual so as to create widespread adoption (e.g., in the open Internet). However, certain instantiations such as InCommon or the NIH Federated system did provide such benefits; in those cases, uptake was high (it might be argued that in those two instances the users did not have alternatives, but the fact remains that the systems provided clear advantages to users).

Privacy, interpreted here as user control over personal data collection, should also be viewed from this perspective. Upon examining what has been produced in the market so far by OpenID, Facebook, and Google+, users have been ignored in the tussle over who controls user data. To handle this, some have proposed identity management systems such as Higgins (2009) or User Managed Access (Kantara Initiative, 2011), in which control over transactional information resides with end users, who control what data to share with Identity and Service Providers. The issue of control is a complicated one. Ease–of–use and user–data privacy are often in conflict. The success of the Kantara Initiative User Managed Access and similar projects depends critically on easy methods for users to control their data.

Government regulators and policy–makers also have a role to play if user privacy is to be included in successful systems. Here European data privacy commissioners have been active; their negative response to Passport and positive one to the Liberty Alliance protocols were important in the early days of federated identity management systems. We suspect that the best prospect for achieving user privacy in future FIM deployments will require an active role by policy–makers in advocating on behalf of users, who are largely voiceless in current debates over FIM proposals. The recent Facebook IPO, and the new economic pressures that will result from the social network becoming publicly owned, may accelerate regulators’ efforts in user privacy protections.

What are the lessons for the future?

Federated identity management systems exhibit a number of economic tussles, of which liability for failures is only one. As in any complex engineered system, the tussles cannot be resolved separately. Liability must be viewed as part of a larger set of economic conflicts occurring between the user, Identity Provider, and Service Provider. This provides an opportunity for resolving the liability problem, which properly belongs in the context of other tussles. Seeing liability this way creates opportunities for compromise. We are therefore optimistic that taking the broader view of all tussles may actually simplify the liability problem.

Another way to put this is that if the Identity Provider accrues (most of) the benefits, it would be natural to also expect the Identity Provider to accrue (most of) the risk. At one level, that is obvious; at another, by isolating the various tussles, this provides room to determine the bargaining that must arise between the three players. Of these, only two, the Identity Provider and Service Provider, are typically in the explicit negotiations; the users, of course, walk with their feet (or in this case, their fingers).

Another observation is that the payment–card networks have largely overcome liability issues between stakeholders and deployed a highly successful, if technically imperfect, system. When systems have failed to succeed commercially, it is usually caused by an unfair distribution of responsibilities and benefits between Identity Providers, Service Providers and users. One cannot expect any technology, including FIM, to solve irreconcilable incentive incompatibilities on its own. The key to success lies in setting the rules of the platform so that each stakeholder derives benefit from cooperation.

A key function of payment–card networks in e–commerce has been their ability to authenticate users for completing transactions. The early participation of American Express in the Liberty Alliance shows that even though there is less active participation now, there was initial interest by the payment–card industry in federated systems.

Payment–card networks already provide a usable solution to authenticating payments, the primary requirement of many e–commerce applications. This weakens the business case for many aspiring identity–management solutions, particularly given the strong network effects present in two–sided markets and the high fixed costs of deployment. Furthermore, a widely deployed FIM system might commoditize payment processing, particularly if their main competitive advantage is ubiquitous authentication of cardholders.

Thus we conclude with an open question: can payment–card networks peacefully coexist with a successful, widespread deployment of a federated identity management system, or will the present success of payment–card networks prevent federated identity management systems from taking off in the open Internet? End of article

 

About the authors

Susan Landau works in the areas of cybersecurity, privacy, and public policy. Landau was a Distinguished Engineer at Sun Microsystems, and has been a faculty member at the University of Massachusetts at Amherst and at Wesleyan University. She has held visiting positions at Harvard, Cornell, and Yale, and the Mathematical Sciences Research Institute. Landau is the author of Surveillance or security? The risks posed by new wiretapping technologies (MIT Press, 2011), and co–author, with Whitfield Diffie, of Privacy on the line: The politics of wiretapping and encryption (MIT Press, 1998; revised edition, 2007). Landau serves on the Computer Science Telecommunications Board of the National Research Council. She also served on the advisory committee for the National Science Foundation’s Directorate for Computer and Information Science and Engineering, the Commission on Cyber Security for the 44th Presidency, and on NIST’s Information Security and Privacy Advisory Board. She is a 2012 Guggenheim fellow, and was a fellow at the Radcliffe Institute for Advanced Study, the recipient of the 2008 Women of Vision Social Impact Award, and a fellow of both the American Association for the Advancement of Science and the Association for Computing Machinery. She received her B.A. from Princeton, her M.S. from Cornell, and her Ph.D. from MIT.
E–mail: susan [dot] landau [at] privacyink [dot] org

Tyler Moore is an Assistant Professor of Computer Science and Engineering at Southern Methodist University. His research interests include the economics of information security, the study of electronic crime, and the development of policy for strengthening security. Moore completed his Ph.D. in Computer Science at the University of Cambridge, supervised by Professor Ross Anderson. His Ph.D. thesis investigated cooperative attack and defense in the design of decentralized wireless networks and through empirical analysis of phishing attacks on the Internet. Moore has also written reports for the European Union and the U.S. National Academy of Sciences, detailing policy recommendations for improving cyber security. Previously, Moore was a postdoctoral fellow at Harvard University’s Center for Research on Computation and Society. He has also held a faculty position in the Computer Science department at Wellesley College. He is a 2004 Marshall Scholar.
E–mail: tylerm [at] smu [dot] edu

 

Notes

1. Portions of the introduction appeared in Landau (2011).

2. U.S. General Accounting Office, 2003, p. 15.

3. At least in the U.S., that situation is changing. The National Strategy for Trusted Identities in Cyberspace strongly emphasizes the need to incorporate robust privacy protections into system design (Schwartz, 2011).

4. General Accounting Office, 2003, p. 19.

5. Burr, et al., 2006, p. 2.

6. This is an abbreviated list of the requirements for the four levels; for the full set of requirements, see Burr, et al. (2006).

7. Burr, et al., 2006, p. 31.

8. Burr, et al., 2006, p. 22.

9. Burr, et al., 2006, pp. 32–33.

10. Burr, et al., 2006, p. vii.

11. Burr, et al., 2006, p. 33.

12. Burr, et al., 2006, p. vii.

13. Burr, et al., 2006, pp. 23–24.

14. Burr, et al., 2006, p. viii.

15. Maler and Reed, 2008, p. 17.

16. Tolstoy, 1983, p. 13.

17. Shibboleth is Hebrew and comes from the criterion used to distinguish one group, the Ephraimites, from another, the Gileadites.

18. 20 U.S.C. Section 1232g.

19. The American Library Association (2011) includes unrestricted access to information and guarding against impediments to open inquiry as part of its interpretation of the Library Bill of Rights.

20. Morgan, et al., 2004, p. 14.

21. Ibid.

22. Morgan, et al., 2004, p. 15.

23. Alterman, 2007, slide 6.

24. Alterman, 2007, slides 7 and 9.

25. Liberty Alliance Project, 2008, p. 4.

26. Liberty Alliance Project, 2008, p. 3.

27. The list includes the Georgia Bureau of Investigation, California Department of Justice, Oklahoma State Bureau of Investigation, numerous Pennsylvania law enforcement–related agencies, and the County of Los Angeles.

28. Wandelt, 2007, slide 47.

29. Nigriny and Sabett, 2010, p. 8.

30. The Wikileaks of U.S. State Department secret cables provides a striking example of differing processes between agencies. These “cables” (they are, of course, no longer cables, but the name has stuck for historical reasons) were on the “Sipdis”, or Siprnet Distribution, the U.S. military Internet (which is separate from the public Internet). This means that the information was available on U.S. internal embassy Web sites and by U.S. military — probably a much wider distribution than the State Department had ever intended (Borger and Leigh, 2010).

31. Credit cards are covered by the U.S. Truth in Lending Act of 1968, implemented by the Federal Reserve as Regulation Z, while debit card holders are covered by the Electronic Funds Transfer Act, implemented through Regulation E.

32. http://www.alexa.com/topsites/.

33. European Commission, 2004, p. 23.

34. Ibid.

35. Bamberger and Mulligan, 2011, p. 273.

36. Bamberger and Mulligan, 2011, p. 286.

37. Bamberger and Mulligan, 2011, pp. 250–252.

38. Bamberger and Mulligan, 2011, p. 274.

39. U.S. Department of Commerce, 2011, p. 3.

40. U.S. Department of Commerce, 2011, p. 12.

41. U.S. Department of Commerce, 2011, p. 23.

42. Liability assignment for payment network depends on the laws and regulations in the operating environment.

43. U.S. Department of Commerce, 2011, p. 9.

 

References

Peter Alterman, 2007. “U.S. federal IdM/federation strategy and your apps,” NIH Federated Authentication Town Hall (29 November), at http://www.docstoc.com/docs/18199461/US-Federal-IdMFederation-Strategy-and-You, accessed 25 September 2012.

Ross Anderson and Tyler Moore, 2006. “The economics of information security,” Science, volume 314, number 5799 (27 October), pp. 610–613.

Ross Anderson, Ian Brown, Terri Dowty, Philip Inglesant, William Heath, and Angela Sasse, 2009. “Database state,” at http://www.cl.cam.ac.uk/~rja14/Papers/database-state.pdf, accessed 25 September 2012.

Kenneth A. Bamberger and Deirdre K. Mulligan, 2011. “Privacy on the books and on the ground,” Stanford Law Review, volume 63, number 2, pp. 247–316.

BBC News, 2007. “Google queried on privacy policy” (25 May), http://news.bbc.co.uk/2/hi/technology/6692063.stm, accessed 18 April 2011.

Julian Borger and David Leigh, 2010. “Siprnet: Where America stores its secret cables,” Guardian (28 November), at http://www.guardian.co.uk/world/2010/nov/28/siprnet-america-stores-secret-cables, accessed 23 February 2011.

William E. Burr, Donna F. Dodson, W. Timothy Polk, 2006. “Electronic authentication guideline,” NIST Special Publication 800–63 (April), Version 1.0.2, National Institute of Standards and Technology, Technology Administration, U.S. Department of Commerce, at http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf, accessed 25 September 2012.

Jean Camp, 2010. “Identity management’s misaligned incentives,” IEEE Security & Privacy, volume 8, number 6, pp. 90–94.http://dx.doi.org/10.1109/MSP.2010.178

David D. Clark, John Wroclawski, Karen R. Sollins, and Robert Braden, 2005. “Tussle in cyberspace: Defining tomorrow’s Internet,” IEEE/ACM Transactions on Networking, volume 13. number 3, pp. 462–475.http://dx.doi.org/10.1109/TNET.2005.850224

Mark Coderre, 2011. Personal communication with Susan Landau (2 May).

European Commission, 2004. “Seventh report on the situation regarding the protection of individuals with regard to the processing of personal data and privacy in the European Union and in third countries covering the years 2002 and 2003” (21 June), at http://ec.europa.eu/justice/policies/privacy/workinggroup/wpdocs/2004_en.htm, accessed 25 September 2012.

Google, 2011. “Federated login for Google account users,” at http://code.google.com/apis/accounts/docs/OpenID.html, accessed 23 February 2011.

Higgins, 2009. “Open source identity framework,” at http://www.eclipse.org/higgins/, accessed 23 February 2011.

InCommon, 2011. “Current InCommon participants,” at http://www.incommon.org/participants, accessed 16 January 2011.

Kantara Initiative, 2011. “UMA work group,” http://kantarainitiative.org/confluence/display/uma/Home, accessed 23 February 2011.

S. Landau, 2011. “NIST leads the charge on online authentication,” Huffington Post (12 January), at http://www.huffingtonpost.com/susan-landau/post_1538_b_806394.html, accessed 12 January 2011.

Liberty Alliance Project, 2008. Aetna Enhances Secure Provider Portal with SSO and SAML 2.0, at http://www.projectliberty.org/liberty/content/download/4420/29635/file/Aetna IDDY liberty case study 8.08.pdf, accessed 25 September 2012.

Liberty Alliance Project, 2002. “Global information assurance certification paper,” at http://www.giac.org/paper/gsec/2133/liberty-alliance-project-single-sign-on/103643, accessed 25 September 2012.

Mark MacCarthy, 2010. “Information security policy in the U.S. retail payments industry,” Ninth Workshop on the Economics of Information Security, at http://weis2010.econinfosec.org/papers/panel/weis2010_maccarthy.pdf, accessed 25 September 2012.

Eve Maler and Drummond Reed, 2008. “The Venn of identity,” IEEE Security and Privacy, volume 6, number 2, pp. 16–23.http://dx.doi.org/10.1109/MSP.2008.50

R.L. Morgan, Scott Cantor, Steven T. Carmody, Walter Hoehn, and Kenneth J. Klingenstein, 2004. “Federated security: The Shibboleth approach,” EDUCAUSE Quarterly, volume 27, number 4, pp. 12–17, and at http://www.educause.edu/ero/article/federated-security-shibboleth-approach, accessed 25 September 2012.

Steven J. Murdoch, Saar Drimer, Ross Anderson, and Mike Bond, 2010. “Chip and PIN is broken,” Proceedings of the IEEE Symposium on Security and Privacy, pp. 433–446; version at http://people.csail.mit.edu/costan/readings/oakland_papers/chip-and-pin-broken.pdf, accessed 25 September 2012.

Jeff Nigriny and Randy V. Sabett, 2010. “The third–party assurance model: A legal framework for federated identity management,” Jurimetrics, volume 50, number 4, pp. 509–538.

Jean–Charles Rochet and Jean Tirole, 2003. “Platform competition in two–sided markets,” Journal of the European Economic Association, volume 1, number 4, 990–1,029.

Ari Schwartz, 2011. “Identity management and privacy: A rare opportunity to get it right,” Communications of the ACM, volume 54, number 6, pp. 22–24.http://dx.doi.org/10.1145/1953122.1953134

David Simonsen, 2011. Private communication to Susan Landau (28 April).

Leo Tolstoy, 1983. Anna Karenin. Translated and with an introduction by Rosemary Edmonds. New York: Penguin.

U.S. Department of Commerce, 2011. National strategy for trusted identities in cyberspace: Enhancing online choice, efficiency, security, and privacy (April), at http://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf, accessed 25 September 2012.

U.S. General Accounting Office, 2003. “Electronic government: Planned e-authentication gateway faces formidable development challenges,” Report to the Committee on Government Reform and the Subcommittee on Technology, Information Policy, Intergovernmental Relations and the Census, U.S. House of Representatives, GAO–03–952 (September), at http://purl.access.gpo.gov/GPO/LPS38233, accessed 25 September 2012.

U.S. Federal Public Key Infrastructure Authority and Wells Fargo Bank, 2008. “Cross certification agreement ” (26 November).

John Wandelt, 2007. “Global federated identity and privilege management (GFIPM)” (August), at http://www.it.ojp.gov/, accessed 25 September 2012.

WAYF, 2011. “Welcome to WAYF,” at http://wayf.dk/, accessed 30 April 2011.

Yvonne Wilson, 2010. Personal communication to Susan Landau (6 December).

Yahoo, 2009. “Yahoo! OpenID: Now with Attribute Exchange!” (4 December), at http://developer.yahoo.com/blogs/ydn/posts/2009/12/yahoo_openid_now_with_attribute_exchange/, accessed 23 February 2011.

 


Editorial history

Received 25 May 2012; accepted 4 September 2012.


Creative Commons License
This paper is licensed under a Creative Commons Attribution–NonCommercial–ShareAlike 2.5 Generic License.

Economic tussles in federated identity management
by Susan Landau and Tyler Moore
First Monday, Volume 17, Number 10 - 1 October 2012
http://firstmonday.org/ojs/index.php/fm/article/view/4254/3340
doi:10.5210/fm.v17i10.4254





A Great Cities Initiative of the University of Illinois at Chicago University Library.

© First Monday, 1995-2014.