Merge branch 'master' of ssh://taler.net:/var/git/api

3 files changed, 16 insertions, 16 deletions

diff --git a/api-merchant.rst b/api-merchant.rst
index 6881d150..6555a494 100644
--- a/api-merchant.rst
+++ b/api-merchant.rst
@@ -19,7 +19,8 @@ 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
 provided in the HTTP "Date:" header for this purpose, but the customer
-is expected to check that the time is approximately correct.
+is expected to check that the time of his machine is approximately
+correct.
 
 
 -----------------------
@@ -29,7 +30,7 @@ Architecture's Overview
 In our settlement, the "merchant" is divided in two independent
 compontents, the `frontend` and the `backend`.
 
-The `frontend` is the existing shopping portal of the merchant.  
+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
@@ -45,7 +46,7 @@ and a Taler mint.
 Wallet-Frontend communication
 +++++++++++++++++++++++++++++
 
-Taler's virtual wallet is designed to notify the user when a certain webpage
+Taler's wallet is designed to notify the user when a certain webpage
 is offering Taler as a payment option. It does so by simply changing the color of
 the wallet's button in the user's browser. In the other direction, the website
 may want to make the Taler payment option visible `only if` the user has the Taler
@@ -255,7 +256,7 @@ visiting a checkout page, the page should listen for the
 event to hide the Taler payment option.
 
 Secondly, when the Taler extension is active and the user closes (or navigates
-away from) the checkout page, the page should listen to a 
+away from) the checkout page, the page should listen to a
 
   .. js:data:: taler-navigating-away
 
@@ -448,7 +449,7 @@ The following API are made available by the merchant's `backend` to the merchant
   * `merchant_pub`
   * `mints`
   * `H_wire`
-  
+
   The `backend` then completes this information based on its configuration.
 
   **Success Response**
diff --git a/api-mint.rst b/api-mint.rst
index 75534272..360500de 100644
--- a/api-mint.rst
+++ b/api-mint.rst
@@ -224,7 +224,7 @@ When transfering money to the mint such as via SEPA transfers, the mint creates
   :query reserve_pub: EdDSA reserve public key identifying the reserve.
 
   .. note::
-    The client currently does not have to demonstrate knowledge of the private key of the reserve to make this request, which makes the reserve's public key privliged information known only to the client, their bank, and the mint.  In future, we might wish to revisit this decision to improve security, such as by having the client EdDSA-sign an ECDHE key to be used to derive a symmetric key to encrypt the response.  This would be useful if for example HTTPS were not used for communication with the mint.  
+    The client currently does not have to demonstrate knowledge of the private key of the reserve to make this request, which makes the reserve's public key privliged information known only to the client, their bank, and the mint.  In future, we might wish to revisit this decision to improve security, such as by having the client EdDSA-sign an ECDHE key to be used to derive a symmetric key to encrypt the response.  This would be useful if for example HTTPS were not used for communication with the mint.
 
   **Success Response: OK**
 
@@ -371,7 +371,7 @@ However, the new coins are linkable from the private keys of all old coins using
 .. _refresh:
 .. http:post:: /refresh/melt
 
-  "Melt" coins.  Invalidates the coins and prepares for minting of fresh coins.  Taler uses a global parameter `kappa` for the cut-and-choose component of the protocol, for which this request is the commitment.  Thus, various arguments are given `kappa`-times in this step.  At present `kappa` is always 3.
+  "Melts" coins.  Invalidates the coins and prepares for minting of fresh coins.  Taler uses a global parameter `kappa` for the cut-and-choose component of the protocol, for which this request is the commitment.  Thus, various arguments are given `kappa`-times in this step.  At present `kappa` is always 3.
 
   The request body must contain a JSON object with the following fields:
 
@@ -480,7 +480,7 @@ However, the new coins are linkable from the private keys of all old coins using
   The `new_coins` array contains the following fields for each element:
 
   :>jsonarr base32 link_enc: Encrypted private key and blinding factor information of the fresh coin
-  :>jsonarr base32 denom_pub: ECDHE public key of the minted coin.
+  :>jsonarr base32 denom_pub: RSA public key of the minted coin.
   :>jsonarr base32 ev_sig: Mint's blinded signature over the minted coin.
 
   **Error Response: Unknown key**:
@@ -564,7 +564,7 @@ Administrative API: Bank transactions
 
   **Failure response**
 
-  :status 403: the client is not permitted to add incoming transactions
+  :status 403: the client is not permitted to add incoming transactions. The request may be disallowed by the configuration in general or restricted to certain IP addresses (i.e. loopback-only).
 
   The mint responds with a JSON object containing the following fields:
 
@@ -853,7 +853,7 @@ EdDSA signatures are always made on the hash of a block of the same generic form
 
 The `purpose` field in `struct SignedData` is used to express the context in which the signature is made, ensuring that a signature cannot be lifted from one part of the protocol to another.  The various `purpose` constants are defined in `taler_signatures.h`.  The `size` field prevents padding attacks.
 
-In the subsequent messages, we use the following notation for signed data described in `FIELDS` with the given purpose.  
+In the subsequent messages, we use the following notation for signed data described in `FIELDS` with the given purpose.
 
 .. sourcecode:: c
 
diff --git a/wallet.rst b/wallet.rst
index ed65819f..c8e4c528 100644
--- a/wallet.rst
+++ b/wallet.rst
@@ -3,9 +3,9 @@ The Wallet Reference
 ====================
 
   .. note::
-     
+
      This documentation goes in parallel with the wallet's development, so is to be considered as `work in pregress`
-     until a first operative version of the wallet will be released. 
+     until a first operative version of the wallet will be released.
 
 
 This section explains how to set up a wallet. It is worth noting that there are two versions for
@@ -48,13 +48,13 @@ Web and installed by just visiting its URI.
 Emscripten
 ^^^^^^^^^^
 
-Since the wallet makes extensive use of cryptographic primitives and of come coins' manipulating primitives, it relies on two fundamental libraries:
+Since the wallet makes extensive use of cryptographic primitives and of coin manipulation primitives, it relies on two fundamental libraries:
 ``libgnunetutils_taler_wallet`` and ``libtalerutil_wallet``; being the former from the `gnunet <https://gnunet.org>`_ project, and the latter from `taler <https://taler.net>`_
 project itself. Moreover, since those libraries depend on `libgpg-error`, `libgcrypt` and `libunistring`, and the non markup part of the extension is JavaScript,
 a language-to-language compiler such as `Emscripten <http://emscripten.org>`_ has been used to port `C` sources to JavaScript.
 
   .. note::
-     
+
      To just compile the extension and install it into your browser, it suffices to follow the above steps and simply ignore
      this section. That is possible since `git master` ships a previously made JavaScript version of ``libgnunetutil_taler_wallet``,
      that the extension is properly linked against to. So this section is dedicated to those who want to reproduce the steps
@@ -126,8 +126,7 @@ whereas for `gnunet` and `taler`, do
      ./bootstrap.sh
 
 
-Finally, run the provided script (any final file will be placed under ``/tmp/emscripten``) that we
-just copied under any component's tree.
+Finally, run the respective `myconf-*.sh` scripts in the order of the components given above. All generated files will be placed under ``/tmp/emscripten``.
 
 At this point, you have the header files and the static library for each component compiled in the `LLVM` intermediate form. To see some final JavaScript, it is needed to compile a `C` program, though that is not the only way against the libraries we have just built.
 See the official `emscripten's documentation <http://kripken.github.io/emscripten-site/docs/compiling/Building-Projects.html#building-projects>`_ for more details.