[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: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.