From b4f3dbc56841dddba11458b80cd551f39f80bd2f Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Thu, 25 Aug 2016 17:37:49 +0200 Subject: [PATCH] minor edits --- articles/ui/ui.tex | 50 +++++++++++++++++++++------------------------- 1 file changed, 23 insertions(+), 27 deletions(-) diff --git a/articles/ui/ui.tex b/articles/ui/ui.tex index 7bf0c1a2d..3167e7465 100644 --- a/articles/ui/ui.tex +++ b/articles/ui/ui.tex @@ -272,7 +272,7 @@ credentials to the merchant. Many different authentication and authorization schemes are in use in various combinations. Secure systems typically combine multiple forms of authentication including secret information, such as personal identification numbers (PINs), -transaction numbers (TANs)~\cite{kolbil2016tan} or credit card +transaction numbers (TANs)~\cite{kobil2016tan} or credit card verification (CCV) codes, and physical security devices such cards with an EMV chip~\cite{emv}, TAN generators, or the customer's mobile phone~\cite{mtan}. A typical modern Web payment process involves: @@ -422,12 +422,12 @@ volatile.~\cite{jeffries_economists_v_btc,lehmann_btc_fools_gold,lewis_btc_is_ju Bitcoin's pseudononymity applies equally to both customers and merchants, which makes Bitcoin amen\-able to tax evasion, money laundering, sales of contraband, and especially extorion - \cite{NYA:CyberExtortionRisk}. + \cite{NYA:CyberExtortionRisk}. As a result, anonymity tools like mixnets do not enjoy widespread support in the Bitcoin community where many participants seek to make the currency appear more legitimate. While Bitcoin's transactions are difficult to track, there are several examples of Bitcoin's -pseudononymity being broken by investigators~\cite{BTC:Anonymity}. +pseudononymity being broken by investigators~\cite{BTC:Anonymity}. This has resulted in the development of new protocols with better privacy protections. @@ -569,16 +569,16 @@ auditor. \begin{figure}[b!]%[36]{R}{0.5\linewidth} \subfloat[Bank login. (Simplified for demonstration.)]{ -\includegraphics[width=0.45\linewidth]{figs/bank0a.png} +\includegraphics[width=0.4\linewidth]{figs/bank0a.png} \label{subfig:login}} \hfill \subfloat[Specify amount to withdraw. (Integrated bank support.)]{ -\includegraphics[width=0.45\linewidth]{figs/bank1a.png} +\includegraphics[width=0.4\linewidth]{figs/bank1a.png} \label{subfig:withdraw}} \\ \subfloat[Select exchange provider. (Generated by wallet.)]{ -\includegraphics[width=0.45\linewidth]{figs/bank2a.png} +\includegraphics[width=0.4\linewidth]{figs/bank2a.png} \label{subfig:exchange}} \hfill \subfloat[Confirm transaction with a PIN. (Generated by bank.)]{ -\includegraphics[width=0.45\linewidth]{figs/bank3a.png} +\includegraphics[width=0.4\linewidth]{figs/bank3a.png} \label{subfig:pin}} \caption{Required steps in a Taler withdrawal process.} \label{fig:withdrawal} @@ -848,16 +848,13 @@ provided by the merchant (Figure~\ref{subfig:fulfillment}). 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 -site. In particular, this architecture is secure against a merchant -that generates a page that looks like the wallet's payment page -(Figure~\ref{subfig:payment}), as such a page would still not have -access to the private keys of the coins that are exclusive to the -background context. +this background context. By running in the background context, the +wallet can perform the cryptographic operations protected from the +main process of the Web site. In particular, this architecture is +secure against a merchant that generates a page that looks like the +wallet's payment page (Figure~\ref{subfig:payment}), as such a page +would still not have 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 @@ -992,8 +989,8 @@ 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 It supports restoring session state for bookmarked + Web resources even after the session state is lost by the user agent. \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. @@ -1005,7 +1002,7 @@ it has the following key advantages: the fulfillment page begins with processing an accepted contract. It is thus possible for these pages to be managed by separate parties. The control of the fulfillment page over the transmission of the payment - information minimizes the need for exceptions to handle cross-origin + data 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 @@ -1040,7 +1037,7 @@ obtaining change is automatic and handled by the wallet, i.e., if the user has a single coin worth \EUR{5} and wants to spend \EUR{2}, the wallet may request three \EUR{1} coins in change. Critically, the change giving process is completely hidden from the user. -In fact, the graphical user +In fact, our graphical user interface does not offer a way to inspect the denominations of the various coins in the wallet, it only shows the total amount available in each denomination. Expanding the views to show details may show @@ -1130,17 +1127,16 @@ This dramatically simplifies setting up a shop to the point that the respective software only needs to be provided with the merchant's wire transfer routing information to become operational. -Figure~\ref{listing:presence} shows how easy it is for a Web site to -detect the presence of a Taler wallet. The payment process requires a +The payment process requires a few cryptographic operations on the side of the merchant, such as signing a contract and verifying the customer's and the exchange's signatures. The merchant also needs to store transaction data, in particular so that the store can match sales with incoming wire -transfers from the exchange. Taler simplifies this for merchants by +transfers from the exchange. We simplify this for merchants by providing a generic payment processing {\em backend} for the Web shops. -\begin{figure*}[t!] +\begin{figure*}[b!] \begin{center} \begin{tikzpicture}[ font=\sffamily, @@ -1199,7 +1195,7 @@ passes it to the wallet (sample code for this is shown in Figure~\ref{listing:contract}). Instead of adding any cryptographic logic to the merchant frontend, -the generic Taler merchant backend allows the implementor to delegate +the Taler merchant backend allows the implementor to delegate coin handling to the payment backend, which validates the coins, deposits them at the exchange, and finally validates and persists the receipt from the exchange. The merchant backend then communicates the @@ -1208,7 +1204,7 @@ for executing the business logic to fulfill the order. As a result of this setup (Figure~\ref{fig:frobearch}), the cryptographic details of the Taler protocol do not have to be re-implemented by each merchant. Instead, existing Web shops implemented in a multitude of -programming languages can straightforwardly add support for Taler by: +programming languages can add support for Taler by: {\bf (0)} detecting in the browser that Taler is available; {\bf (1)} upon request, generating a contract in JSON based on the shopping cart; {\bf (2)} allowing the backend to sign the contract before