If you have looked at other technologies for exchanging claims (they not called that, but are at heart the same thing), you will see this system disentangles the communication protocol, the trust framework and the payload formats, whereas previous systems conflated them. Because there are now three independent axes, the trust frameworks and payloads can evolve without destabilizing anything.<\/p>\n
CardSpace “comes with” a “simple self-asserted identity provider” that uses the SAML 1.1 token format. But we just did that to “bootstrap” the system. You could just as well send SAML 2.0 tokens through the tubing. In fact, people who have followed the Laws of Identity and Identity Metasystem discussions know that the fifth law of identity<\/a> refers to a pluralism of operators and technologies. When speaking I've talked about why different underlying identity technologies make sense, and compared this pluralism to the plurality of transport mechanisms underlying TCP\/IP. I've spoken about the need to be “token agnostic” – and to be ready for new token formats that can use the same “tubing”.<\/p>\n There have been some who have rejected the open “meta” model in favor of just settling on tokens in the “concept de jour”. They urge us to forget about all these subtleties and just adopt SAML, or PKI, or whatever else meets someone's use cases. But the sudden rise of OpenID shows exactly why we need a token-agnostic system. OpenID has great use cases that we should all recognize as important. And because of the new metasystem architecture, OpenID payloads can be selected and conveyed safely through the Information Card mechanisms just as well as anything else. To me it is amazing that the identity metasystem idea isn't more than a couple of years old and yet we already have an impressive new identity technology arising. It provides an important example of why an elastic system like CardSpace is architecturally right. <\/p>\n It's sometimes hard to explain how all this works under the hood. So I've decided to give a tutorial about “HelloWorld” cards. They don't follow any format previously known to man – or even woman. They're just someting made up to show elasticity. But I'm hoping that when you understand how the HelloWorld cards work, it will help you see the tremendous possibilities in the metasystem model.<\/p>\n The best way to follow this tutorial is to actually try things out. If you want to participate, install CardSpace on XP or use Vista, download a HelloWorld Card and kick the tires. (I'm checking now to see if other selector implementations will support this. If not, I know that compatibility is certainly the intention on everyones’ part). <\/p>\n The HelloWord card is just metadata for getting to a “helloworld” identity server. In upcoming posts I'll explain how all this works in a way that I hope will make the technology very clear. I'll also make the source code available. An interesting note here: the identity server is just a few hundred lines of code. <\/p>\n To try it out<\/a>, enter a login name and download a card (if you don't enter a name, you won't get an error message right now but the demonstration won't work later). Once you have your card, click on the InfoCard icon here<\/a>. You'll see how the HelloWorld token is transferred to the relying party web site. <\/p>\n This card uses passwords for authentication to the HelloWorld identity provider, and any password will do. <\/p>\n![](\"\/wp-content\/images\/2007\/02\/helloworld.jpg\")
<\/a><\/p>\n