[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
Re: [Auth]Re: [DotGNU]A Proposal for a Solution (please read the end at least)
Mon, 16 Jul 2001 02:07:04 -0400
"Dan Kuykendall (Seek3r)" wrote:
> 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
yes, i now completely agree with you.
> 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
i'm very glad you think so. i was wondering how much of an uphill climb
this effort would be. but it is looking at least a little easier now
> > "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
yes, correct. i don't blame those that think of jabber as simply an IM
system. this is where jabber started off, and proved itself. but b/c of
it's high XML flexability, and very modular structure (the protocol
even, not just the OSS server), it has a lot more potential. the jabber
of 10 years from now will not be even half IM. it will be applications
talking to other applications, users interacting with remote
applications, services using it to store user's data, and everything
else you can think of (except maybe make vanilla ice cream. i don't
think it will be able to do that :-).
> > 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
yep, i feel i have to emphasize this:
"jabber is the protocol, not the software. not only *can* you make a
GPL'ed Jabber implimentation, but you will in fact be cheered by the
Jabber community to do so. You will have our 100% support, and then
oh, yes, i forgot another server on my last post. there is actually 3
* Jabelin, an OSS server done in C under the JOSL.
* Jabber.com's, a proprietary one done for traditional companies who
* and the Java Jabber Server, done by Al Sutton, an OSS server done in
Java that just started up. don't know what license, maybe GPL, in which
case may i suggest helping out Al? he's a good guy, and would love the
we would love to see a GPL one.
> > 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
/me grins (a jabber thing). :-)
> > 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.
i am not as familiar wiith XML-RPC as i am with SOAP, and don't follow
it much, so am not sure by any means, but yes, while it is not standard
among jabber, there is a big effort to make it so, and standardize alot
of stuff now, for the betterment of the whole system.
> > 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
ok, i see your point. we have not gotten to this quite yet in the
Identity list, but are about to discuss it soon since we are heading in
this direction after drafting up the various plans.
this will likely be done by a PKI-based system, with certificates. only
the certificates would not be for users, they would be for servers.
> > 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.
yes, as i posted in quick reply to my original post, i did get mixed up
with the whole licensing thing. the protocol is not licensed (cannot be,
even), and is 100% open. therefore, all we need to do is decide how we
want to use Jabber (if we do. *please! please!*), and then make GPL
server and other neccessities.
> 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
yes, IMO this is a *huge* benefit. recycle! reuse! take what is working!
> 2) Its been gaining acceptance over time
yep, very rapidly over the past 12 months or so, in fact.
> 3) It has several companies backing it as well as many in the free
> software community
yes, very true. even IBM is investigating Jabber, if i am not mistaken.
> 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
oh, coolness is very important. noticed how many cool projects succeed,
while boring/bland ones fail, even with lots of $$ and people to back