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

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

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