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

[1] 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

[2] _:client = webid .

From [1] and [2] it can deduce that

[3] _: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 [2] and not be able to conclude to [3]. 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, becauseas
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 canconnect
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 directlyfrom
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 useCA's
that are not globally known. As a result one had to create a cert for each website,
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 Iam
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....

Henry

On 19:40, Fri 16 Apr 10, Story Henry wrote:

Once the server knows this identity, he can authentify the user via his WebIDfrom there on.

If that is correct then I don't see where the user needs to have his certsigned 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 verymoment
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 webserver with foaf+ssl when he never visited that web site before.

The trick here is that you do the foaf+ssl authentification, then the serverhas a handle on you: your webid. It could just continue to use that WebId, or Isuppose it could have you coin a JID. I am not sure how it gives you the JIDback 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 dothat - the identity JID = webID. Which would be a way also for other servers toknow 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 canpublish documents tied to a JID. An issue to take into consideration is that ifsay Jabber uses a URL scheme such as

Then that would be another WebId identifying the user. But there would stillbe
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 formof vcard
fields (xep-0054, which is widely adopted server side, I think). And there ispubsub
(xep-0060) and a simpler variant called PEP (Personal Event Publishing, whereeach jid
has is own node where it publishes information and other people can subscribeto).

(Q: If jabber does document publication, does it understand the concept ofcontent negotiation? )

Kind of. In PubSub, you can specify a collection of items. Leaf nodes have apayload,
and you can specify the type of the payload you are using ( atom is the commoncoin,
but I guess you can use rdf instead ).

yes, that would be good. But unless you have a way of verifying the webid = jidthe above won't be good enough. After all anyone could create a certificate witha 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 onsimplifying 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 alootkup at the jid, find the webid and do the authentification that way. (or onecould 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 onesuppose to be able to login to any jabber server with a jid, or is it alwaysonly the same server? Because if it is always the same, then one can easily justlog 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...