Re: [Auth]some more thoughts

[Jeremy Petzold]

I think that that is the general direction the project is taking, however, I 
belive that it will turn into somthing that anyone could build and run, minus 
the Auth servers, I don't see how you could have an auth server that is run by 
the guy trying to get access, but the databank can be run on a homegrown server 
or a leased space from a web host, then the person just needs to register with 
the Auth system so that he can start tuse his information. as long as the auth 
system and the Data system are seperate we can retain the freedom of the people 
who use it, passport bundles both the auth and Databank servers together and 
that is where the lack of freedom is.

On Tue, 17 July 2001, Keith Geffert wrote:

> 
> Hello all,
> 
> I know were trying to minimize this kind of banter, but I haven't gotten my 
> 1.252 cents in yet.
> 
> 
> My thoughts on dotGNU
> 
> 
> I've been reading all the comments and suggestions from the list and have 
> formulated some of my own ideas that I think should be discussed.
> 
> 1)  Basic dotGNU auth system should be as small as possible.  Why?  So that 
> it is suitable to be implemented on small devices: Pda's, cell phones, and 
> other things that haven't been introduced into the consumer market that will 
> eventually be connected to the internet.  You may not be shopping from your 
> cell phone, but I could imagine a dotGNU address book that you may want to 
> access from your phone.  You could also "surf" wap sites with your cell based 
> websystem (cellphone/webpad) and have access to all the compliment of sites 
> you have access with your primary device.
> 
> 2)  Hooks for various authentication systems like a password secret, smart 
> card, digital certificates, and biometrics.  This allows a user to have 
> multiple ways of accessing their profile(s) from various devices with varying 
> degrees of access.  You may need a strong cert to update your credit card 
> info, or give a website access to your credit card info, but only a password 
> for your email address.  This should also be configurable by the user.  The 
> user gets to choose how strong of an authentication is required for various 
> items in thier profile(s).
> 
> 3)  After reading all the arguments back and forth, I think storing your 
> profile on a 24/7 connection is the best choice for a few basic reasons.
>   a)  providing info from a client system requires a trust relationship to be 
> built from the client to the dotGNU application your trying to give info to.
> 
>   b)  Having your virtual identitie(s) stored on a service provider allows 
> you to give permission to sites to have access to information.  They now do 
> not need to that information (indefinitely).  They merely need to store the 
> pointer to your profile (and cache the actual data to increase optimization 
> -- which actually could happen in the dotGNU api).
> 
>   c)  Using (b) above, if you change information in your profile it changes 
> for everyone that has rights to view that information.
> 
>   d)  As an extention, an address book could be created in your profile as 
> well as bookmarks/hotlists.  These merely being pointers to the acutal URI's 
> (don't know if that's the right term).
> 
>   e) Small devices could use a technique like (d) to give you access to your 
> stored address book. This would obliterate the need to syncronize or download 
> your local database to devices that may not have enough storage space to hold 
> it anyway.  The devices uses only the parts that it would need.
> 
>   f)  Transferring your profile from device to device becomes irrelevant.  
> You could use a system at say the public library to authenticate to your 
> dotGNU service provider and have access to the same information as you would 
> have your primary system.
> 
> 4)  LDAP might be a good choice for storing profiles.  Using some type of 
> trustee relationship on each property and value could be used to proivde much 
> granularity, while providing security to your personal information.  If you 
> don't want your data mined, make sure your not giving any rigts to the world. 
>  Trustee's would have a TTL. Allowing you to give certain systems access to 
> information for only a short while.  You can then revoke these rights as you 
> see fit.
> 
> 5) Authentication might be accomplished using something simliar to how dns is 
> now constructed.
> 
>      root trust ring
>             +
> +-----------+---------------+
> |   |   |   |   |   |   |   |   -- registered auth servers
> A   A   A   A   A   A   A   A      (probably every isp)
> 
> 
> All root servers trust each other.  Each contain a DB of the authoritative 
> servers for different partitions of the internet.  Any auth server will 
> eventually trust any ohter auth server because they both trust the root trust 
> ring, and that ring trusts each server indivually. (using PKI)
> 
> Auth servers can "trust" other servers to auth sections of its own slice.  
> 10.0.0.42 is a trusted auth server, which serves (*.mydomain.com.).  It can 
> trust 207.174.32.15 to serve (*.somegroup.mydomain.com.) by configuration.  
> Every dotGNU device would require access to a trusted auth server.
> 
> We then do mutual authentication via pki.  I trust the webserver because my 
> dotGNU app was able to verify the identity of the service running on a 
> particular server.  The webserver trusts me because I provided it with 
> credentials that were verified by my auth server (the 3rd party).  The 
> webserver passed these off to its auth server which eventually says Yes or 
> no.  The auth servers do a tree walk until the correct server can be located 
> that stores your profile.
> 
> For quick dirty and simple?  All this is compacted to a single server. Auth 
> servers can manage as many slices as needed.
> 
> 
> 
> My thoughts,
> 
> No matter what direction is taken, we need to remember what we do today, if 
> successful, will probably be the basis for most identity verfication on the 
> internet.  This system will have to last and be flexible enough to handle the 
> innovations in auth technology for years to come.  Once the true auth system 
> is implemented it will be very difficult to make radical changes.  We all 
> need to keep that in mind.
> 
> I could see this becomming a basis for any type of identity authentication, 
> and eventually be embedded into our basic communication protocols (dotGNU 
> enabled ftp, smtp, pop3, imap).  Allowing the authentication token to passed 
> in the TCP syn packet for services that require identity verification before 
> your even allowed to initiate a TCP session ( imagine tcp wrappers with this 
> ability ).
> 
> As far as legacy services (those converting to .something or not even 
> .something enabled) this could be handled by the basic service that it 
> provides.  Http forms might require a small XML document (inline or pointer) 
> that describes the form fields and how they relate to dotGNU profile 
> properties.  Your dotGNU enabled app could then properly fill in the form.
> 
> Anyway I've written out everything I got so far.
> 
> Thanks...
> 
> 
> --
> Keith Geffert
> http://www.penguingurus.com/
> GnuPG Public Key: 
> http://www.penguingurus.com/public_key.txt

Regards,

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