View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007304 | Taler | exchange | public | 2022-08-20 19:28 | 2024-12-13 18:15 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | 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 | normal | Severity | tweak | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 0.14 | Fixed in Version | 0.14 | ||
| Summary | 0007304: should we normalize payto://-URIs in the exchange before hashing? [5d] | ||||
| Description | We use the h_payto to re-identify accounts during KYC. It is used as the sharding key, and also in the protocol. In _most_ places (except for the GET /deposits/, where the client is really expected to already know the h_payto) the exchange now does return it to the client, so the client doesn't have to compute the hash itself. Still, normalization will make it "easier" to not accidentally re-require the (expensive) KYC process when little things have changed, such as a BIC in an 'iban' URI or capitalization of hostnames (x-taler-bank) or similar small shitty changes that don't matter (including possibly the 'receiver-name' as set by LibEuFin). Whether to normalize and how is an open question. Where is pretty clear: the payto-uri hashes are all computed in libtalerutil in one function. | ||||
| Tags | No tags attached. | ||||
| Conclusion of the discussion has been that the only component that should normalize is the merchant (spa/backoffice) before hashing the payto://-URI and sending it to the exchange for payment. | |
| We should discuss which normalizations should be one. Candidates: - lower-case everything (including receiver-name) - upper-case everything (including receiver-name) - remove BIC from iban/ payto://-URIs Other? | |
| Related issue: fakebank revenue API returns payto with receiver-name, libeufin returns it without receiver name. Merchant backend stores it with receiver-name, but has to match without it. See SUBSTRING logic around payto we used to match. Very inefficient (but OK, we have very few entries in that table), but primarily indicative of an issue: we index and match by payto://-URI, but don't have a proper normal form! | |
| @Christian could you please remind me why we want to keep the receiver name before hashing? I recall there was some reason, but I'm not sure anymore what it was. | |
| I think there are different parts of the protocol with different objectives. If a merchant backend wants to instruct an exchange where to wire the funds and provides a payto://-URI with receiver name, we want to hash that payto://-URI with the receiver name as that is part of the instruction and thus should also be included in what is digitally signed. And if the receiver name changes and thus the hash changes, that's pretty harmless, it only prevents aggregation across the different receiver names, which might actually be a very good thing. That's completely different from other use-cases of payto://! | |
| It'll be a mighty messy migration if we do this once AML/KYC data is in the system. Maybe this is actually the time to introduce a TalerNormalizedPaytoHashP or something like that. And then go over all existing use-cases and figure out which one is what. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-08-20 19:28 | Christian Grothoff | New Issue | |
| 2022-08-20 19:28 | Christian Grothoff | Status | new => assigned |
| 2022-08-20 19:28 | Christian Grothoff | Assigned To | => Florian Dold |
| 2022-08-23 08:29 | Christian Grothoff | Note Added: 0019025 | |
| 2022-08-23 08:31 | Christian Grothoff | Note Added: 0019026 | |
| 2022-08-23 08:31 | Christian Grothoff | Assigned To | Florian Dold => |
| 2022-08-23 08:31 | Christian Grothoff | Priority | urgent => normal |
| 2022-08-23 08:31 | Christian Grothoff | Status | assigned => feedback |
| 2022-10-20 09:16 | Christian Grothoff | Target Version | 0.9 => 0.9.1 |
| 2022-10-20 09:41 | Christian Grothoff | Priority | normal => low |
| 2022-10-20 09:41 | Christian Grothoff | Target Version | 0.9.1 => |
| 2023-04-04 17:30 | Florian Dold | Product Version | git (master) => 0.11 |
| 2023-04-04 17:31 | Florian Dold | Product Version | 0.11 => git (master) |
| 2023-04-04 17:31 | Florian Dold | Target Version | => 0.11 |
| 2023-12-22 14:12 | Christian Grothoff | Target Version | 0.11 => post-1.0 |
| 2023-12-24 05:30 | Christian Grothoff | Status | feedback => acknowledged |
| 2024-01-28 21:25 | Christian Grothoff | Note Added: 0021064 | |
| 2024-01-30 12:08 | Florian Dold | Note Added: 0021088 | |
| 2024-01-30 12:20 | Christian Grothoff | Note Added: 0021089 | |
| 2024-01-30 13:07 | Antoine A | Relationship added | related to 0008287 |
| 2024-09-09 18:13 | Christian Grothoff | Priority | low => normal |
| 2024-09-09 18:13 | Christian Grothoff | Target Version | post-1.0 => 1.0 |
| 2024-09-09 18:25 | Christian Grothoff | Note Added: 0023221 | |
| 2024-09-13 23:12 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2024-09-13 23:12 | Christian Grothoff | Status | acknowledged => assigned |
| 2024-09-16 21:54 | Christian Grothoff | Summary | should we normalize payto://-URIs in the exchange before hashing? => should we normalize payto://-URIs in the exchange before hashing? [2d] |
| 2024-10-31 09:27 | Christian Grothoff | Summary | should we normalize payto://-URIs in the exchange before hashing? [2d] => should we normalize payto://-URIs in the exchange before hashing? [5d] |
| 2024-11-05 11:29 | Christian Grothoff | Status | assigned => informing |
| 2024-11-05 11:29 | Christian Grothoff | Resolution | open => fixed |
| 2024-11-05 11:29 | Christian Grothoff | Fixed in Version | => 0.14 |
| 2024-11-05 11:29 | Christian Grothoff | Target Version | 1.0 => 0.14 |
| 2024-12-13 18:15 | Christian Grothoff | Status | informing => closed |