diff options
Diffstat (limited to 'design-documents')
| -rw-r--r-- | design-documents/020-backoffice-tips-management.rst | 97 | ||||
| -rw-r--r-- | design-documents/021-exchange-key-continuity.rst | 75 | ||||
| -rw-r--r-- | design-documents/index.rst | 3 |
3 files changed, 175 insertions, 0 deletions
diff --git a/design-documents/020-backoffice-tips-management.rst b/design-documents/020-backoffice-tips-management.rst new file mode 100644 index 00000000..566f8fb5 --- /dev/null +++ b/design-documents/020-backoffice-tips-management.rst @@ -0,0 +1,97 @@ +Design Doc 020: Backoffice Tips Management +########################################## + +Summary +======= + +This document describe the complete list features for tips and reserve +management and how will be shown. + +Motivation +========== + +User will use the backoffice to manage reserve and authorize + +Requirements +============ + +User should use the backoffice to: + +* creating new reserves +* listing active reserves +* authorize tips for a reserve +* list all tips for an active reserve +* check tips status + +Proposed Solution +================= + +Listing reserves +---------------- + +.. image:: ../backoffice-reserve-list.svg + :width: 400 + + +Can be filtered with optional arguments: + +* after: if present will brings reserve created after specified date + +* active: if present will bring reserve active (or inactive), otherwise all + +* failures: if present will bring all reserves that have different initial + balance reported by the exchange (or equal), otherwise all + +columns: + +* initial: if the exchange and merchant-backend disagree in the initial balance + (failure) the cell will be red and have a tooltip with more information + +* actions: delete button will be disabled on failure or committed > 0, new_tip + button will be disabled on picked_up == initial or failure + + +Create new reserve +------------------ + +.. image:: ../backoffice-reserve-create.svg + :width: 400 + +fields: + +* initial balance must be >0 and the current currency + +* exchange should be a known exchange of the merchant backend + +* wire method should be one of the current supported of the instance + +If there is an error in the creation a Notification message will be shown + +Authorize Tip +------------- + +The merchant can authorize tips clicking in the plus (+) button that will bring +the next popup + +.. image:: ../backoffice-tip-create.svg + :width: 400 + +after confirm it will continue with a success page: + +.. image:: ../backoffice-tip-create.confirmation.svg + :width: 400 + +Details of reserve +---------------------------- + +.. image:: ../backoffice-reserve-details.svg + :width: 400 + +Tips sorted from newer to older + +When the reserve has not yet funded + +.. image:: ../backoffice-reserve-details.unfunded.svg + :width: 400 + + diff --git a/design-documents/021-exchange-key-continuity.rst b/design-documents/021-exchange-key-continuity.rst new file mode 100644 index 00000000..e09b6fe0 --- /dev/null +++ b/design-documents/021-exchange-key-continuity.rst @@ -0,0 +1,75 @@ +Design Doc 021: 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 that's 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 advertized 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 d0ccef22..7f875095 100644 --- a/design-documents/index.rst +++ b/design-documents/index.rst @@ -28,4 +28,7 @@ and protocol. 017-backoffice-inventory-management 018-contract-json 019-wallet-backup-merge + 020-backoffice-tips-management + 021-exchange-key-continuity + 022-wallet-auditor-reports 999-template |