InfoCards don’t have the notion of a username in the classic sense. That means you need to find some other unique value to “recognize” your users.

Two unique values are created whenever you send a card to an application for the first time. These values are a public/private key pair and the PPID. The private key is used to sign the card, and the public key is sent along the card so that the relying party is able to verify the signature (and thus authenticate the card – but not the user). The PPID is a claim which is a long number that should make it easy to distinguish between cards. When you send the same card to five different applications, each application will see a different PPID and key pair. This prevents phishing and that one application can try to use your data to log into a different application.

CardSpace generates these values based on the identity of the relying party and a locally stored salt. The exact algorithm that is used to create these values is not public, but the general approach depends on the type of certificate that the relying party uses (e.g. a SSL certificate for a web application).

Since you have to base your user management on one of these values (or even both in combination), you should be aware of the implications when you select or change the certificate of your application.

For EV (extended validation) certificates the generation is based on the Organisation, State, Country and Location fields in the certificate. This means that you can change you certificate over the times as long as it is still an EV cert and these values don’t change. You can even have multiple applications/servers with different certificates and share the users between them as long as the above mentioned fields match.
The term EV is kind of a joke IMO. It is the job of a Certification Authority to validate the identity of the person/company that requests the certificate. Obviously most CAs do a questionable job here. So EV really means that they now try to do it properly – and this of course is also more expensive…

For “normal” certificates the approach is totally different. Here the subject fields from all the certificates in the chain, all the way to the root certificate are used. This means that you have to be very careful when you change a certificate. If one of the subjects change, the unique values will be calculated differently. This in turn means that your stored user records are now out of sync with the incoming cards, and you basically lost your users.

You can read more details about that here.

I came across a lot of companies which see certificates just as a necessary evil to get SSL up and running and they choose whatever CA is the cheapest on a yearly basis (basically after a customer reports that their browser gives them a security warning when trying to access the web application).

Be aware that you have to be more careful with your certificates when you plan to use CardSpace as an authentication system.