[standards-jig] JEP-0070 & JEP-0101

Richard Dobson richard at dobson-i.net
Fri Jun 27 15:11:25 UTC 2003

> I am really not convinced by your assertion that JEP-101 and JEP-70 are
> at entirely different markets, since there seems to be a large amount of
> overlap between the stated aims for both.

The two different "markets" or a better term of "areas" I was refering to
were 'web farm/web server' environments and 'jabber client http, e.g. file

Now here is why do sincerly think the two protocols are "that" much
different that a new JEP was required, and why I think each is more
appropriate to a different area:

Webfarm environments
JEP-0070 is not really suited to web farm environments because the jabber
component and the webserver need to be tightly integrated and the state of
each attempt to authenticate needs to be stored server side, that state
needs to be shared by the webserver and the jabber component. In a web farm
environment this does create a reasonable high barrier for ease
implementation and scalability. Also on a more general note both protocols
are susceptable to either the "accept token" in the case of JEP-0070 or the
"jabber ticket" in the case of JEP-0101 being sniffed and someone else being
able to pass that to the webserver themselves and authenticate. Also I dont
really see the reason that their needs to be so much jabber traffic for
JEP-0070 where JEP-0101 only needs a single request, and that they both
offer virtually the same level of security.

JEP-0101 is far more suited to web farm environments because the jabber
component and the webserver do not need to be coupled, infact they could be
in different parts of the world, all they need to share in common is the
correct encryption keys to encode/decode the encrypted tickets, this makes
implementation and scalability far more easier. Also as noted above since
both protocols are susceptable to the same form of attack, the reduced
complexity, increased scalability and easier implementation make a ticket
based system a better choice. Also Tickets are much truer way to do single
sign on, if say several separate websites are offered by someone and they
are same realm the ticket only needs to be requested once which makes things
far easier, most true single sign on systems that I know of (Kerberos and MS
Passport) use tickets too.

Client provided HTTP services
JEP-0070 is more suited to client provided HTTP services because it means
they dont have to have full encryption capabilities built-in, also because
their is not real scalability issue there is no need for the scalability
that tickets provide.

Because of this I still see the need for two JEP's since JEP-0070 unless
rewritten completely to be a ticket style system it is not useful to me
since it just wont work where a ticket system is far more appropriate. Also
I dont see why these two systems cant co-exist seeing as they have distinct
benefits to each particular area, just like you have multiple methods for
jabber authentication (digest, plain text, sasl digest-md5 etc etc) whats
wrong with having multiple standards where they do have distinct benefits
for different people?, instead of just having one standard that doesnt fit
all circumstances, again whats wrong with giving people choice to pick the
most appropriate? (although of course not an unlimited choice :) ).

> Anyway, I agree that this seems to have been blown out of all
> proportion, and hope that now you and Matthew have had a chance to
> explain your viewpoints you can decide whether there really is a need
> for 2 JEPs.

I couldnt agree more, this has been blown out of all proportion.


More information about the Standards mailing list