View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010401 | Taler | merchant backend | public | 2025-09-12 17:34 | 2025-09-12 18:03 |
| Reporter | sebasjm | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Summary | 0010401: do not ask mfa timeout for the same AC | ||||
| Description | similar to "timestamp_timeout" on sudo if the merchant backend has already ask for MFA it should not ask for a period of time, configurable in taler-merchant.conf similar to sudo timestamp_timeout this is problematic when creating an account, is being ask 3 times on (1) account creation (2) login (3) adding a bank account. my suggestion is to associate with the access token as follows: * between (2) and (3) we have the access token than can be used as link for which the MFA should not be asked. * between (1) and (2) we don't have a token but the account creation already provides the password so maybe the endpoint for self-provision can return an access token? (just for the sake of not asking mfa in the login step) not sure, or maybe the login endpoint can receive the challenges IDs solved by the account creation step, (re using the recently solved challenges) * the ac token can be marked as 'mfa validated' with true/false * the timestamp_timeout can be translated into the token duration (when the server is asked for a token with duration X and timestamp_timeout is Y the server reply the token with duration min(X,Y) ) * when the SPA refresh the token the 'mfa validated' is NOT carried on to the next token | ||||
| Tags | No tags attached. | ||||
|
|
I like more the idea of associating the timeout with the challenge ID instead of the access token. If the "timestamp_timeout" is implemented as challenge duration and that duration also in the response then I can save those challenge ID in the localStorage of the SPA and reuse is for some new request and the server can decide if those challenge are good enough or the client requires new ones. |
