[taler-docs] branch master updated: further DD updates

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new fc04dcd  further DD updates
fc04dcd is described below

commit fc04dcde8609a528d38f9c61bd051898b602ea07
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sun Oct 3 15:23:06 2021 +0200

    further DD updates
---
 design-documents/023-taler-kyc.rst | 74 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)

diff --git a/design-documents/023-taler-kyc.rst 
b/design-documents/023-taler-kyc.rst
index 6047997..91489fc 100644
--- a/design-documents/023-taler-kyc.rst
+++ b/design-documents/023-taler-kyc.rst
@@ -95,6 +95,74 @@ We may want to consider directly deleting prewire records 
instead of setting
 them to ``finished`` in ``taler-exchange-transfer``.
 
 
+
+Exchange database schema changes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Note that there is may be some slight complication in the migration as the
+h_wire in deposits is salted, while the h_payto in the new wire_targets is
+expected to be unsalted. So converting the existing information to create the 
wire_targets table will be tricky!
+
+We can *either* not support a fully automatic migration, or do an "expensive"
+migration with C logic (so not just SQL statements).
+
+.. sourcecode:: sql
+
+  -- Everything in one big transaction
+  BEGIN;
+  -- Check patch versioning is in place.
+  SELECT _v.register_patch('exchange-TBD', NULL, NULL);
+  --
+  CREATE TABLE IF NOT EXISTS wire_targets
+  (wire_target_serial_id BIGSERIAL UNIQUE
+  ,h_payto BYTEA NOT NULL CHECK (LENGTH(h_payto)=64),
+  ,payto_uri STRING NOT NULL
+  ,kyc_ok BOOLEAN NOT NULL DEFAULT (false)
+  ,PRIMARY KEY (h_wire)
+  );
+  COMMENT ON TABLE wire_targets
+    IS 'All recipients of money via the exchange';
+  COMMENT ON COLUMN wire_targets.payto_uri
+    IS 'Can be a regular bank account, or also be a URI identifying a 
reserve-account (for P2P payments)';
+  COMMENT ON COLUMN wire_targets.h_payto
+    IS 'Unsalted hash of payto_uri';
+  COMMENT ON COLUMN wire_targets.kyc_ok
+    IS 'true if the KYC check was passed successfully';
+  --
+  -- NOTE: logic to fill wire_target missing, so this
+  -- CANNOT work if the database contains any data!
+  --
+  ALTER TABLE wire_out
+    ADD COLUMN wire_target_serial_id INT8 NOT NULL REFERENCES wire_targets 
(wire_target_serial_id),
+    DROP COLUMN wire_target;
+  COMMENT ON COLUMN wire_out.wire_target_serial_id
+    IS 'Identifies the target bank account and KYC status';
+  --
+  ALTER TABLE reserves_in
+    ADD COLUMN wire_source_serial_id INT8 NOT NULL REFERENCES wire_targets 
(wire_target_serial_id),
+    DROP COLUMN sender_account_details;
+  COMMENT ON COLUMN wire_out.wire_target_serial_id
+    IS 'Identifies the target bank account and KYC status';
+  --
+  ALTER TABLE reserves_close
+    ADD COLUMN wire_source_serial_id INT8 NOT NULL REFERENCES wire_targets 
(wire_target_serial_id),
+    DROP COLUMN receiver_account;
+  COMMENT ON COLUMN reserves_close.wire_target_serial_id
+    IS 'Identifies the target bank account and KYC status. Note that closing 
does not depend on KYC.';
+  --
+  ALTER TABLE deposits
+    ADD COLUMN wire_target_serial_id INT8 NOT NULL,
+    DROP COLUMN h_wire,
+    DROP COLUMN wire;
+  COMMENT ON COLUMN deposits.wire_target_serial_id
+    IS 'Identifies the target bank account and KYC status';
+  -- Complete transaction
+  COMMIT;
+
+
+TODO: Check if we missed miss any tables to migrate!
+
+
 Merchant modifications
 ^^^^^^^^^^^^^^^^^^^^^^
 
@@ -167,6 +235,12 @@ this may create issues if multiple KYC processes are 
initiated for the same
 entity (and this is likely not detectable by the bank at that time). Also,
 this information would again not be reasonably verifiable by the auditor.
 
+The exchange could periodically check the KYC status with the bank instead of
+relying on the proposed explicit management KYC revocation API. This may make
+revocation simpler for the bank, but OTOH may create many additional useless
+API requests to the bank's KYC infrastructure.
+
+
 
 Drawbacks
 =========

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.