wallet-core/articles/ui/ui_short.tex

\title{Taler: \\ Usable, privacy-preserving payments for the Web}
 \author{
 Jeffrey Burdges \\ \and
 Florian Dold \\ \and
 Christian Grothoff \\ \and
 Marcello Stanisci
}
\date{\today}

\documentclass[twoside,letterpaper]{sigalternate}
\usepackage[margin=1in]{geometry}
\usepackage[utf8]{inputenc}
\usepackage{url}
\usepackage{tikz}
\usepackage{eurosym}
\usepackage{listings}
\usepackage{graphicx}
\usepackage{wrapfig}
\usepackage{caption}
\usepackage{subcaption}
\usepackage{url}
%\usepackage{dblfloatfix}

\usetikzlibrary{shapes,arrows}
\usetikzlibrary{positioning}
\usetikzlibrary{calc}

\begin{document}
\maketitle

\section{System overview}

Content and services provided on the internet, such as reading a blog post or
sending an email, tend to be of very small monetary value compared to
traditional financial transactions.  Currently the majority of online offerings
are financed via advertisements.  Any alternatives must reduce the mental
and technical overheads of existing payment systems to handle micro-payments.
Addressing this problem is urgent: ad-blocking technology is eroding
advertising, and the Big Data business model where citizens pay with their
private information in combination with the deep state hastens our society's
regression towards post-democracy~\cite{rms2013democracy}.

Taler is a new electronic online payment system that provides
anonymity for customers.  Here, {\em anonymous} simply means that the
payment system does not require any personal information from the
customer, and that different transactions by the same customer are
unlinkable.  For strong anonymity, Taler usually needs to be used in
combination with existing techniques (such as~\cite{apod}) to avoid
circumstances leaking information about the customer's identity.  The
fact that the user does not need to authenticate and that the merchant
thus never learns sensitive personal information about the customer
improves usability and security: the payment process is simplified, the
merchant's security requirements are dramatically reduced and the customer's
risk of identity theft does not accumulate with every (micro-)payment.

Taler uses blind signatures~\cite{chaum1983blind} to create digital
coins, and a novel ``refresh'' protocol to allow giving change and
refunds while maintaining unlinkability.  We will not go into the
details of Taler's cryptographic protocols here\footnote{Full
documentation at \url{https://api.taler.net/}} and instead focus on the
high-level concepts to explain how the system works from the
perspective of customers and merchants in the Taler
system (Figure~\ref{fig:system}).
% "... and how it contributes to customer privacy"?

\begin{figure}[t!]
\centering
\begin{tikzpicture}
 \tikzstyle{def} = [node distance=3em and 5em, inner sep=1em, outer sep=.3em];
 \node (origin) at (0,0) {};
 \node (exchange) [def,above=of origin,draw]{Exchange};
 \node (customer) [def, draw, below left=of origin] {Customer};
 \node (merchant) [def, draw, below right=of origin] {Merchant};
 \node (auditor) [def, draw, above right=of origin]{Auditor};

 \tikzstyle{C} = [color=black, line width=1pt]

 \draw [<-, C] (customer) -- (exchange) node [midway, above, sloped] (TextNode) {withdraw coins};
 \draw [<-, C] (exchange) -- (merchant) node [midway, above, sloped] (TextNode) {deposit coins};
 \draw [<-, C] (merchant) -- (customer) node [midway, above, sloped] (TextNode) {spend coins};
 \draw [<-, C] (exchange) -- (auditor) node [midway, above, sloped] (TextNode) {verify};

\end{tikzpicture}
\caption{Taler system overview.}
\label{fig:system}
\end{figure}

\section{Customer perspective}

In Taler, customers use a {\em wallet} to withdraw, hold, and spend coins.
Withdrawing coins requires the customer to authenticate and to optionally
authorize the specific transaction, e.g. via a PIN/TAN method as commonly used
by banks.  Afterwards, the customer can anonymously spend their coins by visiting
merchants without having to authenticate for each transaction.

The wallet is implemented as a cross-platform browser extension.  All
cryptographic operations and access to sensitive data are executed in a
component that is isolated from websites the user visits.

By necessity, the wallet leaks one bit of information to websites that the user
visits, namely whether the wallet is installed and activated by the user.
Websites cannot access the customer's balance or purchase history.  This
however also means that all cryptographic tokens of value are kept locally, and
the customer is responsible for not losing them.  Future versions of the wallet
will provide encrypted backups and synchronization between the wallets of a
user.

A common activity for online content is sharing and bookmarking.
Taler specifically provides support to make this easy for the user.
A resource that was purchased is identified by a unique \emph{fulfillment URL}
for each purchase of the resource.


\begin{figure*}[h!]
\begin{center}
\begin{tikzpicture}[
  font=\sffamily,
  every matrix/.style={ampersand replacement=\&,column sep=2cm,row sep=2cm},
  source/.style={draw,thick,rounded corners,fill=green!20,inner sep=.3cm},
  process/.style={draw,thick,circle,fill=blue!20},
  sink/.style={source,fill=green!20},
  datastore/.style={draw,very thick,shape=datastore,inner sep=.3cm},
  dots/.style={gray,scale=2},
  to/.style={->,>=stealth',shorten >=1pt,semithick,font=\sffamily\footnotesize},
  every node/.style={align=center}]

  % Position the nodes using a matrix layout
  \matrix{
    \node[source] (wallet) {Taler Wallet};
      \& \node[process] (browser) {Browser};
      \& \node[process] (shop) {Web shop};
      \& \node[sink] (backend) {Taler backend}; \\
  };

  % Draw the arrows between the nodes and label them.
  \draw[to] (browser) to[bend right=50] node[midway,above] {(4) signed contract}
      node[midway,below] {(signal)} (wallet);
  \draw[to] (wallet) to[bend right=50] node[midway,above] {(signal)}
      node[midway,below] {(5) signed coins} (browser);
  \draw[<->] (browser) -- node[midway,above] {(3,6) custom}
      node[midway,below] {(HTTP(S))} (shop);
  \draw[to] (shop) to[bend right=50] node[midway,above] {(HTTP(S))}
      node[midway,below] {(1) proposed contract / (7) signed coins} (backend);
  \draw[to] (backend) to[bend right=50] node[midway,above] {(2) signed contract / (8) confirmation}
      node[midway,below] {(HTTP(S))} (shop);
\end{tikzpicture}
\end{center}
 \caption{Both the customer's client and the merchant's server execute
          sensitive cryptographic operations in a secured
          background/backend that is protected against direct access.
          Interactions between the Taler components
          (Figure~\ref{fig:system}) are not shown.  Existing system
          security mechanisms are used to isolate the cryptographic
          components (boxes) from the complex rendering logic
          of existing Web applications (circles).}
 \label{fig:frobearch}
\end{figure*}

% maybe mention division into two phases (a) contract offer/accept
% and (b) contract execution/replay

% How far does this allow the merchant 
Should the session state that allows the user to access the content be lost,
visiting the fulfillment URL will transparently restore the session state by
transparently replaying the payment with the same digital value tokens from the
user's wallet.  Replaying a contract is only allowed from the domain that the
contract originated from, and thus does not allow arbitrary websites to obtain
information about previous purchases that the customer made.  Sharing the
fulfillment URL with a user that did not pay for the associated digital
contract will result in the expected behavior, namely that they receiving a new
instance of the digital contract with the opportunity to pay for it.

% idea while writing this:  why do we need a correlation id
% if we already have the url? i.e. the non-fulfillment URL
% that just identifies the resource ...

The case where a user already payed for a resource and then visits
the resource URL (instead of the fulfillment URL) after losing temporary
session state is also handled as expected, since the wallet component will
look for contracts that refer to the same resource.

While Taler is designed to work well with digital resources on the web,
it can also be used for more traditional purchases.  The resource that
is being payed for then represents the shopping cart of items that
are being purchased.

%\newpage
\section{Merchant perspective}



%\begin{figure}[b!]
%\includegraphics[width=0.45\textwidth]{figs/taler-pay.pdf}
%\caption{Payment processing with Taler.}
%\label{fig:taler-pay}
%\end{figure}


A new payment system must also be easy to integrate and deploy for merchants.
Figure~\ref{fig:frobearch} shows how the security critical payment components of
Taler interact with the logic of existing Web shops.  First, the Web shop
front-end is responsible for constructing the shopping cart.  For this,
the shop front-end generates the usual Web pages which are shown to the
user's browser client front-end.  Once the order has been constructed,
the shop front-end gives a {\em proposed contract} in JSON format to
the payment backend, which signs it and returns it to the front-end.
The front-end then transfers the signed contract over the network, and
passes it to the wallet.  Here, the wallet operates from a secure
background context on the client side, which allows the user to securely
accept the payment, and to perform the cryptographic operations in a
context that is protected from the Web shop.  If the user accepts, the
resulting signed coins are transferred from the client to the server,
again by a protocol that the merchant can customize to fit the
existing infrastructure.



Instead of adding any cryptographic logic to the merchant front-end,
the generic Taler merchant backend allows the implementor to delegate
handling of the coins 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 result of the transaction to the front\-end, which is
then responsible for executing the business logic to fulfill the
order.
As a result of this setup, 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 rather trivially add support for Taler by {\bf (1)} upon
request, generating a contract in JSON based on the shopping cart,
{\bf (2)} allowing the backend to sign the contract before sending it
to the client, {\bf (7)} passing coins received in payment 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 it with the
respective wire transfer routing details, such as an IBAN number.  The
customer's authentication of the Web shop continues to rely upon
\mbox{HTTPS}/X.509.

\section{Conclusion}

We encourage everyone to try our prototype for Taler
at \url{https://demo.taler.net/}.

% These APIs are all RESTful in the modern sense because that greatly
% simplify integrating Taler with web shops and browsers.

\section*{Acknowledgements}

This work benefits from the financial support of the Brittany Region
(ARED 9178) and a grant from the Renewable Freedom Foundation.


\bibliographystyle{abbrv}
\bibliography{ui,btc,taler,rfc}

\end{document}