Today I updated the xmldap relyingparty to contain two HTML objects of type "application/x-informationcard". To keep things simple I just have put two forms on the website each containing one object. The only difference between the two is that on requires a self-issued card while the other does not restrict the issuer. The id selectors seem to handle this well. I tested it with the openinfocard id selector and with CardSpace. What is this good for?! Well, one object could request a card from the

Sometimes wishes become true. I just whined about the cost for certificates but only a few hours later I found this offer from GoDaddy for opensource projects . Have to wait how complex this gets... Sending the application was easy. Now I am waiting for approval...

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

Perhaps I am easy to impress or maybe I have a misconception about IP addresses, but I am still impressed by Jurassic ones. Apple has 17.149.160.10 HP has 15.192.45.21 Everything smaller than 32 is from the Stone Age. In the era of classless routing this is not that impressive anymore, but still... openinfocard.org (today) is 68.178.232.100 which is smaller than 128 but nothing to be proud of. And anyway the rule "smaller is bigger" does not count anymore. And I have to make up my mind what I do

Wednesday and Thursday are the days to be in Munich to attend the 2nd European Identity Conference . Kuppinger and Cole were so kind to provide space and a WLAN and time and marketing people for the first post RSA interop. We will demonstrate interoperability during the last two hours of the expo opening time each day. Most of the RSA interop sites are up and working. The results of this interop go into the main RSA results table. Tomorrow (Tuesday) is the day of interesting pre-conference workshops.

Trying to commit a change to the xmldap STS that makes it obey the subject confirmation method element in the RST. BUT: $ ping openinfocard.googlecode.com Ping googlecode.l.google.com [64.233.187.82] mit 32 Bytes Daten: Antwort von 64.233.187.82: Bytes=32 Zeit=348ms TTL=241 Antwort von 64.233.187.82: Bytes=32 Zeit=2787ms TTL=241 Antwort von 64.233.187.82: Bytes=32 Zeit=1318ms TTL=241 Ahhh. The fourth try to commit the files succeeded. Please find the new version in the xmldap source code repository

Shamelessly copied from Johannes Ernst's blog . FOR IMMEDIATE RELEASE April 7, 2008 MEDIA ALERT Showcasing How Users Can Control their Identity Online, Industry's Largest Identity Interoperability Demonstration Scheduled for RSA 2008 Fifty-seven member open source identity group to test and demonstrate interoperability between user-centric identity protocols and providers SAN FRANCISCO (RSA Conference 2008) - April 7, 2008 - Open Source Identity Systems (OSIS) will conduct the largest user-centric

The early betas of Firefox3 crashed when the openinfocard identity selector was loaded. The current beta and the one before do not crash, but don't work. InternalError: Unable to convert JavaScript value file:/C:/Dokumente%20und%20Einstellungen/Nennker.Axel/Anwendungsdaten/Mozilla/Firefox/Profiles/kb7ofbop.default/extensions/ %7B211DBAEA-CE99-11DA-8254-96BEC52F3316%7D/components/firefoxClassLoader.jar to Java value of type java.net.URL[] Yesterday I retrieved the latest Firefox3 code from CVS and

The openinfocard id selector now works with Firefox3 . The bug in Firefox3 is not fixed but circumvented. Firefox3 treats arrays of java objects differently than before. In a javascript script the call "java_method([aElement])" formerly worked but now it fails. It has to be replaced with var urlArray = java.lang.reflect.Array.newInstance(java.net.URL, 1); urlArray[0] = aElement; // aElement beeing a java.net.URL java_method(urlArray); Please download the latest version in the openinfocard download

You might have noticed that sometimes the security token on xmldap's relyingparty is not valid. The conditions on the token are not met because the time on the server was about 30 minutes off. Chuck corrected this immediately and I wanted to verify that the relyingparty there now accepts a security token produced by the latest openinfocard id selector. I quickly installed it, but booom; it failed. The line of code in question was unnecessary anyway so I cleaned up the javascript quickly; transferred