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
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
|
\documentclass{llncs}
%\documentclass[twoside,letterpaper]{IEEEtran}
\usepackage[margin=1in]{geometry}
\usepackage[utf8]{inputenc}
\usepackage{url}
\usepackage{tikz}
\usepackage{eurosym}
\usepackage{listings}
\usepackage{graphicx}
%\usepackage{wrapfig}
\usepackage[caption=false,font=normalsize,labelfont=sf,textfont=sf]{subfig}
\usepackage{wrapfig}
\usepackage{url}
%\usepackage{stfloats}
\usetikzlibrary{shapes,arrows}
\usetikzlibrary{positioning}
\usetikzlibrary{calc}
% CSS
\lstdefinelanguage{CSS}{
keywords={color,background-image:,margin,padding,font,weight,display,position,top,left,right,bottom,list,style,border,size,white,space,min,width, transition:, transform:, transition-property, transition-duration, transition-timing-function},
sensitive=true,
morecomment=[l]{//},
morecomment=[s]{/*}{*/},
morestring=[b]',
morestring=[b]",
alsoletter={:},
alsodigit={-}
}
% JavaScript
\lstdefinelanguage{JavaScript}{
morekeywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break},
morecomment=[s]{/*}{*/},
morecomment=[l]//,
morestring=[b]",
morestring=[b]'
}
\lstdefinelanguage{HTML5}{
language=html,
sensitive=true,
alsoletter={<>=-},
morecomment=[s]{<!-}{-->},
tag=[s],
otherkeywords={
% General
>,
% Standard tags
<!DOCTYPE,
</html, <html, <head, <title, </title, <style, </style, <link, </head, <meta, />,
% body
</body, <body,
% Divs
</div, <div, </div>,
% Paragraphs
</p, <p, </p>,
% scripts
</script, <script,
% More tags...
<canvas, /canvas>, <svg, <rect, <animateTransform, </rect>, </svg>, <video, <source, <iframe, </iframe>, </video>, <image, </image>
},
ndkeywords={
% General
=,
% HTML attributes
charset=, src=, id=, width=, height=, style=, type=, rel=, href=,
% SVG attributes
fill=, attributeName=, begin=, dur=, from=, to=, poster=, controls=, x=, y=, repeatCount=, xlink:href=,
% CSS properties
margin:, padding:, background-image:, border:, top:, left:, position:, width:, height:,
% CSS3 properties
transform:, -moz-transform:, -webkit-transform:,
animation:, -webkit-animation:,
transition:, transition-duration:, transition-property:, transition-timing-function:,
}
}
\date{}
\begin{document}
\title{Enabling Secure Web Payments with GNU Taler}
% Not sure how to do authors with the
% IEEEtran template correctly ...
\author{Jeffrey Burdges,
Christian Grothoff,
Florian Dold,
Marcello Stanisci}
\institute{Inria Rennes - Bretagne Atlantique \\
\email{FIRSTNAME.LASTNAME@inria.fr}
}
\maketitle
\begin{abstract}
GNU Taler is a new electronic online payment system which provides
privacy for customers and accountability for merchants. It uses an
exchange service to issue digital coins using blind signatures,
and is thus not subject to the performance issues that plague
Byzantine fault-tolerant consensus-based solutions.
The focus of this paper is addressing the challenges payment systems
face in the context of the Web. We discuss how to address
Web-specific challenges, such as handling bookmarks and sharing of
links, as well as supporting users that have disabled JavaScript. Web
payment systems must also navigate various constraints imposed by
modern Web browser security architecture, such as same-origin policies
and the separation between browser extensions and Web pages. While
our analysis focuses on how Taler operates within the security
infrastructure provided by the modern Web, the results partially
generalize to other payment systems.
We also include the perspective of merchants, as existing systems have
often struggled with securing payment information at the merchant's
side. Here, challenges include avoiding database transactions for
customers that do not actually go through with the purchase, as well
as cleanly separating security-critical functions of the payment
system from the rest of the Web service.
\end{abstract}
\section{Introduction}
The Internet needs a secure, usable and privacy-preserving
micropayment system, which is not backed by a ``crypto currency''.
Payment systems involving state-issued currencies have been used for
centuries to facilitate transactions, and the involvement of the state
has been critical as state institutions can dampen fluctuations in the
value of the currency.~\cite{dominguez1993} Controlling money supply
is critical to ensure stable prices that facilitate
trade~\cite{quantitytheory1997volckart} instead of speculation~\cite{lewis_btc_is_junk}.
Internet transactions, such as sending an e-mail or reading a Web
site, tend to be of smaller commercial value than traditional
transactions involving the exchange of physical goods. Consequently,
if we want to associate payments with these types of transactions, we
face the challenge of reducing the mental and technical overheads of
existing payment systems. For example, executing a 3DS payment
process (Figure~\ref{fig:cc3ds}) takes too long, is way too complex
and way to expensive to be used for payment for typical Web articles.
Addressing this problem is urgent: ad-blocking technology is eroding
advertising as a substitute for micropayments~\cite{adblockblocks},
and the Big Data business model in which citizens pay with their
private information~\cite{ehrenberg2014data} in combination with the
deep state hastens our society's regression towards
post-democracy~\cite{rms2013democracy}.
The focus of this paper is GNU Taler, a new free software payment
system designed to meet certain key ethical considerations from a
social liberalism perspective. In Taler, the paying customer remains
anonymous while the merchant is easily identified and thus taxable.
Here, {\em anonymous} simply means that the payment process does not require
any personal information from the customer, and that different
transactions by the same customer are unlinkable. Naturally, the
specifics of the transaction---such as delivery of goods to a shipping
address, or the use of non-anonymous IP-based communication---may
still leak information about the customer's identity. {\em Taxable}
means that for any transaction the state can easily obtain the
necessary information about the identity of the merchant and the
respective contract in order to levy income, sales, or value-added
taxes. Taler uses blind signatures~\cite{chaum1983blind} to create
digital coins, and a new {\em refresh} protocol~\cite{talercrypto} to
allow giving change and refunds while maintaining unlinkability.
This paper will not consider the details of Taler's cryptographic
protocols.\footnote{Details of the protocol are documented at
\url{https://api.taler.net/}} The basic cryptography behind
blind-signature based payment systems has been known for over 25
years~\cite{chaum1990untraceable}. However, only in 2015 the W3c
started the payments working group~\cite{pigs} to explore requirements
for deploying payment systems that are more secure and easy to use for
the Web. Our work describes how a modern payment system using blind
signatures could practically be integrated with the modern Web to
improve usability, security and privacy. This includes the challenge
of hiding the cryptography from the users, integrating with modern
browsers, integrating with Web shops, providing proper cryptographic
proofs for all operations, and handling network failures. We explain
our design using terms from existing {\em mental models} users have
from widespread payment systems.
%\newpage
Key contributions of this paper are:
\begin{itemize}
\item A description of different payment systems using
common terminology, which allows us to analytically compare
these systems.
\item An introduction to the Taler payment system from the
perspective of users and merchants, with a focus on how
to achieve secure payments in a way that is intuitive and
has adequate fail-safes.
\item Detailed considerations for how to adapt Taler to
Web payments and the intricacies of securing payments
within the constraints of modern browsers.
\item A publicly available free software
reference implementation of the presented architecture.
\end{itemize}
\section{Existing payment workflows}
Before we look at the payment workflow for Taler, we sketch the
workflow of existing payment systems. This establishes a common
terminology which we will use to compare different payment processes.
We include interaction diagrams for some of the payment systems
based on resources from the W3C payment interest group.
\subsection{Cash}
Cash has traditionally circulated by being passed directly from buyers
to sellers with each seller then becoming a buyer. Thus, cash is
inherently a {\em peer-to-peer} payment system as participants all
appear in the both buyer and seller roles, just at different times.
However, this view is both simplified and
somewhat dated.
In today's practice, cash is frequently first {\em withdrawn} from
ATMs by customers who then {\em spend} it with merchants, who, in turn,
{\em deposit} the cash with their respective {\em bank}. In this
flow, security is achieved as the customer {\em authenticates} to the
ATM using {\em credentials} provided by the customer's bank, and the
merchant specifies his {\em account} details when depositing the cash.
The customer does not authenticate when spending the cash, but the
merchant {\em validates} the authenticity of the {\em coins} or bills.
Coins and bills are {\em minted} by state-licensed institutions, such
as the US Mint. These institutions also provide detailed instructions
for how to validate the authenticity of the coins or
bills~\cite{ezb2016ourmoney}, and are typically the final trusted
authority on the authenticity of coins and bills.
As customers need not authenticate, purchases remain {\em
anonymous}, modulo the limited tracking enabled in theory
by serial numbers printed on bills~\cite{pets2004kuegler},
which make each bill {\em unique}.
% NOTE : Internet claims this does not happen, but no references.
% https://rocketatm.com/notice-_recorded_serial_numbers_atm_decal
Spending cash does not provide any inherent {\em proof of purchase}
for the customer. Instead, the merchant provides paper
{\em receipts}, which are generated independently and do not receive
the same anti-forgery protections that are in place for cash.
Against most attacks, customers and merchants {\em limit} their risks
to the amount of cash that they carry or accept at a given
time~\cite{Bankrate}. Additionally, customers are advised to choose
the ATMs they use carefully, as malicious ATMs may attempt to {\em
steal} their customer's credentials. Authentication with an ATM can
involve a special ATM card, or the use of credit or
debit cards. In all these cases, these physical security tokens are
issued by the customer's bank.
% \smallskip
\subsection{Credit and debit cards}
\begin{figure*}[h!]
\begin{center}
\includegraphics[width=0.95\textwidth]{figs/cc3ds.pdf}
\end{center}
\caption{Card payment processing with 3DS. (From: W3C Web Payments IG.)}
\label{fig:cc3ds}
\end{figure*}
Credit and debit card payments operate by the customer providing their
credentials to the merchant. Many different authentication and
authorization schemes are in use in various combinations including
both secret information, which are usually PINs, and physical security
devices such as TANs~\cite{kobil2016tan}, cards with an EMV
chip~\cite{emv}, and the customer's mobile phone~\cite{mtan}. A
typical modern Web payment process involves: {(1.)} the merchant
offering a secure communication channel using TLS based on the X.509
public key infrastructure;\footnote{Given numerous TLS protocol and
implementation flaws as well as X.509 key management incidents in
recent years~\cite{holz2014}, one cannot generally assume that the
security provided by TLS is adequate under all circumstances.}
{(2.)} selecting a {\em payment method}; {(3.)} entering the credit
card details like the owner's name, card number, expiration time, CVV
code, and billing address; and {(4.)} (optionally) authorizing the
transaction via mobile TAN, or by authenticating against the
customer's bank, often on a Web site that is operated by the payment
processor and {\em not} the customer's bank. Figure~\ref{fig:cc3ds}
shows a typical card-based payment process on the Web using the
UML style of the W3C payment interest group~\cite{pigs}. Most of the details
are not relevant to this paper, but the diagram nicely illustrates the
complexity of the common 3-D secure (3DS) process.
Given this process, there is an inherent risk of information leakage
of customers' credentials. {\em Fraud detection} systems attempt to detect
misuse of stolen credentials, and payment system providers handle
disputes between customers and merchants. As a result, Web payment
processes may finish with {(5.)} the payment being rejected for a
variety of reasons, such as false positives in fraud detection or
the merchant not accepting the particular card issuer.
Traditionally, merchants bear most of the financial risk, and a key
``feature'' of the 3DS process compared to traditional card payments
is to shift dispute {\em liability} to the issuer of the card---who
may then try to shift it to the customer.
%
% online vs offline vs swipe vs chip vs NFC ???
% extended verification
%
Even in cases where the issuer or the merchant remain legally first in
line for liabilities, there are still risks customers incur from the
card dispute procedures, such as neither them nor the payment
processor noticing fraudulent transactions, or them noticing
fraudulent transactions past the {\em deadline} until which their bank
would reimburse them. The customer also typically only has a
merchant-generated comment and the amount paid in his credit card
statement as a proof for the transaction. Thus, the use of credit
cards online does not generate any cryptographically {\em verifiable}
electronic receipts for the customer, which theoretically enables
malicious merchants to later change the terms of the contract.
Beyond these primary issues, customers face secondary risks of
identity theft from the personal details exposed by the authentication
procedures. In this case, even if the financial damages are ultimately
covered by the bank, the customer always has to deal with the hassle
of {\em notifying} the bank in the first place. As a result,
customers must remain wary about using their card, which limits their
online shopping~\cite[p. 50]{ibi2014}.
% There is nevertheless a trend towards customers preferring cards
% over cash even in face-to-face purchases \cite{} in part because
% cash theft can be violent even if the amounts as stake are smaller
% than with electronic theft.
%
%Merchants are exposed to these same risks because either laws and/or
%contracts with the payment system providers require them to take care
%in handling customer information.
% 40 million stolen at target. fine?
%In cash payments, these risks do not exist because customers have
%complete control over the authentication procedure with their bank
%and the merchant is not involved.
% pressure to shop with big merchants
% merchants keep payment credentials on file
% Just a few merchants like Apple demand credentials up front
% "this reversal of authentication vs shopping slows shopping"
% \smallskip
\subsection{Bitcoin}
\begin{figure*}[b!]
\includegraphics[width=\textwidth]{figs/bitcoin.pdf}
\caption{Bitcoin payment processing. (From: W3C Web Payments IG.)}
\label{fig:bitcoin}
\end{figure*}
Bitcoin operates by recording all transactions in a pseu\-do\-ny\-mous
public {\em ledger}. A Bitcoin account is identified by its public
key, and the owner must know the corresponding private key to
authorize the transfer of Bitcoins from the account to other accounts.
The information in the global public ledger allows everybody to
compute the balances in all accounts and to see all transactions.
Transactions are denominated in a new currency labeled BTC, whose
valuation depends upon {\em speculation}, as there is no authority
that could act to stabilize exchange rates or force anyone to
accept BTC as {\em legal tender} to settle obligations. Adding transactions to
the global public ledger involves broadcasting the transaction data,
peers verifying and appending it to the public ledger, and some peer
in the network solving a moderately hard computational proof-of-work
puzzle, which is called {\em mining}.
The mining process is incentivised by a combination of transaction
fees and mining rewards~\cite{nakamoto2008bitcoin}. The latter
process also provides primitive accumulation~\cite{primitiveacc} for BTC.
Conversion to BTC from other currencies and vice versa incurs
substantial fees~\cite{BTCfees}. There is now an extreme diversity of
Bitcoin-related payment technologies, but usability improvements are
usually achieved by adding a trusted third party, and there have been
many incidents where such parties then embezzled funds from their
customers~\cite{BTC:demise}.
The classical Bitcoin payment workflow consisted of entering payment
details into a peer-to-peer application. The user would access their
Bitcoin {\em wallet} and instruct it to transfer a particular amount
from one of his accounts to the account of the merchant. He could
possibly include additional metadata to be associated with the
transfer and embedded into the global public ledger. The wallet
application would then transmit the request to the Bitcoin
peer-to-peer overlay network. The use of an external payment
application makes payments significantly less
browser-friendly than ordinary card payments, as illustrated in
Figure~\ref{fig:bitcoin}. This has led to the development of
browser-based
wallets.\footnote{\url{https://github.com/frozeman/bitcoin-browser-wallet}}
Bitcoin payments are only confirmed when they appear in the public
ledger, which is updated at an average frequency of once every 10
minutes. Even then, it is possible that a fork in the so-called block
chain may void durability of the transaction; as a result, it is
recommended to wait for 6 blocks (on average one hour) before
considering a transaction committed~\cite{nakamoto2008bitcoin}. In
cases where merchants are unable to accommodate this delay, they incur
significant fraud risks.
Bitcoin is considered to be secure against an adversary who cannot
control around a fifth of the Bitcoin miner's computational
resources~\cite{BTC:Bahack13,BTC:MajorityNotEnough,BTC:Eclipse}. % 21percent?
As a result, the network must expend considerable computational
resources to keep this value high.
According to~\cite{vice_btc_unsustainable}, a single Bitcoin transaction uses roughly enough
electricity to power 1.57 American households for a day.
These costs are largely hidden by speculation in BTC,
but that speculation itself contributes to BTC's valuation being
volatile.~\cite{jeffries_economists_v_btc,lehmann_btc_fools_gold,lewis_btc_is_junk}. % exacerbating risk
% fees hit you 2-3 times with currency conversions
% more on massive transaction fees from blockchain.info
Bitcoin's pseudononymity applies equally to both customers and
merchants, which makes Bitcoin amen\-able to tax evasion, money
laundering, and sales of contraband. 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}. This has resulted in
the development of new protocols with better privacy protections.
\begin{figure*}[t!]
\includegraphics[width=\textwidth]{figs/paypal.pdf}
\caption{Payment processing with PayPal. (From: W3C Web Payments IG.)}
\label{fig:paypal}
\end{figure*}
Zerocoin \cite{miers2013zerocoin} is such an extension of Bitcoin:
It affords protection against linkability of transactions,
but at non-trivial additional computational costs even for
spending coins. This currently makes using Zerocoin unattractive
for payments, especially with mobile devices.
Bitcoin also faces serious scalability limitations, with the classic
implementation being limited to at most 7 transactions per second
globally on
average.\footnote{\url{http://hackingdistributed.com/2016/08/04/byzcoin/}}
There are a variety of efforts to confront Bitcoin's scaling problems
with off-blockchain techniques, like side-chains. % \cite{???}
Amongst these, the Blind Off-chain Lightweight Transactions (BOLT)
proposal~\cite{BOLT} provides anonymity by routing off-blockchain
transfers through bank-like intermediaries. Although interesting,
there are numerous seemingly fragile aspects of the BOLT protocol,
including aborts deanonymizing customers, intermediaries risking
unlimited losses, and theft if a party fails to post a refute message
in a timely fashion.
% Of course, Taler itself could be used to provide a side-chain like technology
% Assuming these issues can be addressed,
% % and the relatively advanced crypto involved became production ready,
% Taler might prove a better platform for deploying a BOLT-like scheme
% than Zerocoin.
% In addition, the Bitcoin protocol does not interact well with
% conventional anonymity networks like Tor \cite{BTC:vsTor}
% dark pools?
% outdated ideas :
% mining suck0rs,
% DDoS : wired article?
% economic ideology
\subsection{Walled garden payment systems}
Walled garden payment systems offer ease of use by processing payments
using a trusted payment service provider. Here, the customer
authenticates to the trusted service, and instructs the payment
provider to execute a transaction on his behalf
(see Figure~\ref{fig:paypal}). In these payment systems, the provider
basically acts like a bank with accounts carrying balances for the
various users. In contrast to traditional banking systems, both
customers and merchants are forced to have an account with the same
provider. Each user must take the effort to establish his identity
with a service provider to create an account. Merchants and customers
obtain the best interoperability in return for their account creation
efforts if they start with the biggest providers. As a result, there
are a few dominating walled garden providers, with AliPay, ApplePay,
GooglePay, SamsungPay and PayPal being the current {\em oligopoly}. In this
paper, we will use PayPal as a representative example for our discussion
of these payment systems.
As with card payment systems, these oligopolies are politically
dangerous~\cite{crinkey2011rundle}, and the lack of {\em competition}
can result in excessive profit taking that may require political
solutions~\cite{guardian2015cap} to the resulting {\em market
failure}. The use of non-standard {\em proprietary} interfaces to
the payment processing service of these providers serves to reinforce
the customer {\em lock-in}.
\section{Taler}
Taler is a free software cryptographic payment system. It has an open
protocol specification, which couples cash-like anonymity for customers
with low transaction costs, signed digital
receipts, and accurate income information to facilitate taxation and
anti-corruption efforts.
% FIXME: maybe say what blind signature are
Taler achieves anonymity for buyers using {\em blind
signatures}~\cite{chaum1983blind}. Since their discovery thirty years
ago, cryptographers have viewed blind signatures as the optimal
cryptographic primitive for consumer-level transaction systems.
However, previous transaction systems based on blind signatures have
failed to see widespread adoption. This paper details strategies for
hiding the cryptography from users and integrating smoothly with the
Web, thereby providing crucial steps to bridge the gap between good
cryptography and real-world deployment.
%\subsection{Design overview}
\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}
There are four components of the Taler system (Figure~\ref{fig:system}):
\begin{figure*}[b!]
\includegraphics[width=0.9\textwidth]{figs/taler-withdraw.pdf}
\caption{Withdrawing coins with Taler.}
\label{fig:taler-withdraw}
\end{figure*}
\begin{itemize}
\item
{\em Customers} use a digital wallet to withdraw,
hold, and spend coins. Wallets also manage the customer's accounts
at the exchange, and keep receipts in a transaction history. Wallets can be
realized as browser extensions, mobile Apps or even in custom
hardware. If a user's digital wallet is compromised, the current
balance may be lost, just like with an ordinary wallet containing cash.
\begin{figure}[t!]%[36]{R}{0.5\linewidth}
\subfloat[Bank login. (Simplified for demonstration.)]{
\includegraphics[width=0.45\linewidth]{figs/bank0a.png}
\label{subfig:login}} \hfill
\subfloat[Specify amount to withdraw. (Integrated bank support.)]{
\includegraphics[width=0.45\linewidth]{figs/bank1a.png}
\label{subfig:withdraw}} \\
\subfloat[Select exchange provider. (Generated by wallet.)]{
\includegraphics[width=0.45\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}
\label{subfig:pin}}
\caption{Required steps in a Taler withdrawal process.}
\label{fig:withdrawal}
\end{figure}
\item
{\em Exchanges}, which are run by financial service providers, enable
customers to withdraw anonymous digital coins,
and merchants to deposit digital coins, in exchange for
bank money. Coins are signed by the exchange using
a blind signing scheme~\cite{chaum1983blind}. Thus, only
the exchange can issue new coins, but coins cannot be traced back
to the customer that withdrew them.
Furthermore, exchanges learn the amounts withdrawn by customers
and deposited by merchants, but they do not learn the relationship
between customers and merchants. Exchanges perform online detection
of double spending, thus providing merchants instant feedback
---including digital proofs---in case of misbehaving customers.
\item
{\em Merchants} provide goods or services in exchange for coins held
by customers' wallets. Merchants deposit these coins at the
exchange for their regular currency value. Merchants consist of a
{\em frontend}, which interacts with the customer's wallet, and a {\em
backend}, which interacts with the exchange. Typical frontends include
Web shops and point-of-sale systems.
\item
{\em Auditors} verify that exchanges operate correctly to limit the risk
that customers and merchants incur by using a particular exchange.
Auditors are typically operated by or on behalf of financial regulatory authorities.
Depending on local legislation, auditors mandate that exchanges
have enough financial reserves before authorizing them to create a given
volume of signed digital coins in order to compensate for potential risks due to
operational failures (such as data loss or theft of private keys) of the exchange.
\end{itemize}
The specific protocol between wallet and merchant depends on the
setting. For a traditional store, a near field communication (NFC)
protocol might be used between a point-of-sale system and a mobile
application. In this paper, we focus on Web payments for an online
shop and explain how the actors in the Taler system interact by way of
a typical payment.
Initially, the customer installs the Taler wallet extension for
their browser. This only needs to be done once per
browser. Naturally, this step may become superfluous if Taler is
integrated tightly with browsers in the future. Regardless,
installing the extension involves one or two clicks to confirm the
operation. Restarting the browser is not required.
\begin{figure*}[t!]
\includegraphics[width=0.9\textwidth]{figs/taler-pay.pdf}
\caption{Payment processing with Taler.}
\label{fig:taler-pay}
\end{figure*}
\subsection{Withdrawing coins}
As with cash, the customer must first withdraw digital coins
(Figure~\ref{fig:taler-withdraw}). For this, the customer must first
visit the bank's online portal. Here, the bank will
typically require some form of authentication, the specific method
used depends on the bank (Figure~\ref{subfig:login}).
The next step depends on the level of Taler support offered by the bank:
\begin{itemize}
\item If the bank does not offer integration with Taler, the
customer needs to use the menu of the wallet to create a {\em reserve}.
The wallet will ask which amount in which {\em currency} (e.g. EUR
or USD) the customer wants to withdraw, and allow the customer to
select an exchange. Given this information, the wallet will
instruct the customer to transfer the respective amount to the
account of the exchange. The customer will have to enter a
% FIXME it is not said that this crypto token is the reserve,
% or, more abstractly, that "identify" this operation
% CG: I don't think this has to be said.
54-character reserve key, which includes 256 bits of entropy and an
8-bit checksum into the transfer subject. Naturally, the above is
exactly the kind of interaction we would like to avoid for
usability reason.
\item Hence, if the bank fully supports Taler, the
customer has a form in the online banking portal in which they can specify
an amount to withdraw (Figure~\ref{subfig:withdraw}).
The bank then triggers an interaction with
the wallet to allow the customer to select an exchange
(Figure~\ref{subfig:exchange}). Afterwards,
the wallet instructs the bank about the details of the wire
transfer. The bank asks the customer to authorize the transfer, and
finally confirms to the wallet that the transfer has been
successfully initiated.
\end{itemize}
In either case, the wallet can then withdraw the coins from the
exchange, and does so in the background without further interaction
with the customer.
In principle, the exchange can be directly operated by the bank, in
which case the step where the customer selects an exchange could be
skipped by default. However, we generally assume that the exchange is
a separate entity, as this yields the largest anonymity set for
customers, and may help create a competitive market.
\subsection{Spending coins}
% \tinyskip
\begin{figure}[t!]
\subfloat[Select article. (Generated by Web shop.)]{
\includegraphics[width=0.30\textwidth]{figs/cart.png}
\label{subfig:cart}} \hfill
\subfloat[Confirm payment. (Generated by Taler wallet.)]{
\includegraphics[width=0.30\textwidth]{figs/pay.png}
\label{subfig:payment}} \hfill
\subfloat[Receive article. (Generated by Web shop.)]{
\includegraphics[width=0.30\textwidth]{figs/fulfillment.png}
\label{subfig:fulfillment}}
\caption{Required steps in a Taler checkout process.}
\label{fig:shopping}
\end{figure}
At a later point in time, the customer can spend their coins by
visiting a merchant that accepts digital coins in the respective
currency issued by the respective exchange
(Figure~\ref{fig:taler-pay}). Merchants are generally configured to
either accept a specific exchange, or to accept all the exchanges
audited by a particular auditor. Merchants can also set a ceiling for
the maximum amount of transaction fees they are willing to cover.
Usually these details do not matter for the customer, as we expect
most merchants to allow most accredited exchange providers, and for
exchanges to operate with transaction fees acceptable to most
merchants. If transaction fees are higher than what is covered by the
merchant, the customer may choose to cover them.
% \tinyskip
\lstdefinelanguage{JavaScript}{
keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break, for},
keywordstyle=\color{blue}\bfseries,
ndkeywords={class, export, boolean, throw, implements, import, this},
ndkeywordstyle=\color{darkgray}\bfseries,
identifierstyle=\color{black},
sensitive=false,
comment=[l]{//},
morecomment=[s]{/*}{*/},
commentstyle=\color{purple}\ttfamily,
stringstyle=\color{red}\ttfamily,
morestring=[b]',
morestring=[b]"
}
\begin{figure*}[h!]
\lstset{language=HTML5}
\lstinputlisting{figs/taler-presence-js.html}
\caption{Sample code to detect the Taler wallet. Allowing the
Web site to detect the presence of the wallet leaks one bit
of information about the user. The above logic also works
if the wallet is installed while the page is open.}
\label{listing:presence}
\end{figure*}
\begin{figure*}[h!]
\lstset{language=JavaScript}
\lstinputlisting{figs/taler-contract.js}
\caption{Sample code to pass a contract to the Taler wallet.
Here, the contract is fetched on-demand from the server.
The {\tt taler\_pay()} function needs to be invoked
when the user triggers the checkout.}
\label{listing:contract}
\end{figure*}
As with traditional Web transactions, customers first select which
items they wish to buy. This can involve building a traditional
shopping cart, or simply clicking on a particular link for the
respective article (Figure~\ref{subfig:cart}).
Taler also allows the Web shop to detect
the presence of a Taler wallet (Figure~\ref{listing:presence}), so
that the selection of other payment methods can be skipped
if a Taler wallet is installed (as it is in Figure~\ref{fig:shopping}).
Web pages can initiate payments by sending a \emph{contract proposal} to the
wallet, either via the status code HTTP 402 Payment Required, or via a
JavaScript API. The wallet then presents the contract to the user. The format
of the contract is in an extensible JSON-based format defined by Taler and not
HTML, as the rendering of the contract is done by the wallet to ensure correct
visual representation of the terms and price. In case that transaction fees need to be covered by the
customer, these are shown together with the rest of the proposed contract.
If the customer approves the contract by clicking the ``Confirm
Payment'' button (Figure~\ref{subfig:payment}), their wallet signs the
contract with enough coins to cover the contract's cost, stores all of
the information in its local database, and redirects the browser to a
{\em fulfillment} URL provided by the merchant
(Figure~\ref{subfig:fulfillment}).
\subsection{Browser security}
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.
The current Taler specification is written to accommodate for
the rather restrictive set of APIs that WebExtension, a
cross-browser extension API, provides.
\subsection{Managing browser session state}
% FIXME: this is where we probably want to revise quite a bit,
% including improving the description AND addressing the JS-less
% implementation.
% Say that this doesn't require accounts!
% explain that HTTP session state can be restored
% from the wallet state (replay!)
% explain repurchase correlation ID
% contract vs complete fulfillment URL
% design that allows merchant to not store any information
A purchase by a customer, completed or in progress, is uniquely identified by a URL, called
the \emph{fulfillment URL}. The information contained in the fulfillment
URL must allow the merchant to restore the full contract that was associated
with purchase, either directly or indirectly from an identifier in a database%
\footnote{Storing information about incomplete purchases potential for abuse from malicious customers.}.
When a customer completed a purchase, navigating to the fulfillment URL in a browser
will show the resource associated with the purchase. This resource can be a
digital good such as a news article, or simply a confirmation for products that
are delivered by other means.
In order to ensure that only the paying customer has access to the web
resources behind the fulfillment URL, the web store's server must check the
browser's session state. Visiting the fulfillment URL for the first
time\footnote{Or after deleting the session state, which e.g. happens when
privacy conscious users delete their cookies. Some user agents (such as the TOR browser)
do not support persistent (non-session) cookies.} triggers the wallet to send the
signed coins that are associated with the contract for the fulfillment URL to
the merchant. This process can be triggered via a JavaScript API for the
wallet, or by a \emph{HTTP 402 Payment Required} status code.
When a user visits a fulfillment URL without having the associated contract
in their wallet, the wallet redirects the browser to the offer URL for that
purchase, if applicable. This behavior is useful when a user wishes to
send a fulfillment link to another user.
Note that due to the limited WebExtensions API, the session
state can only be acquired when the browser navigates to
the fulfillment URL (without session state), since the session
state must be set on the same origin as the fulfillment URL.
Various failure modes are considered:
\begin{itemize}
\item If the payment fails on the network, the request is typically
retried. How often the client retries automatically before informing
the user of the network issue is up to the merchant. If the network
% FIXME this (above) could be ambiguous because the network failure
% can happen between the wallet and the merchant without the merchant
% getting any (failing) request, so the merchant cannot count how much
% times a payment has failed.
% CG: Well, the merchant can do that counting *client-side*. The retries
% will be controlled by the JS on the client side, which is provided
% by the merchant initially.
failure persists and is between the customer and the merchant, the wallet
will try to recover control over the coins at the exchange by
effectively spending the coins first using Taler's
refresh protocol. In this case, later deposits by the merchant
will simply fail. If the merchant already succeeded with the payment
before the network failure, the customer can either retry the
operation via the transaction history, or demand a refund (see
below). Handling these errors does not require the customer to give
up his privacy.
\item If the payment fails due to the exchange
claiming that the request was invalid, the diagnostics created by the
exchange are passed to the wallet for inspection. The wallet then
decides whether the exchange was correct, and can then inform the
user about a fraudulent or buggy exchange. At this time, it allows
the user to export the relevant cryptographic data to be used in
court. If the exchange's proofs were correct and coins were
double-spent, the wallet informs the user that its database must have
been out-of-date (e.g. because it was restored from backup),
updates the database and allows the user to retry
the transaction.
\end{itemize}
While our design has a few extra roundtrips,
it has the following 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 Sending deep links to other users has the expected behavior
of asking the other user to pay for the resource.
\item Asynchronously POSTing coins from injected JavaScript costs
one roundtrip, but does not interfer with navigation and allows
proper error handling.
\item The different pages of the merchant have clear
delineations: the shopping pages conclude by proposing a contract, and
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
resource sharing~\cite{rfc6454,cors}.
\end{itemize}
% \smallskip
\subsection{Giving change and refunds} % FIXME: maybe leave out change entirely?
An important technical difference between Taler and previous
transaction systems based on blind signing is that Taler is able to
provide unlinkable change and refunds. From the user's point of view,
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
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
the exchange providers and fee structure, but not the cryptographic
coins. Consequently, the major cryptographic advances of Taler are
invisible to the user.
Taler's refresh protocol~\cite{talercrypto} also allows merchants to
give refunds to customers. For this, the merchant merely has to send a
signed message to the exchange confirming the refund, and notify the
customer's wallet that the respective transaction was refunded. This
can even be done with anonymous customers, as refunds are given as
additional change to the owner of the coins that were originally spent
to pay for the refunded transaction.
Taler's refresh protocol ensures unlinkability for both change and
refunds, thereby assuring that the user has key conveniences of other
payment systems while maintaining the security standard of an
anonymous payment system.
% Alternative version:
%An important technical difference between Taler and previous
%transaction systems based on blind signing is that in Taler coins
%consist of a public-private key pair with the blind signature on the
%public key, so that coins themselves can be used to anonymously sign
%the purchase contract.
%
%An important technical difference between Taler and previous
%transaction systems based on blind signing is that Taler coins
%consist of a public-private key pair with the blind signature on the
%public key, so that coins themselves can be used to anonymously sign
%the purchase contract.
%
%In general, these coins exceed the cost of the contract, so the wallet
%may specify that only a fraction of a coin be spent, leaving some
%residual value on the partially spent coin as ``change''.
%
%As the merchant received only a signature of the coin, not private
%or symmetric key material, merchants can refund anonymous coins by
%asking the mint to restore a part of the coin's original value,
%and notifying the customer's wallet to refresh the coin.
%
%Spending Taler coins reveals nothing about a customer per se.
%Yet, any coins that hold value after being involved in a purchase or
%a refund operation cannot be considered anonymous anymore because a
%merchant, and possibly the exchange, has now seen them and could
%link them that previous transaction. At best, these tainted coins
%are only pseudononymous, similar to Bitcoin accounts.
%
%To maintain anonymity, a Taler wallet automatically performs a
%{\em refresh} operation with the mint API to both replace tainted
%coins with new freshly anonymized coins and to exchange old coins
%before their denomination's expiration date. We view refreshing
%partially spent coins as analogous to giving change in cash
%transactions, but refreshing refunded coins allows Taler merchants
%to refund anonymous customers. Cash transactions have these options,
%but credit cards require customer identification for both operations.
% Is this true?
% no comment around randomizing the serial numbers on bills
\subsection{Deployment considerations for merchants}
Payment system security is not only a concern for
customers, but also for merchants. For consumers, existing schemes
may be inconvenient and not provide privacy, but remembering to
protect a physical token (e.g. the card) and to guard a secret
(e.g. the PIN) is relatively straightforward. In contrast, merchants
are expected to securely handle sensitive customer payment data on
networked computing devices. However, securing computer systems---and
especially payment systems that represent substantial value---is a
hard challenge, as evidenced by large-scale break-ins with millions of
consumer card records being illicitly copied~\cite{target}.
Taler simplifies the deployment of a secure payment system for
merchants. The high-level cryptographic design provides the first
major advantage, as merchants never receive sensitive payment-related
customer information. Thus, they do not have to be subjected to
costly audits or certified hardware, as is commonly the case for
processing card payments~\cite{pcidss}. In fact, the exchange does not
need to have a formal business relationship with the merchant at all.
According to our design, the exchange's contract with the state
regulator or auditor and the customers ought to state that it must
honor all (legal and valid) deposits it receives. Hence, a merchant
supplying a valid deposit request should be able to enforce this in
court without a prior direct business agreement with the exchange.
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
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
providing a generic payment processing {\em backend} for the Web
shops.
\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) {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 with the Taler exchange from the wallet background
to withdraw coins and the Taler backend
to deposit coins are not shown.
Existing system security mechanisms
are used to isolate the cryptographic components (boxes) from
the complex rendering logic (circles), hence the communication
is restricted to JavaScript signals or HTTP(S), respectively.}
\label{fig:frobearch}
\end{figure*}
Figure~\ref{fig:frobearch} shows how the secure payment components
interact with the existing Web shop logic. First, the Web shop
frontend is responsible for constructing the shopping cart. For this,
the shop frontend generates the usual Web pages, which are transmitted
to the customer's browser. Once the order has been constructed, the
shop frontend provides a {\em proposed contract} in JSON format to the
payment backend, which signs it and returns it to the frontend. The
frontend then transfers the signed contract over the network, and
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
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
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 (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:
{\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
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 the
wire transfer routing details, such as the merchant's IBAN number.
Ideally, the merchant might also want to obtain a certificate for the
public key generated by the backend for improved authentication.
Otherwise, the customer's authentication of the Web shop simply
continues to rely upon HTTPS/X.509.
\section{Discussion}
We will now discuss how customer's may experience relevant operational
risks and failure modes of Taler, and relate them to failure modes
in existing systems.
% \smallskip
\subsection{Security risks}
In Taler, customers incur the risk of wallet loss or theft. We
believe customers can manage this risk effectively because they manage
similar risks of losing cash in a physical wallet. Unlike physical
wallets, Taler's wallet could be backed up to secure against loss of a
device.
Taler's contracts provide a degree of protection for customers,
because they are signed by the merchant and retained by the wallet.
While they mirror the paper receipts that customers receive in
physical stores, Taler's cryptographically signed contracts ought to
carry more weight in courts than typical paper receipts.
Point-of-sale systems providing printed receipts have been compromised
in the past by merchants to embezzle sales
taxes.~\cite{munichicecream} With Taler, the merchant still generates
a receipt for the customer, however, the record for the tax
authorities ultimately is anchored with the exchange's wire transfer
to the merchant. Using the subject of the wire transfer, the state
can trace the payments and request the merchant provide
cryptographically matching contracts. Thus, this type of tax
fraud is no longer possible, which is why we call Taler {\em
taxable}. The mere threat of the state sometimes tracing transactions
and contracts back to the merchant also makes Taler unsuitable for
illegal activities.
The exchange operator is obviously crucial for risk management in
Taler, as the exchange operator holds the customer's funds in a
reserve in escrow until the respective deposit request arrives\footnote{As
previously said, this {\it deposit request} is aimed to translate {\it coins}
into real money and it's accomplished by a merchant after successfully
receiving coins by a wallet. In other words, it is the way merchants get
real money on their bank accounts}. To ensure that the exchange operator
does not embezzle these funds, Taler expects exchange operators to be
regularly audited by an independent auditor\footnote{Auditors are typically
run by financial regulatory bodies of states}. The auditor can then verify that the incoming and outgoing
transactions, and the current balance of the exchange matches the logs
with the cryptographically secured transaction records.
% \smallskip
\subsection{Failure modes}
There are several failure modes the user of a Taler wallet may
encounter:
\begin{itemize}
\item
As Taler supports multiple exchanges, there is a chance that a
merchant might not support any exchange where the customer withdrew
coins from. We mitigate this problem by allowing merchants to
support all exchanges audited by a particular auditor. We believe
this a reasonable approach, because auditors and merchants must
operate with a particular legal and financial framework anyways. We
note that a similar failure mode exists with credit cards where not
all merchants accept all issuers, which is often the case internationally.
\item
Restoring the Taler wallet state from previous backups, or copying the
wallet state to a new machine may cause honest users to attempt to
double spend coins, as the wallet does not know when coins are spent
between backup and recovery. In this case, the exchange provides
cryptographic proof to the wallet that the coins were previously spent so the
wallet can verify that the exchange and the merchant are behaving honestly.
% FIXME FIXME: the following paragraph seems to describe a scenario where the
% wallet lost coins due to a restore from backup and then ask for refresh
% of lost coins: but how does the wallet know lost coins' public keys?
% CG: I don't understand the problem.
%
% Also in this paragraph: how can a payment end in-flight due to insufficient
% funds? If the payment has been started by the wallet, then no 'insufficient
% funds' may occur, otherwise the wallet would not have started the payment.
%
% CG: Yes, as I explain if the Wallet isn't aware that some coins were
% already spent (I make a backup, spend coins, restore backup, try to
% spend again), then this may happen.
%
% A way to fix that could be to better define 'internal invariants' ..
%
% CG: The internal invariant is exactly the one you fell upon:
% That the wallet knows which coins have been spent!
\item
There could be insufficient funds in the Taler wallet when making a
payment. Usually the wallet can trivially check this before beginning
a transaction, but when double-spending is detected this may also
happen after the wallet already initiated the payment. This would
usually only happen if the wallet is unaware of a backup operation
voiding its internal invariant of knowing which coins have already
been spent. If a payment fails in-flight due to
insufficient funds, the wallet can use Taler's refresh protocol to
obtain a refund for those coins that were not actually double-spent,
and then explain to the user that the balance was inaccurate due to
inconsistencies, and insufficient for payment.
For the user, this failure mode appears equivalent to an insufficient
balance or credit line when paying with debit or credit cards.
\end{itemize}
\subsection{Comparison}
The different payment systems discussed make use of different security
technologies, which has an impact on their usability and the
assurances they can provide. Except for Bitcoin, all payment systems
described involve an authentication step.
% FIXME alternative for the following sentence:
% With Taler, the authentication is implicit when withdrawing, since
% the user has to login into his bank's Web portal in the first place,
% and no further authentication is required during the whole payment
% experience.
% CG: Not exactly, as the authentication to the bank is still
% a very explicit authentication step. It's just more natural.
With Taler, the authentication itself is straightforward, as the customer is
at the time visiting the Web portal of the bank, and the authentication is
with the bank (Figure~\ref{fig:taler-withdraw}). With PayPal, the
shop redirects the customer to the PayPal portal (step 5 in
Figure~\ref{fig:paypal}) after the user selects PayPal as the payment
method. The customer then provides the proof of payment to the
merchant. Again, this is reasonably natural. The 3DS workflow
(Figure~\ref{fig:cc3ds}) has to deal with a multitude of banks and
their different implementations, and not just a single provider.
Hence, the interactions are more complicated as the merchant needs to
additionally perform a lookup in the card scheme directory and verify
availability of the bank (steps 8 to 12).
The key difference between Taler and 3DS or PayPal is that
in Taler, authentication is done ahead of time.
After authenticating once to withdraw digital coins, the customer can
perform many micropayments without having to re-authenticate. While
this simplifies the process of the individual purchase, it shifts the
mental overhead to an earlier time, and thus requires some planning,
especially given that the digital wallet is likely to only contain a
% FIXME line below: which 'funds'? Coins or real money? (If they are
% coins, recall that the wallet withdraw all the coins from a fresh
% reserve, so there is no 'fraction' of user's available funds; at
% least in the current implementation)
% I originally wrote ``wealth'' or ``net value'', but given that
% most customers are in debt today, that makes little sense, so
% I changed it to ``available funds'', but I meant _all_ the money
% he has.
small fraction of the customer's available funds. As a result, Taler
improves usability if the customer is able to withdraw funds once to
then facilitate many micropayments while Taler is likely less usable
if for each transaction the customer first visits the bank to withdraw
funds. This is deliberate, as Taler can only achieve reasonable
privacy for customers if they keep a balance in their wallet,
which breaks the association between withdrawal and deposit.
% FIXME the sentence above can be in contrast with how the exchange
% actually deposits funds to merchants, that is through 'aggregate
% deposits' that may add unpredictable delays (but that doesn't affect
% this article too much)
% CG: I think mentioning aggregation here would distract.
Bitcoin's payment process (Figure~\ref{fig:bitcoin}) resembles that of
Taler in one interesting point, namely that the wallet is given
details about the contract the user enters (steps 7 to 11).
However, in contrast to Taler, Bitcoin wallets are expected
to fetch the ``invoice'' from the merchant. In Taler, the browser
provides the Taler wallet with the proposed contract directly. In
PayPal and 3DS, the user is left without a cryptographically secured
receipt.
Card-based payments (including 3DS) and PayPal also extensively rely
on TLS for security. The customer is expected to verify that their
connections to the various Web sites are properly authenticated using
X.509, and to know that it is fine to provide their bank account
credentials to the legitimate
\url{verifiedbyvisa.com}.\footnote{The search query
``verifiedbyvisa.com legit'' is so common that, when we entered
``verifiedbyvisa'' into a search engine, it was the suggested
auto-completion.} However, relying on users understanding their
browser's indications of the security context is inherently
problematic. Taler addresses this challenge by ensuring that digital
coins are only accessible from wallet-generated pages. As such
there is no risk of Web pages mimicking the look of the respective
page, as they would still not obtain access to the digital coins.
Once the payment process nears its completion, merchants need to have
some assurance that the contract is valid. In Taler, merchants
obtain a non-repudiable confirmation of the payment. With 3DS and
PayPal, the confirmation may be disputed later (e.g. in case of
fraud), or accounts may be frozen arbitrarily~\cite{diaspora2011}.
Payments in cash require the merchant to assume the risk of receiving
counterfeit money.
% FIXME what about (for the following sentence): merchants should care
% about maintaining change and depositing the money earned
% CG: No, it's not optional, ``should'' doesn't come into the equation
% here. It's a mandatory business expense.
Furthermore, merchants have the cost of maintaining change and depositing
the money earned. At the extreme, there is no definitive time until a
Bitcoin payment can be said to be confirmed (step 19, Figure~\ref{fig:bitcoin}),
leaving merchants in a bit of a tricky situation.
Finally, attempts to address the scalability hudles of Bitcoin using
side-chains or schemes like BOLT introduces semi-centralized
intermediaries, not wholey unlike Taler's use of exchanges.
We expect a Taler exchange operating in BTC to offer stronger security
to all parties and stronger anonymity to customers, as well as being
vastly cheaper to operate and more compatible with existing financial regulations.
\section{Future work}
This paper has focused on how Taler would work for Web payments.
However, the underlying cryptography should work just as well for
other domains. In particular, we plan to adapt Taler for NFC and
peer-to-peer payments in the future.
\subsection{NFC payments}
We have so far focused on how Taler could be used for Web payments;
however, Taler can in theory also be used over other protocols, such
as near field communication (NFC). Here, the user would hold his
NFC-enabled device running a wallet application near an NFC terminal
to obtain the contract and confirm the payment on his device, which
would then transfer the coins and obtain a receipt. A native NFC
application would be less restricted in its interaction with the
point-of-sale system compared to a browser extension, and the security
of the communication channel is also comparable. Thus, running
Taler over NFC is largely a simplification of the existing process.
In particular, there are no significant new concerns arising from an
NFC device possibly losing contact with a point-of-sale system, as for
Web payments, Taler already only employs idempotent operations to
ensure coins are never lost, and that transactions adequately persist
even in the case of network or endpoint failures. As a result, the
NFC system can simply use the same transaction models to replay
transmissions once contact with the point-of-sale system is
reestablished.
\subsection{Peer-to-peer payments}
Peer-to-peer payments are in principle possible with Taler as well;
however, we need to distinguish two types of peer-to-peer payments.
First, there is the {\em sharing} of coins among entities that
mutually trust each other, for example within a family. Here, all
users have to do is to export and import electronic coins over a
secure channel, such as encrypted e-mail or via NFC. For NFC, the
situation is straightforward because we presumably do not have to worry
about man-in-the-middle attacks, while secure communication over the
Internet is likely to remain a significant usability challenge. We
note that sharing coins by copying the respective private keys across
devices is not taxable: the exchange is not involved, no contracts are
signed, and no records for taxation are created. However, the
involved entities must trust each other, because after copying a private
key both parties could spend the coins, but only the first transaction
will succeed. Given this crucial limitation
inherent in sharing keys, we consider it ethically acceptable that
sharing is not taxable.
Second, there is the {\em transactional} mutually exclusive transfer
of ownership. This requires the receiving party to have a {\em
reserve} with an exchange, and the exchanges would have to support
wire transfers among them. If taxability is desired, the {\em
reserve} would still need to be tied to a particular citizen's
identity for tax purposes, and thus require similar identification
protocols as commonly used for establishing a bank account. As such, in
terms of institutions, one would expect this setup to be offered most
easily by traditional banks.
In terms of usability, transactional
transfers are just as easy as sharing when performed over NFC, but
more user friendly when performed over the Internet as they do not
require a secure communication channel: the Taler protocol is by
design still safe to use even if the communication is made over an
unencrypted channel. Only the authenticity of the proposed contract
needs to be assured.
\section{Conclusion}
Customers and merchants should be able to easily adapt their existing
mental models and technical infrastructure to Taler. In contrast,
Bitcoin's payment models fail to match common expectations be it in
terms of performance, durability, security, or privacy. Minimizing
the need to authenticate to pay fundamentally improves security
and usability.
% FIXME (following paragraph): it's never said that the Taler wallet
% keeps any 'receipt' of transaction -- maybe here we want to say 'contract'
% instead of 'receipt'?
% CG: I'd say on the customer side, the signed contract is a receipt.
% That should be intuitive.
We expect that electronic wallets that automatically collect digitally
signed receipts for transactions will become commonplace.
In this way, Taler gives the user full control over the usage of their
transaction history, as opposed to giving control to big data corporations.
We encourage readers to try our prototype for Taler
at \url{https://demo.taler.net/}, and to ponder why the billion dollar
e-commerce industry still relies mostly on TLS for security given
that usability, security and privacy can clearly {\em all} be improved
simultaneously using a modern payment protocol.
% 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. We
thank Neal Walfield for comments on an earlier draft of the paper.
\bibliographystyle{splncs03}
\bibliography{ui,btc,taler,rfc}
\end{document}
% \smallskip
\subsection{Anonymity}
We strongly recommend that the user use Tor Browser to protect their
% FIXME wasn't the use of Tor discouraged to login into personal things?
IP address, both initially when withdrawing coins and later during
purchases.
There are lingering risks that anonymous coins can be correlated to
customers using additional information.
After withdrawing coins, customer should usually wait before spending
them, as spending them immediately ....
% wallet determines coin denominations
Wallet provides isolation
Near copy from EXIST proposal?
- Limits user risk
- Nearly eliminates risk for merchant and exchange
- lower transaction fees
- Reserves simplify things
Denomination choice
- Anonymity refresh protocol
- Withdraw automates like ATMs
Browser extension
- RESTful vs Bitcoin, OpenCoin, etc.
- Retrying RESTful transactions always works
- minimizing dialog
- see & pay ??
- TBB integration
- Needed anyways
- Other browser integration?
- Is it wise? Ok if not worried about anonymity Taler is still better
- Is tor2web worse?
- W3C
Autopay? pat payment recognition?
- dangerous?
- high charges
- good for funny money
NFC
% \smallskip
\subsection{Risks}
A Taler exchange's need not face significant financial risks beyond
the risk of losing a denomination signing key. Exchanges can limit that
risk by carefully tracking how much they issue in each denomination.
Taler merchant's risks are limited primarily by depositing coins
quickly and stating contracts accurately.
|