From b56fedc0aefefb86fa8fe82135e219f4e2fddb6c Mon Sep 17 00:00:00 2001
From: Florian Dold <florian.dold@gmail.com>
Date: Mon, 3 Aug 2020 13:32:20 +0530
Subject: cleanup

---
 contrib/articles/ui/ui-cameraready.tex | 1640 ++++++++++++++++++++++++++++++++
 1 file changed, 1640 insertions(+)
 create mode 100644 contrib/articles/ui/ui-cameraready.tex

(limited to 'contrib/articles/ui/ui-cameraready.tex')

diff --git a/contrib/articles/ui/ui-cameraready.tex b/contrib/articles/ui/ui-cameraready.tex
new file mode 100644
index 000000000..59a834212
--- /dev/null
+++ b/contrib/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.
-- 
cgit v1.2.3