One of the problems around managed cards is that if they are protected through username and password then the benefit to the user seems not as big as one might expect. The promise to get rid of passwords is not completely fulfilled because now instead of giving a username and passport to a RP I have to give one to the IdP. The user now is disappointed and the product management responsible for the introduction of information cards at the RP is unhappy because the user is disappointed. Well, the promise

I just uploaded a new version (xmldap-0.9.9.200712212304.xpi) to the openinfocard's download area . This version allows you to change the value of the http header that advertises the id selector to the relying party. You can choose between no advertising advertise existence advertise id selector name Please enlarge this picture to see the values in the preference dialog. The X-Id-Selector http header is visible in the left sidebar. This version has now similar object handling code from digitalme

Kim Cameron noted that the certificate of the xmldap paymentCard_sts was expired. This is/was my fault. I used the wrong key alias and selected the expired certificate instead of the current one. I changed the application's configuration today. Now I am able to create a card and import it into CardSpace , which formerly complained about the expired certificate and refused to import the managed card. Please note that the paymentCards are importable into CardSpace but not usable with CardSpace, because

A new version of the openinfocard id selector (0.9.9.20071206) is in the download area of the project. The oldest card that was once sent to a relying party is now ensured to be visible by scrolling it into view. Here a picture after using the infocard login at signon.com :

Please find the new version of the openinfocard id selector for Firefox 2.0.0.9 in the project's download area . It is best used with the new version of the identity selector selector which can be downloaded from this project's download area . I tested both with most of the relying parties in the table " I2 Relying Party results with Identity Selectors ". First the id selector selector with CardSpace 1.0, then with the latest openinfocard id selector. I did not test RPs that bugged me with certificate

While investigating the issues described in my former post I began to wonder why this all has ever worked... You had this feeling in your computer science life too now and then, right? My personal history regarding this is: Chuck designed the code of the openinfocard id selector in a way that it worked with early relying parties according to the examples given in THE GUIDE . Our relying party at xmldap.org is designed excactly along the examples from the guide. When I joined the team I did not have