There have been many efforts at internet "identity" systems, such as Microsoft Passport, Liberty Alliance, and a variety of others. A recent conference was held in SF, though I didn't go, but I thought it was time to put forward one important idea.

These days, it's common in designing computer systems to make an engineering decision on where they will fit in the client/server model. Putting functions on a server has many advantages -- it's often cheaper to code, and there is central control, maintenance and updating of the servers. It easily allows roaming and can be more efficient. Tools on clients are more work to code and maintain but can be much faster, make use of client resources and provide much better user interfaces. Often the decision is to work out the right mix of both. The more client tools like javascript become available, the easier it is to take a commonly client based app like Email and turn it into gmail.

Also, sometimes something goes into a server because business rules demand it. You can only make money from it as a service you sell, so you build it that way.

The calls for server based identity systems tend to seek a number of the server goals, but they, and others, are forgetting that there can be a privacy reason to put functions into a client, even if engineering and business concerns point to putting them in a server.

I think managing my identity -- deciding which bits of my personal information will be given out to other people, companies and programs -- is one of those things worth extra effort to put into a client. Yes, that means writing and maintaining the tool for every platform, and it means that roaming requires you have the tool everywhere and a secure means to move the appropriate data among the endpoints, but it also means that your data remains under your control and not in the hands of 3rd parties, at least not unencrypted.

Oddly, the earliest identity programs, which were the digital wallets that filled in forms on eCommerce web sites, had it right. But they lost out because it is more complex to write custom programs for the endpoints.

The first goal we heard about was single sign-on. That actually would have been pretty easy to do with a basic protocol and some code put in browsers. The same applies to controlled sharing of information. It's a bit harder to do in the client, but one reason is that personal data stored by you has 4th amendment protection, and personal data stored by 3rd parties does not. This trumps a lot of engineering concerns.

All this said, I will add one caveat. I think it's reasonable for young, marginally funded startups to start with the most efficient approach to their products, which may indeed be a server model. Doing private data in the client can be more expensive, but is worth it, but may not be affordable by a young business. However, they should make plans to move the information into the client when they can afford it.

To facilitate this, it would be good if existing client software -- notably the web browser -- did a better job of providing a toolkit for such functionality. This frees the small software developer from the burden of supporting client software over all the platforms, which is the expensive part.