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

[Dan Kuykendall (Seek3r)]

Adam Theo wrote:
> 
> I have a proposal to make. I have been thinking about this all day, and
> believe I am ready to advocate such a position.

OK, brave man I have many comments, and overall generally support your
points.

> Before this point I believed DotGNU's best idea was to take the fully
> client-side, P2P route for authentication, since it seemed to 'fit' with
> the GNU philosophy the best. But after some thought and reading the
> recent threads on this list, I have come to believe otherwise.

I never agreed with those that think this can all be done peer to peer.
Sometimes it is best for companies to implment a trusted auth server in
their environment

> I am very active in the development of a system called 'Jabber' (
> www.jabber.org ). Jabber is a 100% open source protocol and platform
> (notice I say protocol and platform, not software or product). As an
> entry in the Jabber FAQ says:

Im glad a jabber guy jumped in. I do think highly of jabber and it is a
viable option as far as I can see

> "Jabber is an XML-based, open-source system and protocol for real-time
> messaging and presence notification. The first application of Jabber is
> an instant messaging (IM) system similar to AOL Instant Messenger, ICQ,
> MSN Instant Messenger, or Yahoo! Messenger. However, Jabber is also
> being applied in the realms of wireless communications, embedded
> systems, and Internet infrastructure."

Yes, too many people get caught up in the "jabber? that instant
messenger thing?". Jabber can do more, but Instant messages has been
some of the proving ground

> It uses a very distributed client/server tier platform, *very* much like
> the email system (email was the 'eureka!' idea that the founders had in
> mind, i believe in fact). It does this to remove complexity away from
> the client and client developers, and eliminate massive software updates
> when updates come through. However, as the FAQ says:
> ---- snip -----
> Also since it is similar to the email system, that means anyone can set
> up a Jabber server of their choice. I in fact have done so under my
> domain name theoretic.com, and hundreds of others have as well.
>
> No one can even control the naming system, since this follows email as
> well, using the well-known user*host.domain naming convention, instead
> of 'global' names like AIM's 'Adam Theo 2000' or ICQ's '3617306'. So
> no-one controls the naming system of it anymore than they can now.

Yes, and this is its greatests strenghts. At some point this will
normalize the instant messenger market as did sendmail and smtp before
it.

> You also do not need to worry about the the jabber server not fitting
> your needs, meaning that the Jabber system is the *protocol* not any
> server daemon created by one company or group of people. 

Correct. The protocol can be used and implemented by anyone
 
> The Jabber protocol heavily uses XML, which as we all know is a truely
> awesome technology (ok, sorry, I'm a little biased. I love XML... :-).

/me cheers

> It's XML implimentation is also very open to other XML specs and
> Schemas, potentially allowing someone to use Jabber to send and recieve
> XML-RPC and SOAP calls (web services over Jabber, anyone?); talk with
> applications on the Internet, not just human users (take a second and
> think of the possibilities); and also any other XML-based communication
> you can think of.

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.

> And for Authentication and Identity for the Jabber system, this is being
> taken care of, as well. By none other than myself and a small group of
> others who are making fast progress on an open, flexible, powerful, and
> very secure Identity system that runs using Jabber. For more information
> on this, head over to http://www.theoretic.com/identity .

Your current status looks good. I do like the ticket idea because its
simple, but all seem to have a problem I havent figured out myself. Let
me try and explain a problem I see:
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 who verifies with Authco
all is well.
But... how does CompanyA know that AuthCo is a trusted source and that
Joe didnt just set himself up an auth server on a linux box in the
corner?

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

> Now, if all of you are still skeptical about how Jabber can be used, I
> propose that this list choose one or two people from among us to learn
> about Jabber. Give them a week or so, and have the report back to the
> list on what they think. This way all of us can see how Jabber looks
> from a FSF and DotGNU perspective, without all of us having to learn
> about it.

I agree with this plan. I would jump in and start studying jabber in
more depth if you guys want. However my next two weeks will be swamped
with changing jobs (going to work for Foundstone, www.foundstone.com)
and I am speaking at the O'Reilly Open Source conference in San Diego.
So i will not be able to do major work on this for at least 2 weeks.

> The only problem, and I repeat the *only* problem I can see any of you
> having with Jabber is licensing. The Jabber protocol itself is licensed
> undfer the Jabber Open Source License (JOSL), which is BSD and MPL in
> origin. This was decided the best license for their needs at the time
> because they wanted to get businesses and other developers to take up
> the Jabber system. Therefore they allowed proprietary extensions and
> narrowed the definition of 'derivitive work'. This has worked very well
> for the needs so far, and would allow everyone (including everyone here)
> to do what they want with the system.

I dont think the protocol has these restrictions... only the existing
jabber server.

I do agree that jabber may be a solution for this. Jabber has a few
things going for it.
1) It exists, and is a working distributed solution
2) Its been gaining acceptance over time
3) It has several companies backing it as well as many in the free
software community
4) Its got plenty of 'coolness' factor, which cant be overlook even tho
it may sound silly to outsiders, 'coolness' is a key ingrediant to a
successful free software project

Seek3r