What you always wanted to know about Microsoft Cardspace - Part 3

The publication of Vittorio's book "Understanding Windows Cardspace" about which I wrote a post only yesterday I realize that there is more and more demand for information about topics around identity. And from my experience it is not only people working in IT or have a great affinity to technology who are interested in this area but also the common internet user. This is a very positive trend and encourages me to further blog about identity and Windows Cardspace in particular. So here's part 3 in the series about things you wanted to know about Windows Cardspace.
 
Q: Is there a possibility for a service provider to differentiate between required and optional claims?
A: Yes, Cardspace exposes the possibility to a service provider to ask for required claims and optional claims as a response to a service request of a user. This means that the user needs to provide the required claims to gain access to the service of the service provider and can or cannot provide the optional claims information in order to give the service provider the change to improve service quality. This can technically be done by setting the "Optional" attribute on the respective "ic:ClaimType" like this:

<ic:ClaimType Uri=”xs:anyURI” Optional="xs:boolean"? />

The Cardspace Card Selector surfaces this by explicitly marking the claims which are optionally requested. At this time the optional claims can be send or not only as a single block which means that the user has no change to selectively choose individual optional claims to send. This means either all optional claims are send or none.

Q: Are the cards secured on my PC?
A: The cards itself are stored encrypted on the user's PC which gives a fair amount of security if the PC on which the cards reside is handled with a sense of responsibility. The second layer of security is that a managed card only caries metadata and the real identity information payload is stored at the identity provider. So for most of the very sensitive data that one needs in online transactions such as credit card data, etc. will never be stored on the user's PC anyway at least not in the context of Windows Cardspace. In order to use a managed card and have a security token carrying the payload data created by the identity provider proper authentication must be performed like outlined in Part 1.

Q: Is a service provider able to influence the order in which valid Cards are shown in the Card Selector?
A: I do not know of any way to influence the order if there is more than one card that provides the required information. I also doubt that this will be possible at all even in future versions of Windows Cardspace because this wouldn't respect the user centered approach reaping some degree of control from the user to another party in the identity ecosystem. However there is a simple trick to make a certain card the only card that shows up in the card selector as valid and in full color and that is to add a custom claim type to the request which can only be satisfied by the card the service provider prefers. However of course this only works as long as there is only one card that can provide this custom card.

Q: Can I use Windows Cardspace Infocards also if I don't use Windows or the .Net Framework 3.0?
A: Yes definately you can and the answer to this question although it may seem a little bit complex can always be reduced to the topic openness. This said I make it clear from the beginning: Windows Cardspace and the underlying concepts completely rely on open web-services standards and standardized encryption standards and the protocol is well documented. The implication of that is quite obvious. This means that anyone can implement own implementations of any component needed or involved in a Windows Cardspace trust relationship scenario. And there already quite some parties that actively develop components leveraging the Cardspace Idea and enable other platforms (browser or OS) for the use of Microsoft Infocards. A few examples are:

• A card selector for use with Firefox maintained on CodePlex

• A Java based card selector for Firefox maintained at XMLdap.org and Google which also runs on Linux

• DigitalMe including a CardSelector implementations for Suse, Fedora Core and Mac OS X as well as a browser add-on for Firefox all maintained by the Bandit-Project backed through Novell.

Q: What is the roadmap of Windows Cardspace, how does the technology evolve and what are the areas of focus?
A: Short answer is:"I don't really know". There is not yet an officially announced roadmap for Cardspace Vnext. However from informal discussions and feedback from customers and the community there are certainly some areas of improvement or extension that may be covered by a future version. These may include:

• Enhancements to support payments and customer loyalty programs
• Multifactor Authentication enabling an identity provider to enforce multiple authentication schemes to further increase security
• Improve tool support and developer experience (Will be released as the Identity Framework)
• Further hardening of the Card Selector
• Roaming support

Well, that's it once more. Hope there was some valuable information for you in this blog which you can reuse. Wether or not stay tuned as there might be a next part coming soon.