One thing that has been bugging me, and many others with me, is the need to sign up for every website/service/forum separately. Why not have one super username/password combination that works everywhere and be done with it?
Microsoft has attempted to solve this problem with Passport, but it failed. People don’t trust Microsoft with their personal information. Sun and others have started Project Liberty, but not much has followed from it, for as far as I can see. And the end result will undoubtly be a very complicated API.
Still, the problem bugs me. People don’t trust one company with their personal information. Then I thought, OK, so maybe decentralizing is a solution. People leave their personal information with companies and websites already. Apparently, people trust those websites and companies. It reminded me of Jabber. Jabber is a decentralized instant messaging service. There is no central server where all the contact lists and user data is stored, each user picks or runs its own server where his or her data is stored. For example, my jabber id is firstname.lastname@example.org. What this means is that I have an account at the 12jabber.com Jabber server, and my username there is ‘zef’. If somebody wants to send me a message, his or her jabber client contacts the 12jabber.com server and tells it that it has a message for user ‘zef’. This way you don’t need a central server. The user id tells you where to send and get information.
Ok, so how can this concept be applied to, say, websites that use an authentication service, like forums? People hate to sign up for each site individually, it would be great if they can easily transfer their profile from one website to the other. I came up with a very simple solution, very similar to what Jabber does. I dubbed it SPTP for now, the Simple Profile Transfer Protocol. This is how it works:
Every application (for example forums) implements a SPTP server. It is a simple script that accepts a username and password and returns the profile data if the username and password match. The software also includes a SPTP client. When somebody attempts to login with a username that does not exist, the format of the username is checked. If it looks like this: email@example.com, or even: firstname.lastname@example.org/forums, the software concludes that this is probably a SPTP user. It contacts someserver.com to retrieve the profile data and uses this data to register the user locally on the website. After registration is completed (ideally the user doesn’t even notice this is happening), the user is logged in.
The protocol that I chose for SPTP is very simple and not amazingly secure. On the other hand, profile data is not very secret, so I don’t expect this to be a problem. It is a good idea, however, to allow SPTP login attempts for each user only once very, say, 20 seconds, to avoid people trying to brute force their way in.
The implementation of SPTP is extremely simple. At the end of this post I’ll include a .zip file with a PHP SPTP library that basically has two functions: sptp_exportprofile (to export an associative array of profile data to SPTP XML) and sptp_getprofile (which takes a userid and password and retrieves the profile data for you). All you have to do to use it is implement the automatic registration and server part. I implemented all this in a couple of hours.
SPTP authentication happens as follows: Let’s assume the user Zef@zefhemel.com has attempted to login to a forum where no such user exists. First the file http://www.zefhemel.com/sptp_auth_path.txt is requested by the SPTP library. This file contains the path to the authentication service, for example /sptp/auth.php. Then a POST request is done to http://www.zefhemel.com/sptp/auth.php with two POST fields: username and password. The auth.php script checks the username and the password and, if they are correct, returns a simple XML file which looks roughly like this:
<sptp version="1.0"><br> <nickname>Zef</nickname><br> <avatarurl>http://www.fmf.nl/~zef/icon.php?icon.gif</avatarurl><br> ...<br></sptp>
The forum then uses this data to register the user locally and logs the user in. That’s it.
One problem remains: which profile fields are there and what are they called? Different kinds of services (and even similar ones) have different profile fields and I think they should be free to add any field they like in SPTP. Fields that the software does not recognize will just be ignored. I think there should be a set of standardized field names, however. Which those would be is open for discussion, some that I can come up with right now:
I created a very simple SPTP service and client for demonstration purposes, which you can see and test here. You can download this example and the ad-hoc SPTP implementation I just created here.
It’s all not finished. At this stage I’m mainly interested in input from others. So let me know your thoughts and concerns.