As I'm sure you are well aware, .NET represents a blatant attempt by Microsoft to move its dominance from the desktop to the Internet. While MS cannot stress enough that .NET is an "open standard," anybody familiar with Microsoft's history concerning standards should know that Microsoft will do anything and everything to assure that only it reaps the massive profit potential of a .NET like system. The FSF and Ximian seem to have recognized the incredible threat of .NET but have responded foolishly by attempting to simply copy the system. This might not be such a mistake if .NET was not riddled with technical flaws. Nobody completely understands Web Services and the gigantic ramifications of moving data (XML documents) as opposed to code. Microsoft's attempt to build a complete Internet platform with corresponding object model and garbage collection, etc, is a land grab, plain and simple.
That being said I was extremely excited to see your July 17th column at davenet.userland.com. Right now there is little need for an Internet platform, but there is an extreme demand for a decentralized authentication scheme. After carefully reading your article and reviewing the XMLStorageSystem spec I'd like to offer a few suggestions.
1. Do not assume that there is a human at the keyboard. This is one of the core principals of the Unix Philosophy: avoid captive user interfaces (those interfaces that require human input). If services like eBay and the many online brokerage systems had not designed their interfaces so that human input was required, the entire need for Web Services today would not exist. To maximize convenience for the user, the user should be able to authenticate a computer or an account on a computer. Once the user has authenticated a computer, that computer should be able to stand-in for the user at any place in the authentication chain. What this means is that it is very important exactly how you retrieve login information such as username and password from the user and the URI to an authentication server. The obvious solution is to give the user the option of storing login information in an XML document with a standard interface at some location on her computer. The problem is, how do you retrieve that XML document? One solution is to let the user run a specialized webserver that serves up XML documents. When given the URI 'xml:http:///personal/login' the server might respond with the XML document containing the user's authentication information.
Of course, this is not a complete solution because it would allow anybody with a browser to view your login information. Therefore some redundant authentication scheme must be built in. Using digital certificate technology this would require that the machine requesting the special URI on the user's personal webserver present a digital certificate which the user has cached and validated herself. If such a system were employed this would allow for maximum flexibility. For example, let us take the canonical example of a user who wants to retrieve his calendar information for a given week. When the user is on the road the user might use a client website to do this. He would present the website with a username, password, and an authentication server. The client website would contact the login server, running a system very much like xmlStorageSystem, and ask for the XML document containing the user's calendar information. The user would then edit the information and save it. But, when the user is at home synching a wireless device she should be able to press a button on the device and forget about it. The device should then be able to do exactly what the client website did - contact the login server, authenticate itself, and retrieve the Calendar XML document - with one key difference. Because the wireless device is connecting from the user's home computer it should be able to retrieve the locally stored XML document containing the user's login name, password, and the address of the authentication server.
The above is a somewhat trivial example. To understand the real need for allowing passive authentication (as opposed to active authentication where the user must be at the keyboard to type in a login name, password, and the URI of an login server), you must peek farther ahead into the future. As time progresses, users will want full automation of many of the trivial tasks they must accomplish. For example, if somebody goes shopping every Friday to purchase the same exact thing, there is no reason that their computer should not be able to do this for them during the night by connecting to a HomeRuns.com like website and placing the delivery order. The user should not even have to think about this, let alone type in a password. Another very important aspect is the inevitable rise of agent-software. Agent software, as you might know, is just intelligent software that does stuff for you without you explicitly telling it to. It is much like the idea of a personal secretary. Consider the following scenario. The user has a toothache but he does not have the time to make an appointment with the dentist. For two weeks in a row, he instructs his computer to purchase oral pain-relief gel. At this point, his local Health Agent might contact the computers of his dentist and request an appointment for him. The dentist office eventually contacts the user to confirm the appointment and the user, pleasantly surprised because this is the first time he's hearing about the appointment, agrees. This example is not far fetched. It may be a while before we see interoperability on this scale, but all of the technology exists today or will exist soon. This is why we must not make the assumption that it is always the user authentication herself and not some trusted device.
(In addition to increasing convience, this technology does open up a whole new can of worms. One could imagine a naive user making his laptop a trusted device without securing it. Then, if that laptop is stolen, in addition to getting a nice piece of hardware, the theif has complete access to the user's identity. But that's the way technology works and these problems can be solved by technology.)
2. Do not assume that the user will store all of his information on a single server and maintain a single identity. This should be obvious, but many Internet authentication schemes (such as .NET) assume the user will only want to place all of their information at one site (passport.com). For what should be obvious reasons, this is a bad idea. Many people need or desire the ability to maintain multiple identities. This is evident from the fact that many people have multiple email addresses. You do not want the email address you use to register at a disreputable website to be your email address at work where recieving certain kinds of email can resolve in disciplinary action. As you wisely note, it must be very easy for a user to migrate his personal information from one login server to another, but it must be equally easy for the user to rely on multiple login servers so he is not locked into a single server. Some believe that giving users the ability to create multiple identities and even fake identities is irresponsible but these are often the people who have a vested interest in potentially violating the user's privacy. Users must have the option of not only separating work from home, but if they feel they require it, they should be able to create wholly fake identities. The anonymity of the Internet should be preserved at all costs even if it means inconveniencing the user. This means when a service requires that the user authenticate herself it must not simply ask for a name and a password it must also ask for the address of the authentication server the user wants to use.
3. Not all clients can be trusted. Everybody seems to be making the assumption that once we have a distributed authentication scheme then all authentication problems will magically go away. In fact, all that will happen is that authentication will become more difficult and more complex. The reason for this is that not all clients can be trusted. For example, return to the earlier situation where a user wants to create an account on another website or use a service on a website. Ideally, the user should be able to simply type in a login name, a password, and an authentication server. The website should then contact the authentication server and attempt to retrieve the user's personal information. Unfortunately, there are two very weak links in this chain. First, there is the website/client program. The possibility of a hostile website is very real. For example, a website hosted by a user's employer offering the user the ability to edit/retrieve his health information online may decide to forward that information to his employers. This occurs without the user explicitly allowing the website to transfer this information. Or consider the worst case scenario: a website offering the user access to his financial information may be a pure front-end. Once the user types in his name and password the website appears to offer the user the ability to buy and sell stocks but in reality it is stealing large amounts of money.
In order to protect against these two technologies, authentication servers will have to offer coarse grained access to the user's personal information through permissions. This means if a calendaring website contacts the authentication server and attempts to retrieve the user's health records then something is wrong. There is no need to retrieve a user's blood pressure and his todo-list. In order to retrieve certain ultra-sensitive information the authentication must allow the user to trust only specific websites and clients. By the simple fact that the user typed in his password is not enough display of trust, the user must explicitly tell the authentication server that a certain client can retrieve certain information. But even this is not enough, because the user might still be tricked into unwittingly granting a criminal client strong permissions. The ultimate solution is to establish a network of trust and a powerful system of trust-metrics, literally measuring trust. When a user grants a certain client, be it a website, a software program, or a device or even an IP address, permission to receive certain information the authentication server must be able to go to a trusted authority and ask that trusted authority if the client can be trusted with these permissions. For example, the user may give his new Palm Pilot permission to view his todo-list and calendar data. When this occurs the user might type in the serial number of his new Palm. At this point the authentication server must do everything possible to verify that this serial number is a Palm Pilot, is the Palm Pilot the user purchased, and is a Palm Pilot that can be trusted with this information. In this case the authentication server would most likely contact Palm Inc. and ask them to verify all of this information. In this case, Palm Inc. would be the trusted authority.
When it comes to security, too much is never enough. A distributed authentication scheme would be a welcome and powerful tool guranteed to increase human productivity even if it means we spend less time typing in redudant information like our address and credit card number. But a distributed authentication scheme does not solve the security problem, it merely makes things more complex. Even with a complex system using trusted authorities and trust metrics, questions still arise. How does the authentication server know that a trusted authority can indeed be trusted? Even if a trusted authority is run by a national government, it cannot be completely trusted. Furthermore, what happens if the authentication server itself is compromised? What happens if a client is compromised? Even if the chain between a user, a client program, an authentication server, and a trusted authority is completely secure, what happens when the user's physical access point has been compromised? If you are using a computer in an Internet Cafe and logging onto clients that require a name, password, and authentication server URI in order to offer their complete services to you, how do you know you are not 1. being filmed 2. having your keypresses recorded? What if the user is threatened with physical violence and forced to relinquish this information? I offer all of these "What ifs" to drive home a point: NOTHING AND NOBODY CAN BE TRUSTED. Not the user, not the authentication server, not even the trusted authority. Everybody and everything can and will be compromised by a determined and intelligent criminal.
Even if it is impossible to build a completely secure distributed authentication scheme, that does not mean it should not be done. The fact is, it will be done because there is a demand for it to happen. This demand will arise because it offers powerful productivity enhancements such as the potential of agent-based software and its offers of great convenience. But, as always, if you don't want to end up living in a world where you have absolutely no control over your private information then now, as we attempt to build these systems, we must tread very very carefully and be aware of the implications of what we're doing. I do firmly believe that the problems technology causes can be solved by technology.