This is the information you've been waiting for!  You've seen the InfoCard -IE 7 demo at RSA Conference last week.   If you missed it, not too worry - plenty of articles you can read.

Many have asked me, how does it really work?

In a simplest scenario, a web site could simply add an HTML tag (either using OBJECT tag or XHTML tag) as part of <FORM> element.  When IE 7.0 sees this, the InfoCard experience lights up.

Here is a simple example of OBJECT tag and XHTML insider FORM tag.

  <FORM method="post"
        action="" >
        <input type="submit" name="InfoCardSignin" value="Log in"
         id="InfoCardSignin" />
        <OBJECT type="application/infocard" name="xmlToken">
          <PARAM Name="tokenType" Value="urn:oasis:names:tc:SAML:1.0:assertion">
          <PARAM Name="issuer"
          <PARAM Name="requiredClaims"
OR --------

<html XMLNS:ic>
     <form  method="post" action="" >      
        <ic:informationCard  name='xmlToken'
           claimType='…/claims/emailaddress' />
       <input type="submit" name="InfoCardSignin" value="Log in" id="InfoCardSignin" />

Notice that the InfoCard OBJECT or XHTML tag will be part of POST message, just like any other element inside the <FORM>.

Once the InfoCard UI shows up, user selects the card, and token is generated by the IP, the token will be posted as part of specified field ( in the example above, the field name is "xmlToken") to the targetUrl (in this example,

The login page above requires SSL connection.  InfoCard will use this certificate to (1) display the trust dialog for first time visit  (2) encrrypt the token to the targetUrl.  InfoCard also supports High Assurance certificate, just like IE7.0. 

You also notice that inside the <OBJECT> tag or XHTML (implement as binary behavior), you could specify RP's policy such as issuer, token types, claim set (either optional or mandatory), etc.

The POST message will look like this:

POST /test/s/TokenPage.aspx HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 6478
Content-Type: application/x-www-form-urlencoded
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)
UA-CPU: x86


If you look at closely, the un-escaped version of the token is an XML fragment which includes information such as the encrypted token, the method of encryption, token signature etc.

Of course, this is only one scenario. Other scenarios could involve one or more STS (security token services) owned by RP.  In this scenario, the target page will process the token, and it can make authentication and authorization decision, or it can also return another token (for example setting the cookie, if appropriate) 

It's simple, isn't it?  I think it's enough for one post to digest.  Please send your comments, feedback.