View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009109 | Taler | exchange | public | 2024-08-21 22:03 | 2024-09-11 22:06 |
| Reporter | sebasjm | Assigned To | sebasjm | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | low | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | won't fix | ||
| Product Version | git (master) | ||||
| Target Version | 0.14 | Fixed in Version | 0.14 | ||
| Summary | 0009109: the exchange should provide the kyc-spa location to the wallet | ||||
| Description | after the wallet gets a LegitimizationNeededResponse the user should be redirected to the exchange spa wallet should be able to construct this URL without hardcoding we may: 1.- return the actual URL in the LegitimizationNeededResponse 2.- return a template in the /config or /keys endpoint (if kyc is enabled) | ||||
| Tags | No tags attached. | ||||
| Why? The URL is defined as $BASE_URL/kyc-spa/$ACCESS_TOKEN. What is wrong with this? | |
| because having this a spec which the wallet needs to follow is confusing. I needed to fix a routing problem in the exchange ($BASE_URL/kyc-spa/$ACCESS_TOKEN as returning 404 ) also affecting kyc-spa (the workaround was sending the accToken in the fragment $BASE_URL/kyc-spa/#/token/$ACCESS_TOKEN ) to find out that this was implemented in the wallet (!!) because of the spec. much saner is to allow the exchange to return `kyc_spa_url` instead of the `access_token` here [1], construct the URL in the exchange (why ask the wallet to do this?) not a blocker in any sense, moving to 1.0-stretch [1] https://docs.taler.net/core/api-exchange.html#get--kyc-check-$REQUIREMENT_ROW | |
| The access token is more flexible. It allows us to use this value for other endpoints in the future. It also allows us to define alternative endpoints in future versions of the protocol, and to migrate to those nicely. For example, a future wallet may directly access and interpret /kyc-info/$ACCESS_TOKEN/, instead of only redirecting to the KYC SPA. Finally, it reduces bandwidth and redundant data transmission as the client/wallet already knows the exchange base URL and must already understand the endpoint (and its path!) to correctly interact with it. I really don't see this as a necessary or even positive change! | |
| /kyc-spa/$ACCESS_TOKEN should also not 404, unless the access token is invalid. If the SPA cannot do the redirect to /#/token/$ACCESS_TOKEN, I think it's in principle fine to do this in the exchange. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-08-21 22:03 | sebasjm | New Issue | |
| 2024-08-21 22:03 | sebasjm | Status | new => assigned |
| 2024-08-21 22:03 | sebasjm | Assigned To | => Christian Grothoff |
| 2024-08-22 12:41 | Christian Grothoff | Note Added: 0023029 | |
| 2024-08-22 22:25 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2024-08-22 22:25 | Christian Grothoff | Status | assigned => feedback |
| 2024-08-30 13:14 | sebasjm | Note Added: 0023120 | |
| 2024-08-30 13:14 | sebasjm | Target Version | 0.14 => 1.0 stretch goals |
| 2024-08-30 13:14 | sebasjm | Assigned To | sebasjm => Christian Grothoff |
| 2024-09-01 09:49 | Christian Grothoff | Note Added: 0023124 | |
| 2024-09-01 09:52 | Christian Grothoff | Note Added: 0023125 | |
| 2024-09-01 09:52 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2024-09-11 16:43 | sebasjm | Status | feedback => informing |
| 2024-09-11 16:43 | sebasjm | Resolution | open => won't fix |
| 2024-09-11 22:06 | Christian Grothoff | Product Version | 1.2 => git (master) |
| 2024-09-11 22:06 | Christian Grothoff | Fixed in Version | => 0.14 |
| 2024-09-11 22:06 | Christian Grothoff | Target Version | 1.0 stretch goals => 0.14 |
| 2024-09-11 22:06 | Christian Grothoff | Status | informing => closed |