On Mon, 2013-01-07 at 11:51 -0700, Peter Saint-Andre wrote:
Given that Empathy has both SIP and XMPP support, it would be great if one of the Empathy developers could provide feedback on a short spec we've been working on at the IETF about dual-stack clients: http://tools.ietf.org/html/draft-ivov-xmpp-cusax-02 Even a quick "looks mostly sane" would be appreciated.
Hi Peter, I thought I'd add some thoughts as someone who works with contact aggregation in the Folks client library [1] that the Gnome Desktop uses. Our main backends provide support for Evolution addressbook and Telepathy contacts (though we have a few other backends as well). " In order for CUSAX to function properly, XMPP service administrators should make sure that at least one of the vCard [RFC6350] "tel" fields for each contact is properly populated with a SIP URI or a phone number when an XMPP protocol for vCard storage (e.g., [XEP-0054] or [XEP-0292]) is used. ... When receiving SIP calls, clients may wish to determine the identity of the caller and bind it to a roster entry so that users could revert to chatting or other forms of communication that require XMPP. To do so clients could search their roster for an entry whose vCard has a "tel" field matching the originator of the call. " Folks aggregates people at the simplest level by finding matching (trustworthy) identifying details amongst contacts. So, if user has a local vCard contact with X-JABBER:alice example org and the XMPP contact alice example org, Folks will present them at the highest level as a single metacontact with their aggregate features and contacts, the most-relevant avatar, full name, etc. We don't currently automatically link on an XMPP's "tel" field because we can't necessarily trust the "tel" field of the contact; if a malicious user set their XMPP account's "tel" field to another person's SIP account, they could potentially spoof that person's identity and initiate or receive text communication as that other person. But if we had some means to verify the connection between a SIP and XMPP contact, then we could link them together and present them as a single person. Eg, if the SIP contact had a reference to the XMPP contact, like an X-JABBER vCard field set to the XMPP contact's JID, Folks or other clients could reasonably link them together. For a malicious user to set up both links, they'd need control over at least one of the victim's accounts, at which point, there would be nothing we could do to help anyhow. In an ideal world, both contacts would have the same verifiable identity certificate, but I don't foresee that ever being common enough for us to support. Client certificate management is just too much of a hassle for all but the most technical and motivated of users. A similar real-world case is Facebook users available over XMPP. Even if they provide VoIP or chat contact details, we can't link to any matching contacts on that basis because Facebook doesn't verify any user-set addresses. " An alternate mechanism would be for CUSAX clients to add to " Not relevant to folks, but this section seems to have been truncated. Regards, -Travis [1] https://live.gnome.org/Folks
Attachment:
smime.p7s
Description: S/MIME cryptographic signature