[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Taler] KYC support in GNU Taler (Part 1)

From: Christian Grothoff
Subject: [Taler] KYC support in GNU Taler (Part 1)
Date: Sat, 13 May 2023 23:36:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0

Dear all,

NLnet has generously decided to support the work of Taler Systems SA in implementing KYC support in GNU Taler. I'm writing to give you an update on the first milestone and possibly get some feedback on the most important part: the design. Work on the implementation is ongoing, and rapid progress is expected. That said, this is about the fundamentals.

is the new section in the exchange operator manual describing how an exchange operator would configure KYC plugins, trigger events, providers and so on. It also introduces these concepts. Feedback on anything being unclear in this chapter would be very welcome.

https://docs.taler.net/core/api-exchange.html#kyc-status-updates describes the REST API of the exchange. /kyc-wallet is only for the wallet, GET /kyc-check/ is for wallets or merchants that got a notification (HTTP status 451) that KYC is required to continue some operation. GET /kyc-proof/ allows certain KYC providers to tell the exchange that the process is done by redirecting a browser here. /kyc-webhook/ in turn allows providers to tell the exchange directly via a webhook.

Slightly more funky is our new reserve attestation API, which only indirectly has something to do with reserves:


Here, a wallet can request the KYC data stored by an exchange for a wallet. This is basically automating a GDPR-like information request for data stored by the exchange about a customer. However, it's a bit more, as the exchange offers to *cryptographically sign* arbitrary subsets of that data. This way, when a wallet sends an invoice for P2P payments, it can *choose* attach these attributes and the signature, thereby proving to the payer the origin of the invoice! Note that you need the private key of the reserve to get these attestations, and that attaching such data to an invoice is purely optional (and not yet implemented either). But I think this could be a cool feature against invoice fraud.

describes how we *store* the attributes in the database. The 'birthdate' is here to enable age restrictions, but I've been discussing with Oec to move it to the reserve and only keep it in plaintext for users that are actually minors and subject to age restrictions. What is important here is that the actual data are not stored in plaintext in the database but using (AES+GCM) encryption. This way, replications of the database (for example, at the auditor) won't have access. In fact, we could run a subset of the exchange HTTPDs with KYC access (by giving them the key) and others without --- and then use the reverse proxy to send only those HTTP requests that require access to the KYC data to the exchange HTTP processes that have that key, effectively further isolating the sensitive user data (and its key) from the main payment engine. (Note that legally we expect that exchange operators will need to store such data in their own database.)

https://git.taler.net/exchange.git/tree/src/exchangedb/0002-legitimization_requirements.sql and https://git.taler.net/exchange.git/tree/src/exchangedb/0002-legitimization_processes.sql are used to help us track KYC requirements and ongoing KYC operations.

Now for those that really want to read code:

* DB implementation is at
https://git.taler.net/exchange.git/tree/src/exchangedb/pg_insert_kyc_requirement_process.c and https://git.taler.net/exchange.git/tree/src/exchangedb/pg_insert_kyc_requirement_for_account.c and https://git.taler.net/exchange.git/tree/src/exchangedb/pg_insert_kyc_attributes.c and https://git.taler.net/exchange.git/tree/src/exchangedb/pg_lookup_kyc_process_by_account.c and https://git.taler.net/exchange.git/tree/src/exchangedb/pg_lookup_kyc_requirement_by_row.c and https://git.taler.net/exchange.git/tree/src/exchangedb/pg_select_kyc_attributes.c and https://git.taler.net/exchange.git/tree/src/exchangedb/pg_update_kyc_process_by_row.c and

* REST API server implementation is at
https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_kyc-check.c and https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_kyc-proof.c and https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_kyc-wallet.c and https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_kyc-webhook.c and https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_reserves_attest.c and

* REST API client implementation is at
https://git.taler.net/exchange.git/tree/src/lib/exchange_api_kyc_check.c and https://git.taler.net/exchange.git/tree/src/lib/exchange_api_kyc_proof.c and https://git.taler.net/exchange.git/tree/src/lib/exchange_api_kyc_wallet.c and

And finally, the crypto for the attribute encryption/decryption is here:

Next steps (I will post here when ready):
* AML support (WiP)
* Auditor support (not really started)
* Finish work on OAuth2.0 (largely done, but not tested well!)
* More work on KYCAid/Persona plugins (WiP)
* Work on wallet/merchant integrations (WiP)

Feedback welcome!

Happy hacking!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]