Hey! CardSpace is not just a consumer technology. If you think it is, you’re missing the point. It is a bit frustrating to hear even some of my Microsoft colleagues refer to CardSpace as though it belongs on the shelf somewhere between Zune and Halo3. So if you’re one of those people running around spouting the idea that CardSpace is only important for Joe and Mary Dinnerpail; knock it off! You’re simply incorrect at the top of your lungs. On the other hand, if you are interested in finding out why this technology is so important for non-consumer scenarios, you may want to keep reading.
Yes, CardSpace is incredibly valuable to consumers because it can help protect online privacy, putting the control of digital identity back where it belongs—in the hands of the web user. It will help prevent less savvy users from inadvertently revealing passwords and other sensitive personal information to phishing scams. It is a powerful preventative for identity theft and helps eliminate many of the worst aspects of password-based authentication on the Internet. True, all of this is pure goodness for consumers, but if you stop and think about it for a moment, these benefits are just as important to businesses, institutions and government organizations of the small, medium or large variety.
CardSpace is actually an extremely important first step for any person or organization with an interest in conducting secure transactions via the Internet. This includes business-to-business (B2B) and business-to-employee (B2E) every bit as much as business-to-consumer (B2C) scenarios. Notice that there is no ‘C’ in B2B or B2E? These scenarios were important design centers for CardSpace right from the beginning. Moreover, CardSpace is based upon the widely embraced family of open, industrial strength standards referred to as WS-*, meaning WS-Federation and WS-Trust, among others. Most importantly of all, there are intense forces at work in a wide range of industries scenarios driving the need for secure, federated transactions between separate organizations.
An Industry Scenario
To see why, take a look at the scenario I bumped into recently in the insurance industry. As anyone who has purchased insurance knows, many products are sold and sometimes managed by independent insurance agents. For these products, the industry is not simply a collection of large, competing carriers; it’s an ecosystem of inter-dependent organizations. In order for the ecosystem to flourish and operate efficiently, independent agents need to access any number of electronic resources from carriers who offer these policies. Many other processes, such as first notice of loss, claims, and adjustment may require similar access to resources and applications at various carriers.
Like many other industries, important segments of insurance depend upon secure interactions with the independent agents, experts and professionals from other organizations. It’s often highly impractical to manage the identities of these non-employees as though they were internal members of your own organization. Yet at the same time, providing direct access to internal resources or applications can really streamline core business processes—if this access is secure. But this many-to-many relationship creates vulnerabilities similar to those found in the online consumer world.
The Trouble with Passwords
Authentication mechanisms designed to facilitate access to internal resources are typically based on a simple username and password encrypted over an (SSL) channel. Like most people, agents that need to logon to multiple carrier sites will avoid password fatigue by using the same password for every site. This is where the many-to-many vulnerabilities quietly creep into the picture.
Imagine that the digital identity of one of these agents has been compromised by a clever phishing scam. Then ask yourself who is vulnerable. In many cases, every system the agent has access to, at every carrier the agent does business with, would then be vulnerable to fraud. There is no consumer in this picture, but the problem that the industry is facing is very much the same as the one consumers face. If fraud does occur, the credibility of the agent (and perhaps the agency) may be at risk as well, even though his or her only mistake was to be deceived by one of the increasingly slick, sophisticated, and highly targeted phishing scams proliferating on the web. To make matters worse, a conscientious agent who realizes her mistake will have an enormous uphill battle to notify all vulnerable parties and remedy the situation because so many different accounts are involved.
The trouble with passwords, no matter how strong they are, is that they are highly fungible from site to site. The same password can be used at many sites. Once compromised, every site where a particular password has been used is automatically compromised as well. CardSpace directly addresses this problem by using tokens that are not fungible at all. Instead of using an ordinary password, the user is actually sending a cryptographically sealed token that is only accessible to one party, the party that supplied the proper certificate (key) i.e the party it was intended for. This is incredibly important because it means a site can securely identify the user, and the user can strongly identify the site. When passwords are used instead of a CardSpace tokens, it is very difficult for users to be certain who they are actually dealing with. Phishing sites are counting on this to perpetrate their deception. My point about this is that many industries are just as vulnerable to these scans as consumers are, but they CardSpace provides a powerful weapon that is already available for combating this problem in industry as well as consumer settings.
Being Kim Cameron
If you want to see the big picture about identity on the Internet, you have to be Kim Cameron (because John Malkovich hasn’t had much to say on this subject). If you haven’t read his blog on THE LAWS OF IDENTITY, you should do yourself a favor. It’s certainly the best thing I’ve read on this subject. The insurance industry scenario I described a moment ago is just one of many in what is referred to as the ‘identity ecology’.
Kim Cameron makes a compelling case for the development of an identity metasystem for the Internet. The root problem is that the Internet was born without any identity system at all. As a result, the need to conduct secure transactions via the web has spawned a patchwork of different proprietary systems of very variable strength that users have no means to assess. Cameron points out that in absence of a standards-based identity metatsystem on the Internet, we are left with patchwork of password-based systems like the ones we have described a moment ago. Such systems make it difficult, if not possible, for users to exercise control over their own identities. Control over one’s identity means the ability to control what personal information is given and to whom. In a word, the identity ecosystem is a very fragile one at the moment and it is becoming weaker as each new scheme for identity theft and fraud further erodes trust. This is a problem for consumers, but it is also a problem for specific industries as well. And, in the industry case, it will require a solution forged by industry consensus.
CardSpace is a major contribution to an open, standards-based identity metasystem, strengthening the identity ecosystem in a way that fully respects the laws of identity. I’ll spare you a detailed mapping of laws to features, but I do want to call out the importance of CardSpace support for law number six: Pluralism of Operators and Technologies. With CardSpace, Microsoft has demonstrated its commitment to pluralism and open standards in several important ways, including the recently announced collaboration to support CardSpace/OpenID interoperation. In addition, Nigel Watling and the CardSpace team have demo-ed an open source implementations that uses CardSpace Infocards on other platforms. Check it out. This demonstrates the commitment to the pluralism that will be essential to a successfully address identity and security across many platform, technology and organizational boundaries.
Enter ADFS2—another Piece of the Puzzle
If CardSpace has so much to offer, you may be wondering why isn’t more pervasive by now. It’s a good question and there are a number of good reasons. First, there is a chicken and egg phenomenon happening here. Sites don’t take the trouble to support it because it isn’t widely used. Web users don’t widely use it because very few sites support it at the moment. This problem will work itself out over time, but there other issues.
CardSpace is definitely an industrial strength solution, but it isn’t really a complete solution for a full-blown identity metasystem. Perhaps the missing piece of the puzzle isn’t obvious for those still laboring under the misconception that CardSpace is just for consumers—but it is actually a very important piece for all the B2X scenarios. Average consumers aren’t members of an LDAP domain such as Active Directory. For them, the Windows Vista desktop acts as the identity provider and affords them many of the protections mentioned earlier. However, even for consumers, this can be inconvenient at times if someone wants to use an existing Infocard from a location where they don’t have access to their own PC. But for many B2B scenarios, what is really needed is a highly scalable, widely trusted set of identity providers (IP) that can provide CardSpace tokens in the cloud. Among other things, this would make Infocard information available anywhere—without requiring users to relinquish control over what information they provide or to whom they provided it.
I use the phrase ‘set of identity providers’ to re-emphasize the notion of a pluralism of operators. This idea is intrinsic to the metasystem. Pluralism makes the idea of a metasystem very different than the Windows Live ID system today, though Live ID could certainly become one IP among others. Building a mega security token service (IP-STS) in the cloud is a major undertaking. Moreover, services such as Live ID will not suffice for a number of important industry scenarios. Highly capable, but specialized IPs.will also be needed to support industry specific scenarios. If we return to the independent insurance agent scenario for a moment, it is obvious that insurance carriers have a compelling mutual interest in securely authenticating (identifying) agents. But carriers also have a compelling interest in validating other information about agents such as whether an independent sales agent has the proper industry credentials required to broker certain types of policies.
In the language of security tokens, this information is referred to as “claims”( or sometimes assertions). It is unfortunate that this term has an overloaded meaning in the insurance business, but I prefer it nonetheless, because ‘claim’ carries some of the same connotations for both meanings. A claim carries the connotation of something that must be verified or validated before it can be trusted as legitimate. So insurance, like many others, has a compelling interest in the ability t represent and validate information in the form of electronic claims about independent agents who conduct transactions with them. General identity providers like Live ID are unlikely to specialize in providing these types of industry-specific security claims .
In addition to this scenario, many organizations are seeking to federate with one another, so that employees from either company can access resource at the other. In insurance, perhaps subrogation is a good example, because employees may need to securely share documents with one another in order to reach a mutually acceptable settlement. Of course, similar patterns are evident in many other industries as well. For this type of B2B scenario, most companies will want to leverage their existing investments in identity management.
Within insurance, for example, Active Directory is fairly pervasive. Many companies will want to use this identity information when employees are conducting business on behalf of the company. To do this, a company will need their own STS that integrates Active Directory so that they can provide identity information in the form of security token claims. You can think of this as an electronic identity “badge” issued from one company and trusted by another. A Relying Party security token service (RP-STS) is needed; ideally, one that can also integrate transparently with industry IP-STS services. These requirements put us well beyond the general capabilities of desktop or generic IP-STS like Live ID.
For these situations, Microsoft is developing new technology that will be another very important step for conducting secure transactions via the Internet. The next generation of ADFS (let’s call it ADFS2 for now) will be an industrial strength foundation for implementing a claims-based security token services (STS). ADFS2 will alleviate the need to build a standards-based token service from the ground up. Among others, it will provide two very important pieces of the digital identity metasystem puzzle. First, like ADFS today, it will directly integrate with Active Directory. This will allow employees of one organization to use an Infocard that contains their internal identity information. It will also allow members of the ecosystem to evaluate the trustworthiness of claims tokens issued by other members of the ecosystem. Secondly, ADFSv2 will integrate directly with CardSpace, eliminating many of the dangers of federation based upon passwords as we described above. ADFS2 will not only help to build a more complete metasystem, it will allow companies who already invested in Active Directory to leverage that investment of federated, B2B transactions.
The Industry Dilemma
In order for specialized, industry-specific IPs to emerge, demand for such services must be generated. In short, organizations must demonstrate their willingness to consume identity tokens from external identity providers. But they will hardly be willing to invest in the technology to consume tokens if there are no providers. The chicken and egg problem rears its ugly head once again. This, too, will work itself out in time because the drivers for an industry solution are strong. But there are still other issues.
A clear business model for trusted IPs must also be worked out. Different industries may require very different business models. Without one, highly robust IP-STS services may be slow to emerge. In addition, there are questions of legal liability. Who is at risk and who is legally liable if a false claim is issued? Will it be users, providers, or relying parties? None of these issues are insurmountable. Arguably, overall risk is considerably reduced by a more secure system. And finally, enterprise and industry architects must play an active part in helping to shape and refine standard protocols that are absolutely essential to realize a genuine identity metasystem.
I point out these issuesto highlight the need for interested parties within each industry to come together and work these problems out in concert with one another. If industry leaders do so, it can only help to accelerate a solution to the mutual satisfaction and benefit of all concerned parties.
