Re: [Auth]My two cents

[Jeremy Petzold]

a few more thoughts on this Idea. 

1)this will work with a Data Bank as well, the client just needs to send the 
request throught the databank.
how this would work is:

the databak has set up the client with a key, and the auth server has also set 
the client up with a key.
when a request for the data is made to the databank, it will verify its key 
before  releasing the data to the destination site. then the destination site 
sends the auth key to the auth server listed in the data and when that is 
verified, the request is processed.

2)you can set up multiple auth locations and keys to build in redundancy.

if the primary auth server is down, the website sending the request will get no 
responce, it will assume that the server is down and send a request to the 
secondary auth server. this does not need to be with a diffrent auth provider, 
the same company can offer to diffrent auth locations, however having 2 
seperate companies may be possable.

-Jeremy


On Mon, 16 July 2001, Jeremy Petzold wrote:

> 
> 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
> _______________________________________________
> 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