[Telepathy] Empathy, SIP, and XMPP

[Peter Saint-Andre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/7/13 3:50 PM, Travis Reitter wrote:
> 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,

Hi Travis. A very belated thanks for your feedback!

> 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.

Emil has already incorporated much of your feedback into the spec, but
I've also just added the second sentence to the following paragraph:

        In addition to discovering phone numbers from vCards, clients
        may also check for alternative communication methods as
        advertised in XMPP presence broadcasts and Personal
        Eventing Protocol nodes as described in <xref target="XEP-0152">
        XEP-0152: Reachability Addresses</xref>.  However, these
        indications are merely hints, and a receiving client ought not
        associate a SIP address and an XMPP address unless it has some
        way to verify the association (e.g., the vCard of the XMPP
        account lists the SIP address and the vCard of the SIP account
        lists the XMPP address).

(I've also corrected the spelling of your last name.)

> " An alternate mechanism would be for CUSAX clients to add to "
> 
> Not relevant to folks, but this section seems to have been
> truncated.

Yes, we've published several versions of the document since then. The
latest (published April 4) is here:

http://tools.ietf.org/html/draft-ivov-xmpp-cusax-04

Again, many thanks for taking the time to provide your feedback!

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRfypaAAoJEOoGpJErxa2ppW0P/jYJxm14d5zUDNgXzp1ZSayK
BJA6UMiuSHsRToU//Cf6jNWZ/1cWlUhe1oArDiXXLkMQMccChMo/jy6eFW5tJGIW
dii/LvhdkM41H0kiLsBQnoYQSAp+xvTFw3vwJj+Wl3LAj6L6YrSbmWDErllytza1
IUUdBelA4FNGcf4yPiOyiB11dFQ2gnneX8bZ6S7dX/Ci6XALzL/30ntfUpADvJY9
GZuZIFmU8JW1YH6FrYbwEdjfpxvReKEbiOZwwOiFmKN3Rl8dkaQdu4GRsT3dWI2l
DtAZid/srNLuwX65muMMjIkeQkw7r8WThd4VRybguMpZjeBRzzjT2iNzNO5TFQAA
xme2C0MW0+vGpr5AJIDGcyyNOysrgfVncyBF44DJWzCAK3iY3eu/FlvTEhr4CNth
NvTN/Odd2vY3knLg2aJna7ry9uKY5FRlvFNvrMiaAkcjB0V3ovO/eB+hUfUrvzUp
mFLovY4qOQNQSS71WUbynk/RQtZzvSJQUoP2BNeMD1s9B9L6U3R0rEUAOh+ohYJ+
o86+iN/XxMBmpn0HCNA33oCbfbQCeQSKR0R99vRgLW8/1E/HJ8bQoB/cp2Y6eXWj
SIkDkIYjl3BBwi+4hmhm1LicOICRd5GI/sQp3cVPgBH3JPRf4v/t3rG81IXLdx2k
+c+TX4RUn8vTkK5hetZI
=qPnB
-----END PGP SIGNATURE-----