commit 1b404c2d1f5ec16dbca30e245d51a91e136ddcc6
parent 522eb3d1a7f02adfa610b5916f42c223deb4811e
Author: Antoine A <>
Date: Fri, 15 Dec 2023 19:37:57 +0000
[dd 52] add Q / A
Diffstat:
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/design-documents/052-libeufin-bank-2fa.rst b/design-documents/052-libeufin-bank-2fa.rst
@@ -17,7 +17,7 @@ Requirements
============
* Support future TAN channels (YubiKey, trusted devices, etc) without API-breaking changes
-* Support mulitple TAN channels per user
+* Support multiple TAN channels per user
Proposed Solutions
==================
@@ -30,8 +30,6 @@ We have two kinds of operations we would like to protect:
* state-machine operations that already have a ``pending`` and ``confirmed`` status and require multiple endpoint calls to complete (cashout and withdrawal).
* one-shot operations that are currently completed using a single endpoint call (transaction, account reconfiguration and account deletion).
-We could choose different designs for each kind of operation, as they have different implementation challenges.
-
Fine-grained or coarse-grained authentification
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -121,3 +119,18 @@ The bad
- Having a short-term token in addition to a long-term refreshable token can be confusing for clients.
- We still keep the pending state of one-shot operations at the client level.
- Coarse-grained authorization, one token for any operation for a short amount of time.
+
+Q / A
+=====
+
+* Q: Where do we want to handle TAN challenges logic and error handling, in each operation API or a TAN-specific API?
+
+ * In each operation means fewer API calls and TAN-specific means more API calls but better/cleaner logic separation.
+
+* Q: Where do we want to store pending states for oneshot transactions in the client or the backend database?
+
+ * In the client makes things simpler for the backend but is incompatible with coarse-grained authorization.
+
+* Q: Do we need coarse-grained authorization or fine-grained is enough?
+
+ * Coarse-grained authorization requires that we store pending states for operations even for the ones that are currently oneshot. We could use a different strategy for each kind.
+\ No newline at end of file
