What's new in CardSpace in .NET Framework 3.5? Well, it is quite similar to the version that shipped in .NET Framework 3.0. The differences are minor with the exception of HTTP support:

User experience refinements
We have made a number of small user interface refinements based upon feedback from users:  

Streamlined first usage
The "Out of the Box Experience" (OOBE) dialog box that appears when you launch CardSpace for the first time has been removed. The user is not shown a list of empty card list or a list of disabled cards but is taken directly to the Create a New Card page or Install a Managed Card page.

Installing managed cards
When installing or restoring cards from outside CardSpace by double-clicking on a .CRD or .CRDS file CardSpace automatically exits when it has finished adding the card(s). This behaviour was found to be more intuitive than remaining in the CardSpace UI after cards have been added.

Editing cards 
When creating a self-issued card "on-the-fly" for a site only edit boxes for the required claims are displayed. Edit boxes for optional claims are grayed out until enabled via a check box. Claims not asked for do not appear in the UI. Once the edit boxes have been filled the card can be sent straight away without having to go through a Save step.

Default card image in richer colour
The default card image (an androgynous human figure) was in sepia tones which, while pleasing to the graphic artist who designed it, made it difficult to determine when a card was enabled or disabled. It's been made more colourful to make this more obvious.

Send is the default button
Send is now the default button in the card chooser dialog. So pressing the <Enter> key will send the selected card.

Enhancements for Identity Providers
Contact information in .CRD
Identity Providers can include custom information (up to 20 name/value pairs) in a .CRD file (the infromation card file) and CardSpace will display it to the user when they are looking at the card details. One obvious use of this feature is to provide IP contact information to the user (email or phone details for support).

Custom authentication messages (authentication fails)
Identity Providers can return a SOAP fault and CardSpace will now display the Fault Reason Text.  This feature enables IPs to present the user with help and support information such as phone numbers or URLs. The fault reason text can be localised in which case CardSpace will display text based on the current UI locale.

Support for the latest OASIS specs
CardSpace now supports the Oasis WS-SX versions of the WS-Trust (v1.3), WS-SecurityPolicy (v1.2) and WS-SecureConversation (v1.3) protocols in addition to the versions supported in 3.0.

Site Information Page 
When a user first wants to send a card to a site - and also when the site changes its policy or the CardSpace ledger is cleared - a Site Information Page is displayed giving information about the site and its certificate. This has been updated.

If the site is using an Extended Validation (EV) SSL certificate a lock symbol is diplayed to signify SSL protection and the certificate information has a green background to highlight that it comes from an EV certificate (somewhat similar to the address bar in browsers).

If the site is using a normal SSL certificate a lock symbol is diplayed to signify SSL protection and the warning text (because it is not an EV certificate) has been changed from "This site does not meet Windows CardSpace requirements for a bank or major Internet business. To learn more, click Why is this important?" to "Only the name of the site has been verified. The operator of the site and its location are not verified. Banks or major Internet businesses may choose to better identify themselves for your protection. To learn more, click Why is this important?"

If the site is not using a certificate (a new feature with 3.5, see below) the user is warned as follows: "The information that you send is not protected with encryption and can be viewed by others. Do not send a card that includes sensitive information" and "This site's information cannot be verified. Banks or major Internet businesses usually choose to better identify themselves for your protection. To learn more, click Why is this important?"

HTTP Support
Prior to .NET Framework 3.5, CardSpace required sites to have an SSL certificate (either standard or Extended Validation). Now you can use CardSpace with HTTP. This means that tokens pass over the wire in the clear and users are warned of this in the Site Information Page (see above).

Besides the change of protocol, all that a Relying Party has to do differently is omit the decryption step when doing token processing. It should always validate the token signature.

To use CardSpace over HTTP, clients need to have the .NET Framework 3.5 installed and a browser or browser add-in that knows how to call CardSpace when the user chooses the information card tag in a page. The initial release of IE7 blocks if a user tries to use CardSpace over HTTP, current versions of IE7 (patched using Windows Update) work correctly.

Identity Providers should decide how to function over HTTP connections. They might only issue identities over a secure channel - in which case they can mark their managed information cards with the <wsid:RequireStrongRecipientIdentity xmlns:wsid=‘http://schemas.xmlsoap.org/ws/2007/01/identity’> attribute and the cards will not "light up" in the CardSpace UI when HTTP is used. They could also send a different set of claims for HTTP versus HTTPS.

Auditing STSes, which require the Relying Party's identity, are sent the RP's URI in lieu of RP certificate information.

An Identity Provider can still encrypt the issued token and thus keep the token contents confidential over HTTP. However, the Relying Party has to know which key to use to decrypt the token (in the absence of an SSL certificate). One possibility is for the IP and the RP to agree a priori which key pair to use.

The whole purpose behind adding HTTP support is that there are many cases where confidentiality is simply not necessary because the claims are of intrinsically low value. Examples include blogs, forums and simple hosted sites where SSL is superfluous and the important thing is authentication not privacy.

Authentication using information cards does not rely on privacy. The problem with passwords is that they depend on privacy to work: once you share a password - deliberately or not - someone can pretend to be you. When the user selects an information card the Identity Provider creates a Private Personal Identifier (PPID) for the user that varies according to the identity of the Relying Party. This PPID is then enclosed in a digitally-signed token which is sent back to the client and then on to the Relying Party. In other words, each website receives a different, but consistent, id for the user. A malicious RP that lures the user into authenticating using an information card will get a PPID scoped to that malicious RP. The PPID is useless as a user identifier at other Relying Parties including the one the malicious RP is imitating. The token cannot be modified without breaking the signature.

When using HTTPS the Relying Party's identity is represented by information in their SSL certificate. With HTTP the RP's identity is based upon the fully-qualified DNS hostname or IP address. Thus even though the token passes in the clear it still authenticates the user in a secure, phishing-resistant way.