CardSpace in .Net Framework 3.0 required that sites deploying CardSpace always have a SSL certificate. This meant that every site that wanted to use CardSpace was forced to deploy an https site.

Based on customer feedback, we have decided to relax this requirement for the next release of CardSpace (currently available in .NET Framework 3.5 Beta 2). We realize that there are some sites like blogs which would like to use CardSpace, but consider the SSL requirement to be a deployment blocker. Now, if you have a website that you want to add CardSpace support to, all you need to do is add the object tag to the page and you are done.

In addition to requiring .Net Framework 3.5 beta 2 or later, a new version of icardie.dll is required to use this new feature. This will ship with Vista SP1 and an upcoming update to IE7.

CardSpace does behave differently for http vs. https sites. When CardSpace is invoked from an http site, CardSpace will inform the user about the lack of an SSL connection and the security implication of this. (Also, note the new streamlined look of this window)


No SSL screenshot

In addition, managed card issuers can decide if the card they issued can be used on sites that do not support SSL. This can be done by adding the following element to the .crd file.

      <wsid:RequireStrongRecipientIdentity xmlns:wsid= ‘’> 

If this element is specified then the card can only be used on a site that has a SSL certificate. The card will not ‘light up’ when the user is on an http site. A point to be noted is that cards that were issued for last release of CardSpace will light up on http sites as they will lack this new element. In that case, the IP STS can make a decision on whether to release a token based on the identity of the recipient sent in the RST message. Another feature that was added for this release is the support for custom soap faults (next blog entry will have details on that feature) and that can be leveraged to provide the user with appropriate error information. Similarly, if a .crd file with this element is imported into the last release of CardSpace, it will be ignored.

Some other differences on an http site are:

1)    PPID value is different as no certificate is available. The method used to calculate the PPID is the same as described in the Identity Selector Interoperability Profile. The only difference lies in the calculation of the RP identifier. The RP Identifier is calculated as follows

a.    OrgIdString = fully qualified DNS host name or the IP address of the server specified in the URI of the site.

b.    Encode all the characters in OrgIdString into a sequence of bytes, call it OrgIdBytes, using Unicode encoding (UTF-16LE with no byte order mark).

c.    Hash OrgIdBytes using the SHA256 hash function, and use the resulting value as the RP identifier.

RP identifier = SHA256 (OrgIdBytes)

2)      For an auditing STS, only the URL of the site is sent to the IP STS as identity information for the relying party. As described in the Identity Selector Interoperability Profile ( Section 4.3.3), if no wsp:AppliesTo is specified in the relying party’s token policy and the IPSTS requires it, the following will be sent for a http site




<wsa:Address></wsa:Address> </wsa:EndpointReference>

</wsp:AppliesTo> ...


Though a certificate is not sent to the IP STS, the token returned by the STS can still be encrypted if the identity provider has a pre-existing relationship with the RP and has mutually agreed on the use of a known encryption key.

3)      Self issued tokens are not encrypted. Because the token is unencrypted, the only change most token processing libraries require is to skip the decryption step, the rest of the token remains unchanged.  The token processing sample at will be updated with this change.

4)      Though the self issued tokens are not encrypted they are still signed as described in Section 8 in Identity Selector Interoperability Profile

Let us know if you have questions or feedback.


Software Design Engineer - CardSpace Team