[DotGNU]Archive of Jabber-dotGNU Meeting (Long)

[Adam Theo]

hello, everyone.

The meeting was great! lots of stuff discussed. there is a web archive
of it at:
http://perl.jabber.org/logs/conference.jabber.org/dotgnu/2001-09-13.html

but note the first 15 minutes are missing (didn't get the ChatBot set up
in time...)

here is the full archive, taken directly from my jabber client. sorry
for the length, but i thought many of you would like to have it
inline...

i'm also open to making this a weekly or bi-weekly thing...

[14:03] < JoeH> Do we have a quorum?
[14:03] %% ChatBot has joined
[14:03] <jer> now we do
[14:03] <Theo> yeah, i'd say we have quorum...
[14:03] <reatmon> not yet...
[14:03] %% Dizzy is now known as  ChatBot
[14:03] <reatmon> I have to set ChatBot up
[14:03] < ChatBot> :)
[14:03] <jer> ChatBot: what can you tell us about DotGNU?
[14:04] < ChatBot> I know nothing.
[14:04] < ChatBot> jer: Why don't you tell us something about DotGNU?
[14:04] <Theo> ok, dotgnu as i understand it:
[14:04] <stpeter> hehe
[14:04] <Theo> dotgnu really is trying to be an operating system for the
internet.
[14:04] <stpeter> ChatBot: you are so smart, i'm continually impressed
[14:04] < ChatBot> stpeter: At least I'm smarter than you.
[14:04] <stpeter> LOL
[14:05] <Theo> they plan on working on a number of large projects, such
as a VM that will first handle C#, i think,
[14:05] *  ChatBot notices stpeter being sarcastic
[14:05] <jer> Theo: how closely related are the technologies they want
to develop w/ the .Net stuff?
[14:05] <Theo> but they want to also support java and eventually make
their own.
[14:05] %%  ChatBot is now known as Dizzy
[14:05] <Dizzy> Make their own..?
[14:05] <Dizzy> own what?
[14:05] <Theo> jer: how so? you mean how close are they following .Net?
[14:05] <stpeter> their own VM?
[14:05] < JoeH> Common Language Runtime (CLR)?
[14:05] %% pgmillard has joined
[14:05] <Theo> (make their own language for a VM...)
[14:06] <Theo> (CLR, yes)
[14:06] <Dizzy> make a new _language_..isn't that going a bit far?
[14:06] <Dizzy> oh..n/m :)
[14:06] <chillywilly> http://ivm.sourceforge.net is interesting though
[14:06] <chillywilly> bbiab
[14:06] <fils> theo, I am not sure i have seen any talk of a new
language, have I missed something
[14:06] %% reatmon has left
[14:06] * stpeter nods to chillywilly
[14:06] <Theo> hm... possibly.
[14:06] <Theo> i am not sure about the whole new language bit,
[14:06] %% reatmon has joined
[14:06] <ChatBot> [reatmon]: Hey, Dad!  Can I borrow the car keys?
[14:06] <Theo> all i know is they are starting with c#, then moving to
java, 
[14:06] <reatmon> ChatBot: good bot
[14:06] <ChatBot> reatmon: Tell me more about that.
[14:07] %% TSCHAK has joined
[14:07] <Dizzy> I realize I have nothing to do with the dotgnu project,
but why not go the other direction?
[14:07] <Dizzy> (java -> c#)
[14:07] <Theo> but the VM will be an integral part of DotGNU.
[14:07] <Theo> dizzy: it was decided that java had too much legal
baggage, i think...
[14:08] <Theo> c# was at least becoming an open standard.
[14:08] < JoeH> I would expect that, like Mono, they will need to have a
set of compilers for the languages that they want to support (presumably
at least C#), as well as the CLR, and some subset of the foundation
classes.
[14:08] <Theo> joeh: yes, i think you expect right.
[14:08] <fils> Joeh, that is the work that is being done by portable.net
righ tnow I think...
[14:08] * reatmon has changed the topic to: DotGNU Discussion - Logs at
http://perl.jabber.org/logs/conference.jabber.org/dotgnu/2001-09-13.html
[14:09] <Theo> but, the point is not to discuss the VM/compilers.
[14:09] <TSCHAK> the question is, at what point does compatibility get
misconstrued for infringing on intellectual property?
[14:09] <Theo> the point is to discuss how jabber can first of all help
these VMs and compilers work on a network?
[14:09] < JoeH> Let's table all of the license talk, and all of the Mono
vs. DotGnu vs. .Net talk, so we can get down to Jabber/dotGnu
integration.
[14:10] <stpeter> yes
[14:10] <Theo> joeh: yes, thank you. this is just about jabber and
dotgnu.
[14:10] <Theo> mone has *nothing* to do with this. .Net has *nothing* to
do with this.
[14:11] <Theo> oops, mono :-)
[14:11] <Theo> ok,
[14:11] <Theo> so jabber, being an excellent router of XML....
[14:11] <Theo> could jabber provide any registration or subscription
features or services to the VM?
[14:12] < JoeH> Let's start easy: 1) route SOAP requests (like the
Jabber RPC stuff that is going on in the XML-RPC community)
[14:12] <Theo> to help the VM act as part of a larger network?
[14:13] <Theo> soap: yes. it can route soap and rpc... that's a good
point.
[14:13] <Dizzy> Theo: long term what's your vision for Jabber and
DotGNU?
[14:13] <Dizzy> Or I should say, what is the vision of the DotGNU team
for network integration?
[14:13] <Theo> hm, i don't much have any visions right now. that is
mostly the point of this conf, to see what visions we can do...
[14:13] <Theo> but,
[14:14] <Theo> i'd say that my biggest vision is to see dotgnu use
jabber as a backbone, similar way the Web uses http and apache as a
backbone...
[14:14] <Theo> jabber would provide the common protocol and platform for
this dotgnu traffic on the net...
[14:15] <Dizzy> http/apache are an entirely different type of "backbone"
from Jabber -- simply in the fact that data is not routed between
webservers
[14:15] <Theo> i'd say that dotgnu doesn't really need to build it's own
network. it can easily use jabber's...
[14:15] <Theo> just have users of dotgnu and applications using dotgnu
use jabber accounts,
[14:15] <Theo> probably customized for dotgnu...
[14:15] < JoeH> Are we talking about a bunch of Hailstorm-like services?
[14:16] <Theo> dizzy: yes, i understand, but that was the best thing i
coulfd think of that i knew about...
[14:16] * Dizzy notes that he is just being inquisitive -- he's not
trying to attack
[14:16] <Theo> hailstorm-like will be half of dotgnu,
[14:16] <Theo> in that they do want to support web-only services,
[14:16] * stpeter notes Dizzy's inquisitive nature
[14:16] * Dizzy thwaps stpeter
[14:16] <Theo> but it is *very* important to note that is only half of
dotgnu, whereas that is all of hailstorm.
[14:17] * Dizzy ponders
[14:17] <Dizzy> what's the interest level in DotGNU for integration...of
any sort?
[14:17] <stpeter> what's the other half?
[14:17] <TSCHAK> It is important to note that M$ is having to glue a
bunch of crap onto hailstorm to support things that Jabber does natively
(because HTTP is so stateless)
[14:17] <Theo> the other half will allow for bytecode programs to be
easily shuffled around the net, so that users can run a service as a
local app, not only as a web service.
[14:17] < JoeH> Security?
[14:17] <Dizzy> ugh
[14:17] <Theo> i know, i hate the bytecode thing,
[14:17] <pgmillard> woah...sounds like an easy way to distribute a
virus.
[14:17] < JoeH> Worm Enablement Protocol...
[14:17] <Theo> and disliked dotgnu at first because of that,
[14:18] <Dizzy> i've done work on forced mobile agent systems -- dude,
you're opening a _HUGE_ can of worms
[14:18] <Theo> but if bytecode is very important to them (and it is),
then we should do our best to work with it. agree?
[14:18] * pgmillard wonders why JoeH has a space in front of his nick
[14:18] %% Dizzy is now known as  Dizzy
[14:18] <stpeter> pgmillard: that's to match the space above his neck :)
[14:19] %% cowmix has joined
[14:19] <pgmillard> ROTFL
[14:19] < JoeH> probably a JIM bug.   grmph.
[14:19] <Theo> what is the can of worms here?
[14:19] <Theo> i can see how it'd be easy to distribute viruses,
[14:19] <Theo> since you are moving around execuatbles...
[14:19] <Theo> that is why i think they want to set up a registry
system...
[14:20] < Dizzy> a registry?
[14:20] <Theo> a distributed registry system for the VM to use...
[14:20] <jer> signatures, trust, validation
[14:20] <Theo> yeah, to my understanding. a trust matrix...
[14:20] <Theo> yes, what jer said.
[14:21] <temas> it better not be like pgp's web of trust =)
[14:21] <Theo> so first, how can jabber help with this trust
matrix/registry?
[14:21] <temas> these are design issues though, and I don't think we're
designing dotGnu
[14:21] <temas> have to know how it works first
[14:21] *  Dizzy agrees with temas
[14:22] < Dizzy> Theo: I think you implement these services on top of
jabber perhaps
[14:22] <temas> not just how it works, but some pretty good details on
it
[14:22] <Theo> temas: i don't know. i don't think they've settled on
anything yet, but i have faith that they'll figure out the best thing
for it...
[14:22] <jer> nope, we just want to faciliate whatever design they come
up with, be a technology provider  to them in their quest for a solution
[14:22] < Dizzy> jer: exactly
[14:22] <Theo> jer: exactly.
[14:22] * pgmillard nods
[14:22] < Dizzy> My gut feeling is that we can't be much help until a
solid concept is decided upon
[14:22] <temas> yeah
[14:22] <temas> unfortunately we're both moving targets too
[14:23] <jer> they have a little bit of direction already though, and we
can ponder how that overlaps with jabber
[14:23] < JoeH> Let's list the base-level services that Jabber can
provide today, and those that we could add easily.
[14:23] <Theo> dizzy: and i think you are right, a dotgnu/jabber server
can just provide agents to handle this registry.
[14:23] <Theo> joeh: good idea.
[14:23] <jer> they'll need a network that is transparent to NATs,
firewalls, endpoints-vs-middlepoints, and transport protocols
[14:24] <Theo> jabber: biggest is XML routing in real-time in a
distributed fashion.
[14:24] <Theo> jabber: next is a location/addrtessing scheme with JIDs
and resources.
[14:24] < JoeH> examples of the addr's, please?
[14:24] < Dizzy> Theo: ok..we provide all that.
[14:25] <stpeter> Theo: the RLS stuff?
[14:25] <jer> whats the link to the rls draft again?
[14:25] <Theo> joeh: for jabber?
[14:25] <stpeter> http://www.dotgnu.org/spec/rls.htm
[14:25] <Theo> i'll fetch the RLS.. brb.
[14:26] <Theo> http://dotgnu.org/spec/rls.htm
[14:26] <pgmillard> rls://[User address@hidden<DotGNU Server>[:port]/<DotGNU
Service>[?Meta-Token]
[14:26] <Theo> yep.
[14:26] <Theo> RLS is basically their answer to JIDs and resources...
[14:26] <stpeter> s/answer to/reinvention of/
[14:26] <jer> it's fairly close
[14:26] < JoeH> Is an RLS a subset of URI's?
[14:26] <Theo> one thing about RLS, though, is i think they don't need
to put the 'tokens' in the URI itself...
[14:26] < Dizzy> JIDs work better tho -- no data embedded in the URI
[14:26] <stpeter> JoeH: yes
[14:27] <TSCHAK> are there any advantages to RLS's versus JIDs?
[14:27] <TSCHAK> ahh
[14:27] < Dizzy> Theo: exacatmondo
[14:27] * pgmillard nods to dizzyd
[14:27] <Theo> yes, i agree.
[14:27] %%  Dizzy is now known as Dizzy
[14:27] <jer> they have :port and the resource is simply a bit more
strict, otherwise it's the same
[14:27] <Theo> i think it's a bad idea to put any data itself in the
URI...
[14:27] <stpeter> shyeah
[14:27] <temas> port should be handled through SRV I would think
[14:28] <Dizzy> temas: indeed
[14:28] <Theo> jer: i agree. RLS and JIDs are basically identical except
they put data in the URI... ala http GET action.
[14:28] < JoeH> If you are routing XML data, you don't need to put the
data in the address.
[14:28] <jer> I think they're thinking more along the lines of stateless
http-like, where anyone can run a "service" on any box
[14:28] <Theo> joeh: my thoughts exactly.
[14:29] <Theo> jer: they are, but they want it to not be static so much
as stationary.
[14:29] <Theo> that's how i think jabber can help. provide the
'stationary' addressing and location schemes,
[14:29] <Theo> while allowing the content to be dynamic, non-static.
make sense?
[14:30] <Theo> they don't want a web,
[14:30] <Theo> where you just point a browser to a address and receive
info.
[14:30] <Theo> they want it all to be dynamic like running apps on your
local computer... to an extend, of course.
[14:31] < JoeH> The other thing that is important is the ability to send
async stuff to the client.
[14:31] <Theo> they want, and need, the XML routing stuff.
[14:31] <Theo> and if they have that, i think they should keep all data
in the xml packet, not the URI...
[14:31] < JoeH> web (and web services for that matter) doesn't have any
concept of Async, currently.
[14:32] <Dizzy> currently, no web have you.
[14:32] %% Dizzy is now known as Yoda
[14:32] *  JoeH notices yoda in the room.
[14:32] <Theo> ok, so i think this is the first consensus: jabber can
help by seperating the data from the addressing?
[14:33] <Theo> next: back to bytecode real quick.
[14:33] <Theo> can Jabber provide the file- and bytecode- transfer
network to shuffle this bytecode around?
[14:33] <Theo> or is that best left to http and other techs?
[14:34] %% ChatBot has left
[14:34] %% ChatBot has joined
[14:34] <Yoda> indeed
[14:34] < JoeH> yes, as a first step.
[14:35] * temas returns with some corndogs
[14:35] < JoeH> bytecoding is handled by UTF8, or xml encoding,
depending on what you mean.
[14:35] <Theo> ok, so second consensus: jabber can provide the bytecode
transfer platform to move all this bytecode around?
[14:35] <Yoda> no
[14:35] < JoeH> you mean IL bytecode.
[14:36] <Yoda> transfer bytecode, you must not.
[14:36] < JoeH> (IL-like.  whatever)
[14:36] <Theo> yeah, IL-like,
[14:36] <Theo> ok, oda, why not>?
[14:36] <Theo> oops, Yoda...
[14:36] <Yoda> Information which is binary, Jabber can carry not.
[14:37] <Theo> hmmm...
[14:37] <Yoda> Once you go down this path, never can you return.
[14:37] <stpeter> LOL
[14:37] <temas> if it's encoded it can, but I don't know how much you
would gain
[14:37] <Theo> so jabber can only carry ASCVII?
[14:37] < JoeH> UTF-8.
[14:37] <Theo> ack! ASCII?
[14:37] <Theo> oh,
[14:37] <Theo> not even binary encoded in the XML packets?
[14:38] <temas> the gains in my head are the tunnels that jabber
provides
[14:38] <Theo> like, included in the XML message?
[14:38] < JoeH> you could, but why would you want to *push* bytecode?
[14:38] <Theo> hm... good point...
[14:38] <temas> generally I would imagine the bytecode would be on
publically accessible servers
[14:39] <Theo> yeah, and downloaded via http?
[14:39] <Theo> not jabber?
[14:39] < JoeH> you could send a URL through Jabber.  i.e. jabber:x:oob
[14:39] <Theo> true... send the http or ftp URL through jabber...
[14:40] <Theo> but not the bytecode.
[14:40] <Theo> ok, that makes sense.
[14:40] <Theo> so jabber can't help much in the bytecode transfer area.
[14:40] <Yoda> Use the HTTP, Theo.
[14:40] * temas thwaps Yoda
[14:40] <stpeter> LOL
[14:40] * Theo shakes head...
[14:40] <Theo> ok,
[14:40] %% Yoda is now known as Dizzy
[14:40] <Theo> no bytecode on jabber.
[14:40] <Theo> but data?
[14:41] <Theo> data such as 'web services',
[14:41] <Theo> where a person visits a service,
[14:41] %% tweedledee has joined
[14:41] <Dizzy> data is fine, just not binary data -- structured
textutal data is great
[14:41] <Theo> and data where services communicate with each other...?
[14:41] <tweedledee> heya
[14:41] <tweedledee> things still happening?
[14:41] <Theo> hi, mike.
[14:41] %% tweedledee is now known as Mike
[14:41] <Theo> yep.
[14:42] <Theo> about halfway though, i guess.
[14:42] <Mike> just read the mail
[14:42] < JoeH> http://www.pipetree.com/jabber/XMLRPC/
[14:42] <Mike> good stuff
[14:42] <Theo> joeh: looking into it.
[14:42] <Theo> what's your comments on it?
[14:42] < JoeH> do something similar for SOAP.
[14:42] <cowmix> Is there a reason XMLRPC is being used over SOAP?
[14:42] <Dizzy> cowmix: it was easier
[14:42] <Dizzy> :)
[14:42] <Theo> i think XMLRPC is lighter,
[14:43] <jer> cowmix: being used for what?
[14:43] <Theo> but SOAP is just as possible. just need to get the man
hours to work it in, like XMLRPC.
[14:43] <cowmix> We have being routing SOAP over Jabber with little
issues thus far.
[14:43] <cowmix> just playing around with it.
[14:43] <Theo> cowmix: cool beans! already?
[14:44] < JoeH> jabber allows you to route arbitrary XML messages
through it.
[14:44] <jer> there's been numerous efforts doing soap/jabber... we need
a nice spec like the xmlrpc/jabber one to get everyone on the same page
:)
[14:44] <cowmix> yeah.. we are using the PocketSoap with VB.. and a Java
client that routes the SOAP packets to any SOAP service.
[14:44] <Theo> ok, so i take it jabber is already quite capable of doing
XMLRPC and SOAP routing already, today? 
[14:44] <Theo> that's good.
[14:44] <cowmix> I'll try to post our Java SOAP gateway soon.
[14:45] <Theo> yeah, i knew jabber can route*ny* xml. i was just
wondering about the front ends and such...
[14:45] <Dizzy> is NY xml still working?
[14:45] <Mike> can anyone sum up what has been said so far?
[14:45] <Theo> dotGNU will be very excited about the SOAP and XMLRPC
aspects...
[14:46] <chillywilly> back
[14:46] <Theo> dizzy: sorry, that was supposed to be *any* XML... :-)
[14:46] <chillywilly> lol @ Yoda :)
[14:46] <Theo> mike: yeah,
[14:46] * chillywilly just got caught up
[14:46] <Theo> mike: no bytecode on jabber.
[14:47] <Mike> theo: not even base64 encoded or something?
[14:47] <Theo> mike: jabber can seperate the data from the addressing,
which dotGNU's does not.
[14:47] <Mike> hang on: dotGNU's what doesn't?
[14:47] <Theo> oops, dotGNU's RLS doesn't...
[14:48] <Theo> RLS = resource locator strings.
http://dotgnu.org/spec/rls.htm
[14:48] <Mike> ok thanks
[14:48] %% Kint has joined
[14:49] <Theo> mike: and finally, XMLRPC and SOAP support over jabber
can be done today, is already being done. big plus for dotgnu.
[14:49] <Mike> yeah
[14:49] <Mike> what about distributed authentication?
[14:49] <Theo> ok, any other point anyone can think of?
[14:49] <Dizzy> what do you mean by that?
[14:49] <Theo> mike: good point.
[14:49] <Mike> i have designed a system for this for jabber. What is
.GNU planning for this?
[14:49] <Dizzy> (dist. auth)
[14:49] <Mike> like Passport
[14:49] <Mike> but that doesn't suck
[14:49] <temas> passport isn't distributed auth
[14:49] <jer> yeah, passport's is missing the "distributed" :)
[14:49] <temas> =)
[14:50] <Theo> mike: i am sure they would be interested very much in
your tokens auth system...
[14:50] <Mike> that's basically it
[14:50] <Mike> I have refined it since then adam
[14:50] <Theo> awesome :)
[14:50] <Mike> it would basically allow services/websites/software to
authenticate users based on their jabber accounts
[14:50] <Mike> but it's all on paper right now
[14:50] < JoeH> Mike: URL?
[14:50] <Theo> but i'm sure they would gladly do the code...
[14:50] <Mike> so much more flexible than Passport which is for websites
only and is very centralised
[14:51] <jer> Mike: interesting...  any tidbits online anywhere?
[14:51] <Mike> JoeH: www.passport.com tells you about the competitor.
Search for AOL Magic Carpet for info on what AOL is doing in this area
[14:51] <Mike> There are probably some articles about our plans in the
JabWiki
[14:51] <Theo> mike: i think he meant url for your tokens spec... :)
[14:51] <Mike> i have forgotten. If there's interest I'll write it up
and post ot jdev
[14:51] <Theo> yeah, heg's JabWike...
[14:51] <Mike> at the moment though like i said it's all in my head,
sorry about that
[14:51] <Theo> but it's offline right now, i think...
[14:52] <Theo> we had all our stuff on Heg's JabWiki
(http://jab.sirlabs.com), but it went offline...
[14:52] <Theo> hopefully it will be back up soon.
[14:52] <Mike> did it? damn. ah well, like i said things have moved on
since then
[14:52] < JoeH> Yes, I meant a URL for the stuff you "have on paper".
[14:52] <Theo> yeah...
[14:52] <Mike> ah sorry, a turn of phrase. I apologise
[14:53] <Mike> I will try and get it on paper tonight though if you
like, it shouldn't take long
[14:53] <Theo> mike: well, looks like you'll need to make the time to
put the stuff you have in your head online... :-)
[14:53] <Theo> hehe, yep.
[14:53] <Mike> it's not especially complex. I'd need help with the
security aspects though as I don't know much about designing secure
systems
[14:53] <Theo> ok, i'm sure someone can help you.
[14:53] <Mike> ok thanks. anything else?
[14:56] <Mike> perhaps not. if you like i can basically explain the dist
auth system now?
[14:56] < JoeH> please.
[14:56] %% jkernsjr has joined
[14:56] <Mike> ok. Here we go
[14:56] <Mike> Basically the system revolves around the idea that
peoples identity should exist in one place ie. that instead of having
many many user accounts for different services and the lack of secure
passwords that this implies,we should have one user login for all
computers and services
[14:56] <Mike> At the moment, the infrastructure for this doesn't exist,
but MS have produced a tantalising glimpse into the future with their
Passport system
[14:57] <Mike> Unfortunately for the citizens of the net, Passport is
fatally flawed. It is entirely centralised, and relies totally on
Microsoft keeping their servers up and running 24/7
[14:57] <Mike> Websites can use Passport for single sign in (SSI). This
means that once you've authenticated yourself with passport, you don't
have to login again - websites will automatically recognise you
[14:58] < JoeH> assume that we understand what Passport is.
[14:58] <Mike> At the moment this works only with a very few sites,
mainly MS ones although there are others.
[14:58] <Mike> ok
[14:58] <Mike> Now the system I have designed works thusly
[14:58] * Mike will assume we are using a wcs SOAP interface to the
jabber protocol here
[14:58] <Mike> A jabber account can be used to authenticate with:
[14:58] <Mike> - websites
[14:59] <Mike> - other servers or services
[14:59] <Mike> - and the jabber server itself
[14:59] < JoeH> so you just want to be able to send an auth request from
an external system?
[14:59] < JoeH> (over wcs?)
[14:59] <Mike> For websites the mechanism is different to other services
because of the importance of not letting user credentials (at the moment
passwords but maybe in the future iris data, fingerprints etc)
[15:00] <Mike> JoeH: yes sort of. But it's more complex than that,
because the user may not wish the service to know their credentials
[15:00] <Dizzy> so you want to be able to blacklist certain domain names
for auth'ing you externally?
[15:00] < JoeH> or do you want full, granular ACL's?
[15:00] <Dizzy> s/for/from
[15:00] <Theo> i think granular ACLs are best...
[15:00] <Dizzy> mmm... yummy...ACL <homer drool>
[15:01] <Theo> dizzy: hehe...
[15:01] <Mike> We are planning on fairly flexible ACLs at the moment,
but just for authentication ACLs are not required. Once tied into the
profiles framework then maybe.
[15:01] <Mike> but anyway
[15:01] <Mike> I'll take you through websites first:
[15:01] <Mike> 1) User goes to a website supporting jabber
authentication
[15:01] * Theo informs: ACL stands for Access Control List... look it
up.
[15:01] * Dizzy notices Theo informing
[15:01] *  JoeH thwaps yoda
[15:01] <Mike> 2) There is a small form containing a username field and
a submit button. User enters for instance address@hidden
[15:01] * Dizzy looks around for yoda
[15:02] <Mike> 3) Once submitted, the users server is contacted (via wcs
or jabber natively, either will do) and sends a message/iq saying "I am
a website and want to authenticate the user. What do I do?"
[15:02] <Dizzy> Mike: but..this isn't single sign in...is it?
[15:02] <Mike> 4) The server replies with something like this
[15:02] <Theo> mike: ok, and if this was for a local application, they'd
be entering this info... into a field in the app, or could be taken from
their login into their computer?
[15:03] <Mike> dizzy: almost. I don't like the idea of complete ssi
because you may not wish sites to know who you are. But after logging in
once, you don't have to do it again
[15:03] <Mike> just a sec, let me finish, it'll become clear
[15:03] <Mike> 4) Server replies: go to
http://authenticate.jabber.org/?token=00fdase454gfahkzt5
[15:03] <Theo> mike: good point.
[15:04] <Mike> 5) So the website that the user wishes to authenticate
themselves with (site A) sends an HTTP redirect to that URL, which note
can be anything
[15:04] <Mike> 6) If this is the first time a user has logged in from
this computer for the web, they will be presented with a form that
requests their password and perhaps lets them set permissions for what
the site can do
[15:05] %%  JoeH is now known as  mass
[15:05] < mass> so is this similar in any way to kerberos/active
directory?
[15:05] <Mike> 7) If it isn't then there will be a cookie available that
will simply automate this form filling, so we carry on
[15:05] %%  mass is now known as  JoeH
[15:05] <Mike> JoeH: it has elements of this, but is designed for the
internet and does not require the tight encryption of kerberos
[15:06] <Mike> 8) authenticate.jabber.org or whatever checks the users
details out, and if they clear then it redirects the user to a URL
provided in the original SOAP/IQ message. Once the user has reached this
return url, site A knows they are authenticated and can set cookies
meaning they never have to identify themselves again (or don't until
next time for instance)
[15:07] <Mike> So now the user is logged into the web using their jabber
account and all they have to do it tell each site their JID to be logged
in
[15:07] <Mike> And this of course could be automated further for true
ssi with extensions to the browser
[15:07] <Mike> anyone got queries on that, or shall i continue to other
services which are simpler?
[15:08] * Dizzy departs for a few
[15:08] %% Dizzy has left
[15:08] <Mike> hmm ok, i'll continue
[15:08] <Mike> dizzy can catch up from the logs
[15:08] <chillywilly> can I forge a Jabber ID?
[15:08] <Mike> if anyone wishes me to stop then please say so
[15:09] <Mike> chillywilly: not sure. I don't think so, unless you set
up your own server
[15:09] < JoeH> in TC, yes, but not as far as the server is concerned.
[15:09] < JoeH> TC just lest you change your nick to anything.
[15:09] <stpeter> TC == text conferencing
[15:09] < JoeH> the server rewrites from's to prevent spoofing.
[15:09] < JoeH> s/lest/lets/
[15:10] <Mike> chillywilly: theoretically if you could intercept the
redirects, or messages you could hijack someones identity. which is why
i need security experts to help me refine the system
[15:10] <Mike> ok services
[15:10] <Theo> yes, that is one of the very nice things with jabber...
no spoofing possible.
[15:10] <Mike> the problem with the web is that browsers do not know
anything about jabber, hence the need for an intermediary site
[15:10] <Mike> theo: don't speak too soon!
[15:10] <Theo> hm... true...
[15:10] <Mike> with services, we can assume that the client software
knows something about jabber. If not, then we can deal with this too,
I'll explain how in a min
[15:11] <Theo> i revoke my earlier statement about spoofing, after
thought.
[15:11] <chillywilly> if it is not encrypted someone could hijack the
URL with the token couldn't they?
[15:11] <Mike> i'll use the example of an FTP server for now
[15:11] <Theo> i'm sure it will be encrypted, right? it's just not
detailed yet.
[15:11] <Mike> chillywilly: possibly yes, but the token would be a hash
anyway
[15:11] <chillywilly> or intercept cookies
[15:11] <Mike> chillywilly: if they can do that, then they can probably
intercept the form being submitted with the password in anyway
[15:12] <Theo> good point.
[15:12] <Mike> cookies would be encrypted to stop them being read by
software on the user machine
[15:12] <Mike> anyway, the jabber aware FTP server
[15:12] <Mike> and also of course jabber aware client
[15:12] <Mike> in this case, we can simply use an extension of the
authentication used at the moment
[15:13] <chillywilly> anyone here on the FD list?
[15:13] <Theo> chilly: nope, sorry.
[15:13] < JoeH> FD?
[15:13] <Mike> 1) User selects Jabber Auth in their FTP client and
connects, gives the server their jid
[15:13] <Theo> FD == freedevelopers?
[15:13] <chillywilly> yes
[15:13] <Theo> freedevelopers.net
[15:13] <chillywilly> yes
[15:13] <chillywilly> that be the place
[15:14] <Theo> mike: ahh... ftp.. nice.
[15:14] <Mike> 2) ftpd contacts jabber server, and requests say digest
authentication. jabber server returns a token in the soap/iq message
[15:14] <Mike> 3) ftpd sends the token to the client which asks the user
for their password (or let's fantasise here, an iris scan. How cool
would that be? point is credentials don't have to be passwords)
[15:14] <Mike> fantasize rather
[15:15] * Mike looks sheepish
[15:15] <Mike> oh well
[15:15] <Theo> mike: gotcha
[15:15] <Theo> i understand.
[15:15] <Theo> very nice.
[15:15] <chillywilly> retna scan
[15:15] <Theo> needs some fine-tuning, of course,
[15:15] <Theo> but the basic principles are all very nicely laid out.
[15:15] <Mike> 4) Client concats token and password, hashes them and
gives them to the ftpd, which forwards them to the jabberd. Jabber
server checks out hash in the same way
[15:15] < JoeH> I guess this all still looks functionally like Kerberos
to me.  Couldn't we wrap kerb stuff in XML, and route it through jabber?
[15:16] <Mike> 5) If clear, then jabberd informs ftpd and all goes
through ok. ftp server never saw the credentials
[15:16] <Theo> yes, we probably could...
[15:16] <Mike> JoeH: I looked at kerberos, but it looked incredibly
complex. Also, aren't there problems with an MS specific version or
something?
[15:17] <chillywilly> yes, M$ bastardized
[15:17] <chillywilly> it
[15:17] <Mike> Also, this will have lower traffic requirements than kerb
and not need the clock synchro
[15:17] <Mike> but i'm open to suggestions
[15:17] <temas> but that doesn't mean the regular one isn't out there
[15:17] <TSCHAK> mike: You can authenticate to Win2k kerberos
servers..... making win2k clients authenticate to MIT Kerberos servers
is another matter.
[15:17] <Mike> oh and finally: what to do when the users client doesn't
know about jabber
[15:17] <Mike> this uses Adams IM idea
[15:17] <Mike> Let's say FTPd is jabber aware, but I'm using an old
client that isn't. How do I authenticate?
[15:17] <Theo> ah, the Immer plan?
[15:18] <Mike> yeah
[15:18] <Theo> ok.
[15:18] <Mike> well, I provide the server with my JID and either a blank
or dummy password
[15:18] <Mike> the server realises that I'm attempting to use my jabber
account and that the client doesn't support it, and sends the SOAP/IQ
message to the server
[15:18] <Mike> it says: "I need to auth for a client using IM"
[15:19] <Mike> the server sends the user a message with a jabber form in
it that says something like:
[15:19] <Mike> "Service 'FTP server' at address 192.23.4.44 wishes to
authenticate using your account. Confirm authentication? OK CANCEL"
[15:19] <Mike> or something like that. If you click OK in your chat
client, authentication goes ahead as normal (no password is needed as
you've already authed with your im connection)
[15:20] <Mike> and that's it basically!
[15:20] <Theo> mike: very well explained, thank you :-)
[15:20] <TSCHAK> nice 'n' simple.
[15:20] <Theo> there is one last topic i'd like to bring up,
[15:20] <Theo> then his can come to a close...
[15:20] < JoeH> Mike: I'd suggest you write that up, we agree that we
need something like that (whether it's exactly that or not) and move on.
[15:20] <Theo> i've heard talk before about ways to use a jabber server
as a GPG/PGP repository??
[15:20] <Mike> JoeH: ok will do hopefully tonight
[15:21] <chillywilly> gabber lets me put my gpg key in it
[15:21] <Theo> how practical is this concept?
[15:21] <Theo> yes, i think other clients do, too.
[15:22] <Mike> this could be linked to the profiles system. So we have a
security profile that has PGP/GPG keys in, and signatures, certificates
etc.
[15:22] <chillywilly> it would be just another service right?
[15:22] <chillywilly> ah
[15:22] <Theo> mike: yes, a PGP Profile would be the best way to do it,
i think...
[15:23] <Theo> ok, i think that is it, then...
[15:23] <Theo> whew, what a conf, heh?
[15:23] <Mike> lol yeah
[15:23] <chillywilly> you can encrypt messages too right?
[15:23] <Mike> we should have these "bluesky" sessions more often
[15:23] <Theo> yep.
[15:23] <Mike> chillywilly: yeah, you can do this at the moment i think
[15:23] <Theo> chilly: yes, you can.
[15:23] < JoeH> I just set up a mailing list, where we can continue this
discussion.  Send mail to: address@hidden
[15:23] <chillywilly> in prefernces->security tab it has a check box for
that in gabber
[15:23] <Theo> ok, thanks.
[15:24] < JoeH> That would be a good place for mike to send his paper.
[15:24] <Theo> i'll also see about making this jabber conf a weekly
thing...