In April 2002, Microsoft and IBM published a joint whitepaper outlining a roadmap for developing a set of web service security specifications. Commonly called WS-*, the specifications work in a modular fashion to build on each other to create an overall effect.^[*]

The first jointly developed specification from IBM and Microsoft, WS-Security, offers a mechanism for attaching security tokens to messages, including tokens related to

Figure 12-1. The interrelationship among federation standards

identity. The roadmap described in the 2002 whitepaper included other specifications that support web services.

WS-Policy is a language for describing the security policy of a particular web service. For example, WS-Security can use several different security token systems such as SAML assertions or Kerberos tickets. Using WS-Policy, a web service might specify that it accepts SAML 1.1 assertions but not Kerberos tickets.

WS-Trust is a language that allows services to some trusted authority that one token be exchanged for another. This action is the basis for federation, because essentially what’s happening is one site’s security token is being exchanged from an equivalent one on the other site.

WS-Federation orchestrates the WS-Trust interactions to allow different security domains to federate by brokering trust of identities, attributes, and authentication between participating web services.

There are many other specifications in the WS-* constellation. Each attempts to solve a particular problem in web services interoperability.

OASIS, the Organization for the Advancement of Structured Information Standards, is a not-for-profit, international consortium that produces e-business standards.^[*] OASIS has published several important web services standards including SAML, SPML, and XACML. SAML is widely used as an identity standard in web services and, as shown in Figure 12-1, is the foundational standard for much of what’s happening in federation. Our discussion of SAML in Chapter 11 highlighted use cases that showed how SAML can be used to federate identity between the web sites of an airline and a rental car company. Other standards in the figure create a context for web sites to exchange SAML tokens to enhance interoperability.

The Liberty Alliance is a consortium of 170 companies that develops specifications for federated identity management.^[*] It originally envisioned creating a single comprehensive federated identity specification. In March 2003, however, it released a new blueprint that described three separate specifications that can be used together or independently:

One federation standard not shown in Figure 12-1 is Shibboleth, the identity architecture project of Internet2.^[†] Internet2 is a coalition of U.S. universities building a next-generation Internet. Shibboleth, which is based on SAML, enables single sign-on and federated administration of access to restricted resources. The user’s site and the target site negotiate based on attributes (e.g., faculty member at a particular school, student in a particular course) rather than the unique identity of the user, an approach designed for active privacy management.

So where do these standards all lead? At this point, it’s not clear. While there is overlap among standards from each group, each was begun with a slightly different problem set in mind. It’s clear that the OASIS standards are being adopted and used by both the Liberty Alliance and the IBM/Microsoft consortium. What’s less clear is whether or not the Liberty standards and the WS-* standards will converge and, if so, how. The market and how users adopt the various standards will make the final decision.

This uncertainty needn’t be a barrier for most organizations, however. Most of the products I’ve looked at support multiple protocols. The products will adapt as the standards change, and in many cases, your application will not be dependent on the specifics of the standard. My advice is to press forward, keeping a wary eye on the standards process and being careful about limiting your specific dependencies on any of them.

The first pattern for federating identity consists of adding relationships one by one on an ad hoc basis. As noted in the previous section, there will be powerful incentives to implement federated digital identity. In the ad hoc pattern, companies will do so piecemeal, linking with individual business partners (or a small group of them) to accomplish specific goals.

Ad hoc identity federation has been going on since networks were first invented. When I was the CTO at iMall, for example, we had an agreement to resell our e-commerce services to customers of Verio Web Hosting. We created a system that allowed Verio’s customers to sign on to their e-commerce accounts automatically after being authorized by Verio. The system also provisioned e-commerce accounts at iMall on the basis of an account provisioning action at Verio. The system was completely custom, because there were no standards for federating identity in 1999. We did similar partnerships with other companies, but the number was severely limited because of the initial expense of setting the system up and the cost of maintaining it as the participating companies changed their systems to roll out new products.

Standards such as SAML and SPML that are available now would have solved many of the technical hurdles, but we would have still faced significant challenges creating the legal framework and operating procedures necessary to make the partnerships work. Doing this once is not difficult, but it doesn’t scale easily. As a consequence, the size of ad hoc federations will be limited by the ability of any player to negotiate and enforce bilateral trust agreements with a broad range of partners.

As an initial step, companies can be expected to federate identity internally. For example, they will tie together customer touch points through CRM implementations. At the same time, an unrelated IT project may give employees single sign-on access to the corporate intranet and their 401K information. Moving outside the firewall, organizations will connect their backend systems with other companies upstream and downstream in their supply chains. With partnerships and acquisitions, they will add new federation points.

Unfortunately, the ad hoc federation scenario does little to alleviate the problems of centralized identity management described earlier in this chapter, because the federation relationships are bilateral or, at most, limited to a few companies in a private multi-lateral arrangement. The same set of technical and legal decisions must be made for each connection. If one party prefers the Liberty Alliance specifications and another favors WS-Federation, they must negotiate an accommodation prior to establishing a new link. Questions such as security, performance standards, and liability for fraud will emerge time and time again, with no obvious answers. Such issues become increasingly intractable as ad hoc identity federations overlap. A company may believe it can manage its own identity relationships, but each of its partners has its own web of relationships, its own partners, and so forth—conflicting requirements will abound as these disparate networks come together.

Without a clear, single set of basic federation standards and a neutral organization for establishing rules of liability, recourse, and risk management, ad hoc federation devolves to a free-for-all, with major identity players creating unique federations to meet their own needs. Smaller players will have little say in these federations, but they will participate out of necessity. The result will be archipelagos of identity domains linked by bilateral agreements. The islands in these archipelagos will, at least initially, be relatively small and isolated from one another, because bilateral trust agreements do not scale well. The company at the center will determine the policies and technical elements of the cluster. This is the idea behind hub-and-spoke federation.

As these clusters of identity federation grow, each additional agreement will bring new costs in the form of legal fees and administrative expenses, and new risks as enforcement becomes more complicated. If a federation member decides to join another federation, it must start the process again. Software, implementation work, and legal agreements from one cluster won’t likely transfer to another.

A small number of powerful players will emerge as focal points of identity domains that they control. Imagine a Boeing cluster, a General Motors cluster, an http://Amazon.com cluster, and so on. Smaller organizations seeking federation will be left with almost no bargaining power, because the hubs will set rules to their own advantage. Powerful players dominating particular identity federations will be able to structure those federations to provide them with something approaching virtual centralization. Although they won’t store identity information centrally, they will be able to manage access to the information distributed across the federation. Other participants will chafe at the control exerted by the central players.

At the same time, the hubs will find themselves struggling to manage networks of growing complexity. With other network members participating only grudgingly, disputes are inevitable. Both large and small participants may try to twist the system to their own advantage. The large central players, who may even compete in other areas with other members of the federation, will never fully win the trust of those subject to their policies.

The third pattern is federation within an identity network . An identity network is an independent entity focused solely on the technical and administrative aspects of identity federation. An identity network will typically gain support once a sufficient number of individual participants have become frustrated with the challenges of operating in an ad hoc bilateral environment, or a hub-and-spoke network has begun to groan under its own weight.

That is exactly what happened in the credit card industry. Just two years after Bank of America began franchising BankAmericard, the situation had become so unworkable that it called its licensees to a meeting in Columbus, Ohio to try to address the problems. The meeting quickly turned into a session of acrimonious finger-pointing. Finally, Dee Hock, vice president at a licensee bank in Seattle, stood up and suggested that the group form a committee to study the core problem in more depth. The participants immediately created the committee and appointed him chair.

Hock’s committee recommended that the banks collectively create a new kind of organization that was not only cooperative, but decentralized. Hock saw that participants in the BankAmericard federation were independent, competing organizations that needed to cooperate on standards, rules, and processes for the cross-boundary use of a device (the BankAmericard). However, the federation could not persist over time if the organization couldn’t address the needs of all issuers of the BankAmericard equally.

In response to these recommendations, the BankAmericard federation became independent in 1970. The result was a unique entity, initially called National BankAmericard Inc. and later rebranded as Visa. Visa is an autonomous, member-owned organization. Visa exists to coordinate the cooperation required from an ever-expanding membership, thus enabling them to issue and manage credit cards even as they compete with one another. Visa took the islands of banks that had grown weary of the autocratic licensing system of BankAmericard, and brought them together under shared governance, a common purpose, and a new vision. It created a genuine network.

Visa’s success is indicative of the benefits of an independent identity network. Challenges that are peripheral to any member of the network—ensuring the smooth interchange among participating institutions, selecting technical standards, defining liability responsibilities, determining common policies, managing security and fraud risks, enforcing privacy policies, resolving disputes among members, and interfacing with governments—are the core mission of an identity network. When federation occurs through an identity network, the network can avoid the redundancy inherent in the ad hoc and hub-and-spoke models, and can devote its full attention to ensuring that the network scales effectively and serves the needs of all its members.

An identity network could provide an ordered ecosystem for enterprises and individuals to interact, transact, and compete. Operating as a neutral, decentralized legal entity, the identity network would define common security and privacy standards for all members. Disputes among members would be settled within the network, and the member-owned network has the wherewithal to enforce its standards, rules, and judgments. Noncompliant members would be subject to liability, recertification requirements, fines, suspensions, or even expulsion.

Such a network would also facilitate interoperability among its members in three ways.

In contrast to hub-and-spoke identity federations controlled by powerful central players, an identity network serves the self-interest of all participants, big and small. Because the network is a general-purpose, member-owned entity, no individual member is able to design or manipulate network rules and processes to gain an unfair advantage over other members. Small companies can compete on an equal footing with large companies, and no single company can leverage network resources to gain a monopoly.

Federated identity can operate only in an environment in which relations of trust between parties have already been established. In an ad hoc federation, trust is established one bilateral agreement at a time. Each trust relationship is a custom creation. In hub-and-spoke federations, the trust relationship is created between the central player and the smaller players. Since trust is not transitive, unless the larger player is willing to incur the liability, these smaller players also often need to establish trust relationships through legal agreements between themselves. In networked federation, trust is established through agreements with the network and a common foundation that apportions liability.

In each of these patterns, trust comes from the participants and the structure of their relationships; it cannot be created through technical specifications alone. SAML, for example, does not specify how much confidence should be placed in an identity assertion. Nor does SAML, or most other digital identity standards, directly address privacy policies. It is up to each organization to decide what level of security precautions and privacy protections are sufficient and then to negotiate baseline operational agreements with partners.

Federated identity cannot establish trust—it can only communicate it. Creating an environment in which digital identity can be strongly authenticated and thus authorized for high-value online transactions across identity domains is not simply a software engineering problem. Creating such an environment requires well-established business, legal, and social processes. For this reason, companies are likely to begin by limiting their identity interchanges to already-established federations, either through bilateral arrangements with existing business partners or through industry-specific clusters led by powerful players. However, as we’ve seen, neither of these arrangements produces a truly scalable trust model.

Digital identity is not something necessary for a single business process or relationship; it is a fundamental element of the emerging world of decentralized business. Ultimately, companies will need trusted federated identity mechanisms that scale to different users, partners, and applications. An identity network is the only effective means to do so while ensuring that operational, legal, and security obligations are met.

By creating a quality-controlled environment for identity federation, the identity network both mitigates the risk of fraud or security breaches and reduces the likely damages of any breaches that do occur. The network is in a better position to design and implement monitoring, certification, tracking, and compliance mechanisms than any of its individual participants. Moreover, the network’s ability to enforce its security standards ensures that there will be no weak links among members. Network members who fail to adhere to policies can be subject to liability, recertification requirements, fines, suspensions, or even expulsion.

By pooling data and experience, the network can identify theft patterns and create effective protections against criminal activity more quickly and less expensively than any individual organization. Criminals tend to repeat attack patterns against various targets until vulnerabilities are recognized and closed. The common practices and information-sharing possible in an identity network give members a security advantage against organizations that do not participate in the federation.

An identity network also provides an environment perfectly suited to protecting the privacy of personal information online. In the identity network, access to personal information is permission-based. As a result, no one company will have a complete view of any individual’s identity information. Indeed, the distributed nature of the identity network ensures that no one party could ever know more than one piece of the identity puzzle without the individual’s express consent. Individuals will be able to control access to their personal data, providing only what is absolutely necessary to gain access to a particular online resource.

What’s more, companies will be able to take advantage of personal data without actually seeing it when third-party authenticators authorize individual users. The strong privacy protections that can be established and enforced by the identity network also shield member organizations from the significant potential costs, including fines, legal awards, and damaged reputation of failures to protect privacy.

All this does not mean that establishing a federated identity network is an easy task; there are significant challenges. Unlike a credit card network, where a small fee can be extracted from each transaction to fund the operation of the network, federated identity networks will require that members fund them out of pocket. Also, issues like liability are more fully understood in a financial services network, and it’s relatively easy to charge higher fees for riskier transactions. What’s more, there is a large body of legal knowledge about financial services that helps to establish the ground rules. These problems are yet to be solved for federated identity networks.

Given these challenges, are federated identity networks really possible? I believe so, because the benefits are sufficiently large to motivate companies to overcome the obstacles. Ultimately, the creation of wide-scale identity networks will be motivated by the realization that the market for federated identity is immense and that the full potential of digital identity can be adequately tapped only by a network that is independent of any individual member company.

There are two companies that I’m aware of that are working to bring about federated identity networks. Each is going about it in a very different way.

Ping Identity, where I serve on the advisory board, is working to establish the PingID network, a member-owned, technology-neutral, identity network designed to address the business and legal issues related to wide-scale identity federation. The network is a legal entity that provides businesses and organizations a common framework within which secure, quality-assured identity interchange can take place. The network will establish and enforce minimum security and privacy standards and use pooled information and collective action to detect and respond to incidents of identity theft and fraud.

The other model is being developed by SXIP (pronounced “skip”). The SXIP Network is user-focused and allows user data to be stored in what are termed “homesites.” When the user visits a web site that requires identifying information (termed a “membersite”), the membersite requests the identity attributes from the homesite. The homesite, in turn, requests that the user approve the release. Unlike the PingID network, SXIP is based on a proprietary standard and is, for now, useful only at web sites. Even so, it’s a workable solution to many of the identity federation problems that web site operators face and provides exceptional privacy protection for user data.

If federated identity networks are as important as I believe they are, then the space will undoubtedly attract more players. Also, the PingID and SXIP networks will continue to evolve over the next several years as they discover new business models and solve new problems. One last lesson we can take from the credit card industry: there is room for more than one network, and if they cooperate, users will probably be happy with whichever is most convenient in a given situation.