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
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: -
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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
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
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
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
- 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.
- 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.
- 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.
- 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.
- The WCS then requests a security token from the selected IdP.
- The requested IdP returns a security token (of desired format & with
expected claims) based on RP's requirements.
- Once this security token has been received, WCS requests user to obtain
her approval of release of token to the RP.
- 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
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
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
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
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
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
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
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.