Chuck Mortimore, has posted the exact steps required to "consume" infocards on his blog (xmldap). I'm not gonna steal the spotlight from him. He deserves more credit for this than anybody else. This is a cross post from Chuck's blog.

Chuck writes:

To get started, you need to get your hands on the XML Token. This should be pretty simple, as your web framework will generally hand back parameters already URL decoded.

Once you’ve got the token, you’ll need to decrypt the token. The token is transmitted as encrypted XML.

Head On Over to Chuck's Blog to see what the xmlToken would look like
OR look at my previous post on what it looks like. Chuck's Post is "complete". Mine's truncated..

Basically what you have here is an ephemeral symmetric encryption key, which has itself been encrypted with the Public Key of the SSL Cert for the website InfoCard is interacting with. As you can see from the metadata provided in the KeyInfo fragment, the key is encrypted using RSA with OAEP encoding and SHA1, using the certificate identified in the SecurityTokenReference with the provided fingerprint (the fingerprint is a SHA1 hash of the cert bytes)

Your first job is to decrypt that encryption key. Step one : remove the Base64 encoding. Step 2 : you need to write a function which takes the private key for the cert referenced by the fingerprint, along with the data as input, and decrypts in this manner RSA-OAEP

Once you’ve successfully decrypted the key ( it should be 256 bits), you can use it to decrypt the token. As you can see in the XML, you need to use AES with a ChainedBlockCipher. Decrypt the token (Don’t forget to strip the initialization vectors...thanks Gary).

Head On Over to Chuck's Blog to see what the decrypted token would look like

The next step would be to quickly check the validity period on this Assertion to make sure it’s still fresh. You might also want to check the AssertionID against a table of previously seen assertions to prevent replay...depends on your level of paranoia.

On to signature validation...you should follow the steps outlined in XML-DSIG, but to paraphrase, check the digest of the canonicalized assetion against the digest in the SignedInfo block, and then validate the signature of the canonicalized SignedInfo using a PublicKey constructed from the provided KeyInfo.

Now, what’s bugging me is the use for the Symmetric Proof key provided in the Subject of the Assertion. Super Pat and I discussed this for awhile, and since it’s not used immediately in this protocol exchange, our best guess is that it’s used in subsequent interactions with the service, although I must admit the InfoCard docs are a little fuzzy on this subject. If anyone can fill me in, I’d appreciate it!

Finally, if your signature validation worked, extract the claims, enforce any policy you’d like, create a session, set a cookie, etc...

Chuck has also reverse-engineered the infocard token creation and has published a tool that can create a token for you on his demo servers.

Now since "infocard walled garden" has been made not so mystical, Here's are my thoughts.

The OBJECT tag required to invoke the Identity Selector is a cool tool, But on the RP side, the RP is just a listener that received tokens "pushed" to it. One does not really need the use of a InformationCardSignInHelper (ie: icardie.dll for ie7)to invoke the Identity Selector (WinFX CTP). One can easily write a tool, that creates these tokens using random data and start pushing these tokens to RP's. I see this as an extremely simple way to set up a DoS attack.

• So are infocards really "secure"?
• Would they make the common man's life easier?
• Would they make RP's more vulnerable to DoS attacks?

Like I said earlier, I am having a extremely hard time trying to digest the First Law from the "Laws Of Identity". For some reason I tend to lean strongly towards not being able to digest "user control". Hopefully over time, I shall grow out of it and be able to digest the theory.

SO: Higgins folks have a base to work off of for their open source version of "infocard-whatever" (not that they needed it). And I'd like to see if folks credit Chuck for HIS hard work.