[foaf-protocols] foaf+ssl+xmpp, half-baked implementation and some thoughts

Melvin Carvalho melvincarvalho at gmail.com
Sun Apr 18 13:08:03 CEST 2010

2010/4/16 elcalamartevigila <elcalamartevigila at gmail.com>

> hi,
> as melvin commented some weeks ago, we have been working on a tutorial
> about enabling client certificates authentication on a jabberd2 server,
> following the sasl-external xmpp spec.
> the tutorial is at:
> https://rhizomatik.net/myceliafoafssl/wiki/XmppFoafSSL
> and shortly consist of applying a couple of patches to jabberd2 (now in
> trunk) and gajim, plus a django application to generate the client
> certificates and handling the user registration.
> there is a demo server running at xmpp.rhizomatik.net:5222, you can
> register an user at http://foafssl.rhizomatik.net
> Right now, the jabberd2 server just checks the certificates to see if they
> are
> signed by a trusted  CA, but we are working to integrate parts of the mod_
> authn_webid to check the cert credentials against the webid.
> About this, we have some doubts about how to continue.
> The CA signature checking is now the only way to assert that the user
> presenting
> the credentials is the one who registered the JID. The only way we see to
> skip
> the trusted CA verification is to give to the server your WebId in the very
> moment
> of the registration (your IdP could do this for you, ie, make a in-band
> registration with some external jabber server in the moment of creating
> your
> certificate), so the "real" foaf+ssl+xmpp authentication would be:
> 1. client: present cert with URI:<yourwebid> + id-on-xmppAddr in the
> subjectAltName
> 2. server: get mod / exp from cert
> 3. server: **check that URI:webid matchs the one associated with this JID
> on its internal
>           database**
> 4. server: sparql over your URI:webid to match against mod/exp represented
> there.
> 5. authd!
> Does it makes sense? Am i missing something?
> Regarding how to transfer the WebId URI to the xmpp server, I'm not sure if
> a
> specific XEP would have to be proposed to the xmpp community, or if just
> updating the vCard with a foaf field inmediately after the registration
> would do
> it.
> Beyond this, I guess that also the own xmpp server could act as an IdP to
> the https
> world.
> ..
> I was also wondering about if the xmpp use case can be somehow different
> from the https world, in general terms.
> On one hand, I envision the power in bringing linked data into the jabber
> data models: your roster can be kept in sync with your foaf,
> and of course much more interesting access control schemas can be built
> upon
> the foaf+ssl mechanism (fine grained control over pubsub nodes?). Also very
> interesting possibilities about end-to-end encryption and the p2p stuff
> with
> jingle... (A very nice toy could be, for instance, trust metrics before
> accepting
> a presence request). Also, BOSH would be a very nice case with hybrid
> http/xmpp
> applications.
> On the other side, I see some differences about the more resource
> intensive,
> persistent connections related to a xmpp server. In xmpp you don't need to
> authenticate with different sites, as the relationship is mainly mediated
> by
> your server, so foaf+ssl is not so interesting at that respect.
> Nevertheless, I think is interesting to explore the possibilities and
> surely we
> can find benefits.

Awesome work guys!

Sorry haven't had time to look closely at this,  but I've put this on the
radar or dirk meyer ( http://xmpp.org/extensions/xep-0250.html ) and he said
he'd take a look tomorrow.

I'll also make time to review this week.

Thanks again ... I think this looks really promisiing ... with one social
web starting to grow too (web client comes next) ... the worlds of FOAF and
XMPP seem to have got one step closer together!

> --
> abra  su mente al dinero,
> venda su alma al capital.
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100418/242ab48c/attachment.htm 

More information about the foaf-protocols mailing list