[Standards] Easy XMPP
jonas at wielicki.name
Wed Jun 8 13:28:03 UTC 2016
On 07.06.2016 17:04, Georg Lukas wrote:
> in the last weeks we've seen that XMPP is too hard for the WhatsApp
> generation. Instead of blaming them for not understanding federation, we
> should make it as easy as possible to use XMPP (IM) in a secure fashion.
> In the last days, I've collected some ideas on how to accomplish that
> into a set of wiki pages (initially originating from discussions on xsf@
> which I didn't want to lose).
Thank you very much for that!
I find much of what is written in those wiki articles very sensible.
On <https://wiki.xmpp.org/web/Easy_Onboarding>, someone wrote
> To allow for password recovery, something needs to be done. One
> possibility is to ask the user for their phone number or email
> address. However, users often mistype things, so that the
> number/address needs to be validated during onboarding. This is
> making XMPP less accessible and onboarding more complicated.
Mobile clients (which are, I feel, those with the most need for a very
very very simple onboarding process) could simply let the user choose
one of the phone numbers associated with the device. A server operator
would in that case have to send a check SMS. "Ideally", the client would
transparently read that SMS if the user allows that, or the SMS contains
a URL which can be opened with either the XMPP client or with a normal
web browser which concludes the verification.
An additional idea I had was on the matter of how to add more devices to
your XMPP account. One way which came into my mind was to use client
certificates throughout the whole setup. But use them transparently.
Treat them as client keys, ignore the whole expiration date and CA
stuff, simply add a white-list of fingerprints or even public keys to
the account on the server side.
To add a new device, the server could generate an authentication code
and send it to an existing device of the users choice (e.g. in response
to an Ad-Hoc command). A complying client on another device would have
an input for such a code (+ JID/Domain). It could connect to the server
and with an additional protocol (or something along the lines of
XEP-0077 with a data form) submit the code entered signed with a freshly
generated private key as well as the public key. Server validates the
signature and auth code and adds the public key to the whitelist.
> 1. Should Romeo's client or his server implement token generation and
> subscription approval?
> - A server-side implementation violates RFC6121 §3.1.3
> - A client-side implementation is not immediate if the user is
> currently offline
> - A client-side implementation needs to sync tokens between
> multiple clients
> - A server-side implementation needs an additional protocol for the
> client to request/invalidate tokens
A client-side implementation seems flaky for the reasons outlined there.
"violation" of RFC6121 §3.1.3 is at least debatable: one could argue
that using such a feature is "entering an agreement with the service
> 2. Should the invitaiton link only encode minimal information (JID
> and token), or should it contain sender-defined display names for one
> or both parties?
> - A minimal implementation is fast to implement (see
> Conversations.im) and has less corner cases, but also less user
> - Having a display name that differs from the JID localpart might
> be beneficial to many users, and querying the JID before adding
> them to the roster is challenging
+1 for adding display names.
I don’t want to comment on the third point there right now.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Standards