dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU][PG-Proposal] dotGNU authentication and authorization subsys


From: Matthew Copeland
Subject: Re: [DotGNU][PG-Proposal] dotGNU authentication and authorization subsystem.
Date: Wed, 11 Jul 2001 11:26:30 -0500

First off, you might want to go and look at the revised version of this
doc.  It totally removes a centralized server.   The problem with
centralized servers is that someone controls them who is not the enduser,
and the enduser had no control over who it was.  Thus, it can be used to
manipulate the user.  Instead, the idea is to place the trust in the user.
The updated version of this Proposal included that.  It is also fairly
easy to remove a DNS style authentication system when you realize that you
can just run the authentication system off of the users own system, and as
a part of your protocol you include the location of where the
authentication server is located at.  (There are also several other ways.)
The key point of importance is the fact that we can use a little more
technical savvy to overcome possible moral and ethical issues that might
arise from centralization.

Matthew M. Copeland

p.s.  The Auth mailing list has been created.  Those interested should
subscribe and perhaps start discussing the important points and how to put
together a good description/specification document.



> >Distributed and scalable control mechanism for servers such that
> >any individual, company, or government can create an
> >authentication server and the user can decide which to
> >use at run time.  (This means that no single authority can
> >also manage primary servers like you see with the
> >root nameservers under DNS.)
>  
> I see the minimalist centralisation that exists within DNS as 
> probably a neccessary evil. I don't understand how you are going to
> get a simple, fast lookup system for a consistent and meaningful 
> global namespace without some form of global domain address delegation.
> I am aware of other alternative proposals for naming network 
> objects e.g. within gnutella and freenet, which avoid heirarchical 
> naming, but I don't consider these schemes likely to be either simple 
> or fast or meaningful. Also there is nothing to prevent other 
> groups implementing other DNS's with more or different top level 
> domains, other than people choosing not to use such alternatives. 
> A completely alternative DNS system could however be at the heart 
> of DotGNU, which doesn't rely on any of the current DNS nameservers. 
> But this alternative would end up introducing another replicated 
> directory service pointing to the many DotGNU TLD servers which is 
> considered more reliable and authoritative than any others.
> 
> The only real centralisation here is about how you get agreement over
> maintaining the top level part of a replicated global namespace 
> directory which contains the canonical addresses of TLD name servers. 
> This degree of centralisation doesn't impose anything much on
> how parts of the namespace below it are used, so long as
> there is a system of delegated authority for different parts of
> the namespace. This seems more meaningful, simple and fast to me
> than alternatives involving generation of long enough random object
> identifiers to reduce the risk of identifier collisions.
> 
> I see this as an area where the wrong decision at this stage
> could have significant consequences, possibly leading to blind
> development alleys which could take 12-24 months to back out of. 
> The naming system is going to be so much built into other areas of
> DotGNU that what we dislike about DNS might be a price worth
> paying for something which we know to work well enough. I don't 
> think we should let the ideal to be the enemy of the good here.
> 
> Richard Kay
> address@hidden
> http://copsewood.net/
> 
> 
> 
> _______________________________________________
> Developers mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/developers
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]