Something we've been working on is the ability to create a web-based card selector which will work in situations where a full card selector is not available or appropriate. Since selectors are not yet ubiquitous and inappropriate in many tactical situations, we are working on using a HTML5 based approach to enable an Infocard/CardSpace-based enterprise to work with standard web browsers. The major changes in HTML5 which allow for this to occur are offline caching (HTML Manifest), the navigator.registerProtocolHandler

Ah. Sweet success. Finally. A InfoCard compliant STS which issues credentials from a LDAP backend based on X509 credentials. A pursuit which was wonderfully enlightening, painfully tedious, and maddening at times. Thanks to an idiotic obsession to complete this thing and some limited help received from a Java PingIdentity guy on the MSDN forums about proper certificate hashing ( ! ), I've got a working proof of concept based on the work of the XMLDAP work . As I close the compiler and take a few

I'm still having fun in my IDP quest. I've successfully navigated the X509V3Credential issue thanks to some help from the MSDN board and despite some apparently bad or outdated MS doco . What does that mean? I'm accepting requested along with a client certificate (which I trust), which is then included into the card I issue. When the user selects the card, the CardSpace client will retrieve the certificate from the appropriate store and use it for authentication back to the IDP. The IDP will retrieve