[DotGNU]Log of Oct 18 DotGNU/Jabber Meeting (long)

[Adam Theo]

Another very productive meeting today. This one focused on 
authentication and authorization, since I'm going to be speaking at 
O'Reilly's upcoming P2P Conference on Identity Services. Here's the log, 
it's long  :-)

[14:54] * theo has changed the topic to: DotGNU/Jabber Meeting in 10 Minutes
[14:55] <dirkx> theo: when is the P2P reschuduled to ?
[14:55] %% nb has joined
[14:55] <theo> Nov 5-8
[14:55] <theo> in a couple of weeks
[14:56] <theo> and i'm speaking, woo-hoo!
[14:56] <theo> hi, norbert!
[14:56] <nb> Hi, everyone!
[14:56] <theo> i just sent out an Agenda to the lists.
[14:56] <theo> will be starting in about 5-10 minutes,
[14:57] <theo> will wait for a few more to come.
[15:02] <theo> brb, getting food.
[15:02] %% mangoman has joined
[15:02] <mangoman> hi a;ll
[15:02] %% neiras has joined
[15:03] <neiras> Greetings, everyone
[15:03] <nb> Hi mangoman, neiras :-)
[15:03] <mangoman> =]
[15:03] <neiras> =))

[15:03] %% Willy has joined
[15:03] %% ruud has joined
[15:03] <neiras> Funny this should come up, just as I was considering a
Jabber view for Evolution
[15:03] <mangoman> Bill Gates Has Joined
[15:03] <mangoman> nooo
[15:03] <mangoman> j/k
[15:04] <theo> neiras: a jabber view for Evolution? how so?
[15:04] <neiras> All those on a non-windows OS, wave!
[15:04] %% guy has joined
[15:05] <theo> (and I guess it's time to get this started)
[15:05] <mangoman> neiras
[15:05] * nb waves
[15:05] <Willy> hello everybody!!!
[15:05] <mangoman> i would be on linux
[15:05] <neiras> theo: Well, Evolution is written in a very modular format
[15:05] <theo> Hello!!!  :-)
[15:05] <mangoman> however my router isn't working, and Gaim
continuously hangs
[15:05] <theo> hm, how would Jabber play a part?
[15:05] <mangoman> i was on linux earlier though :D
[15:05] <neiras> It would be possible to integrate a Jabber client into
it, interact with the address book, etc
[15:05] <rikard> hi
[15:05] <theo> huh...
[15:05] <theo> very cool sounding...
[15:05] <neiras> I think so =)
[15:05] <mangoman> I like the whole idea of the Jabber Project
[15:06] <theo> mangoman: yep, so do i :)
[15:06] <nb> I'm getting intrigued, too :-)
[15:06] <theo> wow, i can't believe this many people came in after i
posted to my jabber server  :-)
[15:06] <neiras> FIrst off, can someone clarify any relationship between
DotGNU and Mono?
[15:06] <mangoman> lol
[15:06] <nb> Sure...
[15:06] %% allgaier2 has joined
[15:06] <theo> neiras: i think this is best done by nb.
[15:06] <Willy> what are the most importants goals with this integration?
[15:07] <mangoman> erm
[15:07] <mangoman> 1) that it works
[15:07] <mangoman> 2) i don't know
[15:07] <nb> right now there is no cooperation, and only a superficial
similarity between what Mono is doing, and a small part of what DotGNU
is doing.
[15:07] <theo> Willy: the most important goal is to really get DotGNU
off the ground, and up and running on a powerful, flexible platform as
soon as possible. Microsft has a head start, DotGNU can catch up by
using Jabber.
[15:08] <neiras> Hmm.ç
[15:08] <mangoman> yes
[15:08] <mangoman> quite true
[15:08] <Sunshine> Agenda?
[15:08] <neiras> Is there a central list of tasks as yet?
[15:08] <mangoman> We've got the building blocks, lets build
[15:08] <Willy> theo: that sounds great
[15:08] <theo> yep, just posted the Agenda to the jabber and dotgnu
lists....
[15:08] <theo> i'll get the link to the Agenda, just a sec.
[15:08] <Sunshine> want me to go off-line and READ EMAIL?
[15:08] <Sunshine> :)
[15:09] <theo>
http://dotgnu.org/pipermail/developers/2001-October/001116.html
[15:09] <dirkx> Companing Mono/DotGNU/Jabber(auth)/Liberty and Passport
is IMHO not quite justified; the former are all federated trust/auth
models whereas the latter is a wheel with spokes where you let a third
party make the deceision
[15:10] %% xsee has joined
[15:10] <theo> dirkx: i somewhat agree, but i think that some
comparisons will have to be done. (i'll have to do it in 2 weeks :))
[15:10] <theo> ok, let's start this, then.
[15:10] <theo> everyone just got that link to the Agenda?
[15:10] <dirkx> Theo: That is only fair :-)
[15:10] <rikard> yup
[15:11] <nb> Since when does Mono have a federated trsut/auth model?
[15:11] <mangoman> yes theo
[15:11] * neiras reads happily
[15:11] <theo> excellent.
[15:11] <Willy> yeah
[15:11] <rikard> what's jabber enviroments?
[15:11] <theo> first Topic: Jabber Environments.
[15:11] <Sunshine> point of order
[15:11] <Sunshine> theo
[15:11] <theo> Jabber Environments are an idea i had a few weeks ago.
here's the concept:
[15:11] <Sunshine> can we add something at the end of the agenda?
[15:11] <theo> (sure, sunshine, what do you want?)
[15:11] <Sunshine> I'd like to come back to dirkx's point.
[15:12] <Sunshine> OK?
[15:12] <theo> (yep, sounds good  :-)
[15:12] <Sunshine> (thanks)
[15:12] <Sunshine> let's rock!
[15:12] <theo> Jabber is growing rapidly. It began in the INstant
Messaging space, by goinging together AIM, ICQ, MSN, and a few other
messaging systems.
[15:13] %% Ben has joined
[15:13] <mangoman> Jabber is a new idea that has worked
[15:13] <theo> However, Jabber is now growing very quickly past that
boundary. Recemntly XML-RPC was formalized in Jabber, and SOAP is not
far behind.
[15:13] <neiras> Wow, now I missed that. Exciting!
[15:14] <theo> With this, a person can now run remote applications over
Jabber...
[15:14] <dirkx> Though I acknowledege the history of jabber - I think
one does not do it quite enough justice that way. It really is a very
flexible peer to peer protocol - which just happens to work well in a
instant messaging environment.
[15:14] %% marcel has left
[15:14] <theo> and other great features are not far behind.
[15:14] <theo> However, this poses a great problem.
[15:14] <mangoman> wow. will we be playing our 3d fps games on jabber
soon? =]
[15:15] * neiras snorts
[15:15] <theo> Jabber could very well get too big for it's britches, so
to speak, and end up a fractured, incoherent mass of standards and specs.
[15:15] <dirkx> So I would rather look at jabber as a peer2peer
messaging layer; and then all those other features follow very
logically. (Acknowledging 'theo's statement here big time :-)
[15:15] <theo> I think that is a real possability,
[15:15] <neiras> dirkx... It's not a P2P platform at all.
[15:15] <mangoman> so... what jabber needs if something like an rfc?
[15:15] <theo> so I'm promoting "Jabber Environments" as a solution.
[15:15] <dirkx> -> but at the same time; the bottom layer is quite sound
and simple.
[15:16] <dirkx> neiras: why would you say it is not a P2P platform ?
[15:16] <neiras> Because it requires central servers. It's a server
based system.
[15:16] <nb> What's "Jabber Environments" ???
[15:16] <theo> Jabber Environments are "sub-sets" of Jabber. They pick
and choose among the many growing Jabber specs, and turn their
selections into a coherent, packaged platform.
[15:16] <theo> for example:
[15:17] <nb> My planned "WOS coordinating project"?
[15:17] %% allgaier2 is now known as Snicker
[15:17] <theo> There could be a Jabber Environment of "Simple IM", which
would be the traditional Jabber of Instant Messaging.
[15:17] <nb> Could that be a "Jabber Environment"?
[15:17] <mangoman> great idea
[15:17] <neiras> theo: Interesting. So you would be defining a way for
each environment to make the services it provides public...
[15:17] <neiras> Wow, that's cool,
[15:18] <theo> I'm also working on a Jabber Environment called "Crown",
which would be advanced IM, plus email, telephone, and video
conferencing-like features.
[15:18] <mangoman> oooh
[15:18] <theo> there could be other Jabber Environmewnts: one for web
services, others for distributed computing, e-commerce transactions, etc...
[15:18] <Willy> great theo!!!
[15:18] <theo> basically,
[15:18] <mangoman> great
[15:19] <neiras> theo: keeping interface separate, of course. We are
talking protocol standards, right?
[15:19] <dirkx> neiras: does it require 'central' servers. What stops
everyone to run a few of their own - i.e. your personal proxy ? I agree
that *today* jabber is both a technology (which has P2P properties) and
an infratructure (mostly provided by jabber.com - but see
rooms.theoritic.com too). Do not mix them up.
[15:19] <theo> instead of having one huge "mass" of Jabber specs, you
have a reasonable handful of "Environments" that customize and package
Jabber for different needs...
[15:19] %% sibn has joined
[15:19] <dirkx> theo: how does this 'differ' from careful definition of
namespaces - and splitting each of those up in their own documents or
'environments' ?
[15:20] <neiras> dirkx: THat's the point. In a P2P setup, everyone is a
peer, and everyone is a server *and* a client. IN jabber, you have
clients, and servers. So it's not P2P.
[15:20] <theo> neiras: correct, although the Crown Environment could
make some basic UI standards to define what Crown clients should follow,
to make sure users will be familiar with all Crown clients.
[15:20] <dirkx> and just have the base jabber spec
[15:20] <Sunshine> dirkx, theo, woud an environment be a collection of
namespaces?
[15:20] <neiras> Sunshine voiced my next question
[15:20] <dirkx> neiras: the servers talk to each other peer to peer.
There is not one 'top' or master server (ignoring the DNS root)
[15:20] <theo> dirkx: it would be quite similar to that, just a more
fully "packaged" presentation.
[15:20] <neiras> =)
[15:21] <dirkx> sunshine: yes - that would how I would look at it :-)
[15:21] <theo> Environments could include packaged namespaces, yes,
[15:21] <dirkx> theo: and that last part; the 'packaging' is where today
things severely lack !
[15:21] <theo> but are not restricted to only doing namesapces aspects.
[15:21] <theo> i see Environments as mostly packaging "features" of Jabber,
[15:22] %% carlb has joined
[15:22] <theo> so, with that,
[15:22] %% sabby has joined
[15:22] <theo> I'm thinking DotGNU might be interested in creating a
Jabber Environment,
[15:22] <theo> or a couple, really.
[15:22] <Sunshine> neiras - p2p almost always uses some central servers
anyway, it seems - it's not as pure technologically as is desirec
politically.  Besides, can just run a server as part of a client and
voila pure p2p platform.
[15:22] <nb> Yes, definately...
[15:23] <nb> Two, actually.
[15:23] <theo> excellent.
[15:23] <theo> which ones are you thinking?
[15:23] <nb> One for Jabber auth...
[15:23] <theo> yep....
[15:23] <nb> one for the WOS stuff.
[15:23] <theo> WOS?
[15:23] <nb> "Web Operating System"...
[15:23] <mangoman> =]
[15:24] <nb> It's called "Distributed Execution Environment" on the website.
[15:24] <dirkx> Hmm - so you are thingking of going 'horizontal'. Which
indeed is where there needs to be a clean up; spec wise.
[15:24] <theo> ah... ok.
[15:24] <mangoman> wouldn't that pose a problem if the user didn't use
the internet?
[15:24] <theo> so WOS is the Distributed Computing component of
DotGNU... ok. DEE...
[15:24] <nb> exactly.
[15:25] <theo> mangoman: i assume that WOS/DEE would also work on
intranets....
[15:25] <mangoman> ah right
[15:25] <dirkx> At the same time I would argue for 'vertical' lack as
well. I.e. say for example XML signatures/encription of arbitrary
elements - you'd (or at least I personllay) would ratehr do that
vertical - and let it benefit all - than make a parallel horizonal
'feature' which does something like this for just one
application/namepsace or 'environment'
[15:25] <theo> dirkx: yes, true.
[15:25] <nb> A collection of sysadmin tools and middleware that allows
to manage distributed webservice servers.
[15:25] <theo> ok, next Topic: the Jabber Authentication Framework.
[15:26] * theo has changed the topic to: Jabber Authentication Framework.
[15:26] <nb> For the middleware, I'm currently thinking of: Jabber,
Jabber, and Jabber.
[15:26] <nb> :)
[15:26] <theo> nb: haha... hahaha... *sigh* *wheez*
[15:26] <theo> ok, Auth Framework.
[15:26] %% Willy has left
[15:26] <mangoman> so how would you authenticate the client?
[15:26] <nb> *nod*
[15:26] <theo> Mike Hearn posted a rough draft on his Jabber Auth
Framework idea:
[15:27] <nb> A good authentication solution is the top priority at the
moment in DotGNU.
[15:27] <theo>
http://mailman.jabber.org/pipermail/jdev/2001-October/008864.html
[15:27] <dirkx> mangoman: so you just say: 'this is me and I am cool' -
so you let me in, OK ?
[15:27] <mangoman> sos dirkx
[15:28] <theo> Mike's idea is basically that Jabber would not try to do
an Auth system itself, really.
[15:28] <theo> what Jabber would do with auth is the same it does with
Instant Messaging.
[15:28] <theo> it creates a basic, common, flexible and powerful XML
framework,
[15:28] <theo> and allows others to "plug in" their own auth systems.
[15:29] <nb> But aren't the security / privacy needs of a totally
different magnitude?
[15:29] <theo> yes,
[15:29] <theo> and this is something he is working on.
[15:29] %% mangoman has left
[15:29] <theo> likely, the auth framework would be alot "tighter" than
it is with IM...
[15:29] <dirkx> Well - you 'always' have such a 'trust' question; if
some one auths with someone else - or just has a self proclaimed
identity - when do you beleive him or her.
[15:30] %% ocrampal has joined
[15:30] <theo> requiring things which will block out a few weaker auth
systems.
[15:30] <theo> there are a couple of auth systems that can be plugged
in, likely:
[15:30] <theo> 1. Mike's Ticket Auth system.
[15:30] <dirkx> Traditionally you solve this by a) having a central
authority or b) by letting the receiver of the information build trust
models - based on a CA or on previous experience. i.e. pgp/pkcs
[15:30] * nb nods
[15:31] <rikard> Wouldn't/ shouldn't different Jabber environments have
different security solutions?
[15:31] <dirkx> (Sorry theo: did not want to interupt you).
[15:31] <sibn> pardon me for asking such a simple question, but I've
been sitting here for 10 minutes, and it's not bloody obvious yet.  ;-)
[15:31] <sibn> What is the purpose of this discussion?

[15:31] <theo> Mike's Ticket auth works kind of similarly to Passport,in
that it redirects the user to their Jabber server's website, where they
authenticate, then back to the website they wanted to enter, with a
ticket that could be a cookie or maybe a "Jabber Cookie" or something in
their Jabber client.
[15:32] <theo> sibn: it's to discuss integration of Jabber and DotGNU
(http://www.dotgnu.org)
[15:32] <dirkx> theo: now does it :-) we -go- to a third party at all ?
Why not add something to the web-server- (which you as a site creator
trust and control and manage) and let your server check with someone you
trust ?
[15:32] <sibn> I know what dotgnu is.  I just don't understand what
ground you're attempting to deal with right now.
[15:32] <theo> rikard: exactly. that's why i brought up JENV's.
different JENV's could use different auth plug-ins in this framework.
[15:33] <nb> theo: So one huge advantage over Passport is that everyone,
in particular every ISP, can run an auth server, right?
[15:33] <sibn> Well, I "know" what DotGNU is, meaning 'familiar with the
project.'
[15:33] <dirkx> theo: I am just really confused by this 'forward to
somewhere else' when a P2P network whch is real time enough allows you
to do better.
[15:33] <theo> sibn: right now we're discussing authentication and how
jabber can help.
[15:33] <theo> dirkx: i agree.
[15:33] <sibn> Ok.
[15:34] %% Ben has left
[15:34] <theo> nb: yes, anyone could run an auth server,
[15:34] <sibn> The impression I got was that somebody is aiming for a
central authentication server or something dumb like that.  :)
[15:34] <theo> sibn: nope, not at all.
[15:34] <neiras> Naw
[15:34] <sibn> theo: glad to hear it.  :)
[15:34] <dirkx> theo: a much 'bigger' issue is see (which M$ solves
absolutely wonderfully) is how to work out and -manage- who to trust.
Passport really solves this; trust the gates. And from a practical
perspective that really is a 80/20 solution.
[15:34] <theo> dirkx: i also agree that a real-time IM-based system
could do better, and this is where my "Immer Plan" comes in....
[15:34] <nb> A central auth server farm is good only for MSFT's
business, nopt for anyone else.
[15:35] <Snicker> can we have a framework that is stored on the server,
and run from the client?  i.e. when i log into jabber, it downloads my
auth certificate, and i activate it locally with a key.
[15:35] <dirkx> nb/theo: or you pay your ISP or some third party on a
remote island to be your 'proxy' and cyberwalled on the net
[15:35] <dirkx> and for certain really senstive things you expect them
to contact your cell/phone/IM client for an OK (say before your give
health data on the WebMD site).
[15:35] <Snicker> and then i surf the web "as me"
[15:35] <sibn> nb: and the funny thing being is that that central system
is the target of huge numbers of attacks.  ;-)
[15:35] <nb> One key principle of DotGNU is that there must be nothing
that *forces* you to use any kind of webservice.
[15:36] <theo> Immer is a plan i devised where a user visits a website,
enters their Jabber ID (address@hidden), nothing else, and then
the website sends them a IM. they can "accept" or "reject" to this IM,
telling the website that yes, they really are the person who's at their
website right now.
[15:36] <nb> Whenever there is a webservice (such as single-login) the
end-user must be made capable of running it on their own PC.
[15:37] <dirkx> theo: we have mod_auth_jabber_im.c here at
research.covalent.net which does exactly that and plugs into apache :-)
it is very effective.
[15:37] <dirkx> theo: espcially if you are in europe and can send a SMS
message with a WML 'ok' :-)
[15:37] <theo> now, with the Immer plan, you could have your JID stored
in your browser, so whenever you visit a website, you could
automatically be asked if you are the one visiting, by IM.
[15:37] <theo> dirkx: excellent!!!
[15:38] <theo> i'll want to work with you on that  :)
[15:38] <theo> but, the point will be that both of these, and more, Auth
systems can be fit into Jabber,
[15:38] <theo> and be interoperable with each other.
[15:39] <Snicker> but what will keep a hostile "web service" site from
getting your personal information at will?  if they know your ID...
[15:39] <nb> Will it be a problem to get the needed code under GPL?
[15:40] <dirkx> theo: or you could tie that IM to a cookie the web site
trusts - so you can do it even nicer - with existing browsers
[15:40] <Snicker> if i have that information (on my machine), i can give
them what i want.  but if they are connecting to another site, how do i
control that?
[15:40] <theo> Snicker: that's where Profiles and Access Control come
in. currently in jabber, all info that is public, is public to everyone.
i want to change it where you can restrict access to only those people
you want...
[15:41] <dirkx> snicker: a user should only give his or her information
to a party its trust. Including the auth server.
[15:41] <dirkx> So ultimately the user controls who gets data to give to
others; and to do that thre needs to be
[15:41] <theo> nb: still not sure about getting the existing Jabber Open
Source Server code under GPL.
[15:41] <Snicker> theo: so i specify in my jabber profile that i only
want Amazon to have my CC#?
[15:41] <dirkx> enough trust. So it might be that some, say, ISP offer a
'gold' service where you ahve to press
[15:41] <dirkx> 'OK' on your PDA before it releaes your address.
[15:41] <theo> i don't think we'll be able to get the entire JOSS
re-licensed under the GPL,
[15:42] <theo> but we might be able to get certain individual
programmers to re-license their own woks on it...
[15:42] <dirkx> snicker: that means you need to trust the auth server to
implement your profile correctly and honestly.
[15:42] <theo> Snicker: yep, exactly. and even then they may have to ask
your permission through IM each time they want to get it.
[15:42] <nb> I've been thinking that we really need the
Jabber::middleware parts only.. is that right?
[15:42] <Snicker> right, but i still don't have "control".  trust is a
tough word in the internet world.
[15:43] <theo> nb: possibly. i'm not that familiar with the internals of
the JOSS....
[15:43] <theo> but,
[15:43] <theo> i will say that it is incredibly easy to make a Jabber
server.
[15:43] <Snicker> i still think it's safer if my profile is only
"active" when i am logged in and surfing.  and then used only at my OK.
[15:43] <nb> Snicker:  That's exactly why DotGNU can compete with
Microsoft in this area....
[15:43] <theo> especially if you only want the middleware aspects.
[15:44] <rikard> snicker: control?
[15:44] <theo> also, nb, you could take a look at Jabelin.
[15:44] <Sunshine> dirkx: logged into research.covalent.com.  Nice!
Wish I could start browsing some files now...
[15:44] <nb> people will trust  Free Software with publicly-available
source code much more than any service from Microsoft.
[15:44] <theo> Jabelin is basically JOSS 2.0, and is being re-written
from scratch to do middleware.
[15:44] <theo> www.jabelin.org
[15:44] <dirkx> snicker: that depends; what if the jabber auth server
runs on your local machine - on your machine at home or opn an ISP you
trust ?
[15:44] <Snicker> rikard: anything on a server is not under my direct
control if other wen services can authenticate and pull info without me
knowing.
[15:45] <Snicker> dirkx: that sounds better.
[15:45] <theo> Snicker: i'll address this near the end of the Agenda,
with P2P  :)
[15:45] <nb> What do you think, could we get that dual-licensed under GPL?
[15:45] <dirkx> snicker: I fully expect 'proxy'ies (in the legal sense
of the word) to spring up as 'notaties' and offer such services.
[15:45] <theo> ok, i'll talk with Mike more over the next week to get a
better JabberAuth Framework from him.
[15:46] <theo> and that covers the basics of the Jabber Auth.
[15:46] <nb> Another option would be for Mike to come to the
address@hidden mailing list...
[15:46] <theo> those two Auth plugins we discussed (Tickets and Immer)
can also be used for Single Sign In.
[15:46] <Sunshine> nb: code is already dual-licensed
[15:46] * theo has changed the topic to: Single Sign In
[15:47] %% kb0old has joined
[15:47] <Sunshine> in a fashion
[15:47] <nb> maybe he'd like to start an official project for his stuff
within the DotGNU meta-project.
[15:47] <theo> Suinshine: really? what code? JOSS or Jabelin?
[15:47] <Snicker> i like the P2P idea of being able to control access to
my resources.  (that's the security we need)  i think it may be a solid
model to store the profile on a server (the access anywhere problem),
and then download and activated when i want to use my web service.  then
everything is under my control.  no trust issues.
[15:48] <neiras> YOu could do it both ways... Store your profile info on
your own computer, OR on a service provider's server
[15:48] <Snicker> right, but only active when i need it to be.  that
protects me from the hackers.
[15:48] <neiras> There you go
[15:49] <theo> Single Sign In is the ability for a user to have a master
account that is used whenever they visit a website or application to
automatically sign them in, without having to fill in a username and
password, and especially without having to register by creating a new,
local account.
[15:49] <rikard> what's the single sign-in issues?
[15:49] %% kb0old has left
[15:49] <neiras> And it creates an opportunity for commercial identity
storage =)
[15:49] <dirkx> neiras: or one level at the ISP, one level at home and
one level on the PDA you carry with you. Think of the SIM cards in GSM
phones :-)
[15:49] <neiras> EXACTLY.
[15:50] <theo> Both of the before-mentioned Auth systems (Tickets and
Immer) can be used as a Single-Sign-In system.
[15:51] <theo> Just store your JID in your browser somehow, and it's
automatically picked up by websites that then try to authenticate you
via your preferred method.
[15:51] <dirkx> theo: (just poking fun a bit) - why should I sign in at
all if -at will- I can assert my identity - and the receiving party can
validate it with the trust level it wants/needs/desires ?
[15:51] <theo> dirkx: correct,
[15:52] <dirkx> theo: should it be a 'JID' - how a bout a routable
cookie - almost like a JID. I think you are making this already very
strong/revealing :-) :-) :-)
[15:52] <theo> dirkx: not everyone will use SSI. it's just a
"convenience feature", really.
[15:52] <nb> Yes...
[15:52] <theo> it should be a JID, but the good news is that Jeremie
Miller made an "annonymous login" feature a few weeks ago,
[15:53] <dirkx> theo: I was *not* thinking SSL - I was thinking 'token's
rather than a JID. Say the equivalent of a 'reverse lookup' in DNS -
which you trust cuase 'verisign is at the top'.
[15:53] <theo> that creates a "dummy JID" for you....
[15:53] <theo> this can be used.
[15:53] <dirkx> Actually that is ICANN - just as trustworthy.
[15:53] <nb> however Microsoft is working hard on building up the kind
of momentum that will allow them to push it down into everyo internet
user's throat.
[15:53] <theo> dirkx: I said SSI Single Sign In  :)
[15:53] <sibn> Well, seeing as how I don't have much to offer to the
discussion, it was nice listening in.  cya later.  :)
[15:54] <theo> sibn: oh, well thank you. i will be talking about P2P in
a bit, though.
[15:54] <nb> How will you store that JID in the browser if Microsoft
doesn't want it to be stored there?
[15:54] <dirkx> Right - but what -is- sign in - it is just asserting you
are who you say you are - and especially when you come around *next*
time you are still the same person - or if you show up somewhere else -
you are still that identity too. Or at least the management of that.
[15:55] <theo> well, in IE, it could be done as a cookie readable by the
website...
[15:55] <nb> dirkx: It's also about being able to give the side your
credit card number conveniently.
[15:55] * sibn will hang about for now, then.
[15:56] <nb> dirkx: side=site
[15:56] <theo> dirkx: correct, Single Sign In isn't much, really. it's
just the ability to be signed in to servicesd without having to do
anything extra. the ability for the website to authenticate you off your
jabber account oinstead of requiring you fill inh a username and
password with them...
[15:56] %% neiras has left
[15:56] <dirkx> nb: or a token with they can prsent elsehwere (at a
broker) which causes you to give the credit card #
[15:57] %% neiras has joined
[15:57] <nb> diskx: yes.
[15:57] <theo> yep to both  :)
[15:57] <theo> ok, that wraps up SSI.... now Profiles and Access Control
[15:57] * theo has changed the topic to: Profiles and Access Control
[15:58] <theo> Jabber will soon have a sim[ple Profiles system.
[15:58] <theo> Profiles is basically a "set" of related personal
information.
[15:58] <theo> A Credit Card Profile with your CC#, expiration datre,
name on card, bank, etc....
[15:59] <theo> a Bookmark Profile, with your browser's bookmarks, stored
in your Jabber account.
[15:59] %% Snicker has left
[15:59] %% Sunshine has left
[15:59] %% dirkx has left
[15:59] <theo> the good thing with Jabber's Profiles is we provide just
the basic framework, and allow everyone else to defined what profiles
they have, and what XML schemas are used.
[16:00] %% allgaier2 has joined
[16:01] <theo> hello?
[16:01] <nb> So everyone can define an XML schema, stick it on a
website, and voila.  Cool.
[16:01] <theo> ok  :)
[16:01] <ocrampal> yes...
[16:01] <theo> nb: yep.
[16:01] <theo> and this is also where Jabber Environments can play again.
[16:01] %% dirkx has joined
[16:01] <theo> JENVs could help defines these Profiles and what Schemas
should be used,
[16:02] <theo> to keep the Framework clean,
[16:02] <theo> yet still provide the security and stability of
pre-defined schemas.
[16:02] <allgaier2> (hi guys.  i'm liking the "IM me when someone wants
to access my data" idea more and more)
[16:02] <dirkx> nb/theo: and if you had enough of a language - others
could actually 'understand' your own 'profile'.
[16:02] <theo> allaier2: yep, i really like it too  :)
[16:03] %% allgaier2 is now known as Snicker
[16:03] <theo> dirkx: yep, they could.
[16:03] <theo> also,
[16:03] %% x-virge has joined
[16:03] <Snicker> (sorry, lost the conference for a minute)
[16:03] <theo> Jabber will soon have a basic Access Control system,
[16:03] <theo> which could be used to grant/restrict access to these
Profiles to certain individuals, based on JID.
[16:03] <theo> Snicker: yes, i saw 3 people drop off at once.
[16:04] <nb> Will this address the problem of spam?
[16:04] %% mike has joined
[16:04] %% mike is now known as boat pants
[16:04] <theo> nb: i have two ideas how to handle spam.
[16:04] <theo> one is Razor: http://vipul.net
[16:04] <dirkx> nb: you eat it.
[16:05] <theo> but spam is a topic for another day, possibly the next conf.
[16:05] <sibn> spam is good broiled, fried, baked, chocolate covered,
steamed, and even in some cases, cold.
[16:05] <Snicker> i think we have the technology and ideas to make this
a real competitor.  i think our bigger challenge is industry support.
[16:05] <theo> that wraps up all questions for Profiles and Access
Control? i just wanted to bring those up to show everyone what Jabber
will be capable of soon.
[16:05] <Snicker> that's probably a discussion for another conference....
[16:05] <theo> Snicker: yep, i agree.
[16:05] <theo> ok, next,
[16:06] <theo> P2P...
[16:06] * theo has changed the topic to: Jabber's P2P future
[16:06] <nb> Snicker: DotGNU has made some high-level industry contacts...
[16:06] <Snicker> that's good.
[16:06] <nb> as soon as we know what we're building, I can get some very
interesting things going.
[16:06] <theo> I, personally, am dedicated to seeing Jabber support a
fully P2P architecture.
[16:07] <Snicker> i hope so.
[16:07] <theo> it will take a lot of work, since Jabber is heavily in
the traditional client/server model,
[16:07] <theo> but I think it can be done, and should be done.
[16:07] <x-virge> theo: well, we have talked about this before
[16:07] <x-virge> theo: you just move the server to the current jabber
"clients"
[16:07] <theo> my plan for P2P in jabber is not to *convert* to p2p, but
instead *add* p2p to jabber's arch.
[16:08] <nb> makes sense
[16:08] <x-virge> theo: then not only do you have a more p2p nature, but
you can very easily have multiple logins from the same system with one
connection out
[16:08] <theo> x-virge: yep, but there is the matter of addressing and
location...
[16:08] <rikard> x-virge: is that doable?
[16:08] <Snicker> fully P2P takes away "access once anywhere" nodel.
[16:08] <theo> rikard: yep, very doable.
[16:08] <Snicker> model
[16:08] <x-virge> theo: and normal p2p isn't?
[16:08] %% xsee has left
[16:09] <theo> i plan to look into the p2p thing alot in a month, and
have something out soon after that.
[16:09] <x-virge> theo: you move the server to the "client", then
servers can have lists of "trusted servers" (formerly clients) which
they can store-forward for, like email
[16:09] <theo> just wanted to let everyone know i am sure P2P is very
possible in Jabber, and will be a direction it takes soon.
[16:10] <theo> x-virge: very true. it will be alot easier than i'd thought,
[16:10] <x-virge> theo: doing it this way is doable now. just requires a
little hacking on the server
[16:10] <rikard> so a server becomes a normal node?
[16:10] <x-virge> theo: I can run a jabberd for myself :)
[16:10] %% tweedledee has joined
[16:10] <x-virge> rikard: well, sort of
[16:11] <tweedledee> yo
[16:11] <tweedledee> oww
[16:11] <x-virge> rikard: basically, if you have a bunch of apps on the
same machine which are jabber clients
[16:11] <Snicker> we still need the information stored on a server
somewhere.
[16:11] <theo> tweedledee!
[16:11] <tweedledee> there are a lot of people here
[16:11] <theo> everyone, this is Mike Hearn, of Jabber Auth.
[16:11] %% tweedledee is now known as Mike
[16:11] <Mike> Yo
[16:11] <x-virge> rikard: instead of all talking to an outside server,
you talk to what's more like a daemon
[16:11] <x-virge> rikard: but it's really just the normally outside
server running locally
[16:11] <Mike> for people who can see formatted text, i'm in the blue
tonight
[16:12] <x-virge> Snicker: yeah, so you have servers of servers ;)
[16:12] <ocrampal> hi
[16:12] <rikard> x-virge: lol, thx
[16:12] <theo> x-virge: i see. very nice. will be alot easier, then...
[16:12] <Mike> hmmmm. where are we up to?
[16:12] <nb> Hi, Mike, this is Norbert, address@hidden , very
interested in your Jabber auth stuff for DotGNU.
[16:12] <x-virge> theo: not just easier. there's not a whole lot to be
done this way :)
[16:12] <Mike> we should really have Chatbot here. Hi Norbert, I've
heard of you, pleased to meet you
[16:12] <x-virge> theo: as opposed to coming up with some kind of
protocol, having to hack up clients *and* servers, etc
[16:12] <theo> hehe..., thanks, x-virge. all it needs doing is
implimenting, then...
[16:12] <x-virge> theo: this just involves hacking the server
[16:13] <Mike> theo: what's this about:
[16:13] <Mike> ?
[16:13] <theo> yeah, i wanted ChatBot, too, but i couldn't get him to
get up...
[16:13] * Mike chuckles
[16:13] <theo> mike: this is dotgnu and jabber integration,
[16:13] %% ruud has left
[16:13] <rikard> mike: p2p
[16:13] <theo> specifically talkling about how jabber can provide auth
for dotgnu....
[16:13] <theo> and specifically right now p2p.
[16:13] <Mike> right. I haven't read much about dotgnu
[16:13] <Snicker> "Jabber's P2P future"  ;o)
[16:14] <theo> but the p2p is about to end until next meeting.
[16:14] <Mike> ok. Well in the past few weeks I've been finalizing the
design for Jabber auth in my head
[16:14] <theo> cool.
[16:14] <Mike> I've started learning what I'm going to need to learn to
make it
[16:14] <theo> could you talk about it here? we just wrapped up with the
Agenda, although want to bring up the Mono/DotGNU connection before we end.
[16:14] <Mike> so, i'll lurk for a bit until people want me to start spout
[16:15] <Mike> ok, righty-ho
[16:15] <Mike> fairly quickly, I think I've covered this before
[16:15] <theo> start spouting now, it's your turn  :)
[16:15] <theo> ok, can't hurt to go again in detaiul, though  :)
[16:15] <Mike> Basically, it is MS Passport but decentralised and nicer
features
[16:15] <rikard> theo: if it's not too much to ask for, could you make
the agenda for next week a bit more specific as to what we're trying to
accomplish at the meeting.
[16:15] * nb listens very attentively
[16:15] <Mike> Can I just ask, are the people here familiar with pp?
[16:15] <theo> rikard: certainly. good idea. will do.
[16:16] <ocrampal> Firefly :-)
[16:16] <theo> passport, you mean?
[16:16] <Mike> yep
[16:16] <Mike> well, i'll cover how it works now
[16:16] <rikard> theo: thx
[16:16] <theo> i am, dunno about others, tho.
[16:16] <theo> ok, good.
[16:16] <Mike> The central idea is that the site/service requesting
authentication should _not_ ever see the users credentials
[16:17] <Mike> btw, credentials are what the user uses to prove their
identity
[16:17] <Mike> so it would be passwords, but in the future it could also
be retina-scans for instance
[16:17] <Mike> Now with a web site we have to use a few tricks to get
around various features of the web
[16:17] <dirkx> Mike: (assuming that credenticals can be opaque) is it
not -see- credentials ? or not be able to (re)use credentials and/or
learn anything from them ??
[16:18] <Mike> namely - cookie security, which prevents one site from
reading the cookies of another, and the fact that web browsers were
never designed with distributed auth in mind, so for instance they have
no inbuilt hashing features
[16:18] <Mike> when i say see, i mean this
[16:18] <Mike> Web sites will never actually get the credentials in any form
[16:18] <Mike> for services, they may get a hashed version of the
credentials but that value is essentially opaque - you can't get the
original credentials back or reuse the has
[16:19] <Mike> services are other things you might want to auth with -
for instance FTP servers
[16:19] %% neiras has left
[16:19] <Mike> So, if we deal with websites first, as that is I think
the one of the key "battlefields" for any auth system, and it is also
where the greatest need is
[16:19] %% neiras has joined
[16:19] %% pojo has joined
[16:19] <nb> yes
[16:19] <Mike> sorry, i'm being a little incoherent, it's late here :)
[16:20] <Mike> What happens (although this design may/will change
without notice) is this:
[16:20] <Mike> the User goes to a web site (A) and wishes to login. They
have never logged into their account on the web before
[16:20] <theo> mike: you are doing fine.
[16:20] <Mike> the site A has a little edit box somewhere discreet, and
a sign in button/image. Unlike Passport there are no restrictions on
this, it can be tailored to fit with the site design
[16:21] <Mike> So they enter their network address/jid, in my case
address@hidden
[16:21] <Mike> and click Login. What happens then is that their jid
(i'll use that term here 'cos it's shorter, although this system is not
necessarily jabber centric) is submitted to a CGI
[16:22] <Mike> That cgi connects to the host specified in the users JID
either via Jabber or HTTP (exact bindings haven't been finalised yet)
[16:22] <Mike> It then sends/receives SOAP messages that say in XML the
equivelent of
[16:23] <Mike> - User wants to sign in. Does this host support web auth,
and if so what should I do?
[16:23] <dirkx> so -> web site 'A' who wants to participate needs to a)
have some code/logic and b) trust of the auth '@jabber.com' they talk
to; and c) the site 'A' gets not just a token - but an idenfifier.
[16:23] <Mike> - the Host (address@hidden) then replies "yes, I support web
auth. User is not signed in"
[16:23] <Mike> dirkx: yes basically. I haven't factored a trust network
into this due to the additional complexity this provides
[16:24] * Mike deviates slightly for a moment
[16:24] <dirkx> mike: is fine - I am just trying to understand this as
exacting as I can. no worries.
[16:24] <Mike> I'm assuming a world that is realistically like todays:
accounts are free, so trusting users  is largely meaningless when anyone
can have as many accounts as they like
[16:24] <Mike> so although there is a gap that says "trust goes here",
it's not filled yet, if you see what i mean
[16:24] <Mike> anyway, where was i.... oh yeah
[16:25] <Mike> - So, having got this reply, A then says: "I want to web
authenticate User, using the template page at
http://site.com/template.html, my display name is Nice Organisation etc"
[16:26] <Mike> so it passes any information needed in the original soap
message. It also passes a return-url that points to another CGI
[16:26] <Mike> I'll come to that in a moment......
[16:26] <Mike> Host, having received the information says "OK, just HTTP
redirect the user to this address: http://host/signin?id=0193483953";
[16:26] <Mike> the number is just a transcation ID really, can be a hash
of the time or whatever, or just randomly generated
[16:27] <Mike> the user then sees the signin page. This can be done over
an SSL link if wishes
[16:27] %% sibn has left
[16:27] <Mike> So - they enter their credentials (password), but again,
if wanted there's no reason an applet couldn't be used to do voiceprints
or whatever. For now, I'll assume passwords
[16:28] <Mike> The Host authenticates them. Host doesn't have to be a
jabber server, it just has to speak the lingo. But Jabber already has
the auth stuff in place, as well as decent message passing etc, which is
used later in IM auth (i'll explain that in a sec)
[16:28] <dirkx> template.html -> lets hope it has no java script :-) /
also user expects to be forwarded by 'A' to the 'right' place. Rather
than to 'A's proxy to the right place.
[16:29] <Mike> Yes, however the Hosts CGIs could strip javascript or
whatever. Basically some form of "co-branding" as Passport calls it
[16:29] <Mike> And again, if SSL was used then proxying would be harder.
However, this attack could indeed take place.
[16:30] <Mike> I'll defend it against wouldbe hackers in a moment..
[16:30] %% Snicker has left
[16:30] %% dirkx has left
[16:30] <Mike> Anyway, once cleared the Host redirects the user again to
the original return-url. The return-url contains a very long and
essentially unguessable number (could be encrypted data or whatever)
[16:31] <Mike> basically this URL is what proves to the Site that the
user is authentic. The only way of getting to that address is to
authenticate with the server essentially
[16:31] <theo> eek!
[16:31] <Mike> what's up adam?
[16:31] <theo> i got to leave in a coup[le of minutes for work. wow,
this meeting's lasted for 1 1/2 hours already  :)
[16:31] <Mike> hehe. I'll be quick
[16:31] %% dirkx has joined
[16:31] <theo> np,
[16:32] <theo> if you want to finish up the meeting when i leave,
[16:32] <theo> you can do that.
[16:32] <Mike> OK, once the user is back to the Site, more cookies are
set (this is optional btw) so that once signed in the user doesn't have
to do it again
[16:32] <Mike> this is essentially about convenience with security, not
the other way around
[16:32] <Mike> ok. almost done
[16:32] <theo> ok,
[16:32] <Mike> so that's the web.... service is similar
[16:32] <theo> :-)
[16:32] <Mike> in this case for instance an FTP server wishes to
authenticate...
[16:33] <Mike> The Host in this case MUST be jabber/auth aware, the
client MAY be
[16:33] %% allgaier2 has joined
[16:33] <Mike> if the client is aware, then hashing can be used to hide
the auth (with sesh ids to prevent replays of course)
[16:33] <Mike> if the client is not auth aware (a legacy client for
instance) then IM authentication is used
[16:33] <Mike> this relies on the Host being a Jabber server, and the
user having an IM client signed in.
[16:34] <theo> yep, i explained the Immer ppan earlier.
[16:34] <Mike> the presence of an already authenticated connection is
used ... the user is sent a message with a form embedded in saying
"Please authentication"
[16:34] <Mike> if they click OK, away you go
[16:34] <Mike> ok, that's it in a nutshell
[16:34] * Mike breathes
[16:34] <dirkx> So woudl it be fair to see that in order of make sure
that absolutely no client code is needed (see a small IM in the corner
of the screen) this system gives a fair chunk of flow control to 'A' -
the webserver you auth with - and only to make sure that with the
credentials/ID it does not get a (re)usable password ?
[16:35] <nb> How does it fit into this framework to make an email
address and/or credit card number available to the webservice provider?
[16:35] <Mike> yep
[16:35] <theo> Access Control?
[16:35] <Mike> nb: once authenticated, authorization can take place
[16:35] <Mike> this would allow access to the users information, web
services etc.
[16:35] <theo> yep,
[16:36] <Mike> Authorization fits into that plan. Somewhere. Or at 
least, it will do soon
[16:36] <theo> we are doing access control and athorization stuff in our 
Profiles-JIG.
[16:36] <Mike> dirkx: basically yes. It's a compromise, but it'll work 
with todays technology
[16:36] <Mike> Indeed. I'm thinking perhaps we should roll that into the 
web services stuff
[16:36] <Mike> when you see how it's being done with .NET, it makes more 
sense that way methinks
[16:37] * Mike goes back to reading the AOL top ten chatup lines for a 
moment
[16:37] <Mike> <grin>
[16:37] <nb> I think this project fits into DotGNU very well :-)
[16:38] <dirkx> mike: Hmm - since the website
[16:38] <dirkx> 'A' has to add logic
[16:38] <Mike> hmm yes. I am however keen that it shouldn't be tied to 
hard to any one system
[16:38] <Mike> Yep, the logic is on the server side rather than client 
side. However, servers are generally easier to upgrade than clients, right?
[16:38] <dirkx> I'd rather go for something like an auth module inside 
(apache) the web server. And then work out
[16:39] <Mike> I am designing it so that it doesn't even rely on Jabber
[16:39] <dirkx> a way of not giving site 'A' too much replay ability. I 
am more than a little
[16:39] <Mike> tho that'd make the most sense in terms of implementation
[16:39] <dirkx> worried about the routing control of 'A' and the trust 
required.
[16:39] <Mike> you mean the fact that A must redirect to the login server?
[16:39] <theo> ok, all, i'm heading out. feel free to keep chatting till 
the last person leaves  :)
[16:39] <Mike> i seem to remember that being a criticism of Passport 
too, if you could somehow redirect a user to a fake login screen..
[16:39] <theo> i'll post the logs to the lists when i get back.
[16:40] <Mike> ok, cya adam
[16:40] <Mike> have a good day at work
[16:40] <theo> thanks  :)
[16:40] <rikard> cya, and thanks adam
[16:40] <Mike> yep, thanks
[16:40] <nb> There's a link to an article with some criticisms of 
passport on the dotgnu.org website.
[16:40] <Mike> I have read it yes. Some of the points I don't agree with
[16:40] * nb thanks adam
[16:40] <dirkx> mike: nost just that - but a whole range of issues; 
cross site scripting is just one of them; proxy control. Basically it is 
tying the 'dog' to the 'bone'. Too many tempations.
[16:41] <Mike> In particular, if you could have enough control of a 
connection to reroute someone to a fake site, you'd probably have enough 
control to read the credentials off anyway
[16:41] <Mike> dirkx: the template.html was just an example. Passport 
actually uses a script for the template generation if i remember
[16:41] <dirkx> Now take the other side; say you had a list of one time 
passwords.. and you would look at, say, mod_auth_IM.c in apache - then 
you could do a lot of this - fully secure without any of the trust stuff 
required - and wihtout the opportunity.
[16:41] <Mike> the main problem is - how else do you stop A getting the 
credentials
[16:42] <dirkx> mike; that one time passport is too extreme - but just 
to start at the other end of hte tradeoff.
[16:42] <Mike> yes, but then you don't get the single signon really?
[16:42] <dirkx> mike: by not giving A the credentials !
[16:42] <Mike> one of the main advantages to this really from the end 
users perspective is that once signed in, they don't have to do it again
[16:42] <dirkx> mike: joking aside; you do not want to give 'A' too 
mucjh - just enough to *confirm* your identity with a backend. You could 
give it a signed digital number if you
[16:43] <dirkx> bnoth strusted the same backend.
[16:43] <Mike> instead of an address you mean?
[16:43] <dirkx> Right - say you ran a local www proxy through which your 
request swhere going and which *always* added a cookie. say 
address@hidden; foo=12348978923
[16:43] <dirkx> then the server could auth and take it from there. (just 
trying to be creative :-).
[16:44] <Mike> hehe. And how do you explain to my mum that she has to 
run a local proxy?
[16:44] <Mike> and therefore can't sign in from work?
[16:44] <Mike> Many sites ask for email addresses actually
[16:44] <Mike> it works similar to this already
[16:44] %% lansea has joined
[16:44] %% loppear has left
[16:44] <Mike> You can often get your password emailed to you
[16:44] <Mike> so the trust there is with the email provider. They 
assume that your email account is secured
[16:44] <dirkx> yes I know :-) I was just taking an extreme. But for 
example if your mum ran the IM already then it becomes a differnt kettle 
of fish.
[16:45] <Mike> True. We considered this at the start
[16:45] <Mike> using an IM client to do the authentication
[16:45] <Mike> and this is still a part of it, but it's too hard to 
ensure that the IM client is on the same box at the web browser in 
practicality
[16:45] <Mike> without strong IM/browser integration anyway
[16:46] <Mike> that's the sort of thing MS can pull off but we can;t
[16:46] <Mike> I'm surprised MS haven't thought of this already 
actually. They're being a little slow off the mark there.
[16:47] %% harvestmoon has joined
[16:47] <rikard> mike: hasn't thought of what?
[16:48] <Mike> tying MSN messenger to IE6 - so for instance, instead of 
using a nasty old web based form to authenticate, sites simply send a 
message to MSN Messenger saying "is the user trying to sign into this site"
[16:48] <allgaier2> the passport is integrated in both.  signing in to 
MSN IM also signs you into the "website" passport
[16:48] <Mike> The MSN Messenger can confirm it
[16:48] <Mike> assuming your MSN Messenger password is safe, you've got 
true single-sign-in without all the cookies/HTTP redirects involved
[16:48] <dirkx> (note) I do not want to attack the system proposed - I'd 
just like to figure out how 'hard' the required trust of A is.
[16:48] <Mike> allgaier2: they both use passport yes. but signing into 
msn messenger doesn't do web auth too
[16:48] <Mike> that is separate
[16:49] <Mike> dirkx: sure, don't worry about it
[16:49] <rikard> ahh now i get it
[16:49] <Mike> i attack my own plans too
[16:49] <Mike> basically yes A is trusted to redirect properly
[16:49] <allgaier2> it does!  i promise!
[16:49] <Mike> theoretically, if A sent a user to a fake website it 
could get the password
[16:49] <ocrampal> :-)
[16:49] <Mike> allgaier2: hmm, maybe you are right. I'll check that now 
i think
[16:50] <Mike> but this is unlikely, especially if secured. For 
instance, the page could say "Please check the padlock is lit"
[16:50] <Mike> or something
[16:50] <dirkx> mike: but they Im does nto need to be at the same place. 
It needs to be somewhere :-) so for your mum or cheap ISP account it 
could be a simple YES if thje password matches - in other casses is more 
explicit 'YES' on an IM client or a one-time-password send to you to 
enter (4 digit pin).
[16:51] <Mike> sure. I'm not keen on one-time passwords though
[16:51] <Mike> it reduces the convenience of ssi
[16:52] <rikard> mike: next time i'm thinking of talking about something 
related to the IM-WWW integration -> authentication transports, which 
would allow a jabber-dotgnu user to use our authentication for sites 
that hasn't become a part of the jabber-dotgnu network yet. Any thoughts?
[16:53] <Mike> do you mean, how to support legacy websites?
[16:53] <dirkx> mike: you have levels - again it could be just your user 
ID and the password is the IP address you are coming from or a static 4 
digit pin :-)
[16:54] * Mike is lost
[16:54] <Mike> sorry, where would the pin be used again?
[16:54] <Mike> allgaier2: heh, interesting. It sort of did
[16:54] <Mike> allgaier2: I logged into the MSN client, then went to 
passport.com - it said i wasn't signed in
[16:54] <Mike> when i went to Hotmail, it signed me in automatically. 
When I refreshed the passport.com page, i was signed in
[16:55] %% harvestmoon has left
[16:55] <Mike> I think it might use some kind of client side scripting 
to do that - i've seen webpages accessing my msn contacts list before :( 
very poor security but there you go
[16:55] <allgaier2> right.  you are right, it's a partially integrated 
schema
[16:57] %% ocrampal has left
[16:57] <Mike> what i was talking about though was actually using the im 
program to check the user is authentic
[16:57] <Mike> rather than the im software signing me into the web 
system directly
[16:58] <nb> Does this kind of thing make it impossible to have an IM 
spam filter?
[16:59] <Mike> how do you mean?
[16:59] <Mike> i don't see how, tho it depends on the definition of spam
[17:00] <nb> If the website can send me an IM, does that mean that *any* 
website can send me an IM like "50% discount today"?
[17:01] <nb> And if I try to filter out such spam, maybe the 
confirmation IM doesn't get through anymore?
[17:01] <Mike> yes, in the same way that given an email address, any 
site can send you spam
[17:01] <Mike> however, jabber has pretty thorough filtering support
[17:01] <Mike> so you can easily block users if they spam you
[17:01] %% x-virge has left
[17:02] <Mike> if a company does that - it's going to lose customers 
pretty quick
[17:02] <Mike> actually no, bearing in mind that the confirmation IM 
would come from the auth subsystem
[17:02] <Mike> not the site
[17:02] <nb> Ahhh..ok, that's good.
[17:02] %% xsee has joined
[17:03] * Mike is just playing with passport now
[17:03] <Mike> they've changed it since last time i looked
[17:03] <Mike> now you have to sign into each site manually
[17:03] <Mike> which is a good fix i think
[17:03] <rikard> why is that good?
[17:04] <Mike> before every Passport site would automatically redirect 
you to the central servers before you even hit their front page
[17:04] <Mike> this meant if the passport servers died, so did every 
site using it
[17:04] <Mike> it also meant any site could work out who you were 
without you being able to stop them
[17:04] <nb> In that case, an intelligent client software could realize 
that you're trying to login to a certain site, intercept that IM, an 
dreply to it... while if you don't have an intelligent client, you can 
still confirm the IM manually.... right?
[17:04] <Mike> now, you click Sign in manually, and it's completely 
automatic still, but more secure
[17:05] <Mike> nb: exactly
[17:05] <Mike> hence the IM/browser integration i was talking about earlier
[17:06] * nb nods understandingly
[17:07] * nb yawns
[17:08] * Mike yawns too
[17:08] <Mike> 22:11 here
[17:08] <nb> Thank you so much for sharing about this!
[17:08] <nb> It's getting late here.
[17:08] <nb> 23:11 here.
[17:08] <nb> Where are you?
[17:08] %% pojo has left
[17:09] <Mike> where are you based?
[17:09] <Mike> no probllem
[17:09] <Mike> and for my next trick - a working implemenatation
[17:09] <nb> near Zurich, Switzerland
[17:09] <Mike> good stuff
[17:09] <Mike> i'm in england
[17:10] <nb> great... we're on the same continent! :-)
[17:10] <Mike> hehe
[17:10] <nb> What language are you planning to use for this?
[17:11] %% sabby has left
[17:13] %% Mike has left
[17:13] %% tweedledee has joined
[17:14] <tweedledee> prolly perl
[17:14] <tweedledee> it'd help if i knew c
[17:14] <tweedledee> it'd help if i had a local jabber server to test it 
with too
[17:14] <tweedledee> but family pc you know, so can't really install 
Linux at the moment, and Cygwin doesn't work :(
[17:14] <nb> :(
[17:15] <tweedledee> With perl you can write server plugins quite easily 
though. I just have to get Adam to set up theoretic.com for me
[17:15] <nb> For use with DotGNU, Perl is not ideal...
[17:15] <nb> Would Java work for you?
[17:16] <tweedledee> possibly
[17:16] %% pojo has joined
[17:16] <tweedledee> i don't know what the jabber support in java is like
[17:16] <tweedledee> ditto for soap
[17:16] <tweedledee> pretty good i'd think
[17:16] * nb nods
[17:16] <tweedledee> what's wrong with perl though?
[17:16] <tweedledee> as this will have a website component to it, as 
well as HTTP/SOAP perl has good support for that sort of thing
[17:17] <nb> Perl6 will be ok as soon as their bytecode engine has been 
ported to become a plugin for DotGNU SEE...
[17:18] <nb> but that's still in the pretty distant future.
[17:18] <tweedledee> ah
[17:18] <tweedledee> how would java plugin to it then?
[17:18] <tweedledee> i am still a little hazy on DotGNU
[17:18] <tweedledee> the actual .NET CLI looks to be pretty good really
[17:18] * tweedledee looks at the passport source code
[17:18] <nb> There will be support for that, and also for Java bytecode.
[17:18] <tweedledee> yuck. they actually use javascript timeouts!
[17:19] <tweedledee> hmm ok
[17:19] <tweedledee> well I have no objection to learning Java
[17:19] <tweedledee> it'll take longer, but i suppose is more portable 
than perl
[17:20] <nb> Java has it's own set of problems...
[17:20] <nb> with the Free java compilers not having quite caught up 
with Sun's newest stuff...
[17:21] %% neiras has left
[17:21] <tweedledee> yeah. Well to be honest, as a quick 
proof-of-concept thing i'll prolly stick with perl. The protocols are 
the important thing anyway, and so a Java implementation afterwards 
wouldn't be hard
[17:21] <nb> but if you can make it work with them (i.e. not using the 
very newest features) then you're very portable.
[17:22] <nb> That's fine.
[17:22] <nb> I'd do the first quick-and-dirty implementation in Perl 
too, myself.
[17:23] <nb> Because I know that anything I write will need a good 
rewrite after I understand the matter better :-)
[17:23] <tweedledee> yep
[17:25] <nb> BTW if you need any server-side resources for testing a 
jabberd or whatever, you can do that kind of thing on my backup server.
[17:25] %% rikard has left
[17:26] <tweedledee> nb: cool thanks
[17:26] <tweedledee> i might just take you up on that
[17:26] <tweedledee> adam is helping me at the moment, but i'm new to 
this sort of development
[17:27] <tweedledee> so any spare jabber servers going anyone are 
greatly appreciated! :)
[17:30] %% lansea has left
[17:31] <nb> I think I'm going to call it a day :)
[17:31] <tweedledee> me also.
[17:31] <tweedledee> good to talk to you guys
[17:31] <tweedledee> but i must go sleep
[17:31] <nb> Good night, everyone!
[17:31] <tweedledee> night
--
    /\    -- Adam Theo, Age 22, Tallahassee FL USA --
   //\\   Theoretic Solutions (http://www.theoretic.com)
  /____\    "Software, Internet Services and Advocacy"
/--||--\ Personal Website (http://www.theoretic.com/adamtheo)
    ||    Jabber Open IM (http://www.jabber.org)
    ||    Email & Jabber: address@hidden
    ||    AIM: AdamTheo2000   ICQ: 3617306   Y!: AdamTheo2
  "A free-market socialist computer geek patriotic American buddhist."