[Top][All Lists]

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

Re: [Auth]Re: [DotGNU]A Proposal for a Solution (please read the end at

From: Adam Theo
Subject: Re: [Auth]Re: [DotGNU]A Proposal for a Solution (please read the end at least)
Date: Mon, 16 Jul 2001 21:58:24 -0400

Myrddian wrote:
> I thought of this scenario, one way to have AuthCO and not some buddy on a 
> linux box
> would be to have a Secondary Auth System, well this secondary system verifies 
> the actual
> Auth Server it self not the client. That way the ticket company can "trust" 
> this
> AuthC0 server.

yes! i completely agree. PKI addresses this, does it not? if not, then
here's my idea outline for server to server authentication:

(1) each 'server' or 'user authenticator' can create it's own
'Certificate' following a standard format for such things.
(2) the certificate by itself doesn't really do much. it is what other
Certificate holders 'trust' your certificate that matters.
(3) say you apply to a 'quality control board'. they review your
server's security, your business plan, etc, and you pass their tests.
they reward you by putting you on their own Certificate.
(4) that means that anyone who trusts this Quality Control Board can
automatically trust your authentication service.

make sense?

> The other thing I saw was XNS, now XNS tries to solve this issue by using 
> tighter
> control on how these Auth server certificaes are handed out.

i have taken a brief look at XNS, and don't like it much. it is too
centralized. to get a certificate to operate a XNS service, you have to
apply to them and only them. they and only they grant and control such a
system. it relies too heavily on them.

> Well Like I said in (1) You could contact a "Trusted" Auth server, this server
> then can verify the Auth server in which the user is using. You could to 
> peer-peer
> routes but once again this leads to some interesting issues. Secondly who is 
> this master
> registar? Another company?

does PKI need a master registrar? i think it can be done all P2P-ish,
can't it? after all, there is no master registrar dishing out
certificates, it is you being trusted by peers who trust peers who...

> Well Jabber as far as I see it is a good way for the Virtual Identities 
> system to work.
> However, the scope of DotGNU is far more larger and is a tad bit more scaled 
> that Jabber
> was intended for ( I feel any how ). So extensions as such and a better 
> mechanism
> might be needed. I'll have to read more on it any how, but it's quite good so 
> far :)

as Norbert Bollow has suggested, i will be moving this jabber-specific
line of the thread over to the developers, since it is not about a down
and dirty auth system.

so please look over at the developers list in the next hour or two for
my full reply to this. it will answer all your questions.

i will suffiuce it here to say that jabber is very scaleable, but i can
understand why you might think not because it has traditionally only
been an IM system. jabber can very easily (and is now moving towards)
full P2P architectures, web services platforms, and application to
application communication. it is a *very* valid system to work from,

reply via email to

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