089-merchant-2fa.rst (2645B)
1 DD 89: Merchant 2FA UX 2 ###################### 3 4 Summary 5 ======= 6 7 This design document describes the user experience for two factor 8 authentication in the merchant portal. 9 10 Motivation 11 ========== 12 13 Users have been confused by the design currently implemented. The 2FA is an 14 important flow and as such should be well designed and documented. 15 16 Requirements 17 ============ 18 19 * At every step of the process, 20 it should be clear to the user what they need to do next. 21 22 Proposed Solution 23 ================= 24 25 We differentiate between two cases: 26 27 * 2FA steps where **all** possible channels have to be validated. This is 28 typically the case for sign-up and password reset. Here, we guide 29 the user one by one. The user can't choose the order. 30 * 2FA steps where **some** channels have to be validated. 31 This is typically the case for log-in and protected 32 operations such as modifying bank account information. 33 Here the user can select which channel to use. 34 35 Common considerations: 36 37 * The cancel button always cancels the whole operation. 38 * Once the backend supports it, 2FA codes should have a dash 39 after every group of 4 digits and start with a common 40 prefix (``TM-`` for the Taler merchant) that is already displayed 41 in the UI. Since we don't know the length of the 2FA code, we can't 42 display boxes directly, but the text field should automatically fill 43 in dashes. 44 45 46 Sign-up 47 ~~~~~~~ 48 49 * These wireframes apply to 2FA where *all* channels need to be validated. The 50 sign-up is taken as an example. 51 * For a sign-up, the UI should display the full phone number / e-mail address. 52 For other operations such as password reset, ``S1.2a/b`` should show 53 the redacted addresses. 54 * In the usual flow, the user sees ``S1.1``, ``S1.2a`` and finally ``S1.1b``. 55 56 57 .. image:: images/089/signup.excalidraw.svg 58 59 60 Authentication 61 ~~~~~~~~~~~~~~ 62 63 * These wireframes apply to 2FA where *some* channels (usually one) need to be 64 validated. Adding a bank account is taken as an example. 65 * We explicitly use a check-box instead of a button, since: 66 67 1. We can pre-select the 2FA option that we consider preferable (cost) 68 2. Instead of having many buttons, there's only one primary action 69 70 * For resending / expired auth codes, see ``S1.2b-e*`` 71 72 .. image:: images/089/auth.excalidraw.svg 73 74 Test Plan 75 ========= 76 77 * Non-trivial UI elements should be tested on mobile (such as the 2FA code entry input 78 element with dashes). 79 80 Discussion / Q&A 81 ================ 82 83 * Do we know beforehand from the API which 2FA channels are required? 84 * When signing up, what if the user mistyped their phone number? 85 Do we offer some affordance to go back and edit that information? 86