dd23: security requiremetns

1 files changed, 61 insertions, 6 deletions

diff --git a/design-documents/023-taler-kyc.rst b/design-documents/023-taler-kyc.rst
index e6addbdd..c6898eab 100644
--- a/design-documents/023-taler-kyc.rst
+++ b/design-documents/023-taler-kyc.rst
@@ -46,12 +46,11 @@ Taler needs to take *measures* based on the following primary *triggers*:
 * Import of new sanctions lists and triggering of measures against matches of existing
   customer records against the list
 
-For the different operation types, there can be both soft
-and hard limits. Soft limits are those that the customer
-may raise by providing data and passing KYC checks.
-Hard limits cannot be lifted, for example because an
-exchange forbids crossing those limits in its terms of
-service for all customers.
+For the different operation types, there can be both soft and hard
+limits. Soft limits are those that the customer may raise by providing data
+and passing KYC checks.  Hard limits cannot be lifted, for example because an
+exchange forbids crossing those limits in its terms of service for all
+customers.
 
 
 Process requirements
@@ -148,6 +147,22 @@ be tracked in the system statistics:
 * account closed
 
 
+Security requirements
+^^^^^^^^^^^^^^^^^^^^^
+
+IBANs are predictable. We (probably) do not want random people to be able to
+initate KYC processes for other parties. Similarly, the attestation API
+requires us to somehow *authenticate* the user to ensure we only give out
+attestation data to the data subject themselves. For P2P payments and
+withdrawals, we have the reserve public key that is only known to the data
+subject and thus can be used to authenticate the client via a signature. Only
+pure deposits (by merchants or directly from a wallet) are a problem as the
+only thing we know about the receiver is the IBAN at that time, and literally
+any user could just deposit money into some bank account, so knowledge of the
+IBAN is insufficient to determine that we actually are communicating with the
+owner of the bank account.
+
+
 Further considerations
 ^^^^^^^^^^^^^^^^^^^^^^
 
@@ -279,6 +294,46 @@ Terminology
   wallet) and (high) wallet balance.
 
 
+Account owner authentication
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When we need to authenticate a bank account owner, we will simply require them
+to make an outgoing wire transfer into the exchange bank account with a public
+key in the wire transfer subject (just like when withdrawing), but augmented
+with the string "KYC" so we can distinguish the wire transfer from a regular
+withdrawal. Typically, we would put the merchant public key into the wire
+transfer subject; wallets MAY put their long-term reserve public key instead.
+The amount to be transferred is the *KYC fee*.
+
+This has several advantages:
+
+* Only the account owner can provide us with the public key, so we already
+  have also one super-hard piece of KYC evidence.
+* If the account owner looses their public key, it's not a problem: they
+  would just have to do the transfer again with a new key. No need for
+  us to do any kind of intervention for key management.
+* We could theoretically get paid to do the KYC process, or just "charge" a
+  nominal amount.
+* This also somewhat addresses the payment for voluntary KYC processes where
+  a merchant wants to do KYC to get us to attest their identity for their
+  customers even if we do not yet have a legal need.  The only issue here
+  is that this does not work if voluntary KYC is invoiced while mandatory
+  KYC is gratis. But, that kind of configuration is a business decision
+  and there is no hard need to support it immediately.
+* This definitively addresses the need for authentication to access the
+  attestation API, which so far was only available for P2P payments as
+  we could not authenticate merchants.
+* The "KYC" string allows us to distinguish the authentication transfers from
+  withdrawal transfers; by keeping the KYC fee at or below the closing fee,
+  we can even deploy this without fully updating the logic everywhere to
+  distinguish KYC transfers
+
+TODO: update wire gateway specification, update/new tables for KYC wire
+transfers, update API spec for attestation, update exchange API (below) to
+signal need for auth-payment via wire transfer, update merchant logic to
+expose merchant public key to SPA for wire transfer if needed for KYC.
+
+
 451 Response
 ^^^^^^^^^^^^