Facebook, with their Facebook Platform, can’t really be classified as a walled garden anymore. They provide all the tools both for building Facebook applications that live on “the new internet” aka inside Facebook as well as for building your own applications that live out here on the traditional web but which has access to all the same information as their in-house cousins.This makes them the ideal candidate to see what would be involved in setting up an OpenID Provider that sources information from a social network.
As an initial prototype I’ve setup an Identity Provider (IP) called Identitu.de which act as an OpenID Server backed by your Facebook account and also as a source of XFN information built up from your Facebook network. (Refer to this figure and explanation for a more thorough OpenID walk-through).
In a traditional OpenID server setup the Identity Provider would require some form of authentication, be it a username/password or certificate or by some other means, to verify that you are in fact the owner of the URL you claim to be the owner of. Now with Identitude we offload the authentication to Facebook. So whenever we need to assert that you own your OpenID URL the same process you go through to login to Facebook is triggered. Except that you are also “logged in” to the Identitude application in the same way as you are logged in to all the other applications you’ve added to your Facebook profile.
Below is the steps for 1) Using Facebook as an OpenID Provider and 2) For OpenID users and Relying Parties to extract a XFN friends export from Facebook through the OpenID Provider:
Getting an OpenID:
- You visit Identitude (either online or by using the Facebook application)
- You “Claim” an OpenID URL. (This requires Facebook login so an URL can be associated with you in future interactions) The URL is in the form <yourname>.identitu.de and can be used wherever OpenID is supported.
- Sorted
Using this OpenID:
- Wherever you see the
OpenID logo you can type in your OpenID URL to login instead of using an username or password. (Try www.jyte.com)
- After clicking on login you will be redirected to Identitude.
- Depending on whether you are logged in to Facebook you might get prompted to login to Facebook again. This is to verify that you are in fact the owner of the OpenID URL and to ensure no-one can spoof your identity or claim to be you.
- You will be prompted by Identitude whether or not you trust the site that you are logging in to.
- If you selected Yes in the previous step you are now successfully logged in to the 3rd party site.
Simple Registration Extensions:
Because just using an OpenID for logging in to sites very quickly becomes boring and I already have my basic details on my Facebook profile the next logical step was to add the Simple Registration Extensions. (An extension to the basic OpenID authentication process which allows you to provide the Relying Party with sufficient information to complete a basic registration form. Things like Full Name, a NickName, Sex, D.O.B etc)
Xhtml Friends Network and OpenID 2.0 Attribute Exchange
This is where things becomes more useful. The next logical step was to see how we can make more meaningful information like my relationships with people available to Relying Parties. The most commonly accepted format for this information seems to be the XFN format or “Xhtml Friends Network” format and it also seems to be the most popular suggestion on all recent posts on this subject. Basically it’s a basic modification to hyperlinks which adds meaning of the link or relationship between two people to the markup:
e.g. the link between myself and Thea can be marked up as :
<a href="http://theab.identitu.de/" rel=”sweetheart date met”>Thea Burger</a>
I’m not sure whether I like my relationship marked up as sweetheart/date but will leave it at that…
Here I had to make a couple of decisions. It can either be implemented as another simple extension where the link to my Facebook XFN markup is shared or I had to look at implementing the OpenID 2.0 Attribute Exchange Extension (AX). I went with the AX route as sharing something like an XFN link would mean agreeing on another form of verification and authorization as to who can access that URL and when etc etc. By using AX Identitude would be leveraging of an existing protocol which would be in keeping with the goal of creating a way of opening up social networks.
So provided your OpenID consumer site supports the OpenID 2.0 Draft specifications and AX the site can request his/her Facebook friends in XFN format by issuing an OpenID AX fetch_request message on the back of the authentication messages. (See the OpenID 2.0 Attribute Exchange Specification for more info on the protocol) :
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_request
openid.ax.type.microformats.xfn=http://schematobedefined
# One of the following two options:
openid.ax.required=microformats.xfn
openid.ax.if_available=microformats.xfn
I haven’t specified a proper OpenID 2.0 AX defined type or schema url. For the interim to make it as easy as possible to consume I’m just returning the required markup in the specified field in an URI encoded format and POSTing it back using a form-redirect if the consumer supports the OpenID 2.0 protocol. (Most networks would be too big to try and squeeze into a query string anyways)
There is a test consumer which supports AX and OpenID 2.0 at http://identitu.de/test_auth/login. By checking the AX checkbox the consumer will use the OpenID 2.0 protocol and request a friends list from the OpenID Provider.
Some of the those steps go into a little more detail than necessary. An end-user would not need to understand or know this. He/she only needs to be familiar with the basic OpenID process. Existing Identity Providers MyOpenID, ClaimID and Verisign is already doing a good job of shielding end-users from the underlying complexities.
Privacy
The only information stored in the Identitude database is the Facebook UID used to map a Facebook user to an OpenID URL and a Facebook session identifier as required for integration into Facebook. All other information including relationships between users is discarded directly after use. You also only have access to information that your user would normally have access to through the Facebook interface. All interaction happens in the context of your user.
The only information supplied as part of the Simple Registration Extension is the First Name (NickName), Full Name, Time-Zone, Sex and Postal/ZIP code. Facebook don’t supply the email address so I’m generating a dummy address for now.
As part of the AX the only information from your friends list I supply is the Name and Surname and a relation as friend.
Planned Updates:
- Verified Notifications. As we’re already generating a fake email address incoming email on those accounts can be filtered and only email from sites previously trusted by the user can be forwarded as Facebook notifications to the real user.
- Only returning URLs for friends with known OpenIDs. For privacy reasons I don’t want to share a Facebook profile page or uid. This leaves a problem but also something that is a problem with XFN in general, how to identity or contact users. I’m leaning towards temporary OpenID urls for unknown users.
- Proper OpenID 2.0 Protocol Support. The current implementation is very much a stab at let’s see what is involved with getting OpenID 2.0 running so I’m sure there is a 100 places where it either deviates or fall short of the specifications.
- Proper OpenID 2.0 AX Support. At the moment there is not a proper type or schema for the information exchanged as part of the attribute exchange. Instead relying on the pseudo ax type openid.ax.type.microformats.xfn. To figure out what the best options here are.
- Allowing users to specify different sources for different microformats.
Some useful links:
Share This
Recent Comments