[Auth]Another two or three cents

[Carsten Kuckuk]

Steven and Jerremy,

I've just joined your list, and don't know where your position is, so in
order to avoid further misunderstandings let me explain my position:

I share some of the thoughts that David Gelernter stated in his manifesto
last year, namely that:
(1) Computers will become ubiquitious,
(2) in the future, all computers will be interconnected,
(3) in the future you'll have a data shadow that follows you around,
(4) you'll make use of services distributed all over the world.
If you're like me, you already see (1) in your life. I have three computers
at home and three at work that I use on a regular basis. With the advent of
intelligent mobile phones they will not get less. So in my daily work I have
the problem that I need to move the files that I work on, bookmarks, links,
e-mail around from one computer to another all the time.

The solution to this problem is to outsource e-mail, file storage, and other
stuff to services on the web. Under services I understand simple things like
POP3 mailboxes, storage space accessed via FTP, Radio stations accessed via
Realaudio, etc. Low Tech that just requires an IP address, a user name, and
a password. I think that "web services", SOAP, XML are just buzzwords that
are irrelevant to our daily work. These technologies have to mature, whereas
FTP, e-mail, etc. are already here, working, and business critical.

The collection of all my log-in information that I use to access my data /
services is what I called the "user profile" in my previous post. Currently
it is a sheet of paper I carry around in my wallet. Now imagine I could
approach one of the ubiquitious computers -- be it a PC, a Mac, a Sun
workstation or a mobile phone -- somehow feed this list into the computer,
than this computer would instantly have access to all my current data and be
a full workstation. Unfortunately I can't do this with a sheet of paper. But
I can do this with an electronic file. Unfortunately I can't carry an
electronic file around with me. The solution for this is to store this
information on a central server. This is what the Redmond-based company does
with Passport. It's just a central location to store log-in information. In
order to access this information you need a Passport account and a Passport
password.

The problems I have with this solutions is:
(1) It's a central point of failure. If they lose my profile, my
electronical existence ceases to exist. I'm electronically wiped out. Dead.
(2) I don't trust anybody as much as to store my most valuable information
(user names and passwords). Even my wife doesn't know my passwords, so why
should I trust a commercial company (or any other group)?
(3) Passport decides for me which kind of information it allows me to store
in my profile, because every web service that wants to make use of it has to
have a contract with Microsoft. Immagine for example they refuse to enter
into a contract with a online sex shop, or the communist party, or whatever.
This would effectively be censorship as I would not be able to conveniently
access (or access at all in a decade!) these services. And it would mean
that a US based company with US values could dictate their values to each
and every person in this world.

The solution to problem (1) is simply to store the online profile with more
than one profile providers, and to do this in a way that an error that
occurs with one provider can be corrected. One simple option is to store a
copy of your profile with each provider. Another is, to use error correcting
codes for this purpose.

The solution to problem (2) is to encrypt or scramble the data in a way that
the profile provider can't find out what is stored. The profile provider
would only see a string of bytes without any meaning. The easiest way to do
this that comes to my mind is to XOR the string of bytes with a string of
random bytes. Simple probability theory leads to the conclusion that the
resulting string is as random as the original string. So storing the random
string in one location, the profile XOR random string in a different and
independant location solves this problem. Each provider seed a random
string. The more profile providers there are, the lower the probability that
they can be combined. I would randomly pick a provider in the US to store
the first string there, and randomly pick a provider in Germany to store the
second string. Now all I have to memorize is the account information for
these two accounts.

The solution to problem (3) is the fact that the providers don't know what
they store.

So in this world of thoughts, a virtual online identity is the stored
profile.

In order to implement this, the following parts have to be specified /
defined / implemented:
(1) A protocol for accessing / storing protocol information. I think HTTP is
sufficient for this. There only needs to be an agreement for the URLS. A
very simplistic scheme like
http://www.providerone.net/getprofile/UID=ck/PWD=ck for retrieval,
http://www.providertwo.net/putprofile/UID=ck/PWD=ck/version=456/content=...
would be sufficient. The retrieval would send back the current and the next
to current version. This, combined with the version number in the storage
part would ensure transaction consistency through roll-back in the client.
(2) A standard for encoding/decoding profile information into n parts (with
n=2 initially, and the random-XOR encryption pattern)  for storage purposes.
(3) A standard for the inner structure of profile information. Initially I
would use a simple list consisting of (service-type, account name, password)
tuples with service=pop3, ftp, imap, http.
(4) A small piece of client software (initially written in Java?!) that
first asks the human being for the location of profile provider 1 (with user
name and password there) and profile provider 2 (with user name and password
there). Then it would contact the the providers, get the strings, recombine
them into the profile, display the profile to the user, and lets the user
contact the stored services. It would also need to be able to add a service
or to delete a service and send the updated profiles back to the profile
providers.
(5) Two small PHP (or Perl) scripts that implement the profile provider
functionality and protocol defined in (1)

This is about a weeks work. Then everything would be in place so that people
having web sites could start offering profile services, and other people
could change their existing services to make use of this profile framework.

Is this a bit clearer?

Carsten Kuckuk <-- on digest, so don't expect any quick replies