[foaf-protocols] XMPP & foaf+ssl

[Story Henry]

On 26 May 2009, at 13:21, Melvin Carvalho wrote:
> Hi Henry
>
> I just had a good chat with Dirk Meyer who is working on the X.509
> protocol for XMPP / Jabber.
>
> http://www.ietf.org/internet-drafts/draft-meyer-xmpp-sasl-cert-management-01.txt

thanks for the pointer Melvin.

Hi Dirk, Hi Peter,

as Melvin will have told you we are working on a authentiacation  
mechanism that uses ssl in a way
allowed by the protocol, but not explored at all until recently. We  
put a paper together
to describe this: "FOAF+SSL: RESTful Authentication for the Social  
Web" available here:

http://blogs.sun.com/bblfish/entry/foaf_ssl_restful_authentication_for


> I showed him FOAF+SSL and he instantly understood what we were doing,
> and also said he will include some references in his PhD Thesis.

So I looked at the RFC draft. It seems to me that you could simplify  
it by using
foaf+ssl as the authentication mechanism (which could itself do with  
an RFC perhaps, help
on that is welcome). The advantage of foaf+ssl here are mostly to do  
with it being more general than
your proposal. Here are some thoughts:

   - you can get rid of the publishing aspect of the protocol.  
Publishing the public key can be
done in any number of ways including WebDav, Atom APP, ftp, POST using  
keygen in a browser, ...
So there is no reason for you to limit your jabber authentication to  
just one of these methods. Furthermore by specifying publication  
methods you make your protocol more complex, more difficult to test,  
more fragile, ... I know I spent over a year listening carefully to  
the debates on the Atom APP mailing list, to know how difficult it is  
to do something like this correctly.
     In RESTful talk it seems that you are having to invent POST, PUT,  
GET and DELETE all over for Jabber here. There is no need for you to  
do that. Or if you do, your RFC should be limited to just that.

   - You are also loosing generality by tying yourself to a format,  
rather than working semantically. In foaf+ssl we even avoid that  
piece. So we can consume rdf/xml, rdfa in html, n3, and other formats  
that people may come along with.

   - furthermore there is no need to work only with jabber URLs in the  
Subject Alternative name. HTTP(s) URLs would work just as well.

   - by just using foaf+ssl you may find that many jabber clients will  
already do the right thing, just as we found that most web browsers do  
the right thing out of the box. It would then just be a matter of  
minor updates on the server, without requiring a specific protocol to  
be developed just for Jabber.



> He also says that both systems should be compatible as they use
> SubjectAltName like xmpp:JID and they skip any identifiers they dont
> understand.
>
> So that means we just need to put in a comma separated list and we
> should be able to use our certificates not only for single sign on to
> the web, but also for client side realtime chat and all the other XMPP
> extensions.
>
> This I think is a big advantage, as it means FOAF+SSL can go realtime
> in the not too distant future

Well it is alreadz realtime :-) You mean be used on p2p networks? Well  
I think
yes, it could be used directly in jabber as is. There may be no need  
to invent
anything else, other than perhaps put together a foaf+ssl RFC.


> Best wishes
> -Melvin


Social Web Architect
Sun Microsystems		
Blog: http://blogs.sun.com/bblfish