View Issue Details

IDProjectCategoryView StatusLast Update
0007304Talerexchangepublic2024-01-30 14:07
ReporterChristian Grothoff Assigned To 
Status acknowledgedResolutionopen 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product Versiongit (master) 
Target Versionpost-1.0 
Summary0007304: should we normalize payto://-URIs in the exchange before hashing?
DescriptionWe 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.
TagsNo tags attached.


related to 0008287 closedAntoine A Correction to the way we manage payto uris 


Christian Grothoff

2022-08-23 10:29

manager   ~0019025

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.

Christian Grothoff

2022-08-23 10:31

manager   ~0019026

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


Christian Grothoff

2024-01-28 22:25

manager   ~0021064

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!

Florian Dold

2024-01-30 13:08

manager   ~0021088

@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.

Christian Grothoff

2024-01-30 13:20

manager   ~0021089

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://!

Issue History

Date Modified Username Field Change
2022-08-20 21:28 Christian Grothoff New Issue
2022-08-20 21:28 Christian Grothoff Status new => assigned
2022-08-20 21:28 Christian Grothoff Assigned To => Florian Dold
2022-08-23 10:29 Christian Grothoff Note Added: 0019025
2022-08-23 10:31 Christian Grothoff Note Added: 0019026
2022-08-23 10:31 Christian Grothoff Assigned To Florian Dold =>
2022-08-23 10:31 Christian Grothoff Priority urgent => normal
2022-08-23 10:31 Christian Grothoff Status assigned => feedback
2022-10-20 11:16 Christian Grothoff Target Version 0.9 => 0.9.1
2022-10-20 11:41 Christian Grothoff Priority normal => low
2022-10-20 11:41 Christian Grothoff Target Version 0.9.1 =>
2023-04-04 19:30 Florian Dold Product Version git (master) => 0.11
2023-04-04 19:31 Florian Dold Product Version 0.11 => git (master)
2023-04-04 19:31 Florian Dold Target Version => 0.11
2023-12-22 15:12 Christian Grothoff Target Version 0.11 => post-1.0
2023-12-24 06:30 Christian Grothoff Status feedback => acknowledged
2024-01-28 22:25 Christian Grothoff Note Added: 0021064
2024-01-30 13:08 Florian Dold Note Added: 0021088
2024-01-30 13:20 Christian Grothoff Note Added: 0021089
2024-01-30 14:07 Antoine A Relationship added related to 0008287