diff options
author | Jeff Burdges <burdges@gnunet.org> | 2015-10-30 11:23:20 +0100 |
---|---|---|
committer | Jeff Burdges <burdges@gnunet.org> | 2015-10-30 11:23:20 +0100 |
commit | 31aa125199afacf57c31e789545ec715d3637333 (patch) | |
tree | a9777f9d31a41bae8d45251187edb281adc080e1 /api-merchant.rst | |
parent | 471489d6d9e1683971136e60831b3835a125607a (diff) | |
download | docs-31aa125199afacf57c31e789545ec715d3637333.tar.gz docs-31aa125199afacf57c31e789545ec715d3637333.tar.bz2 docs-31aa125199afacf57c31e789545ec715d3637333.zip |
Yet more minor changes, this time to the merchant
Diffstat (limited to 'api-merchant.rst')
-rw-r--r-- | api-merchant.rst | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/api-merchant.rst b/api-merchant.rst index 3705cf36..6881d150 100644 --- 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 |