[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Auth]some more thoughts
From: |
Keith Geffert |
Subject: |
[Auth]some more thoughts |
Date: |
17 Jul 2001 11:58:47 -0400 |
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
- [Auth]some more thoughts,
Keith Geffert <=