iOS: QR code account setup (XEP-379, XEP-401, XEP-445)

[thenktor]

Hi,

to simplify account setup on iOS devices it could be done by QR code:

1. Create a text QR code with jabber ID on first line and password on second line, e.g. here: https://www.nayuki.io/page/qr-code-generator-library

[email protected]
mystrongpasswordwithsymbols#&7%§!/()429XX

2. Scan generated code on iOS device quick setup.

Code generator could be added to monal.im website.

[anurodhp]

I'm planning on a lot of QR code stuff actually, its something I will do in 2019. QR codes for account setup, contact exchange and key exchange.

[dholl]

And perhaps could the same QR functionality could be offered on the macOS version as well? :)
(Our laptops have cameras built-in... so a friend could hold their phone up to your laptop's camera to exchange a QR code as well...)

Thank you!

[Echolon]

anurodhp@8efa766

anurodhp@13e84a6

anurodhp@b99be27

[ge0rg]

Sorry I'm late for this game, but please, pretty please don't do it this way. Showing the account password in a QR code is a security nightmare.

We have designed a very nice and useful token-based on-boarding mechanism for new accounts that's slowly getting integrated into different implementations, see here:

• XEP-0379: Pre-Authenticated Roster Subscription for an existing user to send "add me" QR codes that work with/without an xmpp client on the receiving end, like https://yax.im/i/#[email protected] but with automatic approval
• XEP-0401: Easy User On-Boarding for an existing user to create an account invitation token / XMPP URI / landing page link
• XEP-0445: Pre-Authenticated In-Band Registration for the receiving client to register an account in a secure way by using an invitation token
• account invitation with QR code between poezio and yaxim, with video
• well-designed user onboarding / landing page and token support in prosody

You should implement the following URI schemes for registration on the receiving end:

• xmpp:example.com?register;preauth=3c7efeafc1bb10d034 - register a new account on example.com using XEP-0445, with a user-defined account name
• xmpp:[email protected]?register;preauth=3c7efeafc1bb10d034 - register as [email protected] using XEP-0445
• xmpp:[email protected]?roster;preauth=3c7efeafc1bb10d034;ibr=y - if no account is registered, register a new account on example.com using XEP-0445, with a user-defined account name, then automatically add [email protected] to the contact list

[Echolon]

#127

[tmolitor-stud-tu]

we will do this later, don't worry :) Am Donnerstag, 3. Dezember 2020, 10:27:32 CET schrieb Georg Lukas:

…

Sorry I'm late for this game, but *please, pretty please* don't do it this way. Showing the account password in a QR code is a security nightmare. We have designed a very nice and useful token-based on-boarding mechanism for new accounts that's slowly getting integrated into different implementations, see here: * [XEP-0379: Pre-Authenticated Roster Subscription](https://xmpp.org/extensions/xep-0379.html) for an existing user to send "add me" QR codes that work with/without an xmpp client on the receiving end, like ***@***.*** but with automatic approval * [XEP-0401: Easy User On-Boarding](https://xmpp.org/extensions/xep-0401.html) for an existing user to create an account invitation token / XMPP URI / landing page link * [XEP-0445: Pre-Authenticated In-Band Registration](https://xmpp.org/extensions/xep-0445.html) for the receiving client to register an account in a secure way by using an invitation token * [account invitation with QR code between poezio and yaxim, with video](https://yaxim.org/blog/2020/01/31/yaxim-0-dot-9-9-fosdem-edition/) * [well-designed user onboarding / landing page and token support in prosody](https://blog.prosody.im/great-invitations/) You should implement the following URI schemes for registration on the receiving end: * `xmpp:example.com?register;preauth=3c7efeafc1bb10d034` - register a new account on example.com using XEP-0445, with a user-defined account name * ***@***.***?register;preauth=3c7efeafc1bb10d034` - register as ***@***.*** using XEP-0445 * ***@***.***?roster;preauth=3c7efeafc1bb10d034;ibr=y` - if no account is registered, register a new account on example.com using XEP-0445, with a user-defined account name, then automatically add ***@***.*** to the contact list

[mimi89999]

Conversations also added this, but they are using a JSON object for that: https://github.com/iNPUTmice/Conversations/issues/3796

I'm still against this feature.

[licaon-kter]

@mimi89999 against which one? The XEP based one by Ge0rg or the Conversations one?

[mimi89999]

@mimi89999 against which one? The XEP based one by Ge0rg or the Conversations one?

@licaon-kter Add account with password in QR code also called provisioning. It was also implemented in Monal in 8efa766, but it seems that they are using a different format.

[thenktor]

@mimi89999 against which one? The XEP based one by Ge0rg or the Conversations one?

@licaon-kter Add account with password in QR code also called provisioning. It was also implemented in Monal in 8efa766, but it seems that they are using a different format.

Well the better solution for provisioning would be to allow a MDM system to set the needed config variables. But most apps do not have this feature and devs are unwilling to add it.

[mimi89999]

Do you have any documentation on how to add MDM support to apps?

[thenktor]

Apparantly the correct name is "managed configuration":
https://www.appconfig.org/ios/
https://developer.apple.com/library/archive/samplecode/sc2279/Introduction/Intro.html

This is used by MDM systems to pre-configure apps. This is done by parameter/value pairs. Users then may only enter their password and are ready to go.

Here is an animated gif that shows the process for configuring Threema Work in a Sophos MDM: https://work.threema.ch/res/threema_mdm_sophos-ios.gif

[ge0rg]

I think onboarding via MDM is a fundamentally different approach for a fundamentally different user group.

MDM: the phone is a company phone and the app gets provisioned by a central account management service. This is only useful for corporate environments that centrally deploy the app to all users.

QR code onboarding: the phone is a private phone and you want to transfer an account from another device / register an account from a friend's invitation.

[mimi89999]

I think onboarding via MDM is a fundamentally different approach for a fundamentally different user group.

I agree, but it might still be good to implement it if an enterprise wants to move from another platform to XMPP.

[Echolon]

I suggest all further MDM requests and discussions should go here:
Add Managed AppConfig support [Buisness MDM]
#164

[thenktor]

MDM: the phone is a company phone and the app gets provisioned by a central account management service. This is only useful for corporate environments that centrally deploy the app to all users.

QR code onboarding: the phone is a private phone and you want to transfer an account from another device / register an account from a friend's invitation.

Yes, but we are using both in our enterprise environment, e.g. QR provisioning with the 3CX phone system, the "managed configuration" with Threema and some other stuff.
Both works well for admins and users. Most important thing is to not waste your time with entering "1000" config options on your smartphone. Users do it wrong many times and call the admins. Admins get grey hair when entering all the stuff for all users. Never a system would be deployed if you know this beforehand 👎

The QR thing is something you can use at home, too. And also at home nobody wants to enter the stuff on the phone anymore. Just open the app, scan something and your done (Signal/Threema). Just my 2 cents ;-)

[Echolon]

Should this issue be connect to 4.9 ?

[Echolon]

@tmolitor-stud-tu @FriedrichAltheide what the status here - should this connected to 4.9?

[FriedrichAltheide]

No

[lissine0]

As of right now, there's nothing that the Add account QR-code scanner would accept:

1. xmpp:[email protected]?roster;preauth=TOKEN;ibr=y
   -> Wrong menu. The qrcode contains a jid. Rescan the qrcode in the add user menu.

2. https://example.com/invite/#TOKEN
   -> invalid format. We could not find a xmpp related QR-Code

3. xmpp:example.com?register;preauth=TOKEN
   -> invalid format. We could not find a xmpp related QR-Code

4. xmpp:[email protected]?roster;preauth=1tMFqYDdKhfe2pwp
   -> Wrong menu. The qrcode contains a jid. Rescan the qrcode in the add user menu.

So it seems like support hasn't been added yet (despite the QR code scanner being there)
Anyway, the support for 2. should be added, in addition to the list of URI schemes @ge0rg wrote.
I'm not sure using such link directly in the xmpp client is mentioned in the XEPs, but Conversations is able to do it, at least on first app use.

Also, as of now, in the Add Contact view, 1. and 4. work, but the jid is simply parsed, which means the other entity would get a roster subscription request.
Instead, the token in the URI should be used for pre-authentication. That way, your roster subscription is immediately accepted.
Moreover, 2. should be supported here as well.

[lissine0]

In Add contact, the share button should use the iOS sharing functionality;
It should probably also show a qr-code of the link/uri

[FriedrichAltheide]

Currently, the account scanner should accept a QR code containing the username and password

[lissine0]

Currently, the account scanner should accept a QR code containing the username and password

I'm not sure that's a good idea. As said in #172 (comment):

Showing the account password in a QR code is a security nightmare.

XMPP invites solve the same problem in a more secure way.

[FriedrichAltheide]

First of all, we did not propose the format. Instead, we implemented a protocol format that was already implemented by Conversations https://github.com/iNPUTmice/Conversations/issues/3796.
As described in the referenced ticket the format was designed to be used directly after registering a new user e.g., using a command line tool.

Scenario: A family member wants an account. This member will - as always - forget his password. Hence, just create an account, let the family member scan the QR-code. In the future, when the family member has a new device: create a new password and let the member scan the new QR code.
In this scenario I do not see a security nightmare.

For other scenarios invite links are the way to go. But I strongly disagree to say that showing a password in a QR code is directly a security nightmare. (e.g., If I want to add a device manually: I open my password manager on my pc, open the XMPP account entry in the password manager and then manually typing my username and password in my phone. It does not matter if the password was shown in plaintext or if it was encoded in a QR code. In both cases I would need to ensure that nobody / or only trusted people are in the room with me and my password)
Or if I follow an invite link, I still need to set a password. This password should better be saved inside the password manager of my choice. Therefore, I will type the password into that software. To make sure that the saved password is the same as set on my phone, I will probably check if the password is correctly saved in the manager. Hence the password is again shown in cleartext on my screen. No difference to generating a password on my computer and scanning it using my phone as again I must ensure that nobody or only trusted people are near my screen.

[lissine0]

Okay, fair point.

[tmolitor-stud-tu]

Regarding invites: this is already implemented, monal reacts on all of ge0rg's urls just fine if you tap on such urls. Only the qr-code usecase is not implemented yet.

[tmolitor-stud-tu]

Invites are already in monal stable, btw.

[lissine0]

I made a mistake while generating the qr codes (I was using qrencode and didn't enclose the uri's in double quotes. So, the parts after a semicolon weren't included)
I am sorry.
I tested again, using alpha build Oct 9 2023: 20:45:29 UTC (it would be helpful if the alpha version string shows the first 7 characters of the last commit, but in this case I believe it's 0a908b6)
Now, everything I tested in #172 (comment) works, (with the exception of registering an account using xmpp:[email protected]?roster;preauth=1tMFqYDdKhfe2pwp
But that's the correct behavior, because it's an invite for just a roster subscription.)

The current invites support in Monal is really satisfying! Thank you for the great work!

Nevertheless, here's some feedback (I think the two points are related):

• When I register an account using an account-and-contact invite (like xmpp:[email protected]?roster;preauth=TOKEN;ibr=y), after finishing registration I see the Add Contact view prefilled with the jid of the person who invited me. When I click Add Group/Channel or Contact, it says Already present. This contact is already in your contact list

• When I add a contact using an invite, I get an alert with Permission Requested. This new contact will be added to your contacts list when the person you've added has approved your request
  Moreover, I get a notification that the person who invited me wants to add me to their contact list.

It would be nice if these things could be skipped when processing an invite.

Bonus points if at some point Monal is able to extract the invite uri from the landing webpage, without the user having to browse it, like Conversations does (at least when C's account list is empty) =]]

[lissine0]

By the way, I'm not sure but I think these XEPs should be marked as complete in the doap file ( 0379, 0401 and 0445)

[tmolitor-stud-tu]

yes, the xeps should be marked as complete, thanks for the hint.

regarding your first point: not all servers auto-add the contact when registering, checking if the contact is already there before opening the add contact gui involves quite a bit of shuffling code around since the login and roster retrieval must be finished before opening the add contact gui.

regarding your second point: this notification is in place because the token for roster pre-approval could be invalid or not processed by the server at all. the incoming notification telling asking you to accept the remote contact is right, too: that is the server sending monal a contact request. if the server had auto-accepted it, it would not have sent this.

your bonus point will never be implemented, because every invite website could in principle invent their own format to transport the xmpp uri inside the http link. extracting something and hoping that it includes everything that was intended to be part of the xmpp: uri is error prone and I don't want to do this.

[tmolitor-stud-tu]

but a quick question: what servers did you try the invite feature with? yax.im on both accounts?

[lissine0]

I used a self hosted Prosody 0.12.4
If you need a test account, or want me to test with another configuration, let me know.

[lissine0]

About the earlier points, I was merely suggesting to improve the UI, from an end-user perspective, because it might be confusing.

[tmolitor-stud-tu]

About the earlier points, I was merely suggesting to improve the UI, from an end-user perspective, because it might be confusing.

I know, but unfortunately it's not that easy.

Could you check if your findings are still true, if all accounts involved in the test are *@yax.im accounts?

[lissine0]

I was going to suggest to remove the Already present. This contact is already in the contact list of the selected account alert. Then I found out that using prosody trunk, when creating an account using an invite, Monal doesn't show the Add Contact view. The inviter is automatically in your contacts' list.

About yax.im, they have allow_user_invites = false, which breaks roster preauth for some reason (tested in Monal as well as in Conversations)
I already mentioned this in the prosody channel, they said it could be snikket-im/snikket-server#105

[tmolitor-stud-tu]

@lissine0 Am I right that this issue can be closed now?

[lissine0]

To my knowledge yes.
From an earlier comment of mine:

The current invites support in Monal is really satisfying! Thank you for the great work!

By the way, it may be the time to mark XEP-397 as complete.
Is there some unimplemented functionality related to it? I noticed that you marked XEP-401 as complete in 6.0 but not XEP-379