[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-docs] branch master updated: DD21
From: |
gnunet |
Subject: |
[taler-docs] branch master updated: DD21 |
Date: |
Tue, 25 May 2021 13:46:35 +0200 |
This is an automated email from the git hooks/post-receive script.
dold pushed a commit to branch master
in repository docs.
The following commit(s) were added to refs/heads/master by this push:
new f5fd51d DD21
f5fd51d is described below
commit f5fd51d99522e9e8d61a3f8af7d345134642568f
Author: Florian Dold <florian@dold.me>
AuthorDate: Tue May 25 13:36:30 2021 +0200
DD21
---
design-documents/021-exchange-key-continuity.rst | 75 ++++++++++++++++++++++++
design-documents/index.rst | 1 +
2 files changed, 76 insertions(+)
diff --git a/design-documents/021-exchange-key-continuity.rst
b/design-documents/021-exchange-key-continuity.rst
new file mode 100644
index 0000000..d6e9ad9
--- /dev/null
+++ b/design-documents/021-exchange-key-continuity.rst
@@ -0,0 +1,75 @@
+Design Doc 020: Exchange Key Continuity
+#######################################
+
+Summary
+=======
+
+This design document discusses what happens if
+an exchange's master public key ever changes.
+
+Motivation
+==========
+
+The exchange master public key is an offline signing key. While this makes
+compromise of this key less likely, it makes it more likely that this key is
+lost.
+
+The wallet (and merchants) must handle such a scenario where the
+exchange deploys a new master public key.
+
+Proposed Solution
+=================
+
+When wallets or merchants specify that they directly trust
+an exchange, the trust record must always explicitly mention
+a base URL and a master public key.
+
+An exchange **should** have a single, canonical base URL.
+However, an exchange thats reachable over different base URLs
+should still be handled gracefully.
+
+Wallet
+------
+
+We generally assume that the base URL of an exchange stays constant.
+Wallets do not support changing the base URL of an exchange.
+
+A ``/keys`` response with an unknown exchange master public key is only
+accepted if the exchange is audited by a trusted auditor or the wallet
+has an exchange trust record with the advertised master public key.
+
+Denomination records explicitly store which master public key
+signed them.
+
+Merchant
+--------
+
+When coins are deposited, the wallet only specifies the base URL
+for the respective exchange, but not the master public key of the exchange.
+The merchant **must** always
+resolve the URL to the current master public key,
+and decide whether to accept the exchange based only
+on the master public key. That is, a merchant
+may not reject an exchange because the wallet is not
+specifying what the merchant believes to be the
+canonical base URL.
+
+
+Alternatives
+============
+
+* The wallet could treat each (base URL, master pub) pair as a
+ separate exchange. This, however, does not work in practice,
+ since the exchange with the new public key should still accept
+ deposits and refreshes of coins with denominations signed by the
+ old key.
+
+
+Discussion / Q&A
+================
+
+* Does the current merchant backend have support
+ for changing master public keys of exchanges trusted
+ via the auditor? Or does the code base make the assumption
+ that one merchant base URL corresponds to only one master
+ public key?
diff --git a/design-documents/index.rst b/design-documents/index.rst
index 737226c..ae95dc1 100644
--- a/design-documents/index.rst
+++ b/design-documents/index.rst
@@ -29,4 +29,5 @@ and protocol.
018-contract-json
019-wallet-backup-merge
020-backoffice-tips-management
+ 021-exchange-key-continuity
999-template
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-docs] branch master updated: DD21,
gnunet <=