It's no surprise to anyone who has visited my blog before that I have had InfoCard support within Serendipity for some time now. Serendipity was not originally designed with third party authentication mechanisms in mind, so in order to allow for this, I had to heavily modify the internals of the code. Although an external authentication plugin has been available, it simply allows a username/password combination to be validated by an outside source. This combination is then saved in the Serendipity author table and then pulled from there. Not the best solution (and a simple explanation on my part of how it really works), but in the case of OpenID and InfoCard quite impossible. There are no username/passwords being submitted to the blog. In any event, this made Serendipity upgrades very painful as I had to merge my changes by hand into the new revisions. The problems I had with integration have been the very same issues that has prevented the addition of OpenID support.
That is until now (hopefully).
For the past few months I have been working with the Serendipity developers to provide a hook into the authentication mechanism that allows for end developers to create plugins to access third party authentication without the need to require a username/password combination. I have done this for my own personal reasons. The biggest being that I was tired of having to maintain my own custom implementation. This required some changes to some of the core pieces of Serendipity. What it needs now is some major testing so I would like to ask anyone who is interested in helping, head over to the Serendipity site and try the latest snapshot of the 1.2 beta version. Full announcement here. Remember, this is beta code and can potentially break things, so *DO NOT TEST IN PRODUCTION ENVIRONMENT*. The snapshots are simply the new code base, so you wouldn't be testing any new authentication methods; just making sure the system runs correctly with the new changes.
The InfoCard implementation currently implemented on my blog is my origional alpha code.; more of a proof of concept. I have started on a plugin for InfoCard support and have the alpha running on my test system. Am going to model an OpenID plugin on the same workflow so hopefully will have something functional soon. They will provide very basic functionality that will then evolve with feedback. If all goes well with the initial beta testing of 1.2, expect to see some early previews of the plugins within the month.
Perusing your site, and reading a forum topic on your OpenID plugin (and your mention of Infocards)... Am I right in assuming Infocard is a Microsoft technology that is a competing, similar protocol using a different strategy? I'd do a search, but I fear I would find much more technical babble than a clear comparison.
They are more complimentary than competing imo. A lot of people might disagree with me, but I see OpenID geared more towards social networking situations. You want single sign on with the capability of having an identifier (you URL) that is publicly known and traceable across different sites. Infocard on the other hand can provide more security and privacy, which makes it great for commercial applications. The payload of an infocard can carry almost any type of information making it much more flexible and powerful, again imo
Take a look at this diagram from Eve Maler to see how they overlap yet also provide different features: http://www.xmlgrrl.com/blog/archives/2007/03/28/the-venn-of-identity/
You might also want to take a look at the "Introducing Windows CardSpace" paper from Microsoft (http://msdn2.microsoft.com/en-us/library/aa480189.aspx). Make sure you differentiate between CardSpace (MS selector) and Infocard when reading it. I personally use the xmldap selector for firefox (http://xmldap.org/) as it runs on Linux too. Note: It does require Firefox 2.0+ to work.
Hmm, I'd personally prefer keeping the information in the authors table as sort of a cache. You'd have an additional field that would contain the necessary information so that the user information could be rechecked. Then the plugin or whatever does the auth could do scheduled runs to invalidate accounts that are no longer valid in the remote site either. Probably a dumb idea but I'd be happy to be told hear the arguments if you're against it.