[Standards] IM Message Routing 2: Device Identity

Georg Lukas georg at op-co.de
Wed Oct 11 17:14:31 UTC 2017


Hello, this is part 2 of the thread about how broken XMPP is
<https://mail.jabber.org/pipermail/standards/2017-October/033499.html>.

Today I'd like to talk about device identity (in the sense that a server
knows when a certain client application instance reconnects).

Having such a universal client ID would be awesome for:

 - client re-synchronization
 - session initiation / resumption
 - per device passwords
 - OMEMO device key management
 - awesome future use cases

What we have instead:

1. Resource identifiers in the JID

Those are unique, so a server must either kill the old session or refuse
the new session on conflict. IMO clients that create a randomized
resource string on account setup, or keep the one initially assigned by
the server, plus servers that kill the old session on a resource
conflict provide a very sane and reasonable setup that works today.

Pro: a client comes back with the same "public" identifier.

Contra: not cloud-scale, because it requires a global lock when a client
reconnects. However, a global lookup table is needed anyway to enumerate
all resource of a client for presence / bare-JID routing.

Contra: some people consider private resource strings a security
measure.


2. XEP-0198 resume id

Again, unique, used to restore a "zombified" session, typically when TCP
has failed. Typically only short-lived, kept around for multiple minutes
after a client vanishes, and then removed.

Pro: server-generated, opaque to the client.

Contra: short-lived, not suitable for long term


3. Double-Resourcepart proposed in the context of Bind 2

Something like `<client-unique-id>/<server-generated-id>` as a
resourcepart, where a stable client ID is combined with some
cluster-node identifier from the server
<https://mail.jabber.org/pipermail/standards/2017-February/032089.html>

Pro: cloud-scale.

Contra: visible to people who are subscribed to you.

Contra: client identifier changes when reconnecting to a different
cluster node.


It might be useful to have a hidden or visible persistent client
identity stored on the server and associated when authenticating /
binding. Maybe even one the user can see and remove from the server's
web interface ;)

Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171011/f66d6419/attachment.sig>


More information about the Standards mailing list