DD 80: Short wire transfer subjects

18.80. DD 80: Short wire transfer subjects#

18.80.1. Summary#

Some mediums and clients do not support subjects big enough to fit an entire reserve public key. We need to add an endpoint to link a reserve public key to shorter sequences than can fit.

18.80.2. Problem#

18.80.2.1. User-provided config vs backend config#

Short wire subjects will be generated based on a size and an alphabet. The supported alphabet would be:

  • numeric 0-9

  • uppercase_alphanumeric A-Z0-9

  • alphanumeric a-zA-Z0-9

We could add other alphabets with symbols or lowercase only, but from experience, the most restrictive system that only accepts small wire transfer subject are also very restrictive about the accepted characters.

Then remains the question of who will decide those parameters: the user or the backend administrator. I would be simpler to let the administrator configure this, but this mean than a user with a special, more restrictive client won’t be able to use our system. Maybe the backend provides a default, and the user can override?

18.80.2.2. Handling small encoding space#

Using a very restricive alphabet like numeric and a very short wire subject lenght can leed us to quickly exaust most of the encoding space. We might need a way to recycle old short subjects.

18.80.2.3. Parsing unstructure subject#

We currently support two kinds of keys: reserve keys and KYC keys. We expect to need more key kind in the future, and using new crypto will make the encoded keys bigger.

A reserve key looks like this: 00Q979QSMJ29S7BJT3DDAVC5A0DR5Z05B7N0QT1RCBQ8FXJPZ6RG

And a KYC key like this: KYC:NDDCAM9XN4HJZFTBD8V6FNE2FJE8GY734PJ5AGQMY06C8D4HB3Z0

We quickly found that users inputing those keys had a tendency to add undesirable separators and worst, some client even add them automatically. Those users where than very frustrated by the experience and somtimes where completly prevented from using Taler. We therefore came up with a solution to parse unstructured subjects like this one:

Taler KIC:NDDCAM9XN4HJZFTBD8V6FNE2FJE8G Y734PJ5AGQMY06C8D4HB3Z0

We first remove all non-alphanumeric ASCII characters to get some chunks:

Taler KYC NDDCAM9XN4HJZFTBD8V6FNE2FJE8G Y734PJ5AGQMY06C8D4HB3Z0

We then try to assemble chunks until they form a potential valid key:

TalerKYC TalerKYCNDDCAM9XN4HJZFTBD8V6FNE2FJE8G TalerKYCNDDCAM9XN4HJZFTBD8V6FNE2FJE8GY734PJ5AGQMY06C8D4HB3Z0 KYCNDDCAM9XN4HJZFTBD8V6FNE2FJE8G KYCNDDCAM9XN4HJZFTBD8V6FNE2FJE8GY734PJ5AGQMY06C8D4HB3Z0

Then we decode the key and check if they are valid public key.

There is also a bit of logic to handle cases where many valid keys are found to prefer the one that looks the most legit (KYC prefixed, uppercase only, etc).

Decoding the key and checking it is expensive, but this whole algo stayed fast because we knew the possible sizes of the encoded keys, either 52 chars for a reserve key or 52 + 3 for a KYC prefixed key. Therefore, most of the assemble chunks where skipped, and we only rarely had to run the expensive decoding logic more than once.

Short subject will be of variable sizes, either because of user config or because of backend configuration changes. We need to chose if and how we want handle this with unstructured subjects.

We can either expect the full subject to be the short one. In that case, it’s, simple, we just remove al non ASCII alphanumeric and make a single search in the database.

Or we reuse the chunk logic and match many potential keys in a single DB query. The problem with this is that this can be expensive as the number of possible chunk is exponential and a bad user could create a very specific subject that create many combination.

18.80.3. Proposed Solution#

TODO