further DD updates

1 files changed, 74 insertions, 0 deletions

diff --git a/design-documents/023-taler-kyc.rst b/design-documents/023-taler-kyc.rst
index 60479979..91489fc4 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
 =========