The Windows CardSpace - Simplified!

Windows CardSpace � A Deck of Aces

Windows CardSpace (WCS) is an ace component of the .NET Framework 3.0 release pack and is at the heart of Microsoft's impending move to create a single simplistic digital identity solution for the Web. It is ostentatiously perceived as a universal wild-card solution for curtailing the prevalent foul-ups of the contemporary Cyberspace. It is professed to offer a suit of innovative trumping capabilities that will de-risk the Internet's organic evolution and bestow a standard based solution for managing diverse digital identities. Clubbing the entire gamut of existing or forthcoming disparate authentication systems coherently together is also in the cards. Fortunately, copious amount of "such" information is available on the Web.. but unfortunately, there is lot being rhetorically said than understood. This article is a humble attempt to compile a terse and discursive introduction to the craved WCS technology.

The Identity Shuffle � A Backdrop

Today, as we step into the onset of another new year, the standing and pertinence of the Internet in our day-to-day life continues to grow by leaps and pounds. The Internet has veritably transformed the way we communicate, learn, work and enjoy - in essence it has swayed every aspect of human society that one can think of. Its significance in both business and private arena has grown considerably in the recent years with exponential surge of its users and services offered. The promised land of Web 2.0, Blogs, Mashups, Real World Web etc. enlivens the hopes of a bright future of the Web. However, while all of this is true and sounds pretty good, there exist certain other unpleasant realities that cannot be disregarded by any means.

According to a Gartner's report, 22% of online buyers have "stopped" online purchasing while other 25% have "reduced" the same! A Harvard study postulates that some good phishing sites can easily delude 90% of its target users into furnishing sensitive information. And that's not all; the pernicious practices like phishing and pharming are supposedly one of the fastest growing segments of the IT industry, with an annual compound growth rate of more than 1000%!! Alas! Internet primarily remains unsafe for its users. It exposes its users to proliferating dangers and is progressively losing its sheen owing to the increasingly professionalized and organized criminal fringes. The risk of a severe crisis is looming large over the Web and inadvertently threatening its organic evolution. The perils of identity theft and sophisticated online practices such as phishing, pharming, phraud, spoofing, spyware, malware are hindering the Web's furtherance.

Despite of spending tons of money and time on plumbing myriad of incoherent authentication systems together and resolving the identity "silo hell", the critical businesses such as banks or airlines are bearing the brunt of online fraudulent transactions or scams. For instance, Kingfisher Airlines recently suffered a loss worth million of dollars due to an online ticket reservation fraud. Zillions of such examples can be divulged and cited. On the other hand, the casual web surfers find the present day Web annoying and complex, despite of all the upgradations and advancements. They are weary of perpetually managing the plethora of username & password pairs (a phenomenon called "password fatigue") and so they often compromise on security by reusing a single pair at multiple places. Does this hassle only the frivolous surfers? Aren't we all vexed up of filling similar registration forms on almost every other website we visit? Haven't we ever experienced the height of coincidence, by virtue of which, we thereupon start receiving enormous unsolicited spam in the inboxes, post submitting these registration forms?

While most enterprises have toiled and developed improvised identity solutions to address these challenges, the Web still has none! There is neither a consistent & secure way to represent an identity on Web nor there is yet any comprehensive framework to evaluate authenticity of a hosted site, online resource, offered service etc. Unfortunately, the present day Internet was built without even a way to know who it is really dealing with!! Thus, the huge gap is remaining to be filled is fabrication of an "identity layer" for the Internet. Reckoning these facts, can such mute and vulnerable Internet continue to grow while committing transactions over it remains almost as safe as walking over a live minefield? Is there any way to prevent the ensuing mass Web bubble bust? Isn't it well understood that the cost of not moving forward swiftly too can be huge? Then, will the Web 2.0 dream ever realize amidst such a crisis? Can there ever be a worthy solution to the current identity representation and authentication disaccord?

Certainly, there is! There is now a nascent identity solution and you have already guessed its name too. WCS has emerged like an effulgent ray of light at the end of the tunnel, that fortuitously doesn't appear to be that of an approaching train!! But before delving deeper into its nitty-gritties, let's deal with some of the pre-requisite facets of the prospective solution.

House Rules of the New Game

An enduring and universally acceptable identity solution must suo moto conform to the following set of fundamental rules: -

1. User Control: The identity solution must be user centric i.e. it must put its users squarely in control, request user's consent before revealing any identity information (identifying the user) and remember user made decisions or preferences etc.
2. Minimal Disclosure: Since the identity information can be sensitive, the solution must acquire, retain and disclose the "least identifying information" as possible to circumvent whatsoever risk.
3. Justifiable Parties: The solution must disclose the identifying information to limited parties only that are having a necessary and justifiable place in a given identity relationship. The requirement applies both to the user � who is disclosing it and the service provider � who is demanding it.
4. Directed Identity: The universal solution must support both omni-directional identities (having a persistent public identifier for use by public entity e.g. url or public key certificate of a retail web site, and can be disseminated to everyone) and unidirectional identities (having a transient, fabricated, completely orthogonal private identifier for use by private entities, on case to case basis such as during a secluded one-o-one session). Thus, it should facilitate mutual discovery while preventing any potential abuse.
5. Allow Pluralism: Since identity can be expressed differently using varied technologies, a universal identity solution must enable the interoperation among the various identity technologies run by different identity providers. Thus, it must be open, non-proprietary & vendor agnostic to be usable by one and all.
6. Human Integration: The identity solution must better integrate the human users to the identity systems by profoundly changing the existing human-machine interfaces or user experiences. The user experience should be made predictable, intuitive and unambiguous enough to allow informed decisions and protection against identity attacks.
7. Consistent Experience: For the unifying solution to be usable, it must guarantee its users a simple, consistent experience completely encapsulated from the underlying technologies used or its providers.

These basic rules are popularly known as "the Laws of Identity". Their compliance by architects conceptualizing an identity solution is as essential as the compliance of the Law of Gravity by architect creating blueprint of a building or a dam.

MS Passport � A Rule Infraction?

The MS Passport (now known as Windows Live ID) has almost certainly been the Microsoft's best-known identity effort till date. Passport was initially intended to be a standard identity (or authentication system) provider for the Internet. While, it overwhelmingly succeeded as an identity provider for the online Microsoft services (MSN, Hotmail etc.), with over 300 million active Passport accounts and a billion authentications per day, it haplessly flunked as an identity provider for the Internet! This was probably a main reason behind auction giant eBay and job site giant Monster dropped its support.

But, the Passport's failure helped Microsoft gain a deep understanding of the operational and technical challenges that Internet scale identity providers and authentication services face. It made Microsoft realize a basic point that it is inordinate for any single organization, even as big as Microsoft, to act as a sole identity provider for every resource on the Internet. It also preposterous for an external party such as MS to play any role in transactions between, say, a caring security savvy company and its key employees or customers. Microsoft consequently displayed a remarkable resilience by successfully applying all the hard-earned lessons & expertise gained in identifying the Laws of Identity, conceptualizing its vision of Identity Metasystem and developing the WCS.

Cutting the Deck - Identity, WCS and the Identity Metasystem

The Identity

A prerequisite to understanding the WCS solution is getting familiar with the WCS terminology, so let's begin by discussing the pertinent jargons. A "digital identity" is a set of claims made by a digital subject about itself or another digital subject. A "digital subject" is a central entity (person or thing represented in the digital arena) which is under consideration e.g. person, computer, document, service, organization etc. A "claim" is simply an assertion of the truth of something, typically disputed or in doubt e.g. "I am Andrea" or "My account # is ABC-12345". All such claims are subject to evaluation by interested parties.

Identities of one person can be of various kinds since she can own multiple identities depending on the context e.g. a Bank card at ATM, Passport at border check, Windows Live ID (Passport) at Hotmail. Due to tremendous diversity among identities and their digital representations, they often tend to go out of context e.g. a Passport at an ATM machine : ( or a Live ID at eBay : (( However, all digital identities have a clear commonality i.e. when transmitted over the network, each digital identity is represented by some kind of security token. A simple security token might include only a claim containing a username, while a more complex one might include sensitive claims such as user's address, credit card numbers & card expiry dates etc. Some of the most prevalent security token formats are username (inscribed as text), X.509 certificates and Kerberos tickets. But, these formats were traditionally designed to convey only authentication information, so they cannot be used to transport additional set desired claims. However, tokens created using Security Assertion Markup Language (SAML), a XML based standard created by the industry group OASIS, do allow this. These security tokens travel across process or machine boundaries as a set of bytes and are in fact misnomers since they can also contain arbitrary set claim information completely unrelated to security.

The Identity Metasystem

Universal adoption of a single digital identity system or technology is a distant dream. Hence, a successful and widely employed identity solution for the Internet requires a different approach � the approach is to wire the existing (and future) identity systems into one Identity Metasystem. This metasystem (or the system of systems) will serve as a framework for providing interoperability between constituent identity systems, leverage from their strengths and enable creation of a consistent user interface for them. Thus, the Identity Metasystem will not compete with or replace the identity systems it connects. It will be implemented as a web services based framework that can use WS-* protocols to communicate (claims) between participating parties, thus will remain completely open and non-proprietary. It will play a role analogous to the Internet Protocol (IP) in the realm of networking i.e. instead competing with or replacing the various systems it connects, it will rely on the individual systems to do its work. The resulting improvements, as outcome of such a metasystem in cyberspace, would benefit everyone, making the Internet a safer place with the potential to boost e-commerce, combat phishing, and solve other digital identity challenges.

Thus, it shall be fundamentally different from the original version of Passport in several ways. The metasystem will abide by all the Laws of Identity, store no personal information and delegate the decision of how & where to store the information to its identity providers. The Identity Metasystem will not be an online identity provider for the Internet; indeed, it will provide a means for all identity providers to coexist with and democratically compete with one another in equal standing. Finally, unlike the original version of Passport, it will be open, non-proprietary, and free from participation charges!!

FYI: The Passport (Windows Live ID) too has evolved to a great deal as a "unified login" service and now no longer stores personal information other than username/password credentials. Passport is now playing comparatively a much comfortable role, the role of an authentication system targeted at Microsoft sites and its MSN partners allowing them to interoperate with Passport through the Identity Metasystem. It's important to note that the Identity Metasystem vision isn't purely Microsoft initiative; rather it is the shared vision of many across the industry and a joint effort to solve the current identity challenges of the Internet.

The Windows CardSpace

Windows CardSpace (WCS) is at the core of Microsoft's aspiring endeavor to implement an Identity Metasystem - a unified, secure and interoperable identity layer for the Internet. WCS, formerly codenamed "InfoCard", is a new feature of Windows (Vista, XP & 2003 platform) that enables users to provide their digital identity to online services in a simple, secure and trusted manner. It participates as an Identity Selector (IdS) within the Identity Metasystem. While, WCS is Microsoft's implementation of Identity Selector software for Windows, some similar identity selector implementations for other operating systems are likely to bud over the time. WCS paves a way for any Windows application (such as Internet Explorer 7.0) to provide users a consistent means to work with their digital identities via a simple and familiar metaphor of a set of cards.

Set of "cards"? Yeah! Because cards are the way we frequently represent or prove our identities in the real world e.g. at a store: a credit card, at an ATM: debit/bank card, at work: I-card, in business: business card, so on and so forth. Thus, a set of cards is a natural metaphor for the user to adopt when choosing a digital identity to provide. So, whenever a user or subject needs to be authenticated by a website or a web service, WCS pop ups a secured UI with a set of "cards" or portfolio (as if user has opened her purse) for the user to choose from. User needs to only select an appropriate card without providing any usernames and passwords or filling lengthy online forms! These "information cards" represent the digital identity of user in a consistent and secure manner. Each "provider or managed card" has some identity data/claims "associated" with it (though not actually stored in the card) and has been issued to the user by an Identity Provider such as user's bank, employer or government. Of course, a user can herself also act as an identity provider, no wonders because this is essentially what we do every time we fill a registration form at a website. The WCS enables users to create such "personal or self-issued cards" also and associate a limited set of identity data. It is important to note here that information cards only contain metadata concerning which claims can be provided and where and how to obtain them. They do not contain any actual identity data nor do they travel off the user's machine across the wire unless explicitly exported or roamed within a domain.

WCS Trump Cards - A Strong Suit

WCS, a subtle but salient part of the grosser Identity Metasystem, features the following unique selling points (USPs): -

i) Seamless Integration with Diverse Identity Systems

Different digital identities used today come from different sources, are expressed in a variety of formats and use different underlying technologies. Hence, it's rather difficult to conjoin such disparate identity systems together. However, looking at their commonalities, following three distinct roles can be unhesitatingly classified:

� Subjects (Users): the individuals or central entities about whom the claims are made such as a bank account holder.
� Identity Providers (IdPs): the issuer of digital identities such as a credit card provider.
� Relying Parties (RPs): entities relying on digital identities for, say, authentication such as a web site or an online service.
* In some cases, the participants (or parties) in the metasystem may concurrently play more than one role.

Figure 1: The protocol for interaction among the roles of WCS metasystem

The underlying protocol for interaction among these metasystem roles is as follows:

1. When a user wishes to access a secured online resource of a RP or begins a transaction that requires the identity validation, her WCS compliant client application (IE 7.0) triggers WCS to request the security token requirements of the RP.
2. The requested security token requirements information is contained in the RP's policy and includes details such as desired security token formats the RP accepts and precisely expected claims those tokens must contain. The requested RP responds with these details.
3. Once the security token requirements are received that RP minimally expects, WCS presents the list of matching IdPs (that can satisfy the requirements) to the user and requests selection.
4. The user selects an appropriate IdP that can satisfy the RP's requirements by selecting an appropriate information card. This card represents her identity but its data is owned & managed by the IdP.
5. The WCS then requests a security token from the selected IdP.
6. The requested IdP returns a security token (of desired format & with expected claims) based on RP's requirements.
7. Once this security token has been received, WCS requests user to obtain her approval of release of token to the RP.
8. Finally, the security token (provided by IdP and meeting the RP requirements) is passed on to the RP. The RP uses this token to authenticate the user and grant access to its resources (or for any other arbitrary purpose).

It's important to note that all of these exchanges defined by the Identity Metasystem and implemented by WCS are done using open standard interoperable WS-* protocols (such as WS-Security & WS-Trust). The unified metasystem is also entirely agnostic about the format of the security token and provides support for multi-factor authentication like certificates and Kerberos. This allows WCS and the Identity Metasystem to be seamlessly integrate with whatever digital identity technologies are (or will be) in place.

ii) Simplified but Powerful Control over Digital Identity

While using standard open protocols for acquiring and transmitting security tokens is useful, it's useless if there is no simple way for users to understand and make sensible decisions about the digital identities these tokens represent. The complete metasystem can collapse owing to its complexity! Hence, one of the prime goals of WCS and the Identity Metasystem is to empower users (naive or sophisticated) to make better decisions about using their digital identities. To achieve this, WCS implements an intuitive user interface for working with digital identities. The following figure illustrates the most important part of this interface, the screen used to select an identity.

Figure 2: WCS identity selection screen

Each information card (or InfoCard), displayed in the figure, represents a digital identity that the user can potentially present to a RP. Along with a unique visual representation, each card can also contain certain information about a digital identity. This information includes which IdP to contact to acquire a security token for this identity, what kind of tokens this IdP can issue, and exactly what claims these tokens can contain. By selecting a particular card, the user is actually choosing to request a specific security token with a specific set of claims created by a specific IdP. The technical complexity is hidden from user to enable her take unequivocal decisions.

As discussed earlier, the process begins with a client application requesting a RP's policy. Once this information is returned and passed to WCS, the user interface displays the card selection screen showing every information card she owns on the system. Only some cards are applicable in a given situation and therefore any information cards whose associated security token and claims don't match the requirements of this RP are grayed and cannot be submitted. Once the user selects a particular card, WCS issues a request to the IdP associated with that card. The IdP then returns a security token that is passed on to the RP for authentication.

Thus, WCS provides a consistent and predictable way to select and use their digital identities. Without this, for all but expert users, the result would surely be confusion or error and the purpose would be defeated. WCS also shields users from differences in security technologies such as underlying security token format X.509 certificates, SAML, etc. WCS offers superior security for protecting each information cards with personal identification numbers (PINs), requiring a user to enter the PIN before the information card is used. To prevent any feasible hack or attack from other locally-running system processes, WCS creates a private Windows desktop for hosting the identity selection screen.

iii) Freedom from Usernames and Passwords

The most common kind of security token on the Internet today is username and the respective authentication mechanism is providing the associated password. Since most sites typically use SSL for communicating with browser, the approach has been pronounced as reasonably secure. SSL merely ensures that the entire communication is encrypted and therefore attackers can't steal information by eavesdropping on the wire. The username/password based authentication scheme is simple (since no third party IdP is required) but overly weak and vulnerable to phishing attacks. By sending delusory e-mail messages, phishing attackers can entice users into logging an imitation of the real site, revealing their passwords and other personal information. If passwords aren't predominantly used on the Web, phishing can be lesser threatening too. To make this possible, and to improve the security of Web login in general, WCS allows replacing password-based Web login with a stronger mechanism, thus freedom from usernames and passwords.

Instead of passwords based authentication, a RP (such as a website) can rather rely on stronger security tokens (that can be evenly accepted by, say, a group or ring of sites). Such approach will cut down the use of passwords, and it's certainly an option that can be used with WCS. While, typically a RP may like to accept security tokens created by a third-party trusted IdP, in umpteen cases, this may not be feasible. So, is a complex digital identity (issued by an esteemed third party IdP) really needed merely to recognize multiple accesses by the same user? Not essentially! Hence, to address this scenario, WCS includes a self-issued IdP that runs on the local Windows system, and it can produce tokens just like any other IdP.

The self-issued IdP contains only basic information, such as the user's name, address, e-mail id, and phone number etc. When a user chooses to submit one of these cards to a RP, the self-issued IdP on that user's system generates a SAML token containing the information the user has placed in this card. The self-issued IdP also generates a public/private key pair, signing the security token with the private key. To prevent an attacker from reusing it, this token contains a timestamp and other information as well, making it useless to anyone except its original user. The application then sends this signed token, together with its associated public key, to the RP. The RP can use the public key to validate the security token's digital signature, thus ensuring that the token is being presented by its rightful owner. To make it impossible for RPs to get together and track a user's activities by comparing that user's public key, the self-issued IdP creates a different key pair for every RP that's accessed with this card. Thankfully, all these details are hidden from the user who has to merely select an information card as her identity.

iv) Improved Assurance to Users about the Identity of Remote Applications

While, freedom from password-based Web logins will help reduce the pain of phishing, it won't eliminate the problem! If a user is tricked into accessing the phisher's site, that site might accept any security token the user provided, self-issued or otherwise, and then ask for information such as a credit card number. The phisher wouldn't acquire the user's password for the site it's emulating, but he or she certainly might learn other sensitive information. Thus, on the other side of the coin, the problem is the user's inability to distinguish the real site (user's bank) from an imposter site put up by a phisher. The site can resemble he original one having same logos, css, contents, and can even use SSL for generating user comfort. BTW, phishers too can acquire certificates just like anybody else. If a user clicks on a link provided in a phisher's e-mail message, he may find himself connected to something that looks just like his bank's site. The little lock in the lower right corner of Internet Explorer might even be present, indicating that the communication is secured by SSL. WCS and the Identity Metasystem address this problem in the fashion described in the succeeding verses of this section:

a) By providing an assured way for a website to prove its credibility to users: Improving the way for a website to proving identity to users may require improving the current SSL certificates since these days a website typically proves its identity using SSL certificates. SSL certificates can only prove that a given site has a particular DNS name but there's no assurance that this DNS name corresponds to the information displayed on that site! A phisher might get a certificate issued for a DNS name that he owns and has been carefully crafted to look just like your bank. SSL certificates thus aren't enough to solve this problem. To fix this, creation of high-assurance certificates is being mused. These certificates will contain more information than a traditional SSL certificate such as the name, location, and logo of the organization it was issued to. The certificate will also be a more authoritative source of information because it's more difficult to obtain since it will require stronger agreements with the authority that issues it. Both IdPs and RPs can use this new certificate type to prove their identities to users of WCS applications.

b) By providing a superior means for users to evaluate a site's identity and ascertain: However, a human being still needs to make a decision about which sites she trusts. WCS makes this decision explicit, requiring every user to approve the use of every IdP and RP that he or she wishes to access. When an information card is first installed on the user's system, a screen asks the user to verify that he or she is willing to accept security tokens created by the IdP that issued this card. Similarly, the first time a RP such as a website is accessed, a screen appears that requires the user to indicate his or her willingness to send it digital identity information. The following figure depicts a sample screen displayed on a user's first access to a hypothetical RP might look.

Figure 3: Screen displayed on first access of an RP resource

As this example shows, the screen can include the name, location, website URL, and logo of the organization whose identity is being approved and can also include the name and logo of the organization that has verified this information. Thus, the user can now make informed decisions since what's shown on the screen varies depending on the level of certificate provided by the IdP or RP. If the higher-assurance certificate is provided, the screen can indicate that the organization's name, location, website URL, and logo have been verified and so this organization deserves more trust. In case if only an SSL certificate is provided, the screen would indicate that a lower level of trust is warranted. And, if an even weaker certificate, or no certificate at all, is provided, the screen would indicate that there's no evidence whatsoever that this site actually is who it claims to be.

Providing such a consistent and predictable experience for accessing new sites will help an average user in making better decisions. Every application built on WCS, including the IE 7.0, will mandate explicit approval, from user, to use each IdP and RP that he or she accesses with WCS. The user will always see the same screens that will provide guidance about the level of assurance the user can have, that the site is who it claims to be. Also, a user is required to make a decision about trusting a site the first time that site is accessed. Later accesses won't display a decision screen. If this screen does appear for a previously-accessed site, it's a strong indication that he or she has somehow been tricked into accessing a phishing site.

The Showdown � Revealing the InfoCards

Let's now uncover the information cards (InfoCards) a bit from WCS's perspective. While, for a user, an information card is simply the visual representation of a digital identity that is displayed on her screen, for WCS, an information card is actually a structured XML document stored on the user's machine. WCS provides a graphical tool that lets users create self issued cards. For other IdPs, user needs to acquire the appropriate cards in some way, such as through the IdP's website or an e-mail sent by the IdP. There's no mandated way as such to acquire information cards and may be defined by individual IdP. However, once acquired, each card (even the self-issued one) is digitally signed by the respective IdP that issued it and comes with the IdP's certificate. This signature is used to verify the identity of the IdP itself. Once the card is on the user's machine, double-clicking it brings up a screen that allows the user to install this card into the standard WCS card store. The user must approve the other IdPs as source for security tokens before its card can be used to request security tokens.

An information card typically holds the following information: -

� A JPEG/GIF image and name of the card that is displayed on user's screen.
� One (or more types of) security tokens that can be requested from its IdP along with a list of claims each tokens can contain.
� The creation timestamp of the information card.
� URLs of the IdPs that can be requested for obtaining security token.
� A globally unique identifier (specified as a URI) created by the IdP.

Evidently, an information card does not store any sensitive data about this identity such as user's credit card number. While such kind of sensitive information might appear as a claim in a security token created by an IdP, it is always stored on the IdP's system. When a security token is sent, its information is typically encrypted, making it inaccessible to both attackers and WCS. A user can also use WCS to preview the information that will appear in a security token created using that card. This information will be fetched from the IdP that issued the card whenever the user requests to see it and is deleted from the user's system post the requested display.

Information cards can be copied (as .crd files) onto an external storage device such as USB drive using the card export option. This feature allows roaming i.e. using same identity from multiple machines (such as home computer and office laptop). Once copied, the cards can then be installed onto other machines, letting a user request security tokens from IdP in the same fashion, whether she's using her home computer or her office laptop. In order to guard against attacks, the exported information cards are encrypted using a key derived from a user-selected pass-phrase. This ensures that even if the storage medium is lost, only someone who knows the pass-phrase can decrypt the cards it contains.

However, using a WCS based identity from a shared system such as cybercaf�, by installing the information cards on cybercaf�'s shared machines, may still not be a good idea. Especially, because to use existing identities created using a self-managed IdP, the keys associated with those identities will also need to be transferred on the shared machine! This is yet not addressed but the ability to independently install a WCS store with a complete self-issued IdP on USB-based hardware is under deliberation. Once this option is available, a user will be able to plug an external device into a computer, and request security tokens directly from it, without having the need to install information cards or keys on the (shared) machine being used.

Another usability issue that may urgently need to be addressed is revocation of a card after being issued. Following are some of the possible revocation scenarios and their indicative revocation procedures:

Scenario I: the IdP wishes to revoke an information card (say, due to non payment of subscription installments by user or something else). In this case, the IdP can simply stops honoring requests for security tokens made with this card. Since every request carries a unique WCS reference, therefore it's easy to identify requests made using the card it has revoked.

Scenario II: the user wishes to revoke an information card (say, since an attacker has stolen the user's laptop that contained installed information cards).

� In case the card was issued by external IdP and was assigned a PIN (that must be entered each time the card is used), the attacker can't use the stolen card unless she knows the PIN.

� In case the card was issued by external IdP but was not assigned a PIN, the user will need to contact the respective IdP to inform that the cards should no longer be honored. As with acquiring cards, there is no mandated way to do this and can be defined by individual IdPs.

� In case the card was self-issued (created by the self-issued IdP); here the IdP too has got stolen as it resided on the user's laptop. Phew!! This case in quite similar to losing an account's password (to someone else), so the user will need to cancel her account manually at each RP that accepts the (now-compromised) card.

However, to our rescue, WCS provides a card history feature that records all sites at which a card has been used, so the owner of the stolen laptop can restore a backup copy of her cards and determine the sites that need to be contacted.

Card Readings - The Outcome

WCS has incredible potential and it paves the way for further innovations by individuals and organizations. The problems it is deemed to addresses are unarguably important and so are the collaboration possibilities it presents. If earnestly adopted and fostered, it has capability to lead us to identity big-bang - the new era of Internet that is identity aware! However, WCS cannot succeed without participation from many other organizations that need to soon come up with conforming RPs, IdPs and IdSs for different platforms. Any further conclusion or prognosis, at this point in time, may probably be a bit foregone.