Title: Editorial

The notion of the identity of an individual on the Internet is an amorphous and almost nonexistent concept. The most commonly exchanged token of identity is the email address. I'm sure you have many. Perhaps one for each of your roles in society: @work.com, @home.com, @society.org, @lastname.com, @hobby.com. Of course email addresses are easy to come by and become disused just as quickly. They provide no authentication as to the identity of the owner. But, this is a powerful thing for breaking down social barriers and for preserving anonymity.

I can make a choice of the appropriate identity for each communication I initiate. Sometimes I represent myself, or some other organisation with which I am affiliated. Within a community there may be an established level of trust for a particular domain. An email from accu.org may carry more weight for you than one from kingospam.com.

In the real physical universe the notion of identity is very real, and again I can identify myself in many ways depending upon the communication I which to initiate. A credit card for a financial transaction, a library card to borrow a book, or a passport when I enter another county. These are the credentials that I carry to authenticate myself. Each issuer of identity, in this case a bank, library, or government, have different levels of trust ascribed to them by society. Each body of trust also has trust relationships with other bodies of trust. Governments have reciprocal trust agreements between each other such that citizens may or perhaps may not travel between them. Governments license banks to operate within their boundaries of control. Banks act as trustees for the owners of assets.

In the virtual world of the Internet the identity providers are numerous. Your internet service provider issues you with an identity so that you may gain access to its network point of presence, and perhaps also to its email sending and receiving servers. You may make use of a free email service at a portal site, so that you may roam freely of your ISP. Your work may provide you with a work email address. Your bank may have provided you with online access to your bank account. Your landline and wireless telephone provider may also offer online account checking. You may also have a paypal account that allows you to pay money over the Internet. You may be running a business on the side via eBay. Perhaps you use PGP and have registered your public key in a directory. You may even have bought a client side certificate from verisign. There are so many providers of identity on the Internet. Yet how many have reciprocal trust relationships? None I can think off.

Identity, authentication, privacy, and trust are all complex issues. I don't claim to be particularly well educated in any of these topics, but I sense that another apocalyptic battle of the Internet age looms on the horizon. Well, yes that may be a little strong, but as time goes on doesn't the browser war start looking like the thin edge of a very big wedge?

Microsoft has launched as part of its .NET platform and XP Operating System two new technologies: Passport and Hailstorm.

Passport is a centralised directory of user identity made openly available over the Internet for any system for user authentication. Envisage a world where you just have one user name and password for every device, system, and account. That's actually very cool, but also very scary.

Hailstorm is an extension of Passport whereby collections of attributes are stored with the user identity, again openly available for any system to retrieve once authenticated. Envisage a world where you never ever again have to type your home address into a website form. Just provide your passport identity and password and the website can fetch the attributes you have approved it to read. Again, very cool, very scary.

Why is this scary? Well, in the real world I have many identities provided by many identity providers. I can choice from them freely. What happens if devices, systems, and account providers only accept identity issued from one provider? I have many user attributes scattered over the Internet, each with different levels of sensitivity. Travelocity knows my seating preference for MD80's (by the exit), and JCrew knows my trouser measurements (34x34). Do I really want all this information centralized?

In the real world the ultimate providers of identity are governments, who are held accountable to the society that elects them. On the Internet the ultimate provider of identity could become a corporation held accountable only by its shareholders.

Why need the user directory be centralized, in order to gain the benefits of portable identity and sharable attributes? Why must the schema of the data be controlled by a corporation in order to benefit from the standardization of the syntax, semantics, and naming of information?

Of course the cynical might suggest that this might be necessary for leveraging the monopoly of a browser market into a monopoly of a server platform, and from there to service provision, and perhaps even from there to an assault on the ownership of the primary customer relationship, currently the province of banks and telephone companies. A common strategy for them attacking a market has been to adopt a standard API so as to turn the implementers of that API into a commodity. Then the API is extended to favour the favourite provider (themselves) and that implementation is offered at a very competitive price point (ie. free).

So, how might these benefits be derived without compromising control of our identities and attributes to a single corporate identity that has not proved to be particularly trustworthy in the past? After all there's little point in complaining without proffering some solution.

The user directory in the sky could be administered by an entity that is trusted by the Internet community at large. An analogous system with which this could be compared is the Domain Name System. Admittedly this is a much simpler technical problem, yet has much of the same social issues to address. The DNS system is administered by commercial entities appointed contracts by ICANN, which is itself run by a board of directors elected by the Internet community. All the technical details are dealt with by a peer organisation named 'The Internet Society' (ISOC), whose sub-organisations; the IETF, IAB, IESG, and IRTF do all the real work.

Another solution would be to give up the centralized model and allow multiple issuers of identity within a federated model. The user identity would include the identity of the issuer. I might then be able to log into a website with the identity 'yahoo.merrells', 'aol.L00z3R', or 'msft.4CB26C03-FF93-11d0-817E-0000F87557DB'. The website then authenticates my credentials with the issuer of the identifier. I can now choose how I identify myself for each communication I initiate.

Within this federated model user attributes become fractionally distributed amongst many identity issuers, and perhaps also non-issuers. Yahoo (an issuer) owns my calendar information, Travelocity (a non-issuer) owns my seating preferences. But, any service or user trying to locate a particular set of attributes will find it very hard. There would need to be some extra information that describes the distribution of the information. One solution might be for non-issuers to register the location of a set of user attributes with the issuer of the identity associated with the data. But then I might have many identities and I don't want to have to remember which attributes are associated with which and be limited to using just one for certain things. A solution might be to allow the user to select a primary identity to which all the secondary identities refer. Now any service can navigate from any identity to any set of attributes. And, of course the user should be allowed to switch primary identities, just as I can switch banks, or citizenships.

This is just the start of a solution. Other issues to be resolved are: the standardisation of schema elements that describe the attribute sets, achieving adequate performance when chasing referrals to other directories, allowing the user to specify whether attribute sets should be stored with non-issuers at all, allowing users to ascribe access control to their attribute sets. And of course the practicability of the solution decreases as the complexity of the solution increases.

I hope this topic hasn't been a surprise to you. I hope that the software engineering community at large is aware of these issues and is discussing the implications of what may play out here.