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

50
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 authorization schemes are in use in various combinations. Secure
systems typically combine multiple forms of authentication including systems typically combine multiple forms of authentication including
secret information, such as personal identification numbers (PINs), 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 verification (CCV) codes, and physical security devices such cards
with an EMV chip~\cite{emv}, TAN generators, or the customer's mobile with an EMV chip~\cite{emv}, TAN generators, or the customer's mobile
phone~\cite{mtan}. A typical modern Web payment process involves: 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 Bitcoin's pseudononymity applies equally to both customers and
merchants, which makes Bitcoin amen\-able to tax evasion, money merchants, which makes Bitcoin amen\-able to tax evasion, money
laundering, sales of contraband, and especially extorion laundering, sales of contraband, and especially extorion
\cite{NYA:CyberExtortionRisk}. \cite{NYA:CyberExtortionRisk}.
As a result, anonymity tools like mixnets do not enjoy widespread As a result, anonymity tools like mixnets do not enjoy widespread
support in the Bitcoin community where many participants seek to make support in the Bitcoin community where many participants seek to make
the currency appear more legitimate. While Bitcoin's transactions the currency appear more legitimate. While Bitcoin's transactions
are difficult to track, there are several examples of Bitcoin's 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 This has resulted in the development of new protocols with better
privacy protections. privacy protections.
@ -569,16 +569,16 @@ auditor.
\begin{figure}[b!]%[36]{R}{0.5\linewidth} \begin{figure}[b!]%[36]{R}{0.5\linewidth}
\subfloat[Bank login. (Simplified for demonstration.)]{ \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 \label{subfig:login}} \hfill
\subfloat[Specify amount to withdraw. (Integrated bank support.)]{ \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}} \\ \label{subfig:withdraw}} \\
\subfloat[Select exchange provider. (Generated by wallet.)]{ \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 \label{subfig:exchange}} \hfill
\subfloat[Confirm transaction with a PIN. (Generated by bank.)]{ \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}} \label{subfig:pin}}
\caption{Required steps in a Taler withdrawal process.} \caption{Required steps in a Taler withdrawal process.}
\label{fig:withdrawal} \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} The Taler wallet operates from a securely isolated {\em background}
context on the client side. The user interface that displays the context on the client side. The user interface that displays the
contract and allows the user to confirm the payment is displayed by contract and allows the user to confirm the payment is displayed by
this background context. If the user accepts, the resulting signed this background context. By running in the background context, the
coins are transferred from the client to the merchant's server. wallet can perform the cryptographic operations protected from the
main process of the Web site. In particular, this architecture is
By running in the background context, the wallet can perform the secure against a merchant that generates a page that looks like the
cryptographic operations protected from the main process of the Web wallet's payment page (Figure~\ref{subfig:payment}), as such a page
site. In particular, this architecture is secure against a merchant would still not have access to the private keys of the coins that are
that generates a page that looks like the wallet's payment page exclusive to the background context.
(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 current Taler specification is written to accommodate for
%the rather restrictive set of APIs that WebExtension, a %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: it has the following key advantages:
\begin{itemize} \begin{itemize}
\item It works in the confines of the WebExtensions API. \item It works in the confines of the WebExtensions API.
\item It supports restoring session state for bookedmarked \item It supports restoring session state for bookmarked
web resources when session state is cleared in the user agent. Web resources even after the session state is lost by the user agent.
\item Sending deep links to fullfilment or offer pages to \item Sending deep links to fullfilment or offer pages to
other users has the expected behavior other users has the expected behavior
of asking the other user to pay for the resource. 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 the fulfillment page begins with processing an accepted contract. It is thus
possible for these pages to be managed by separate parties. The possible for these pages to be managed by separate parties. The
control of the fulfillment page over the transmission of the payment 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}. resource sharing~\cite{rfc6454,cors}.
\item The architecture supports security-conscious users that may have \item The architecture supports security-conscious users that may have
disabled JavaScript, as it is not necessary to execute JavaScript 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 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 wallet may request three \EUR{1} coins in change. Critically, the
change giving process is completely hidden from the user. 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 interface does not offer a way to inspect the denominations of the
various coins in the wallet, it only shows the total amount available various coins in the wallet, it only shows the total amount available
in each denomination. Expanding the views to show details may show 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 respective software only needs to be provided with the merchant's wire
transfer routing information to become operational. transfer routing information to become operational.
Figure~\ref{listing:presence} shows how easy it is for a Web site to The payment process requires a
detect the presence of a Taler wallet. The payment process requires a
few cryptographic operations on the side of the merchant, such as few cryptographic operations on the side of the merchant, such as
signing a contract and verifying the customer's and the exchange's signing a contract and verifying the customer's and the exchange's
signatures. The merchant also needs to store transaction data, in signatures. The merchant also needs to store transaction data, in
particular so that the store can match sales with incoming wire 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 providing a generic payment processing {\em backend} for the Web
shops. shops.
\begin{figure*}[t!] \begin{figure*}[b!]
\begin{center} \begin{center}
\begin{tikzpicture}[ \begin{tikzpicture}[
font=\sffamily, font=\sffamily,
@ -1199,7 +1195,7 @@ passes it to the wallet (sample code for this is shown in
Figure~\ref{listing:contract}). Figure~\ref{listing:contract}).
Instead of adding any cryptographic logic to the merchant frontend, 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, coin handling to the payment backend, which validates the coins,
deposits them at the exchange, and finally validates and persists the deposits them at the exchange, and finally validates and persists the
receipt from the exchange. The merchant backend then communicates 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 this setup (Figure~\ref{fig:frobearch}), the cryptographic details
of the Taler protocol do not have to be re-implemented by each of the Taler protocol do not have to be re-implemented by each
merchant. Instead, existing Web shops implemented in a multitude of 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)} {\bf (0)} detecting in the browser that Taler is available; {\bf (1)}
upon request, generating a contract in JSON based on the shopping upon request, generating a contract in JSON based on the shopping
cart; {\bf (2)} allowing the backend to sign the contract before cart; {\bf (2)} allowing the backend to sign the contract before