From 561e76a26b1e63e6c604c427799de6a8ae69939d Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sun, 18 Sep 2022 11:34:06 +0200 Subject: note on #7365 --- design-documents/023-taler-kyc.rst | 14 ++++++++++++-- design-documents/031-invoicing.rst | 16 +++++++--------- 2 files changed, 19 insertions(+), 11 deletions(-) (limited to 'design-documents') diff --git a/design-documents/023-taler-kyc.rst b/design-documents/023-taler-kyc.rst index 410c4d85..bfc6e514 100644 --- a/design-documents/023-taler-kyc.rst +++ b/design-documents/023-taler-kyc.rst @@ -17,6 +17,8 @@ banks to identify parties involved in transactions at certain points. Requirements ============ +The solution should support fees to be paid by the user for the KYC process (#7365). + Taler needs to run KYC checks in the following circumstances: * Customer withdraws money over a monthly threshold @@ -38,6 +40,10 @@ Taler needs to run KYC checks in the following circumstances: * key: IBAN (encoded as payto:// URI) +* Reserve is "opened" for invoicing or tipping. + + * key: reserve (=KYC account) long term public key per wallet (encoded as payto:// URI) + Proposed Solution @@ -97,8 +103,8 @@ Access is ``authenticated`` by also passing the hash of the payto://-URI. initiate a KYC process are not very sensitive.) Given this triplet, the ``/kyc-check/`` endpoint returns either the (positive) KYC status or redirects the client (202) to the next required stage of the KYC process. The -redirection must be for an HTTP(S) endpoint to be triggered via a simple HTTP -GET. +redirection must be for an HTTP(S) endpoint to be triggered via a simple HTTP GET. As this endpoint is involved in every KYC check at the beginning, this is also the place where we can +integrate the payment process for the KYC fee. The specific KYC provider to be executed depends on the configuration (see below) which specifies a ``$PROVIDER_SECTION`` for each authentication procedure. @@ -310,6 +316,10 @@ long-poller return with positive news. 128-bit salt values (to keep ``deposits`` table small) and checks for salt to be well-formed should be added "everywhere". +An additional complication will arise once the exchange can trigger a KYC +fee (402) on ``/kyc-check/``. In this case, the merchant SPA must show the QR +code to the merchant to allow the merchant to pay the KYC fee with a wallet. + Bank requirements diff --git a/design-documents/031-invoicing.rst b/design-documents/031-invoicing.rst index 24c64d79..419c299d 100644 --- a/design-documents/031-invoicing.rst +++ b/design-documents/031-invoicing.rst @@ -29,21 +29,19 @@ Requirements (or require purse fees if limit is exceeded). * Ensure user has done KYC before doing a merge. - - * Support fees to be paid by the user for KYC process. + (Assuming the exchange does KYC at all.) * Use information from KYC process to help payer identify payee. * Reasonable UX and overall design impact. -Unclear in the current proposal are: + * Wallets may want to pay for the reserve with coins + (reserve fresh, not created via bank transfer), while + tipping merchants likely want to pay from the reserve + balance itself. So both styles of payment should be + supported. - * How to pay for the opening. Do we support the use of - coins, or should we require the user to have a - sufficient balance in the reserve, or do we allow - both? Probably best to only support one. As - reserves are typically instant-drained by the - wallet, might be best to require coins? +Unclear in the current proposal are: * Here (and in other places!), the payment of the KYC fee remains, eh, obscure. This should probably be -- cgit v1.2.3