I have working with, writing about and presenting on CardSpace for over 2.5 years now...and in the process refining how I describe to people the benefits of information cards for improving security for end-users. In particular, end-users that are not like us developers...every day people that don't know how to choose which sites are unsafe, which links to click in email, and so on.

Consider the following malicious PayPal email:

You can see that the "Click here to verify your information" link is not really sending you to the PayPal site. I see this because I hover over the link to verify the destination...but most non-developers won't know to do this. For those unsuspecting users the story might play like this:

• They go to the destination site, which might look just like the PayPal site. 
• They try to log in, it fails repeatedly. In the meantime, they enter every combination of username and password they use in various sites...perhaps including their online banking site.
• The malicious site collects these combinations of username and password.
• The user gives up logging in.
• The malicious sites now tries to log in to the real PayPal account, or worse, to some of the major well-known online banking sites.
• If they are lucky, and the user is unlucky, one of those username and password combinations will work at the online banking site, and they can write themselves a check, or otherwise play havoc on the user's bank account.

It is that easy to lift a username and password combination.

So, how do information cards issued by CardSpace (or, any other identity selector) help?

Let's assume that the user has associated a personal card with their PayPal account...if PayPal supported information cards. The same scenario might go like this:

• The user get's the evil email. They click the link and head to the malicious site that looks just like PayPal.
• If the site doesn't support information cards, the user will be suspicious because they always log in with a card.
• If the site shows support for information cards, the user may fall for it and click on the "log in with personal card" link which takes them to CardSpace.
• CardSpace will ask you to confirm the site by reviewing its privacy statement and site identity. This should trigger an indication to the user that this is not the site they think it is, since they would normally only get this the first time they hit the site. If they have logged in to PayPal before with a card, they wouldn't see this screen:

• Assuming this isn't enough to tip off the user, and they continue, the next strange behavior will be that they are asked to select a card to send to the site...but there will not be any list of cards already used at this site.

They should have seen at least one personal card present as shown here:

• Assuming this is still not enough to tip off the user, and they decide to select a card to send...the destination site will receive a security token with the requested claims which may include any personal information that you can enter into a personal card such as name, address, phone number, date of birth, and your card's private personal identifier (PPID). BUT, if the site requests more claims than PayPal, there are still more indicators of the malicious site. The first is that you'll be informed that the site is requesting new claims:

• This should really stop the user in their tracks, but they can preview the data requested and decide if they are comfortable sharing this data as shown here:

• If the malicious site wants any data I never share with PayPal, the user would probably stop here. But, let's say they continue and add the data, or, let's say they already had entered the data for this card so it wasn't necessary to provide it here. For example, I might create a personal card with my home and business details in full...but that doesn't mean I send all those claims to every site. Perhaps only to my online banking site because they require an address and phone number to help prove who I am sending the card. So, if the card already has all the details, the user is still warned that new claims were requested and should be approved:

• The user can (and should) preview the requested data. In fact I think that CardSpace should force the user to preview it the first time. Furthermore the new data requested should be called out in red here...so it is obvious.

• Now, the user is ultimately responsible for approving sending the information to the malicious site after all of these indicators that something is amiss. But, let's say that they proceed and send the information. What happens then?
• The site get's a signed security token with your name, address, phone number, date of birth details. Nothing so risky as a SSN or passport number.
• The same token carries the card PPID, however this PPID will not be the same PPID as that used for PayPal because every site gets its own PPID for the card.

So, what can the malicious site do with all this information? Can they log in to PayPal now?

• No, because they don't have the PPID and presumably PayPal has associated their own PPID with the account, not the same as the one the malicious site received.

What else can go wrong? A malicious party could somehow get their hands on the PPID information. This wouldn't be so easy, since the security token issued by CardSpace is always encrypted when sent...but once it arrives to PayPal site it is open and available for view, and someone could look over your shoulder as you view your card to send to PayPal and see the PPID for PayPal right there. If this happens, there is another security measure available.

Each personal card has a private key associated with it - called a master key. That master key is used to sign the security token sent to the site. Only your exact card installed in CardSpace can sign the token with this private key. Thus, if the site associates the PPID + hash of the master key cert with your account, only tokens signed with the correct private key carrying the correct PPID will be authenticated. A malicious party cannot get the master key unless they export your cards from the machine, and import to their machine. Hopefully the user has a password on their laptop. Hopefully if they export cards and import to another machine, they do it safely and destroy the copy they put temporarily on the USB drive to transfer the cards.

Still, this is MUCH MORE SECURE than the username and password we use today...because now a malicious party has to get physical access to a user's machine or USB drive with exported cards...and figure out the password protection in the latter case since exported cards are encrypted.

Hopefully this helps explain how CardSpace and personal cards HELP sites to protect users...better than username and password to today.