Re: [Auth]My two cents

[Jeremy Petzold]

ok, what if we did it this way?

the user starts up the service for the first time, he enters his DATA onto a 
form that saves it on his computer. 

he registers with an auth server, but, instead of the auth server holding any 
personal data, the server just creates a Key.

the server then stores a copy of that ticket in an encrypted file and sends the 
same thing to the client.

when the client goeat to buy somthing or anything else that the client would 
like to do that requires any information, he sends the information along with 
his encrypted key.

the site then sends that key to the Auth server (which is specified in the data 
file sent) and the auth server validates the key and sends a reponce back to 
the site verifying that the key is correct.

this solves the problem of data storage being decentralised and not being 
collected by any one place as the DATA stays on the clients computer.

how is that?

Jeremy

On Mon, 16 July 2001, Myrddian wrote:

> 
> > >>>>>
> > ONE master registrar is bad (too much power) Many registrars which can cross
> > sign their identities (and therefore their users one) is perfect.
> > <<<<<
> 
> Yes very bad :)
> 
>  
> > What about two (or more) registrars that store half of the information
> > each?!
> > For example, take two registrars, reg1.net and reg2.net. The user wants to
> > store his profile, given as an array of bytes p[i], with these registrars
> > without
> > trusting any of them. This can be done by taking an array of random numbers
> > r[i].
> > Registrar reg1.net gets to store the array r[i], and registrar reg2.net gets
> > to store the array r[i] XOR p[i]. Both registrars only see arrays of random
> > numbers. In order to recreate the original profile, the client has to
> > retrieve
> > r[i] from reg1.net, and  r[i] XOR p[i] from reg2.net, and XOR these two
> > arrays
> > with each other resulting in r[i]XOR r[i] XOR p[i] == p[i]. So this reduces
> > the
> > problem to the problem of reliably updating profile arrays at two registrars
> > which can be solved by storing two generations of profile arrays.
> > 
> > This model would consist of
> > - Registrars storing two versions of byte arrays for clients that
> > authenticate
> >   themselves via a user/password scheme which the end-user has to remember.
> > - A client computer module that accesses both registrars, retrieves the
> > profile
> >   string halfes, combines them into the real profile string, makes use of
> > it,
> >   updates it, and stores new versions with the registrars.
> > - A net of independent registrars all over the world would be needed that do
> >  not need to know about each other.
> > - Clients would choose two registrars that they have to remember.
> 
> Having two core, registers defeats the de-centralized authorazation system 
> idea.
> We are trying to avoid that, but I see you have a point.
> 
> Problems arise with it though
> 
> 1) Data consistency (how should the data be updated More importantly how 
> frequently)
> 2) Failure, what happens if one of the servers goes down?
> 3) Making the user remember two distinc logins defeats the one login anywhere 
> idea.
>    (But this can be automated, however security?)
> 
> Howeer your document is a good start on how we should solve this problem, I 
> think this also has been
> mentioned in another thread. We should focus this argument more on a specific 
> topic.
> 
> 
>   
> 
> -- 
> __________________________________________
> Myrddian <address@hidden(nospam)au>
> -------------------------------------------
> "I stayed up all night playing poker with tarot cards. I got a full house
>  and four people died". 
> 
>                    -- Steven Wright 
> _______________________________________________
> 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