[Auth]some more thoughts

[Keith Geffert]

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

pgp2Rtc2MzMK5.pgp
Description: PGP signature