I think I might be going about this idea of consolidating your online identity with the OpenID simple registration extension and microformats wrong. I found this microformat library for PHP; It works by by retrieving the microformatted data (in this case hCard) by simply feeding it a URL and it then saves the hCard data for future manipulation. I’m starting to realize this same practice may be another way to consolidate your online identity with OpenID.

Before we get ahead of ourselves, let’s see how the applicable portion of the OpenID protocol works. The first step is to supply our OpenID URL to the consumer site and hit “submit.” For example, I would enter “nickpeters.net” as my OpenID URL to the consumer site ma.gnolia. What is a consumer site exactly? According to the OpenID Specification, the consumer is:

A web service that wants proof that the End User owns the Claimed Identifier.

Pretty much it means a site that wants to find out whether or not we are who we say we are by first asking for our OpenID URL.

After we hit the “Submit” button, an internal script on the consumer site will redirect itself to the given URL and look for two link tags in the head of the given HTML document. For the sake of simplicity, we’re only going to discuss the one of them: rel=”openid.server.” The href value of this link tag is going to be the script that actually authenticates you by asking you for the username and password you use on all OpenID-enabled sites. This practice is useful because you can offload the authentication process to a site like Vox or livejournal instead of setting up a server on your own server. This means I can enter the URL for the livejournal authentication script or a script hosted on my site. It also means your username and password isn’t sent to the consumer site and is only sent to the specified script.

That should be enough information for now, so let’s see how hCards can fit into this. Let’s say we log in to our OpenID consumer site (ma.gnolia) and go through the login process as normal. While the consumer site looks for the and OpenID.server URL in the head of our page, it would also look for some sort of clue as to the location of your hCard information. Perhaps this “clue” could follow in the steps of the existing OpenID protocol and also be a link tag, such as rel=”hcard” in the head of the document. From there, the consumer-site script can retrieve the hCard location by looking at the href value, properly redirect itself, and retrieve your information (Perhaps even using the hKit library).

The pros of this is that you can add as much or as little information as you want about yourself in your hCard. The simple registration data fields are very limited and there maybe some information in there that you don’t want to be shared (such as email address).

The cons is that it requires more administrative overhead. You’ll have to edit the header information of your site. You may not even be able to do this on all OpenID identifiers (such as ones on livejournal) because you don’t have permission to edit the header information.

Right now there are discussions going on in the microformat community about authoritative hCards that could possibly guide this idea in the right direction. I will continue to think about this and would appreciate any ideas from others.

The problem is that some sites on the internet that implement hCards may contain inconsistent data. This proposed solution will allow sites to retrieve your information from one source. If someone wants to find your personal information, they can go to any site that has your hCard instead of having to find your authoritative hCard (this will be a topic of another blog post I’m sure).

Let’s take the OpenID-enabled site ma.gnolia for example. You can sign-in with OpenID and upon successful login, ma.gnolia can retrieve your personal information from your OpenID identity provider. From there it can turn the resulting information into an hCard microformat. Of course there would have to be some sort of control panel to determine which information gets displayed and which information to hide (such as email).

Now, essentially all I am doing is applying an existing protocol, but I wanted to bring awareness to the idea of using OpenID with the hCard microformat. I also wanted to bring attention to the idea of using OpenID as a way to centralize your personal identity so you have consistent personal information among sites.

The first step I took was to actually learn the entire OpenID protocol. I ended up not learning all of the protocol because I felt the documentation was insufficient. This brings up another project idea: document the OpenID protocol in plain English. It was fun learning as much as I did and learning how to implement it myself in PHP. It also gave a chance to learn/use the cURL library in PHP. Perhaps after I learn the protocol, I’ll use a library to make further development easier.

I spent the rest of my time socializing and meeting new people and talking to people met at previous DevHouses. Highlights include talking to Konstantin Koll about his OS that implements a WinFS-like file system, Jesse Andrews of Flock about the next big release of flock (which I eagerly await!), and Chris Moak about his new sleeping schedule and duct tape accessories.

The night was ended by going out to Dennys where we discussed what made this DevHouse a success and what can be done to improve it for next time.

Pictures can be found at: http://www.flickr.com/photos/tags/shdh15