commit f20c9b07f6ea0b54bcc630fb58d3ad8c4f6c4bce
parent 2539137465e021530aa9e2a89b0ff737c258e43c
Author: Florian Dold <florian@dold.me>
Date: Tue, 3 Mar 2026 19:32:31 +0100
DD89: integrate Sebastian's comments
Diffstat:
1 file changed, 14 insertions(+), 0 deletions(-)
diff --git a/design-documents/089-merchant-2fa.rst b/design-documents/089-merchant-2fa.rst
@@ -35,6 +35,12 @@ We differentiate between two cases:
Common considerations:
* The cancel button always cancels the whole operation.
+* Once the backend supports it, 2FA codes should have a dash
+ after every group of 4 digits and start with a common
+ prefix (``TM-`` for the Taler merchant) that is already displayed
+ in the UI. Since we don't know the length of the 2FA code, we can't
+ display boxes directly, but the text field should automatically fill
+ in dashes.
Sign-up
@@ -42,6 +48,9 @@ Sign-up
* These wireframes apply to 2FA where *all* channels need to be validated. The
sign-up is taken as an example.
+* For a sign-up, the UI should display the full phone number / e-mail address.
+ For other operations such as password reset, ``S1.2a/b`` should show
+ the redacted addresses.
* In the usual flow, the user sees ``S1.1``, ``S1.2a`` and finally ``S1.1b``.
@@ -62,6 +71,11 @@ Authentication
.. image:: images/089/auth.excalidraw.svg
+Test Plan
+=========
+
+* Non-trivial UI elements should be tested on mobile (such as the 2FA code entry input
+ element with dashes).
Discussion / Q&A
================
