DD13: make contract terms mandatory, clarify fee limits

1 files changed, 17 insertions, 7 deletions

diff --git a/design-documents/013-peer-to-peer-payments.rst b/design-documents/013-peer-to-peer-payments.rst
index 8087af5a..9666a85b 100644
--- a/design-documents/013-peer-to-peer-payments.rst
+++ b/design-documents/013-peer-to-peer-payments.rst
@@ -7,6 +7,7 @@ Summary
 This design document proposes an extension of the Taler protocol that allows
 payments from wallet-to-wallet without a merchant.
 
+
 Motivation
 ==========
 
@@ -88,8 +89,11 @@ Principles
 ----------
 
 * Purses are ephemeral and only serve for one transaction.
-* Each purse is associated with a contract and an expiration date.
-* The contract is stored encrypted at the exchange.
+* The purse's transaction amount is fixed when the purse is created, and
+  specified together with the maximum deposit fee acceptable to the payee.
+  Deposit fees exceeding this limit must be paid by the payer.
+* Each purse is associated with a contract terms hash and an expiration date.
+* The contract is optionally stored encrypted at the exchange.
   The contract must be encrypted to the purse private key.
   An additional ephemeral public key (for DH encryption) should be
   part of the POSTed payload.
@@ -245,7 +249,7 @@ In this protocol variant, the payer is initiating the process.
 
 1. The payer creates a **purse** by computing a public-private key pair.
 2. The payer POSTs to the ``/purse/$PURSE_PUB/depost`` endpoint to
-   both upload the encrypted contract and deposit coins into the purse.
+   deposit coins into the purse and optionally upload the encrypted contract terms.
    The deposit signatures should use ``payto://taler/$PURSE_PUB``
    as the target address and signing over the ``$CONTRACT_HASH`` as
    usual in deposit operations. Note that the lack of a hostname
@@ -254,11 +258,17 @@ In this protocol variant, the payer is initiating the process.
    of the exchange where the purse was created with the payee.
    This can be done using a ``taler://purse/$BASE_URL/$PURSE_PRIV`` URL.
 4. The payee uses the new ``/purse/$PURSE_PUB`` endpoint to retrieve
-   the encrypted contract and purse balance, which includes all
+   the encrypted contract (if available) and purse balance, which includes all
    (coin) deposits and **merges** involving the purse.
-5. Deposits with a non-zero contract hash have an underlying contract.
-   The contract terms are shown to the payee to have them agree
-   to the contract before proceeding with the **merge** step.
+5. The payee's wallet must ensure that either:
+
+   a. The purse has an attached encrypted contract terms, the contract
+      terms can be decrypted and are valid, and their hash matches the contract
+      terms hash of the purse.
+   b. The wallet received detached contract terms, and their hash matches
+      contract terms of the purse.
+
+   If neither case applies, the payee's wallet must reject the payment.
 6. The payee can then POST to ``/purse/$PURSE_PUB/merge`` a
    request signed by the purse's private key to **merge** the
    funds into an account.  A second signature must be provided