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

[Adam Theo]

> I had a poke around in the (Delphi client) Jabber code back last year. It
> seems to have taken off a lot since then.
> 

yes, Jabber has taken off *alot* in the past year. the 1.4 version of
the Jabelin (open source) server was a landmark b/c it is the first
'real' server that is very stable and fully featured. it is the model we
have since worked off of for all other releases. also, almost every
single aspect of the jabber system and the jabelin server has been
dramatically improved. this has been due in large part ot the surge in
developers the project has gotten in the past 2 years. the development
list has something like 70+ active participants, and around 300 total
subscribers.

> > 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.
> >
> 
> Don't you guys do mapping between things like AOL-IM identities, Yahoo IDs
> and Jabber IDs? Or am I smoking something and it is just that the client is
> compatible with non-Jabber forms of transport.

yes, this is correct, and was in fact the original point of jabber. it
has move *alot* beyond this point since then, but it has good support
for mapping (or transporting, as we call it) between different systems.
currently the systems jabber can mapo to are AIM, ICQ, MSN Messenger,
Yahoo Messenger, IRC, and soon SMTP (email) with another project that is
being done at my website ( http://www.theoretic.com/jabbersmtp ). no
source code has been released yet, but will be within the next week or
two. for more information on this smtp transport, contact Ted Rolle,
email is at the website.

> 
> Where are the identity relationships stored?

currently, as we are thinking now, the identity information is stored
server-side. at first this will be on the same server as the user's
jabber account, but we want to turn the Identity system into just a
'common interface' to remote storage locales. meaning the user can have
their identity info stored anywhere. on a specialized remote hard drive
service, on the jabber server, or on their local machine. to the service
or person requesting this information, it would not matter, b/c they
would ask the same place for it no matter what. that place being the
user's jabber account.

> 
> > 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 .
> >
> 
> I wasn't aware of this.
> 
> I quite like your "TicketPlan"
> (http://jab.sirlabs.com/bin/view/JIGs/JIS/BasicTicketSecurity) and the
> "SimplePlan" (http://jab.sirlabs.com/bin/view/JIGs/JIS/SimplePlanDraft). The
> "ImmerPlan" looks nice, but relies too much on Jabber Forms to be useful in
> the general case.
> 
> All those plans sound like they have had a good deal of though go into them,
> though.

yes, i agree. all of them have their strengths. but i agree also about
rhe immer plan. that is why we just recently hammered out a new plan
that is just a merging of the immer and ticket plans. we are finalizing
the draft, and plan to release it to the website in a matter of days.
this merged plan will use the strengths of IM and jabber without
requiring it like the ImmerPlan does.

> 
> For those of you that haven't read them I should point out that there is
> nothing in them that ties them to Jabber or any form of instant messaging at
> all (apart from the ImmerPlan). They are just schenarios for ways a user
> could get access to a system, and could be run over HTTP posts, XML-RPC,
> SOAP or Jabber.  Jabber does have (I think) some ID infrastructure already
> exisiting, though.

yes, all of that is correct. the plans at the website (
http://www.theoretic.com/identity ) are just outlines of how this
identity data can be accessed, the 'interface' if you will.

> 
> However, all the plans outlined do require some form of non-HTML programming
> for the webmaster to implement them. I don't think that is a bad thing, but
> it does move us away from the simple just-do-some-HTML-stuff thing that has
> been put forward here. (Although it could be implemented as an Apache Module
> - since that seems to be everyone's favourite catchcry for some reason).
> 

i seriously doubt any worthwhile identity/auth plan could *just* use
HTML. we at the Jabber Identity project plan to make this as easy as
possible, however, by creating a simple yet secure CGI script that a
service can run on their own server, that acts as a pre-fabricated
gateway to the Jabber Identity system. all the service will really have
to do is decide what to do with the data they get from the gateway
program.

i encourage everyone here to look into subscribing to the Jabber
Identity list. many useful things will be discussed, and as mr lothian
pointed out before, most of it does not even require jabber, so can be
easily ported to other systems. you can find information about the list
at http://www.theoretic.com/identity or just subscribe by sending to
address@hidden . no subject or body needed.