[Telepathy] Empathy, SIP, and XMPP

[Travis Reitter]

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 at example.org and the XMPP contact
alice at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4042 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20130107/d0642b46/attachment.bin>