[taler-docs] branch master updated: DD13: make contract terms mandatory, clarify fee limits

[gnunet]

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 c1b3f19  DD13: make contract terms mandatory, clarify fee limits
c1b3f19 is described below

commit c1b3f19ccd6f052599ba09b89e3446cec6b50e33
Author: Florian Dold <florian@dold.me>
AuthorDate: Mon Apr 26 17:01:38 2021 +0200

    DD13: make contract terms mandatory, clarify fee limits
---
 design-documents/013-peer-to-peer-payments.rst | 24 +++++++++++++++++-------
 1 file 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 8087af5..9666a85 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

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.