commit 31aa125199afacf57c31e789545ec715d3637333
parent 471489d6d9e1683971136e60831b3835a125607a
Author: Jeff Burdges <burdges@gnunet.org>
Date: Fri, 30 Oct 2015 11:23:20 +0100
Yet more minor changes, this time to the merchant
Diffstat:
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/api-merchant.rst b/api-merchant.rst
@@ -16,8 +16,8 @@ necessary, the merchant assures this by limiting the time for which
the offer is valid.
Taler also assumes that the wallet and the merchant can agree on the
-current time (similar to what is required to connect to Tor or
-validate TLS certificates). The wallet may rely on the timestamp
+current time; similar to what is required to connect to Tor or
+validate TLS certificates. The wallet may rely on the timestamp
provided in the HTTP "Date:" header for this purpose, but the customer
is expected to check that the time is approximately correct.
@@ -29,12 +29,12 @@ Architecture's Overview
In our settlement, the "merchant" is divided in two independent
compontents, the `frontend` and the `backend`.
-The `frontend` is the (usually pre-existing) shopping portal of the
-merchant. The architecture tries to minimize the amount of
-modifications necessary to the `frontend` as well as the trust that
-needs to be placed into the `frontend` logic. Taler requires the
-frontend to facilitate two JSON-based interactions between the
-wallet and the `backend`, and one of those is trivial.
+The `frontend` is the existing shopping portal of the merchant.
+The architecture tries to minimize the amount of modifications necessary
+to the `frontend` as well as the trust that needs to be placed into the
+`frontend` logic. Taler requires the frontend to facilitate two
+JSON-based interactions between the wallet and the `backend`, and
+one of those is trivial.
The `backend` is a standalone C application intended to implement all
the cryptographic routines required to interact with the Taler wallet
