Re: [Auth]Another two or three cents

[Jeremy Petzold]

By the time you get to read this responce your questions will probably be 
answered with the post I did titled 

"Auth system Idea cleaned up(re:re:my two cents)"
read that and see if that adresses your ideas

-Jeremy

On Mon, 16 July 2001, "Carsten Kuckuk" wrote:

> 
> 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
> 
> _______________________________________________
> Auth mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/auth

Regards,

Jeremy
Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com