|Subject:||Re: [foaf-protocols] foaf+ssl+xmpp, half-baked implementation and some thoughts|
|From:||Story Henry (henr...@bblfish.net)|
|Date:||Apr 29, 2010 7:01:32 am|
Great Work, sorry for taking time to reply....
On 21 Apr 2010, at 23:52, elcalamartevigila wrote:
I've put together some simple diagrams to draw the use scenarios at: https://rhizomatik.net/myceliafoafssl/wiki/XmppWebIdCheck
Those diagrams are very helpful. Thanks.
Let me start by the key piece, authentication. How to generate the correct key and associate the WebId/xmpp with the server is a different issue, and there may be many ways of doing that.
This is that last slide in your diagram. This seems perfectly fine.
In fact in this case it seems that the user does not need to have his jid in his x509 certificate, since the XMPP Server knows of the identity
 jid = webid .
Let "_:client" be the handle the XMPP server XS has before authentication on whatever is at the end of the SASL connection. After foaf+ssl authentication XS will know
 _:client = webid .
From  and  it can deduce that
 _:client = jid .
The reason this works is that there is only one Server a client ever connects towith one JID, it seems. If it a client connected to another server XS2 then it would only know  and not be able to conclude to . Placing the JID in the certificate won't help of course.
But it seems from what I understand that this is not an issue in XMPP, because
as with SMTP, a client only ever connects to one server with one id.
This is very different from a web browser then. With one web browser I can
connect to all public web servers, and jump from one web server to another. This is what I understand to be a key element of Peer to Peer. I get the information directly
from the web site I want to communicate with, no intermediaries.
Now until before foaf+ssl though I could not identify myself securely to all web
servers with https. Because practically the client certificates can only use
CA's that are not globally known. As a result one had to create a cert for each web
site, which made using certs impractical.
But as I understand with XMPP, you are tied to only one server anyway.
So what advantage does foaf+ssl+xmpp bring? You could just sign the certificate
with your own server private key right? You don't really need an external CA.
As I see in diagram 2 you have an :xmppCA. That should just be your access to a
private key to test the signatures on incoming certificates, which after all can
ONLY come from you. They would have no use outside. (I may be wrong here. If I
am please clarify).
I still don't have very clear if such a "hack" is an acceptable form of authentication for xmpp, but I'm trying to have some working demo of this, I'm also asking the jabber community.
I think that the authentication would work. What I don't see yet, is that it is needed, since XMPP is not really a p2p protocol.
What would be useful would be the other way. To give your XMPP server a WebID, so that it can ping the WebID server about information, which could then be added to the foaf file. Ie: new friends to add, ...
(soemthing we still have to work on)
Please let me know where I am going wrong in the reasoning above....
On 19:40, Fri 16 Apr 10, Story Henry wrote:
Once the server knows this identity, he can authentify the user via his WebID
from there on.
If that is correct then I don't see where the user needs to have his cert
signed by a trusted CA.
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),
This sounds a bit like the problem someone would have when logging in to a web
server with foaf+ssl when he never visited that web site before.
The trick here is that you do the foaf+ssl authentification, then the server
has a handle on you: your webid. It could just continue to use that WebId, or I
suppose it could have you coin a JID. I am not sure how it gives you the JID
back to use...
the point here is that we were trying to follow the spec respect x509 certificates, that expect your JID to be incorporated in the cert you present (of course the jid lookup could be done via SPARQL to the WebId, and taking the jabber account(s) that matches the domain in question). That would allow to present only a cert with your WebId, and not having to create a new cert specially for your jabber account.
Perhaps at that point the XMPP server can publish at the JID - if XMPP can do
that - the identity JID = webID. Which would be a way also for other servers to
know when derferencing JID that the WebID could also be used as an identifier.
To look at this in more detail we would need to understand how XMPP can
publish documents tied to a JID. An issue to take into consideration is that if
say Jabber uses a URL scheme such as
Then that would be another WebId identifying the user. But there would still
be a need to tie the jid:henr...@jabber.org to the URI above.
As far as I know, in jabber you can publish some basic information in the form
of vcard fields (xep-0054, which is widely adopted server side, I think). And there is
pubsub (xep-0060) and a simpler variant called PEP (Personal Event Publishing, where
each jid has is own node where it publishes information and other people can subscribe
(Q: If jabber does document publication, does it understand the concept of
content negotiation? )
Kind of. In PubSub, you can specify a collection of items. Leaf nodes have a
payload, and you can specify the type of the payload you are using ( atom is the common
coin, but I guess you can use rdf instead ).
<identity category='pubsub' type='leaf'/>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<field var='pubsub#type' label='Payload type' type='text-single'>
<field var='pubsub#creator' label='Node creator' type='jid-single'>
<field var='pubsub#creation_date' label='Creation date' type='text-single'>
<field var='pubsub#title' label='A short name for the node'
type='text-single'> <value>Princely Musings (Atom)</value> </field> </x> </query> </iq>
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!
yes, that would be good. But unless you have a way of verifying the webid = jid
the above won't be good enough. After all anyone could create a certificate with
a valid webid and your jid in the certificate.
First thing I was thinking was making the jabber server know about the webid you are going to use from the begginning.
That seems like the easiest solution initially, indeed.
It's probably best to start with that part, the authentication, then work on
simplifying it. Too many problems at a time, spoil the solution :-)
It can be accomodated into the spec, or you can do the "hack" of registering the account as usual, and then, first thing after registering the jid, publishing your WebId URI in the foaf field of the VCARD. Quite hackish, but painless.
Again if jabber could just publish the identity jid = webid then one can do a
lootkup at the jid, find the webid and do the authentification that way. (or one
could have jid publish a public key too)
Yep, and that ringed bells: There is also a xmpp spec about public key publishing: xep-0189, which uses PEP nodes and would probably be the more "jabberish" way.
So what I am not clear about is how decentralised jabber is either. Is one
suppose to be able to login to any jabber server with a jid, or is it always
only the same server? Because if it is always the same, then one can easily just
log in with one's webid.
Your jid is identifying you at a single server, mostly like smtp architecture.
In fact, the full-JID has three parts: USER @ DOMAIN.L / RESOURCE where resource identifies "agents" that have authenticated with the "bare" jid (ie, your mobile session, your main browser, or maybe bots or agents logged in behalf of you). There is also an interesting priority mechanism that tries to deliver human-readable content to the resource that looks more like a human...
I'll keep playing with this, and let's see where it leads to...
-- e pur si muove...
_______________________________________________ foaf-protocols mailing list foaf...@lists.foaf-project.org http://lists.foaf-project.org/mailman/listinfo/foaf-protocols