editing section 3

1 files changed, 98 insertions, 68 deletions

diff --git a/articles/ui/ui.tex b/articles/ui/ui.tex
index d6828ab95..0f8872abf 100644
--- a/articles/ui/ui.tex
+++ b/articles/ui/ui.tex
@@ -557,7 +557,9 @@ at the exchange, and keep receipts in a transaction history.  Wallets can be
 realized as browser extensions, mobile Apps or even in custom
 hardware.  If a user's digital wallet is compromised, the current
 balance may be lost, just like with an ordinary wallet containing cash.
-
+A wallet also includes a list of acceptable auditors, and will warn
+users against using an exchange that is not certified by one of these
+auditors.
 
 \begin{figure}[t!]%[36]{R}{0.5\linewidth}
 \subfloat[Bank login. (Simplified for demonstration.)]{
@@ -584,7 +586,7 @@ customers to withdraw anonymous digital coins,
 and merchants to deposit digital coins, in exchange for
 bank money.  Coins are signed by the exchange using
 a blind signing scheme~\cite{chaum1983blind}.  Thus, only
-the exchange can issue new coins, but coins cannot be traced back
+an exchange can issue new coins, but coins cannot be traced back
 to the customer that withdrew them.
 Furthermore, exchanges learn the amounts withdrawn by customers
 and deposited by merchants, but they do not learn the relationship
@@ -595,7 +597,11 @@ of double spending, thus providing merchants instant feedback
 \item
 {\em Merchants} provide goods or services in exchange for coins held
 by customers' wallets.  Merchants deposit these coins at the
-exchange for their regular currency value.  Merchants consist of a
+exchange used by the customer in return for a bank wire
+transfer of their value.  While the exchange is determined by
+the customer, the merchant's contract specifies the currency,
+a list of accepted auditors and the maximum exchange deposit
+fee the merchant is willing to pay.  Merchants consist of a
 {\em frontend}, which interacts with the customer's wallet, and a {\em
 backend}, which interacts with the exchange.  Typical frontends include
 Web shops and point-of-sale systems.
@@ -608,6 +614,9 @@ Depending on local legislation, auditors mandate that exchanges
 have enough financial reserves before authorizing them to create a given
 volume of signed digital coins in order to compensate for potential risks due to
 operational failures (such as data loss or theft of private keys) of the exchange.
+Auditors certify exchanges that they audit using digital signatures.  The
+respective signing keys of the auditors are distributed to customer and
+merchants.
 \end{itemize}
 
 
@@ -622,7 +631,7 @@ Initially, the customer installs the Taler wallet extension for
 their browser.  This only needs to be done once per
 browser. Naturally, this step may become superfluous if Taler is
 integrated tightly with browsers in the future.  Regardless,
-installing the extension involves one or two clicks to confirm the
+installing the extension involves only one or two clicks to confirm the
 operation. Restarting the browser is not required.
 
 
@@ -683,13 +692,13 @@ customers, and may help create a competitive market.
 % \tinyskip
 
 \begin{figure}[t!]
-\subfloat[Select article. (Generated by Web shop.)]{
+\subfloat[Select article. \\ Generated by Web shop.]{
 \includegraphics[width=0.30\textwidth]{figs/cart.png}
 \label{subfig:cart}} \hfill
-\subfloat[Confirm payment. (Generated by Taler wallet.)]{
+\subfloat[Confirm payment. \\ Generated by Taler wallet.]{
 \includegraphics[width=0.30\textwidth]{figs/pay.png}
 \label{subfig:payment}} \hfill
-\subfloat[Receive article. (Generated by Web shop.)]{
+\subfloat[Receive article. \\ Generated by Web shop.]{
 \includegraphics[width=0.30\textwidth]{figs/fulfillment.png}
 \label{subfig:fulfillment}}
 \caption{Required steps in a Taler checkout process.}
@@ -751,35 +760,42 @@ merchant, the customer may choose to cover them.
 As with traditional Web transactions, customers first select which
 items they wish to buy.  This can involve building a traditional
 shopping cart, or simply clicking on a particular link for the
-respective article (Figure~\ref{subfig:cart}).
-Taler also allows the Web shop to detect
-the presence of a Taler wallet (Figure~\ref{listing:presence}), so
-that the selection of other payment methods can be skipped
-if a Taler wallet is installed (as it is in Figure~\ref{fig:shopping}).
-
-Web pages can initiate payments by sending a \emph{contract proposal} to the
-wallet, either via the status code HTTP 402 Payment Required, or via a
-JavaScript API.  The wallet then presents the contract to the user.  The format
-of the contract is in an extensible JSON-based format defined by Taler and not
-HTML, as the rendering of the contract is done by the wallet to ensure correct
-visual representation of the terms and price.  In case that transaction fees need to be covered by the
-customer, these are shown together with the rest of the proposed contract.
+respective article (Figure~\ref{subfig:cart}).  Once the articles have
+been selected, the Web shop directs the user to the {\em offer} URL,
+where the payment details are negotiated.  The process usually starts
+by allowing the user to select a {\em payment method} from a set of
+methods supported by the Web shop.  Taler also allows the Web shop to
+detect the presence of a Taler wallet (Figure~\ref{listing:presence}),
+so that the selection of alternative payment methods can be skipped if
+a Taler wallet is installed (as it is in Figure~\ref{fig:shopping}).
+
+% FIXME: add figure for 402 payment!
+The offer URL of the Web shop can then initiate payments by sending a
+\emph{contract proposal} to the wallet, either via the HTTP status
+code {\tt 402 Payment Required}, or via Taler's JavaScript API
+(Figure~\ref{listing:contract}).  The wallet then presents the
+contract to the user.  The format of the contract is in an extensible
+JSON-based format defined by Taler and not HTML, as the rendering of
+the contract is done by the wallet to ensure correct visual
+representation of the terms and prices.  In case that transaction fees
+need to be covered by the customer, these are shown together with the
+rest of the proposed contract.
 
 If the customer approves the contract by clicking the ``Confirm
 Payment'' button (Figure~\ref{subfig:payment}), their wallet signs the
 contract with enough coins to cover the contract's cost, stores all of
-the information in its local database, and redirects the browser to a
-{\em fulfillment} URL provided by the merchant
-(Figure~\ref{subfig:fulfillment}).
+the information in its local database, and transmits the payment to
+the {\em payment} URI of the Web shop.  Once the Web shop confirms the
+payment, the wallet redirects the browser to the {\em fulfillment} URL
+provided by the merchant (Figure~\ref{subfig:fulfillment}).
 
 \subsection{Browser security}
 
-The Taler wallet operates from a securely isolated {\em background} context on
-the client side.  The user interface that displays
-the contract and allows the user to confirm the payment is displayed by
-this background context.  If the user accepts, the
-resulting signed coins are transferred from the client to the
-merchant's server.
+The Taler wallet operates from a securely isolated {\em background}
+context on the client side.  The user interface that displays the
+contract and allows the user to confirm the payment is displayed by
+this background context.  If the user accepts, the resulting signed
+coins are transferred from the client to the merchant's server.
 
 By running in the background context, the wallet can perform the
 cryptographic operations protected from the main process of the Web
@@ -789,10 +805,9 @@ that generates a page that looks like the wallet's payment page
 access to the private keys of the coins that are exclusive to the
 background context.
 
-The current Taler specification is written to accommodate for
-the rather restrictive set of APIs that WebExtension, a
-cross-browser extension API, provides.
-
+%The current Taler specification is written to accommodate for
+%the rather restrictive set of APIs that WebExtension, a
+%cross-browser extension API, provides.
 
 \subsection{Managing browser session state}
 
@@ -810,38 +825,48 @@ cross-browser extension API, provides.
 
 % design that allows merchant to not store any information
 
-A purchase by a customer, completed or in progress, is uniquely identified by a URL, called
-the \emph{fulfillment URL}.  The information contained in the fulfillment
-URL must allow the merchant to restore the full contract that was associated
-with purchase, either directly or indirectly from an identifier in a database%
-\footnote{Storing information about incomplete purchases potential for abuse from malicious customers.}.
-
-When a customer completed a purchase, navigating to the fulfillment URL in a browser
-will show the resource associated with the purchase.  This resource can be a
-digital good such as a news article, or simply a confirmation for products that
-are delivered by other means.
-
-In order to ensure that only the paying customer has access to the web
-resources behind the fulfillment URL, the web store's server must check the
-browser's session state.  Visiting the fulfillment URL for the first
-time\footnote{Or after deleting the session state, which e.g. happens when
-privacy conscious users delete their cookies.  Some user agents (such as the TOR browser)
-do not support persistent (non-session) cookies.} triggers the wallet to send the
-signed coins that are associated with the contract for the fulfillment URL to
-the merchant.  This process can be triggered via a JavaScript API for the
-wallet, or by a \emph{HTTP 402 Payment Required} status code.
-
-When a user visits a fulfillment URL without having the associated contract
-in their wallet, the wallet redirects the browser to the offer URL for that
-purchase, if applicable.  This behavior is useful when a user wishes to
-send a fulfillment link to another user.
+A purchase by a customer, completed or in progress, is uniquely
+identified by a URL, called the \emph{fulfillment URL}.  The
+information contained in the fulfillment URL must allow the merchant
+to restore the full contract that was associated with the purchase,
+either directly from the URL or indirectly from an identifier in a
+database.  Efficiently reconstructing the contract entirely from the
+URL instead of using costly database transactions can be important, as
+costly disk operations for incomplete purchases make merchants
+more susceptible to denial-of-service attacks from adversaries
+pretending to be customers.
+
+When a customer completed a purchase, navigating to the fulfillment
+URL in a browser will show the resource associated with the purchase.
+This resource can be a digital good such as a news article, or simply
+a confirmation for products that are delivered by other means.
+
+In order to ensure that only the paying customer has access to the Web
+resources behind the fulfillment URL, the Web store's server must
+check the browser's session state.  If the merchant can confirm that
+the visitor has paid, the respective Web resource is returned.  If the
+merchant cannot confirm that the visitor has paid for the contract,
+for example because the session state was lost,\footnote{This can
+  happen when when privacy conscious users delete their cookies.
+  Also, some user agents (such as the TOR browser) do not support
+  persistent (non-session) cookies.} it {\em again} triggers a payment
+process (either via JavaScript or using {\tt 402 Payment Required}).
+If the wallet remembers paying for the contract previously, this
+causes the wallet to retransmit the signed coins that are associated
+with the purchase to the merchant.
+
+When a user visits a fulfillment URL without having the associated
+contract in their wallet, the wallet redirects the browser to the {\em
+  offer} URL for that purchase, if applicable.  This behavior is
+useful when a user wishes to share a fulfillment link with another
+user to point him to the same resource.
 
 Note that due to the limited WebExtensions API, the session
 state can only be acquired when the browser navigates to
 the fulfillment URL (without session state), since the session
 state must be set on the same origin as the fulfillment URL.
 
-Various failure modes are considered:
+Various failure modes are considered in this design:
 
 \begin{itemize}
 \item If the payment fails on the network, the request is typically
@@ -860,7 +885,7 @@ Various failure modes are considered:
  refresh protocol.  In this case, later deposits by the merchant
  will simply fail.  If the merchant already succeeded with the payment
  before the network failure, the customer can either retry the
- operation via the transaction history, or demand a refund (see
+ operation via the transaction history kept by the wallet, or demand a refund (see
  below).  Handling these errors does not require the customer to give
  up his privacy.
 \item If the payment fails due to the exchange
@@ -876,14 +901,15 @@ Various failure modes are considered:
  the transaction.
 \end{itemize}
 
-
-While our design has a few extra roundtrips,
-it has the following advantages:
+\noindent
+While our design requires a few extra roundtrips,
+it has the following key advantages:
 \begin{itemize}
   \item It works in the confines of the WebExtensions API.
   \item It supports restoring session state for bookedmarked
     web resources when session state is cleared in the user agent.
-  \item Sending deep links to other users has the expected behavior
+  \item Sending deep links to fullfilment or offer pages to
+    other users has the expected behavior
     of asking the other user to pay for the resource.
   \item Asynchronously POSTing coins from injected JavaScript costs
     one roundtrip, but does not interfer with navigation and allows
@@ -895,13 +921,16 @@ it has the following advantages:
     control of the fulfillment page over the transmission of the payment
     information minimizes the need for exceptions to handle cross-origin
     resource sharing~\cite{rfc6454,cors}.
+  \item The architecture supports security-conscious users that may have
+    disabled JavaScript, as it is not necessary to execute JavaScript
+    originating from Web pages to execute the payment process.
 \end{itemize}
 
 % \smallskip
 
-\subsection{Giving change and refunds} % FIXME: maybe leave out change entirely?
+\subsection{Giving change and refunds}
 
-An important technical difference between Taler and previous
+An important cryptographic difference between Taler and previous
 transaction systems based on blind signing is that Taler is able to
 provide unlinkable change and refunds.  From the user's point of view,
 obtaining change is automatic and handled by the wallet, i.e., if the
@@ -1060,7 +1089,7 @@ shops.
 Figure~\ref{fig:frobearch} shows how the secure payment components
 interact with the existing Web shop logic.  First, the Web shop
 frontend is responsible for constructing the shopping cart.  For this,
-the shop frontend generates the usual Web pages, which are transmitted
+the shop frontend generates the customary Web shop pages, which are transmitted
 to the customer's browser.  Once the order has been constructed, the
 shop frontend provides a {\em proposed contract} in JSON format to the
 payment backend, which signs it and returns it to the frontend.  The
@@ -1087,7 +1116,8 @@ for a contract to the backend; and, {\bf (8)} executing fulfillment
 business logic if the backend confirms the validity of the payment.
 
 To setup a Taler backend, the merchant only needs to configure the
-wire transfer routing details, such as the merchant's IBAN number.
+wire transfer routing details, such as the merchant's IBAN number, as
+well as a list of acceptable auditors and limits for transaction fees.
 Ideally, the merchant might also want to obtain a certificate for the
 public key generated by the backend for improved authentication.
 Otherwise, the customer's authentication of the Web shop simply