Note: Updtaed information on this item now exists. Please see http://www.downes.ca/midm.htm

mIDm - Self-Identification the World Wide Web

Stephen Downes
May 4, 2005

This is part two of a multi-part series. Part one is here.

My thanks to Scott Wilson, James Farmer, Scott Leslie, Luc Belliveau, Rod Savoie, Seb Schmoller and [your name here] for contributing to this article. Please note that contribution does not imply endorsement. ;)

The Concept

The idea behind mIDm - pronounced "My - Dee - Me" - is that people using the web can log in once, on their own website, and then forget about logging in anywhere else. It is, in essence, single sign-on for the people.

Billions of words have been written about user identity on the web. Numerous solutions have been proposed: to name a few, Passport, Liberty Alliance, LID, SxIP, PKI, CoSign and more...

Equally obviously, however, is the fact that no identity management solution has taken hold in any large measure on the World Wide Web. While it would be premature and in a certain sense outright wrong to call any of these initiatives a failure, it nonetheless remains true that for the vast majority of people, on the vast majority of websites, identity continues to be managed via a simple login with a username and a password.

The bulk of the initiatives listed above - if not all of them - are attempting to build something more. Sure, all of them offer some form of single sign-on - that is, a system whereby you enter your username and password once, and then access resources from a number of sites. But in addition, they are also attempting to provide some mechanism for authenticating these logins, that is, some way of asserting that the information supplied in these web forms is true.

And in order to ensure that the assertion is true, these systems employ some sort of central registry or authentication service. Part of this is driven out of pure practicality: how could a website know where to look for information about the user unless the user is registered somewhere? And part of this is driven by the desire for verification: while the website may not implicitly trust the user, it does trust the authentication service.

The prupose of this proposal is to eliminate the need for any central registry or authentication service. That does not mean that it decrees that they must not exist; certainly, there will always be a need for some sort of guarantor, some sort of third party opinion about the person in question. Rather, it means that such registries and authentication services need not exist, that everything the website needs to know about users can come from the users themselves.

The key differences, therefore, between what I propose and other systems, is:

a) You can self-declare the location of your identity server
b) You can self-identify, that is, you can state for yourself who you are and (say) how you can be reached

Which leads to the point of yesterday's paper, and the reason why I wrote it:

c) And self-authentication is good enough (and more to the point, any 'stronger' form of authentication doesn't buy you any greater security than self-authentication does)

What this does, in effect, is to establish a regime where a person's own declaration is the primary source of their identity, their own identity server; they do not need to depend on a proxy (such as a university registration, employment in a corporation, subscription to an internet service provider, or whatever). Sure, they may at a later time refer to some external agency to provide a reference or recommendation, but even this referral is at the user's discretion.

Moreover, since people choose their own identification server, the level of security they require may be as weak or as strict as they desire. If a simple login with cookie support is enough (as it is for the vast majority of people on the vast majority of websites) then this is all they use; if they want secure sockets layer with IP verification, then they may opt for this as well.

Moreover, by creating a mechanism by which anyone may self-identify, it also creates a mechanism whereby any web service may request identification. A website does not need to belong to a federation, be some part of a trusted network, or some such other secret society. The self-identification network is open: anybody can play.

Caveats

In the sections below I will provide some computer code, written in a programming language called Perl. The code provided is not the self-identification service I am proposing. Eventually, I would hope that it will be an instance of it. But not yet.

What I have provided is merely a proof of concept. That is, I have written the minimal amount of code necessary to show that what I am proposing will work. Based on input that I have already received, I can say that this code will definitely change over the next few days and weeks.

Moreover, it is important to empasize at this point that the code is not the proposal. The code is merely an instance of the proposal. It is my expectation (already fulfilled to a degree) that versions of the same proposal will be written in other languages, such as Python or PHP. It is moreover my expectation that application-specific code, such as Drupal or WordPress modules, will also be created.

Finally - it is necessary to stress again - what mIDm is not is an authentication service. That is, websites have to take the user's word that they are who they say they are. But what it does do is to provide any user who wants it with a unique identity. Also, it is not by itself a solution to other problems, such as comment spam. Though such solutions will rely on a system such as mIDm, they will require a second part (which, yes, I will illustrate in a subsequent work).

What I am trying to prove here is that we can get a free, open and distributed system of single sign-on self-identification off the ground using nothing more than Notepad, some common understandings, and a little ingenuity. And what I believe we will prove, in the long run, is that this is all we ever needed.

The Proposal

The proposal is dead simple.

You - a web user - create a website on which you create a program you can log in to (you don't have to do this yourself - you could use a program someone else created to do the same job - but the point is, you could do it yourself.

You then place the address of that program - its URL - into your browser.

Then, any time you go to a website, if that website wants to know who you are, it gets the URL from your browser and sends a request to the program. "Who is this?" the website will ask. "This is me!" the program will reply.

How does the website know that you've sent it to your program, and not someone else's? The same way Feedster or Technorati or Blogshares allows you to 'claim' a blog. It gives you a little bit of code which you then place into your program. Because you have to log into the program, only you could have placed the information there. So once the website gets the little bit of code back from the program, it is satisfied that you, indeed, are the person described by this program.

In a sense, it's no more and no less secure that having you type your personal information into a form. Sure, you could lie - but that's not the point here. The point is that this is a mechanism by which you, the web user, can make a declaration about who you are.

Now, in the code provided below, the messages sent back and forth are very simple - too simple, actually. The 'little bit of code' is nothing more than the current time. The response back is nothing more than the little bit of code.

In the final version, these messages will be a little more complex (but not a lot more complex). They will be, in particular, valid instances of the Security Assertion Markup Language (SAML) V2.0. This means that statements made by mIDm will be predictable - everybody will know how to make a request, everybody will know how to read a response. And it means that your own little self-identification server will speak the same language as the centralized identity servers - just in the same way your home-grown web site speaks the same HTML that Yahoo! or Google speak, just the way your own little cut-and-paste RSS feeds speak the same language as those produced by LiveJournal.

How Does It Work?

In a nutshell:

A user declares the name of his or her private website - the location of an mIDm script on their own server (or a server provided by a host, such as an online community of their choosing)
When the user attempts to access a remote website, the remote website redirects their browser to that mIDm server with an access key (sometimes called a 'handle', though I don't like that name).
The mIDm server accepts and stores the key. The idea here is that only a person with access to the mIDm server can store that particular key.
The mIDm server redirects the user back to the remote website.
Upon the user's return, the remote website independently requests the key from the mIDm server.
If the key is returned, then the server accepts that the mIDm address provided by the user is valid, and hence, may request additional information (such as, say, FOAF data) from the mIDm server.

Now it should be clear from the outset that this system does not prevent the user from adopting an alternative identity. Nor does it prevent several people from sharing a single identity. This is not the purpose of the mIDm system. The sole purpose is to guarantee that the information being provided by the mIDm server is in fact being provided by the user requesting access. In essence, it is as secure as (and no more secure than) requiring a UserID and a password to access a website.

Scott Leslie provides this image of the process:

More precisely, what is proposed is an instance of 'SP Initiated: Redirect->Artifact binding. See Figure 18, pg. 25, of the SAML 2.0 Technical Overview (PDF).

Set-Up - User End

Step One - Install the mIDm script

The mIDm script is a CGI script that runs on the user's web server (or is provided by a website host). This script checks the user's browser cookies for a valid USERID (the code provided uses two cookies, named 'person_title' and 'person_id', but can be altered to accept any cookie values already set by the server). If the cookies are not present the script exits (the code provides redirects the user to a login screen).

To install the script, copy the code listing immediately below (Listing 1) and save it as a file on your web server. Edit the cookie values if necessary. On Linux / Apache systems, chmod the script to 755 (in other words, run-enable the script). Test the script by typing the script address in a browser. You should see the message 'mIDm script installed OK'.

Note: you can't just install this script out of the box and expect it to work. It needs to be tied to a login system. The example provided below is tied to the downes.ca login system. I will, at a future point, provide a script that handles login as well as identification. But this isn't that script.

Note: for most users, access to this script will simply be something provided by their web community of choice and no installation will be required.

Step Two - Declare your mIDm Location

Using a Firefox browser go to the User Agent Switcher Extension website and install the user agent switcher.

Once the extension is installed and the browser restarted, select 'Tools' from the menu bar, then select 'User Agent Switcher', then 'Options', then 'Options'. In the box that pops up, select 'User Agents' from the left-hand menu. A list of user agent names will be displayed; select one of those or add a new one (I simply selected 'Internet Explorer'). Click 'Edit'. In the 'Edit User Agent' box that pops up, in the second line (where it says 'User Agent'), add a semi-colon and then the address of your mIDm script.

The following image shows (part of) the URL of an mIDm script added to the 'User Agent' line (circled in red):

Clock 'OK', then 'OK' again to close the popup boxes. Then select 'Tools > 'User Agent Switcher' again and select the user agent that you just altered from the list.

Luc Belliveau also reports that the User Agent can be changed in Internet Explorer by amending the IE registry entry: "In key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent], the "Version" string can be added to change change it, you can even change the platform."

Note: this slightly cumbersome process relies on an existing extension to amend the user agent. Presumably, someone will write a simple extension and/or plugin that will simply allow you to input the location of your mIDm script, and will automatically append it to the end of your existing user agent.

Warning: Messing around with your User Agent may cause some websites to react in an odd way. I am testing this now and have found no ill effects so far. But you've been warned.

Set-Up - Server End

If you have a web server and would like to enable single sign-on, do the following:

Copy the script below (Listing 2) to your website and chmod it to 775. Edit the URL for your script.

Note: the script supplied does nothing more than say whether the user has been verified or not. OK, so I have no imagination. In a fuller version, once the user has been verified information would be obtained about the user and this information used by the website to provide personalized services.

Try It Before You Install

I have installed a test case of the two scripts on my website.

First, install the User Agent Switcher as instructed above and set the following as your mIDm URL: http://www.downes.ca/cgi-bin/idme.cgi

To try it out, try to access the single_signon script: here. You will notice that you are bounced to the login script.

Now try to access the single_signon on a different server (newstrolls.com): here. You will notice that you are bounced to the same login script on the downes.ca.

So go to the login script: here and log in as UserID: tester password: tester

Now go back to the single_signon script: here. You will notice that you are now verified.

Finally, go back to the single_signon script on newstrolls.com: here. You will notice that you are now verified on the NewsTrolls site as well.

The Road Ahead

So what needs to happen before we can start implementing this systen?

Nothing.

It can be done now, with the tools we have now. For after all, we already have the two major components we need: the place to store the location of our own authentication severs, and the langauge (SAML) websites and identity services can use to talk to each other.

Don't like the code I provide here? Write your own in Python, PHP or whatever. Think my login system is way too loose? Embed your code in Drupal, Plone or whatever - write it as a module, write it as base code.

Nothing new needs to be invented. We don't need to wait for some major authentication project to come along and manage it all for us. We can do it ourselves. We should do it ourselves.

Of course - if you do want to wait, the code provided here will be cleaned up and written more rigorously. You will be able to simply copy the code to your website, make minor modifications, and be up and running. After all, it's not rocket science.

Or, at least, it shouldn't be.

Yes, there will be a part three: Applications of mIDm. Moreover, I will be updating the code listings on this page. Stay tuned.

Scripts

Listing 1 - idme.cgi

#!/usr/bin/perl

use CGI;
use CGI::Carp qw(fatalsToBrowser);

#
#	idme.cgi
#
#	Copyright 2005 Stephen Downes, National Research Council Canada
#	Prerelease - please do not distribute - I'll GPL it when it's ready
#

#
#	Edit these variables for your script
#

my $usercookiename1 = "person_title";
my $usercookieval1 = "Tester";

my $usercookiename2 = "person_id";
my $usercookieval2 = "3";

my $loginscript = "http://www.downes.ca/new_login.cgi?refer=http://www.downes.ca/cgi-bin/idme.cgi";

#
#	OK, that's it - don't mess with the rest unless you know what you're doing
#

my $query = new CGI;
my $vars = $query->Vars;
my $site = $vars->{site};

if ($vars->{request} eq "confirm") { &return_key($site); exit; }
my $person = get_person($usercookiename1,$usercookiename2,$usercookieval1,$usercookieval2,$query);
my $key = $vars->{key};

unless (($site) && ($key)) { print "Content-type: text/html\n\n<h1>mIDm script installed OK</h1>"; exit; }

my $keyfile = &sitefile($site);
open KEYOUT,">$keyfile" || die "Cannot open keyfile: $!";
print KEYOUT $key || die "Cannot print to keyfile: $!";;
close KEYOUT;

print "Content-type: text/html\n";
print "Location: $site?confirm=yes\n\n";
exit;

sub get_person {

# Get Person Info from Cookies
	my ($usercookiename1,$usercookiename2,$usercookieval1,$usercookieval2,$query) = @_;
	my $person_title = $query->cookie($usercookiename1);
	my $person_id = $query->cookie($usercookiename2);

unless (($person_title eq $usercookieval1) && ($person_id eq $usercookieval2)) {
		print "Content-type: text/html\n";
		print "Location: $loginscript\n\n";
		exit;
	}
}

sub return_key {
	my $site = shift;
	die "Must specify a site to request from" unless ($site);
	my $keyfile = &sitefile($site); my $key;
	open KEYOUT,"$keyfile" || die "Cannot open keyfile: $!";
	while (<KEYOUT>) { $key = $_; last; }
	close KEYOUT;
	unlink $keyfile;
	print "Content-type: text/html\n\n";
	print "$key";
	exit;
}

sub sitefile {
	my $sitefile = shift;
	$sitefile =~ s/http:\/\///ig;
	$sitefile =~ s/\//_/ig;
	$sitefile =~ s/\./_/g;
	$sitefile .= ".dat";
	#print "Content-type: text/html\n\n";
	#print "$sitefile<p>";
	return $sitefile;
}

Listing 2 - single_signon.cgi

#!/usr/bin/perl

#
#	single_signon.cgi
#
#	Copyright 2005 Stephen Downes, National Research Council Canada
#	Prerelease - please do not distribute - I'll GPL it when it's ready
#

#
#	Edit these variables for your script
#

my $script_location = "http://www.downes.ca/cgi-bin/single_signon.cgi";

#
#	OK, that's it, don't edit below this line
#

use CGI;
use CGI::Carp qw(fatalsToBrowser);
use LWP::Simple;

# Normally I would test for a cookie here
#print "Content-type: text/html\n\n";

my $query = new CGI;
my $vars = $query->Vars;
my $key = time;

my @useragentstuff = split /;/,$ENV{'HTTP_USER_AGENT'};
my $redirect = pop @useragentstuff;

unless ($vars->{confirm}) {
	open KEYS,">>confirmkeys.dat";
	print KEYS time."\t$redirect\t$key\n";
	close KEYS;
	$redirect .= "?site=".$script_location."&key=$key";
	print "Content-type:text/html\nLocation:$redirect\n\n";
	exit;
}

print "Content-type: text/html\n\n";
print "OK, I'm back<p>";

my $verify = $redirect . "?site=".$script_location."&request=confirm";
my $content = get $verify;
die "Couldn't get $verify" unless defined $content;

print "OK, found the key: $content<p>";

if(&verified) {
	print "Verified<p>";
	# Get more information, write them a cookie, do whatever you want with your signed-on user here
} else {
	print "Not verified<p>";
	# Send them to a login screen, whatever
}

sub verified {

my $confirmed = 0; my $eek;
	my $datafile = "confirmkeys.dat";
	my $tempfile = "confirmkeys.temp";
	my $backfile = "confirmkeys.bak";
	open KEYS,"$datafile";
	open TEMP,">$tempfile";
	while (<KEYS>) {
		chomp;my ($time,$user,$key) = split /\t/,$_;
		if (($user eq $redirect) && ($key eq $content)) { $confirmed = 1; }
		if ((time-$time)<30) { print TEMP "$time\t$redirect\t$key\n"; }
	}
	unless ($eek) { 	# Rename OLD to BAK, NEW to OLD
		if (-e $datafile) { rename($datafile, $backfile) || die "Cant Rename: $!"; }
		if (-e $tempfile) { rename($tempfile, $datafile) || die "Can't rename: $!"; }
	}
	close KEYS;
	close TEMP;
	return $confirmed;
}