DD23 WIP

3 files changed, 131 insertions, 0 deletions

diff --git a/design-documents/022-wallet-auditor-reports.rst b/design-documents/022-wallet-auditor-reports.rst
new file mode 100644
index 00000000..0df5e427
--- /dev/null
+++ b/design-documents/022-wallet-auditor-reports.rst
@@ -0,0 +1,54 @@
+DD22: Wallet Proofs to Auditor
+##############################
+
+.. note::
+
+   Status (2021-05-25): Writing in progress.
+
+
+Summary
+=======
+
+This design document defines the structure and contents of proofs
+of misbehavior that the wallet sends to auditors.
+
+Motivation
+==========
+
+There are some situations where the wallet learns that some entity did
+something against the protocol specification.  When the wallet has
+cryptographic proof for this, this proof should be stored in the database and
+eventually be exportable to auditors, courts, etc.
+
+Requirements
+============
+
+* Users should be able to review all the information that
+  a misbehavior proof would reveal.
+
+Proposed Solution
+=================
+
+Types of Misbehavior
+--------------------
+
+This section collects all types of misbehavior for which the wallet
+can export cryptographic proof.
+
+* ``exchange-denomination-spec-inconsistent``
+
+  An exchange has announced a denomination with the same
+  denomination public key, but different metadata (value, expiration)
+
+* ``exchange-denomination-gone``
+
+  The exchange is not accepting/listing a denomination
+  anymore that it previously listed.
+
+
+Discussion / Q&A
+================
+
+* What about complaints to the auditor that do not contain
+  cryptographic proof?  (e.g. "exchange XYZ has not been responding
+  for the last 14 days")
diff --git a/design-documents/023-taler-kyc.rst b/design-documents/023-taler-kyc.rst
new file mode 100644
index 00000000..aba65a9a
--- /dev/null
+++ b/design-documents/023-taler-kyc.rst
@@ -0,0 +1,76 @@
+DD 023: Taler KYC
+#################
+
+Summary
+=======
+
+This document discusses the KYC processes supported by Taler.
+
+
+Motivation
+==========
+
+
+Requirements
+============
+
+Taler needs to run KYC checks in the following circumstances:
+
+* Customer withdraws money over a monthly threshold
+
+  * exchange triggers KYC
+  * key: IBAN
+
+* Wallet receives (via refunds) money over a monthly threshold
+
+  * this is a client-side restriction
+  * key: reserve public key (generated, long-term)
+
+* Wallet receives money via P2P payments
+
+  * key: reserve (=KYC account) public key
+
+* Merchant receives money above a monthly threshold
+
+  * key: IBAN
+
+
+Proposed Solution
+=================
+
+The new taler-kyc-ledger component keeps track of a mapping between an
+identifier (as a payto URI?) and a KYC status (yes-merchant, yes-customer, no,
+progress (with resume link)).  Different identifiers might be mapped by the
+bank's KYC provider to the same legal user entity.
+
+Identifier:
+
+* IBAN
+* reserve / account
+
+What info do we look at to determine if threshold is crossed / being crossed?
+
+[ ... ]
+
+FIXME: Who keeps track of the threshold?
+* since the kyc-ledger might be run by the bank and
+  not the exchange, the thresholds could/should be kept by
+  the exchange
+
+* kyc-ledger vs kyc-provider
+
+
+Alternatives
+============
+
+None unless we want regulatory compliance?
+
+
+Drawbacks
+=========
+
+
+Discussion / Q&A
+================
+
+(This should be filled in with results from discussions on mailing lists / personal communication.)
diff --git a/design-documents/index.rst b/design-documents/index.rst
index f5b8a93e..f97117ef 100644
--- a/design-documents/index.rst
+++ b/design-documents/index.rst
@@ -30,4 +30,5 @@ and protocol.
   020-backoffice-tips-management
   021-exchange-key-continuity
   022-wallet-auditor-reports
+  023-taler-kyc
   999-template