Within CardSpace, there are two types of cards; there are those that you issue yourself called Personal cards and those that are issued by other Identity Providers. These are known as Managed cards.
The creation of Personal cards is very straight forward within CardSpace, thanks to Microsoft's very simple CardSelector UI. When you create your own card you are basically stating some facts about yourself. You typically give some basic information such as your name, email address, phone number etc. and this information is sent each time you submit the card to a site. Nobody backs this information up and you may ask why any site would trust a personal card? Submitting unsubstantiated information like that is just the same as filling out your name and address when you're creating an account with Amazon. Nobody verifies that data for them. However, the most important thing about the account that you create is that the next time you shop from Amazon, they know it was the same person who created the account. They verify this fact by the use of passwords. So whilst the information you've provided may not be exact, they build up trust with your account each time you shop with them. Personal cards operate in the same fashion, except you verify you are the same person by submitting the same card each time.
But what about more important information that you want undisputable proof is accurate? Age, for example, or credit card details. You may not want your users spoofing this by submitting false (or in the case of credit cards, stolen) information. Sites that sell alcohol over the internet would love to verify that the person buying beer or wine is over the age of 18. In a normal bar/pub situation, you would produce your driver's license or passport. The owner would read this and, trusting the government, accept that the date of birth printed on it was true. Imagine if the government could vouch for you online? That is where managed cards come in.
From the users point of view managed cards are not much difference from the personal cards they create themselves. Firstly, the user would present themselves to an identity provider, in our example it's the government. You would first establish your identity to the government, using your name and social security number etc. The government then, happy that you are who you say you are, will issue you a managed card in the form of a .crd file. Obviously the identity provider could go to greater lengths so prove identity such as face to face meetings etc but let's not get too Orwellian just yet. With your government issued Ident.crd file, you would simply install it into your CardSpace selector. You'll be given a chance to verify the contents of the .crd file and the use of images here help give a visual key to identity as well text. Once you're happy the card is okay, you would complete the installation.
You then log onto www.winesRus.com to purchase a bottle of bubbly and on checkout you're prompted to prove you're over the age of 18. The site accepts CardSpace so you fire up the card selector and choose your government identity card. This has your age contained within and since it's government issue winesRus trust that this data is true so they sell you the champagne. Cheers!
That's a very simple process as far as the user is concerned. What happens under the covers is far more complex. It's important to note that the .crd file that is issues doesn't contain any of the information it will eventually be used to send. All it contains is the details of the identity provider and the name of the card. When you select the card for submission, the card space selector actually sends a request to the issuer of the managed card. The issuer then responds with a token (encrypted and signed by themselves) containing the card information. This token is then sent to the Relying party. The Relying party is the one who wants the data, so in this case it's winesRus.com. WineRus then take this token, inspect that it came from the right issuer, decrypt it and then use the data contained within.
In order to issue your own managed cards there are two components required. The first component will actually issue the .crd files. Once the .crd file has been installed a Secure Token Service (STS) is required to take requests for the managed card and to issue the secure tokens that eventually get sent to the relying part.
One last thing I'd like to say on this is the securing of managed cards. The securing of personal cards isn't that important really since they don't contain any information a hacker couldn't get off your own PC if they had gotten that far. Managed cards on the other hand could represent credit card or bank information and are far more sensitive. To prevent unauthorized users from sending these cards they can be protected by the card space selector in a number of ways. UsernamePassword, SmartCard, SelfIssuedAuth and KerebosAuth are the authentication methods available.
Username/Password: This might seem like it's defeating the purpose but I don't agree. IN the case of a credit card you typically enter four of five pieces of information over and over again, not including your name and address and other bits of information such as email and phone. One managed card could included all that information meaning that you could simple submit it once and enter your standard username and password as you would for your Amazon account, the difference being that Amazon would no longer need to store all that information as they currently do for fraud prevention.
Smartcard: The presence of a certificate can be required in order to use a managed card. The certificate would usually be stored on a smart card so that it's not always present on the machine.
Kerebos: This would basically be windows authentication.
SelfIssuedAuth: A personal card can be used as the authentication method for managed cards. [I'm still a little unclear on how exactly this works and what purpose it serves]
For more information on managed cards, I would suggest downloading the CardSpace sample "Creating Managed Cards" and working with CardWriter.exe.