taler/wallet-core
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Activity

minor edits

Browse Source
This commit is contained in:
Christian Grothoff 2016-08-25 17:37:49 +02:00
parent 481f9ff554
commit b4f3dbc568
1 changed files with 23 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
articles/ui/ui.tex
View File

@ -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:
@ -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