aboutsummaryrefslogtreecommitdiff
path: root/articles
diff options
context:
space:
mode:
Diffstat (limited to 'articles')
-rw-r--r--articles/ui/ui-cameraready.tex1640
1 files changed, 1640 insertions, 0 deletions
diff --git a/articles/ui/ui-cameraready.tex b/articles/ui/ui-cameraready.tex
new file mode 100644
index 000000000..59a834212
--- /dev/null
+++ b/articles/ui/ui-cameraready.tex
@@ -0,0 +1,1640 @@
+\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 \and
+Florian Dold \and
+Christian Grothoff \and
+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 3-D Secure~\cite{3DSsucks} payment
+process takes too long, is way too complex,
+and way too 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, it was not until 2015 that 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} that 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.
+
+
+% \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 3-D Secure (3DS). (From: W3C Web Payments IG.)}
+%\label{fig:cc3ds}
+%\end{figure*}
+%KG: I hope they can print this larger, because this is WAY too small to be of any use.
+
+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. Secure
+systems typically combine multiple forms of authentication including
+secret information, such as personal identification numbers (PINs),
+transaction numbers (TANs)~\cite{kobil2016tan} or credit card
+verification (CCV) codes, and physical security devices such cards
+with an EMV chip~\cite{emv}, TAN generators, or the customer's mobile
+phone~\cite{mtan}. A typical modern Web payment process involves:
+{(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, CCV code, and billing address; and {(4.)}
+(optionally) authorizing the transaction via mobile TAN, or by
+authenticating against the customer's bank. Due to the complexity
+of this, the data entry is often performed on a Web site that
+is operated by a third-party payment processor and {\em not} the merchant or
+the customer's bank.
+%KG: Define 3DS the FIRST time you use it.
+
+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 \cite[\S2.4]{3DSsucks}.
+%
+% 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 procedure
+of {\em notifying} the bank in the first place. As a result,
+customers must remain wary about using their cards, 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 to be 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. 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, sales of contraband, and especially extorion
+ \cite{NYA:CyberExtortionRisk}.
+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.
+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 privacy-preserving 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 complexity of 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=1.5em and 8em, 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 key roles in 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 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 as with an ordinary wallet containing cash.
+A wallet includes a list of trusted auditors, and will warn
+users against using an exchange that is not certified by a trusted
+auditor.
+
+%\begin{figure}[b!]%[36]{R}{0.5\linewidth}
+%\subfloat[Bank login. (Simplified for demonstration.)]{
+%\includegraphics[width=0.4\linewidth]{figs/bank0a.png}
+%\label{subfig:login}} \hfill
+%\subfloat[Specify amount to withdraw. (Integrated bank support.)]{
+%\includegraphics[width=0.4\linewidth]{figs/bank1a.png}
+%\label{subfig:withdraw}} \\
+%\subfloat[Select exchange provider. (Generated by wallet.)]{
+%\includegraphics[width=0.4\linewidth]{figs/bank2a.png}
+%\label{subfig:exchange}} \hfill
+%\subfloat[Confirm transaction with a PIN. (Generated by bank.)]{
+%\includegraphics[width=0.4\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 signature scheme~\cite{chaum1983blind}. Thus, only
+an exchange can issue new coins, but coins cannot be traced back
+to the customer who 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 used by the customer in return for a bank wire
+transfer of their value. While the exchange is determined by
+the customer, the merchant's contract specifies the currency,
+a list of accepted auditors, and the maximum exchange deposit
+fee the merchant is willing to pay. 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 may mandate that exchanges
+have enough financial reserves before authorizing them to create a given
+volume of signed digital coins to provide a buffer against potential risks due to
+operational failures (such as data loss or theft of private keys) of the exchange.
+Auditors certify exchanges that they audit using digital signatures. The
+respective signing keys of the auditors are distributed to customer and
+merchants.
+\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 only one or two clicks to confirm the
+operation. Restarting the browser is not required.
+
+
+\begin{figure*}[b!]
+\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.
+
+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 reasons.
+\item Otherwise, 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.
+ The bank then triggers an interaction with
+ the wallet to allow the customer to select an 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}[p!]
+% \subfloat[Select article][Select article. \\ Generated by Web shop.]{
+%\includegraphics[width=0.30\textwidth]{figs/cart.png}
+%\label{subfig:cart}} \hfill
+%\subfloat[Confirm payment][Confirm payment. \\ Generated by Taler wallet.]{
+%\includegraphics[width=0.30\textwidth]{figs/pay.png}
+%\label{subfig:payment}} \hfill
+%\subfloat[Receive article][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 accept most exchange providers accredited by the
+auditors that wallets include by default. Similarly, we expect
+exchanges to operate with transaction fees acceptable to most
+merchants to avoid giving customers a reason to switch to another
+exchange. 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*}[p!]
+% \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*}[t!]
+ \lstset{language={}}
+\begin{lstlisting}
+HTTP/1.1 402 Payment Required
+Content-Type: text/html; charset=UTF-8
+X-Taler-Contract-Url: https://shop/generate-contract/42
+
+<!DOCTYPE html>
+<html>
+<!-- fallback for browsers without the Taler extension -->
+You do not have Taler installed. Other payment options are ...
+</html>
+\end{lstlisting}
+ \caption{Sample HTTP response to prompt the wallet to show an offer.}
+ \label{listing:http-contract}
+\end{figure*}
+
+%\begin{figure*}[p!]
+% \lstset{language=HTML5}
+% \lstinputlisting{figs/taler-contract.html}
+% \caption{Sample JavaScript code to prompt the wallet to show an offer.
+% 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. Once the articles have
+been selected, the Web shop directs the user to the {\em offer} URL,
+where the payment details are negotiated. The process usually starts
+by allowing the user to select a {\em payment method} from a set of
+methods supported by the Web shop. Taler also allows the Web shop to
+detect the presence of a Taler wallet,
+so that the selection of alternative payment methods can be skipped if
+a Taler wallet is installed.
+
+%\begin{figure*}[t!]
+% \lstset{language=JavaScript}
+%\begin{lstlisting}
+%{
+% "H_wire":"YTH0C4QBCQ10VDNTJN0DCTTV2Z6JHT5NF43F0RQHZ8JYB5NG4W4G...",
+% "amount":{"currency":"EUR","fraction":1,"value":0},
+% "auditors":[{"auditor_pub":"42V6TH91Q83FB846DK1GW3JQ5E8DS273W4236AXC397892ESD0B0"}],
+% "exchanges":[{"master_pub":"1T5FA8VQHMMKBHDMYPRZA2ZFK2S63AKF0YTHJZWFKF45K2JGC8H0",
+% "url":"https://exchange/"}],
+% "expiry":"/Date(1480119270)/",
+% "fulfillment_url": "https://shop/article/42?tid=249960194066269&time=1471479270",
+% "max_fee":{"currency":"EUR","fraction":01,"value":0},
+% "merchant":{"address":"Mailbox 4242","jurisdiction":"Jersey","name":"Shop Inc."},
+% "merchant_pub":"Y1ZAR5346J3ZTEXJCHQY9NJN78EZ2HSKZK8M0MYTNRJG5N0HD520",
+% "products":[{
+% "description":"Essay: The GNU Project",
+% "price":{"currency":"EUR","fraction":1,"value":0},
+% "product_id":42,"quantity":1}],
+% "refund_deadline":"/Date(1471522470)/",
+% "timestamp":"/Date(1471479270)/",
+% "transaction_id":249960194066269
+%}
+%\end{lstlisting}
+% \caption{Minimal Taler contract over a digital article with a value of \EUR{0.10}. The merchant will pay transaction fees up to \EUR{0.01}. The hash over the wire transfer information was truncated to make it fit to the page.}
+% \label{listing:json-contract}
+%\end{figure*}
+
+\subsubsection{Offer}
+
+The offer URL of the Web shop can then initiate payments by sending a
+\emph{contract proposal} to the
+wallet, either via the HTTP status code {\tt 402 Payment Required}
+(Figure~\ref{listing:http-contract}). 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 prices. In case that transaction fees
+need to be covered by the customer, these are shown together with the
+rest of the proposed contract.
+
+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. 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, as such a page
+would still not have access to the private keys of the coins that are
+exclusive to the background context.
+
+If the customer approves the contract by clicking the ``Confirm
+Payment'' button on the payment page, 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
+the {\em fulfillment} URL provided by the merchant in the contract.
+
+\subsubsection{Fulfillment}
+
+%\begin{figure*}[t!]
+% \lstset{language=HTML5}
+%\begin{lstlisting}
+% taler.executePayment("2BAH2AT4GSG5JRM2W4YWTSYGY66EK4X8CX2V69D5VF7XV703AJMG",
+% "https://shop/pay", "https://shop/article/42",
+% (err) => { alert("Sending payment failed"); });
+%\end{lstlisting}
+%\caption{Sample JavaScript code to trigger transmission of a payment to the merchant.}
+% \label{listing:javascript-execute}
+%\end{figure*}
+
+
+\begin{figure*}[t!]
+ \lstset{language={}}
+\begin{lstlisting}
+HTTP/1.1 402 Payment Required
+Content-Type: text/html; charset=UTF-8
+X-Taler-Contract-Hash: 2BAH2AT4GSG5JRM2W4YWTSYGY66EK4X8C...
+X-Taler-Pay-Url: https://shop/pay
+X-Taler-Offer-Url: https://shop/article/42
+
+<!DOCTYPE html>
+<html>
+<!-- fallback for browsers without the Taler extension -->
+You do not have Taler installed. Other payment options are ...
+</html>
+\end{lstlisting}
+\caption{Sample HTTP response when the user agent navigates to a fulfillment
+ URL without the session state that indicates they have paid for the resource.
+ Note that unlike in Listing~\ref{listing:http-contract}, the response
+ references a contract that typically is already known to the wallet via its
+ hash code.}
+ \label{listing:http-execute}
+\end{figure*}
+
+The fulfillment URL uniquely identifies a purchase by some customer,
+while the offer URL identifies a generic offer that is not specific to
+a customer. The purchase identified by a fulfillment URL may have
+been completed or still be in progress. The information contained in
+the fulfillment URL must allow the merchant to restore the full
+contract (including a unique transaction identifier) that was
+associated with the purchase, either directly from the URL or
+indirectly from an identifier in a database. Efficiently
+reconstructing the contract entirely from the URL instead of using
+costly database transactions can be important, as costly disk
+operations for incomplete purchases make merchants more susceptible to
+denial-of-service attacks from adversaries pretending to be customers.
+
+When a customer has 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.
+
+When a customer has not yet completed a purchase (this is always the
+case when a customer visits the fulfillment URL for the first time),
+or when the Web shop cannot confirm that this visitor has paid for the
+contract, for example because the session state was
+lost,\footnote{This can happen when when privacy conscious users
+ delete their cookies. Also, some user agents (such as the TOR
+ browser) do not support persistent (non-session) cookies.} the Web
+store responds by (again) triggering a payment process (either via
+JavaScript or using {\tt 402 Payment Required}, see
+Figure~\ref{listing:http-execute}). However, unlike the response from
+the offer URL, the 402 response from the fulfillment page includes the
+headers {\tt X-Taler-Contract-Hash}, {\tt X-Taler-Pay-Url} and {\tt
+ X-Taler-Offer-Url}.
+
+If the contract hash matches a payment which the user already
+previously approved, the wallet reacts to this by injecting the logic
+to transmit the payment to the {\em pay} URL of the Web shop into
+the page. Then the wallet inspects the response as it may contain
+error reports about a failed payment which the wallet has to handle.
+By submitting the payment this way, we also ensure that this
+intermediate request does not require JavaScript and still does not
+interfer with navigation. Once the Web shop confirms the payment, the
+wallet causes the fulfillment URL to be reloaded.
+
+If the contract hash does not match a payment which the user
+already approved, for example because the user obtained the link
+from another user, the wallet navigates to the offer URL included
+in the header.
+
+\subsubsection{Discussion}
+
+Various failure modes are considered in this design:
+
+\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 kept by the wallet, 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}
+
+\noindent
+While our design requires a few extra roundtrips,
+it has the following key advantages:
+\begin{itemize}
+ \item It works in the confines of the WebExtensions API.
+ \item It supports restoring session state for bookmarked
+ Web resources even after the session state is lost by the user agent.
+ \item Sending deep links to fullfilment or offer pages to
+ other users has the expected behavior
+ of asking the other user to pay for the resource.
+ \item Asynchronously transmitting 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 making an offer, 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
+ data minimizes the need for exceptions to handle cross-origin
+ resource sharing~\cite{cors}.
+ \item The architecture supports security-conscious users that may have
+ disabled JavaScript, as it is not necessary to execute JavaScript
+ originating from Web pages to execute the payment process.
+\end{itemize}
+
+% \smallskip
+
+\subsection{Giving change and refunds}
+
+%\begin{figure*}[b!]
+% \lstset{language={HTML5}}
+%\begin{lstlisting}
+%<script src="taler-wallet-lib.js"></script>
+%<script>
+% // Obtain refund permissions from the merchant backend
+% // ...
+% let refundPermissions = /* ... */;
+% taler.acceptRefunds(refundPermissions, (err) => {
+% alert("An error occured while attempting a refund");
+% });
+%</script>
+%\end{lstlisting}
+% \caption{Sample JavaScript code to trigger a refund from the merchant's web shop}
+% \label{listing:refund}
+%\end{figure*}
+
+An important cryptographic 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, our graphical user
+interface does not offer a way to inspect the denominations of the
+various coins in the wallet, it only shows the total amount available
+in each denomination. Expanding the views to show details may show
+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. To refund a purchase, the merchant obtains a signed refund permission
+from the exchange, which the customer's wallet processes
+to obtain new, unlinkable coins as refund.
+This process allows the customer to say anonymous when receiving refunds.
+
+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.
+
+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. We simplify 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=1.7cm,row sep=1.7cm},
+ 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 customary Web shop 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:http-contract}).
+
+Instead of adding any cryptographic logic to the merchant frontend,
+the Taler merchant backend allows the implementor to delegate
+coin handling to the payment backend, which validates the coins,
+deposits them at the exchange, and finally validates and persists the
+receipt from the exchange. The merchant backend then communicates the
+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 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, as
+well as a list of acceptable auditors and limits for transaction fees.
+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. We note that managing the risk does not imply that customers
+will never suffer from such a loss. We expect that customers will
+limit the balance they carry in their digital wallet. Ideally, the
+loss should be acceptable given that the customer gains the insight
+that their computer was compromised.
+
+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. Customers
+can choose to discard the receipts, for example to avoid leaking their
+shopping history in case their computer is compromised.
+
+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 exchange {\it coins} for bank money, and it is made by a
+ merchant after successfully receiving coins from a wallet during the
+ payment process.} 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 which a customer using 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}
+
+In the future, we plan to make it easy for users to backup and
+synchronize wallets to reduce the probability of the later two failure
+modes. A key issue in this context is that these processes will need
+to be designed carefully to avoid leaking information that might allow
+adversaries to link purchases via side channels opened up by the
+synchronization protocol.
+
+\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
+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
+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.
+
+A 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 withdraws funds once to
+then perform many micropayments, while Taler is likely less usable
+if for each transaction the customer first visits the bank to withdraw
+funds. This is {\em deliberate}, as Taler can only achieve reasonable
+privacy for customers if they keep a balance in their wallet, as
+this is necessary to break 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 resembles that of
+Taler in one interesting point, namely that the wallet is given
+details about the contract the user enters.
+However, in contrast to Taler, Bitcoin wallets are expected
+to fetch the ``invoice'' from the merchant. In Taler, the browser
+can provide the proposed contract directly to the wallet. 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, with cash merchants have the cost of maintaining change
+and depositing the money earned. The most extreme case for lack of
+assurances upon ``completion'' is Bitcoin, where there is no time
+until a payment can be said to be definitively confirmed,
+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 introduce semi-centralized
+intermediaries, not wholey unlike Taler's use of exchanges. Compared
+to BOLT, we would 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.
+
+
+\section{Conclusions}
+
+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.
+By providing a free software wallet, Taler gives the user full control
+over the usage of their
+transaction history, as opposed to giving control to big data corporations.
+
+\begin{center}
+ \bf
+We encourage readers to try our prototype for Taler
+at \url{https://demo.taler.net/}.
+\end{center}
+%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 Bruno Haible for his financial support enabling us to
+participate with the W3c payment working group. We thank the W3C
+payment working group for insightful discussions about Web payments.
+We thank Krista Grothoff and Neal Walfield for comments on an earlier
+draft of the paper. We thank Gabor Toth for his help with the
+implementation.
+
+\bibliographystyle{splncs03}
+\bibliography{ui,btc,taler,rfc}
+
+
+
+\end{document}
+
+
+\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 try to 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 sender's exchange would have to
+support wire transfers to the receiver's exchange. 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, effectively
+merging the technical concepts of a (traditional) bank accounts and
+Taler reserves into one service for the customer.
+
+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.
+
+
+
+
+
+
+\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 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 risk
+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~\cite{ECB:TRoCF2014}. 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{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.