1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
|
\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}
\usetikzlibrary{shapes,arrows}
\usetikzlibrary{positioning}
\usetikzlibrary{calc}
\begin{document}
\maketitle
\section{System overview}
Transactions on the Internet, such as sending an e-mail or reading a
Web site, tend to be of smaller value than traditional transactions
involving the exchange of physical goods. Thus we are faced with the
challenge of reducing the mental and technical overheads of existing
payment systems to handle micro-payments. Addressing this problem is
urgent: ad-blocking technology is eroding advertising as a substitute
for micro-payments, 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 which 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: the payment process is simplified and the
merchant's security requirements are dramatically reduced.
Taler uses blind signatures~\cite{chaum1983blind} to create digital
coins, and a new ``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 interaction sequences to explain how the system works from the
perspective of customers and merchants in the Taler
system (Figure~\ref{fig:system}).
\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}
\newpage
\section{Customer perspective}
In Taler, customers use a {\em wallet} to withdraw (Figure
~\ref{fig:taler-withdraw}), hold, and spend (Figure~\ref{fig:taler-pay})
coins. Withdrawing coins requires the customer to authenticate
and to optionally authorize the specific transaction.
Afterwards, the customer can anonymously spend his coins by
visiting merchants without having to authenticate for each
transaction (Figure~\ref{fig:taler-pay}).
\begin{figure}[h!]
\includegraphics[width=0.45\textwidth]{figs/taler-withdraw.pdf}
\caption{Withdrawing coins with Taler.}
\label{fig:taler-withdraw}
\end{figure}
\begin{figure*}[t!]
\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*}
\begin{figure}[b!]
\includegraphics[width=0.45\textwidth]{figs/taler-pay.pdf}
\caption{Payment processing with Taler.}
\label{fig:taler-pay}
\end{figure}
\newpage
\section{Merchant perspective}
A new payment system must also be easy to deploy for merchants.
Figure~\ref{fig:frobearch} shows how the secure 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 {\em
background} 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 let it know 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.
%\newpage
\bibliographystyle{abbrv}
\bibliography{ui,btc,taler,rfc}
\end{document}
|
