diff options
-rw-r--r-- | design-documents/022-wallet-auditor-reports.rst | 54 | ||||
-rw-r--r-- | design-documents/023-taler-kyc.rst | 76 | ||||
-rw-r--r-- | design-documents/index.rst | 1 |
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 |