dotgnu-auth
[Top][All Lists]
Advanced

[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:44:31 -0400

Norbert Sendetzky wrote:
> 
> On Monday 16 July 2001 07:30, you wrote:
> > Yes, I have seen the XML-RPC implementation that used jabber. I havent
> > seen SOAP, but would think it would be even easier because SOAP is
> > abstracted for these kind of needs. The XML-RPC implementation using
> > Jabber is NOT standard, and is NOT compatible with normal XML-RPC
> > classes. Since I believe SOAP is the way to go for the DotGNU project I
> > dont think this is a problem.
> 
> I think that these protocols are far too complex. They require an
> implementation, which is not present everywhere. People will be easier to
> convince if we give them something, they can understand within a few seconds.

yes, i somewhat agree. at least at this early stage. right now we need a
quick-and-dirty. something simple for everyone to impliment and use, and
something secure and scaleable. but, i don't think that should rule out
the possibility of later building the DotGNU Virtual Identity system off
of Jabber, or even the Jabber Identity system at
http://www.theoretic.com/identity

there is just too much power in 'implimentations' of specs and protocols
like these to ignore for the long term.

> 
> > If we have a distributed system like this, there might be need for a
> > master registar of 'trusted servers'. Then it would work like this:
> > 1) Joe wants to use service of CompanyA
> > 2) Joe has an authentication account with AuthCo and so he logs in and
> > gets a ticket
> > 3) Joe shows his ticket to CompanyA
> > 4) CompanyA sees that the ticket is from AuthCo and checks the registar
> > for AuthCo's listing. If AuthCo is listed then it moves on, otherwise it
> > can deny or accept depending on some settings that CompanyA's admin
> > sets.
> > 5) If we get this far then CompanyA verifies Joes ticket and the
> > transaction can proceed
> 
> ONE master registrar is bad (too much power) Many registrars which can cross
> sign their identities (and therefore their users one) is perfect.

hm... please explain. i agree that one or even a few master auth servers
are very bad, especially if they are 'enforced' bu some authoirty. but
i'm not quite familiar enough with the alternatives to really judge.


reply via email to

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