diff options
| author | Antoine A <> | 2023-12-15 19:37:57 +0000 |
|---|---|---|
| committer | Antoine A <> | 2023-12-15 19:39:29 +0000 |
| commit | 1b404c2d1f5ec16dbca30e245d51a91e136ddcc6 (patch) | |
| tree | a25092fb262c9dcf0e16eeb770358120aabff6f2 /design-documents | |
| parent | 522eb3d1a7f02adfa610b5916f42c223deb4811e (diff) | |
| download | docs-1b404c2d1f5ec16dbca30e245d51a91e136ddcc6.tar.gz docs-1b404c2d1f5ec16dbca30e245d51a91e136ddcc6.tar.bz2 docs-1b404c2d1f5ec16dbca30e245d51a91e136ddcc6.zip | |
[dd 52] add Q / A
Diffstat (limited to 'design-documents')
| -rw-r--r-- | design-documents/052-libeufin-bank-2fa.rst | 19 |
1 files changed, 16 insertions, 3 deletions
diff --git a/design-documents/052-libeufin-bank-2fa.rst b/design-documents/052-libeufin-bank-2fa.rst index 8e5711bb..3d0900e2 100644 --- 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 |