moving here wallet papers forlder

1 files changed, 1352 insertions, 0 deletions

diff --git a/articles/ui/ui.tex b/articles/ui/ui.tex
new file mode 100644
index 000000000..9e7cb0078
--- /dev/null
+++ b/articles/ui/ui.tex
@@ -0,0 +1,1352 @@
+
+\title{Taler: \\ Usable, privacy-preserving payments for the Web}
+% \author{
+% Jeffrey Burdges \\ \and
+% Florian Dold \\ \and
+% Christian Grothoff \\ \and
+% Marcello Stanisci
+% }
+\date{\today}
+
+\documentclass[twoside,letterpaper]{soups}
+\usepackage[margin=1in]{geometry}
+\usepackage[utf8]{inputenc}
+\usepackage{url}
+\usepackage{tikz}
+\usepackage{eurosym}
+\usepackage{listings}
+\usepackage{graphicx}
+\usepackage{wrapfig}
+%\usepackage{caption}
+\usepackage{subcaption}
+\usepackage{url}
+
+\usetikzlibrary{shapes,arrows}
+\usetikzlibrary{positioning}
+\usetikzlibrary{calc}
+
+\begin{document}
+\maketitle
+
+\begin{abstract}
+Taler is a new electronic online payment system which provides
+anonymity for customers and, due to this design choice, also offers
+significantly better usability.  This paper describes the interaction
+processes of online payment systems, and analytically compares their
+usability for both customers and merchants.  We then focus on the
+resulting assurances that Taler provides, as---particularly for payment
+systems---usability and security are intertwined.  Web payment systems
+must also face the reality of constraints imposed by modern Web
+browser security architecture, so the analysis includes considerations of
+how Web payment systems exploit the security infrastructure provided
+by the modern Web.
+\end{abstract}
+
+\section{Introduction}
+
+The future Internet needs a secure, usable and privacy-preserving
+micropayment system that 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}
+
+As transactions on the Internet, such as sending an e-mail or reading
+a Web site, tend to be of smaller value than traditional transactions
+involving the exchange of physical goods, we are faced with the
+challenge of reducing the mental and technical overheads of existing
+payment systems to handle micropayments.  Addressing this problem is
+urgent: ad-blocking technology is eroding advertising as a substitute
+for micropayments~\cite{adblockblocks}, and the Big Data business
+model where 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 on Taler, a new free software payment
+system designed to meet certain key ethical considerations. In Taler,
+the customer remains anonymous, while the merchant is taxable.  Here,
+{\em anonymous} simply means that the payment system does not require
+any personal information from the customer, and that different
+transactions by the same customer are unlinkable.  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 the state can obtain the necessary information about the
+contract to levy income, sales or value-added taxes.  Taler uses blind
+signatures~\cite{chaum1983blind} to create digital coins, and a new
+``refresh'' protocol to allow giving change and refunds while
+maintaining unlinkability.
+
+This paper will not consider the details of Taler's cryptographic
+protocols\footnote{No citation given due to anonymous submission.}, as
+for usability one needs to completely hide the cryptography from the
+users.  Thus, this paper will focus on an analytical description of
+how to achieve usable and secure electronic payments.  Our focus is to
+show that existing {\em mental models} users have from existing
+widespread payment systems will apply naturally.  We leave a
+usability study with actual users for future work, as we believe that
+the basic architecture of such a system is sufficiently interesting by
+itself.
+
+Key contributions of this paper are:
+\begin{itemize}
+ \item A description of different payment systems using
+  common terminology, allowing us to analytically compare
+  these systems with respect to security and usability.
+ \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 ``secure'' browsers.
+ \item A publicly available free software
+  reference implementation of the proposed architecture.
+\end{itemize}
+
+
+\section{Existing payment workflows}
+
+Before we look at the payment workflow for Taler, we will sketch
+the workflow of existing payment systems. This will establish
+a common terminology, a baseline for comparison and crucially
+also an indication as to how we can relate Taler's workflow to
+existing {\em mental models} that users already have, thereby
+allowing us to judge the mental adaptation costs required to
+transition to transactions with Taler.
+
+\subsection{Cash}
+
+Cash has traditionally circulated by being passed directly from buyers
+to sellers, with each seller then becoming a buyer. Thus, cash is
+inherently a {\em peer-to-peer} payment system, as participants all
+appear in the both buyer and seller roles, merely 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 finally
+{\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 by serial numbers
+printed on bills.~\cite{pets2004kuegler}
+% 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 may provide 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 limit their risks to the
+amount of cash 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 steal their customer's
+credentials.  Authentication with an ATM can involve a special ATM
+card, or more commonly the use of credit or debit cards.  In all these
+cases, these physical security tokens are issued by the customer's
+bank of the customer.
+
+
+% \smallskip
+\subsection{Credit and debit cards}
+
+\begin{figure*}[h!]
+\begin{center}
+\includegraphics[width=0.95\textwidth]{figs/cc3ds.pdf}
+\end{center}
+\caption{Card payment processing with 3DS. (From: W3c Web Payments IG.)}
+\label{fig:cc3ds}
+\end{figure*}
+
+Credit and debit card payments operate by the customer providing their
+credentials to the merchant.  Many different
+authentication and authorization schemes are in use in various
+combinations, including both secret information, usually PINs, and
+physical security devices like TANs~\cite{kobil2016tan}
+(cards with an EMV chip~\cite{emv}), and
+ the customer's mobile phone~\cite{mtan}.
+A typical modern Web payment process involves
+{\bf (0)} 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}, the security
+provided by TLS is at best questionable.}
+{\bf (1)} selecting a {\em payment method},
+{\bf (2)} entering the credit card details like owner's name,
+ card number, expiration time, CVV code, and billing address,
+{\bf (3)} (optionally) authorizing the transaction via mobile TAN, or
+ by authenticating against the customer's bank,
+often on a Web site that is operated by the payment
+processor and {\em not} the customer's bank.  Figure~\ref{fig:cc3ds}
+shows a typical card-based payment process on the Web today using the
+UML style of the W3c payment interest group~\cite{pigs}.  Most of the
+details are not relevant to this paper, but the figure nicely
+illustrates the complexity of the common 3-D secure (3DS) process.
+
+Given this process, there is an inherent risk of information leakage
+of customers' credentials.  Fraud detection systems attempt to detect
+misuse of leaked credentials, and payment system providers handle
+disputes between customers and merchants.  As a result, Web payment
+processes may finish with {\bf (4)} the payment being rejected for a
+variety of reasons, from false-positives in fraud detection to 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 hence to shift dispute liability to the issuer of the card, who
+may then shift it to the customer.
+%
+% online vs offline vs swipe vs chip vs NFC ???
+% extended verification
+%
+Even in cases where the issuer or the merchant remain legally first in
+line, there are still risks customers incur from the card dispute
+procedures, such as neither they not the payment processor noticing
+fraudulent transactions, or them noticing fraudulent transactions past
+the date at which their bank will refund 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 verifiable electronic
+receipts for the customers, enabling malicious merchants to later
+change the terms of the contract.  Beyond these issues, customers face
+secondary risks of identity theft from the personal details exposed by
+the authentication procedures. In this case, even if the financial
+damages are ultimately covered by the bank, the customer always has to
+deal with the hassle of notifying the bank in the first place.  As a
+result, customers must remain wary about their card use, 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}[h!]
+\includegraphics[width=0.45\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(s) must know the corresponding private key, which in
+turn is used 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 speculation.  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; the latter process is called {\em mining}.
+%
+The mining process is incentivised by transaction fees and mining
+rewards, the latter also providing the process of initial accumulation
+for BTC.~\cite{nakamoto2008bitcoin} Conversion to and from BTC from
+and to other currencies 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.  The
+classical Bitcoin payment workflow consisted of entering payment
+details into a peer-to-peer application.  The user would access his
+Bitcoin {\em wallet} and instruct it to transfer a particular amount
+from one of his accounts to the account of the merchant, possibly
+including additional metadata to be associated with the transfer and
+embedded into the global public ledger.  The wallet application would
+then transmit the request to the Bitcoin peer-to-peer overlay network.
+The use of an external payment application makes wallet-based payments
+significantly less browser-friendly than ordinary card payments, as
+illustrated in Figure~\ref{fig:bitcoin}.
+
+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~\cite{nakamoto2008bitcoin}.  As a result, customers and
+merchants must either accommodate this delay, or incur fraud risks
+during this indeterminate period.
+
+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.
+In fact, ``a single Bitcoin transaction uses roughly enough
+electricity to power 1.57 American households for a day''.~\cite{vice_btc_unsustainable}
+These costs are largely hidden by speculation in BTC,
+but that speculation itself contributes to BTC being
+unstable.~\cite{lehmann_btc_fools_gold,jeffries_economists_v_btc,lewis_btc_is_junk}. % exacerbating risk
+
+% fees hit you 2-3 times with currency conversions
+% more on massive transaction fees from blockchain.info
+
+There are several examples of Bitcoin's pseudononymity being broken
+by investigators~\cite{BTC:Anonymity}.  Mixnets afford protection
+against this, but they require numerous transactions, exacerbating
+Bitcoin's already high transaction costs.
+%
+Bitcoin's pseudononymity applies equally to both customers and
+merchants, making Bitcoin highly amen\-able to tax evasion, money
+laundering, and sales of contraband.  As a result, anonymity tools
+like mixnets do not enjoy particularly widespread support in the
+Bitcoin community where many participants seek to make the currency
+appear more legitimate.
+% In addition, the Bitcoin protocol does not interact well with
+% conventional anonymity networks like Tor \cite{BTC:vsTor}
+
+% dark pools?
+
+% mining suck0rs,
+
+% DDoS : wired article?
+
+% economic ideology
+
+\subsection{Walled garden payment systems}
+
+\begin{figure}[b!]
+\includegraphics[width=0.45\textwidth]{figs/paypal.pdf}
+\caption{Payment processing with Paypal. (From: W3c Web Payments IG.)}
+\label{fig:paypal}
+\end{figure}
+
+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
+(Figure~\ref{fig:paypal}).  In these payment systems, the provider
+basically acts like a bank with accounts carrying balances for the
+various users.  In contrast to traditional banking systems, both
+customer and merchant 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 oligopoly.  In this
+paper, we will use PayPal as a representative example for our discussion
+of these payment systems.
+
+As with card payments, these oligopolies are politically
+dangerous~\cite{crinkey2011rundle} and the lack of competition can
+result in excessive profit taking that may require political
+solutions~\cite{guardian2015cap} to the resulting market failure.  The
+use of non-standard proprietary interfaces to the payment processing
+service of these providers serves to reinforce the customer lock-in.
+
+
+\section{Taler}
+
+Taler is a free software cryptographic payment system with an open
+protocol specification that couples cash-like anonymity for customers
+when they spend money with low transaction costs, signed digital
+receipts, and accurate income information to facilitate taxation and
+anti-corruption efforts.
+
+Taler achieves anonymity for buyers using {\em blind
+signatures}~\cite{chaum1983blind}.  Ever since their discovery thirty
+years ago, cryptographers have viewed blind signatures as the optimal
+cryptographic primitive for consumer level transaction systems.  Our
+goal is for Taler to become the first transaction system based on blind
+signatures to see widespread adoption.  Hiding the cryptography from
+users and integrating smoothly with the Web are central components of our
+technical strategy to achieve this. % ethical, privacy, etc.
+
+%\subsection{Design overview}
+
+\begin{figure}[b!]
+\centering
+\begin{tikzpicture}
+ \tikzstyle{def} = [node distance=3em and 5em, inner sep=1em, outer sep=.3em];
+ \node (origin) at (0,0) {};
+ \node (exchange) [def,above=of origin,draw]{Exchange};
+ \node (customer) [def, draw, below left=of origin] {Customer};
+ \node (merchant) [def, draw, below right=of origin] {Merchant};
+ \node (auditor) [def, draw, above right=of origin]{Auditor};
+
+ \tikzstyle{C} = [color=black, line width=1pt]
+
+ \draw [<-, C] (customer) -- (exchange) node [midway, above, sloped] (TextNode) {withdraw coins};
+ \draw [<-, C] (exchange) -- (merchant) node [midway, above, sloped] (TextNode) {deposit coins};
+ \draw [<-, C] (merchant) -- (customer) node [midway, above, sloped] (TextNode) {spend coins};
+ \draw [<-, C] (exchange) -- (auditor) node [midway, above, sloped] (TextNode) {verify};
+
+\end{tikzpicture}
+\caption{Taler system overview.}
+\label{fig:system}
+\end{figure}
+
+
+There are four components of the Taler system (Figure~\ref{fig:system}):
+
+\begin{itemize}
+\item
+{\em Wallets} are software packages that allow customers to withdraw,
+hold, and spend coins.  Wallets also manage the customer's accounts
+at the exchange, and keep receipts in a transaction history.  Wallets can be
+realized as browser extensions, mobile Apps or even in custom
+hardware.
+
+\item
+{\em Exchanges} enable customers to withdraw anonymous digital coins
+and merchants to deposit digital coins, in exchange for
+bank money.  Exchanges learn the amounts withdrawn by customers
+and deposited by merchants, but they do not learn the relationship
+between customers and merchants.  Exchanges perform online detection
+of double spending, thus providing merchants instant feedback,
+---including digital proofs---in case of misbehaving customers.
+
+\item
+{\em Merchants} provide goods or services in exchange for coins held
+by customers' wallets.  Merchants deposit these coins at the
+exchange for their regular currency value.  Merchants consist of a
+{\em frontend} which interacts with the customer's wallet, and a {\em
+backend} that 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.
+\end{itemize}
+
+The specific protocol between wallet and merchant depends on the
+setting.  For a traditional store, an 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.
+
+\begin{figure}[b!]
+\includegraphics[width=0.45\textwidth]{figs/taler-withdraw.pdf}
+\caption{Withdrawing coins with Taler.}
+\label{fig:taler-withdraw}
+\end{figure}
+
+
+% \smallskip
+\subsection{Web payment workflow}
+
+We explain how the actors in the Taler system interact by documenting
+a typical payment.
+
+Initially, the customer must once install the Taler wallet extension
+for his browser.  Naturally, this step may become superfluous if
+Taler is integrated tightly with browsers in the future.  Regardless,
+installing the extension involves one or two clicks to confirm the
+operation once the user was pointed to the correct Web site.
+Restarting the browser is not required.
+
+\paragraph{Withdrawing coins}
+
+
+\begin{figure}[p!]
+\begin{subfigure}[H]{0.5\textwidth}
+\includegraphics[width=\textwidth]{figs/bank0a.png}
+\caption{Bank login. (Simplified for demonstration.)}
+\label{subfig:login}
+\end{subfigure}
+\begin{subfigure}{0.5\textwidth}
+\includegraphics[width=\textwidth]{figs/bank1a.png}
+\caption{Specify amount to withdraw. (Integrated bank support.)}
+\label{subfig:withdraw}
+\end{subfigure}
+\begin{subfigure}{0.5\textwidth}
+\includegraphics[width=\textwidth]{figs/bank2a.png}
+\caption{Select exchange provider. (Generated by wallet.)}
+\label{subfig:exchange}
+\end{subfigure}
+\begin{subfigure}{0.5\textwidth}
+\includegraphics[width=\textwidth]{figs/bank3a.png}
+\caption{Confirm transaction with a PIN. (Generated by bank.)}
+\label{subfig:pin}
+\end{subfigure}
+\caption{Required steps in a Taler withdrawal process.}
+\label{fig:withdrawal}
+\end{figure}
+
+As with cash, the customer must first withdraw digital coins
+(Figure~\ref{fig:taler-withdraw}).  For this, the customer must first
+visit the online banking portal of his bank.  Here, the bank will
+typically require some form of authentication, the specific method
+used depends on the bank (Figure~\ref{subfig:login}).
+
+\clearpage
+\newpage
+The next step depends on the Taler support offered by the bank:
+\begin{itemize}
+\item If the bank does not properly integrate with Taler, the
+  customer needs use the menu of the wallet to create a {\em reserve}.
+  The wallet will ask which amount in which {\em currency} (i.e. 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, this is
+  exactly the kind of interaction we would like to avoid for
+  usability.
+\item Hence, if the bank properly integrates with Taler, the
+  customer has a form in the online banking portal where he can specify
+  an amount to withdraw (Figure~\ref{subfig:withdraw}).
+  The bank then triggers an interaction with
+  the wallet to allow the customer to select an exchange
+  (Figure~\ref{subfig:exchange}).  Afterwards,
+  the wallet instructs the bank about the details of the wire
+  transfer.  The bank asks the customer to authorize the transfer, and
+  finally confirms to the wallet that the transfer has been
+  successfully initiated.
+\end{itemize}
+
+In either case, the wallet can then withdraw the coins from the
+exchange, and does so in the background without further interaction
+with the customer.
+
+In principle, the exchange can be directly operated by the bank, in
+which case the step where the customer selects an exchange may 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.
+
+\paragraph{Spending coins}
+% \tinyskip
+
+\begin{figure}[b!]
+\includegraphics[width=0.45\textwidth]{figs/taler-pay.pdf}
+\caption{Payment processing with Taler.}
+\label{fig:taler-pay}
+\end{figure}
+
+\begin{figure}[p!]
+\begin{subfigure}[H]{0.5\textwidth}
+\includegraphics[width=\textwidth]{figs/cart.png}
+\caption{Select article. (Generated by Web shop.)}
+\label{subfig:cart}
+\end{subfigure}
+\begin{subfigure}{0.5\textwidth}
+\includegraphics[width=\textwidth]{figs/pay.png}
+\caption{Confirm payment. (Generated by Taler wallet.)}
+\label{subfig:payment}
+\end{subfigure}
+\begin{subfigure}{0.5\textwidth}
+\includegraphics[width=\textwidth]{figs/fulfillment.png}
+\caption{Receive article. (Generated by Web shop.)}
+\label{subfig:fulfillment}
+\end{subfigure}
+\caption{Required steps in a Taler checkout process.}
+\label{fig:shopping}
+\end{figure}
+
+% \tinyskip
+\lstdefinelanguage{JavaScript}{
+  keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break, for},
+  keywordstyle=\color{blue}\bfseries,
+  ndkeywords={class, export, boolean, throw, implements, import, this},
+  ndkeywordstyle=\color{darkgray}\bfseries,
+  identifierstyle=\color{black},
+  sensitive=false,
+  comment=[l]{//},
+  morecomment=[s]{/*}{*/},
+  commentstyle=\color{purple}\ttfamily,
+  stringstyle=\color{red}\ttfamily,
+  morestring=[b]',
+  morestring=[b]"
+}
+
+\begin{figure*}[h!]
+ \lstset{language=JavaScript}
+ \lstinputlisting{figs/taler-presence.js}
+ \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*}
+
+
+
+At a later point in time, the customer can spend his 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 should not matter for the customer, as we expect
+most merchants to allow most accredited exchange providers, and for
+exchanges to operate with transaction fees acceptable to most
+merchants.  If transaction fees are higher than what is covered by the
+merchant, the customer may choose to cover them.
+
+\begin{figure*}[h!]
+ \lstset{language=JavaScript}
+ \lstinputlisting{figs/taler-contract.js}
+ \caption{Sample code to pass a contract to the Taler wallet.
+          Here, the contract is fetched on-demand from the server.
+          The {\tt taler\_pay()} function needs to be invoked
+          when the user triggers the checkout.}
+ \label{listing:contract}
+\end{figure*}
+
+As with traditional Web transactions, the customer first selects which
+items he wishes to buy.  This can involve building a traditional
+shopping cart, or simply clicking on a particular link for the
+respective article (Figure~\ref{subfig:cart}).  As with card payments,
+the Web shop may then allow the customer to select a payment method,
+including Taler.  Taler also allows the Web shop to detect
+the presence of a Taler wallet (Figure~\ref{listing:presence}), so
+that this step may be skipped (as it is in Figure~\ref{fig:shopping}).
+If Taler was detected or selected, the Web shop sends a digitally
+signed {\em contract proposal} to the wallet extension
+(Figure~\ref{listing: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.  In the case that transaction fees need to be
+covered by the customer, these are shown together with the rest of the
+proposed contract.
+
+If the customer approves the contract by clicking the ``Confirm
+Payment'' button (Figure~\ref{subfig:payment}), his wallet signs the
+contract with enough coins to cover the contract's cost, stores all of
+the information in its local database, and redirects the browser to a
+{\em fulfillment} URL provided by the merchant
+(Figure~\ref{subfig:fulfillment}).  The wallet cannot directly send
+the payment to the merchant, as the page showing the contract is
+provided as a background page controlled by the Web Extension\footnote{\url{https://developer.chrome.com/extensions}} and thus
+submitting coins from the background would not use the HTTP-context
+that the Web shop's page requires for session management.
+
+Instead, the server-side of the fulfillment page usually first detects
+that the contract has not yet been paid by checking the merchant's
+local database and the HTTP session state.  {\bf (A)} If the state
+indicates that this customer did not yet pay, the merchant generates a
+page that shows the customer an indication that the payment is being
+processed, and tries to interact with the wallet, requesting payment.
+If the wallet is not detected after a few milliseconds, the page
+transitions to the card payment process.  If the wallet is present,
+the page requests payment from the wallet.  The wallet then determines
+that the customer already confirmed the payment and immediately
+transfers the coins to the JavaScript logic of the fulfillment page.
+The fulfillment page then transfers the coins to the merchant, usually
+using an asynchronous HTTP POST request.  The request is controlled by
+the merchant's JavaScript and not by the wallet. This ensures that the
+merchant is in full control of the communication between the
+merchant's server and the client-side scripts interacting with the
+merchant's server.  The interactions with the wallet are thus purely
+local interactions within the browser.  Upon receipt of the payment
+information, the merchant confirms the payment with the exchange,
+marks the payment as received, and notifies the JavaScript on the
+client side of the result.
+
+\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 customer and merchant, the wallet
+ will try to recover control over the coins at the exchange by
+ effectively spending the coins first using Taler's special
+ ``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 later via the transaction history, or demand a refund (see
+ below).  Handling these errors does not require the customer to give
+ up his privacy.
+\item If the payment fails due to the exchange
+ claiming that the request was invalid, the diagnostics created by the
+ exchange are passed to the wallet for inspection.  The wallet then
+ decides whether the exchange was correct, and can then inform the
+ user about a fraudulent or buggy exchange.  At this time, it allows
+ the user to export the relevant cryptographic data to be used in
+ court.  If the exchange's proofs were correct and coins were
+ double-spent, the wallet informs the user that its database must have
+ % FIXME what about giving an example of an out-of-date DB?  Put in
+ % this way, it appears that Taler has viable ways to fail. In other
+ % words, that it's normal to get such a failure. Instead, that failure
+ % can occur due to coins not spent for *years* (or some other corner case),
+ % that saves Taler from being "blamed"
+ been out-of-date, updates the database and allows the user to retry
+ the transaction.
+\item If the payment succeeded, the JavaScript on the
+ client side triggers effectively a ``reload'' of the fulfillment
+ page, triggering case (B) detailed below.
+\end{itemize}
+
+{\bf (B)} Upon subsequent visits, the server detects that the payment
+has already been processed and directly generates a fulfillment page
+either confirming the payment, or---in the case of payments for a
+digital article---transmits the digital artifact to the client.
+
+\paragraph{Bookmarks and deep links}
+
+This particular architecture also enables smooth use of the payment
+URIs on the contemporary Web.  In particular, we need to consider the
+possibility that a user may bookmark the fulfillment page, or forward
+a link to the fulfillment page to another user.
+
+The given design supports {\em bookmarking}. If the merchant's
+session management is still tracking the user when he returns via the
+bookmark, the page generation detects that the user has already paid
+and serves the final fulfillment page.  If the session has been lost,
+the merchant will generate a fulfillment page asking for payment.  In
+this case, the wallet will detect that it has already paid this
+contract via a unique identifier in the contract, and will
+automatically re-play the payment.  The merchant confirms that this
+customer already paid, and generates the final fullfilment page that the
+user has previously payed for (and seen).  All this still appears as
+instantaneous to the user as it merely adds a few extra network round trips.
+
+In contrast, if the customer sends a link to the fulfillment page to
+another user, thereby possibly sharing a {\em deep link} into the
+merchant's shop, the other customer's wallet will fail to find an
+existing payment.  Consequently, the fulfillment page will not receive
+the payment details and instead provide the user with the proposed
+contract which contains a description of the item previously bought by
+the other user. The recipient of the link can then decide to also
+purchase the item.
+
+The design, in particular POSTing the coins asyn\-chro\-nous\-ly from
+JavaScript, also ensures that the user can freely navigate with
+the back and forward buttons.  As all requests from all HTTP(S)
+URIs ever seen by the user in the browser are fetched via HTTP
+GET, they can be bookmarked, shared and safely reloaded.  For
+caching, the merchant needs to ensure that the fulfillment
+page generated in case (A) is not cached by the browser,
+and in case (B) is not cached in the network.
+
+As an aside, there are actually several distinct roles comprising the
+merchant: shopping pages end their role by proposing a contract, while
+a fulfillment page begins its life processing a contract.  It is thus
+possible for these components being managed by separate parties. The
+control of the fulfillment page over the transmission of the payment
+information minimizes the need for exceptions to handle cross-origin
+resource sharing.~\cite{rfc6454,cors}
+
+% FIXME: for the above: add figures with code samples!
+% \smallskip
+
+\paragraph{Giving change and refunds} % FIXME: maybe leave out change entirely?
+
+An important technical difference between Taler and previous
+transaction systems based on blind signing is that Taler is able to
+provide unlinkable change and refunds.  From the user's point of view,
+obtaining change is automatic and handled by the wallet, i.e. if the
+user has a single coin worth \EUR{5} and wants to spend \EUR{2}, the
+wallet may request three \EUR{1} coins in change --- critically, this
+is completely hidden from the user. In fact, the graphical user
+interface does not offer a way to inspect the denominations of the
+various coins in the wallet, it only shows the total amount available
+in each denomination.  Expanding the views to show details may show
+the exchange providers and fee structure, but not the cryptographic
+coins.  Consequently, the major cryptographic advances of Taler are
+invisible to the user.
+
+Taler's technology also allows merchants to give refunds to
+customers. For this, the merchant merely has to send a signed
+message to the exchange confirming the refund, and notify the
+customer's wallet that the respective transaction was refunded.
+This can even be done with anonymous customers, as refunds are
+given as additional change to the owner of the coins that were
+originally spent to pay for the refunded transaction.
+
+Taler's protocol ensures unlinkability for both changes and refunds,
+thus 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{NFC payments}
+
+We have so far focused on how Taler would be used for Web payments;
+however, Taler can also be naturally 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.  An NFC
+application would be less restricted in its interaction with the
+point-of-sale system compared to a browser extension; thus, running
+Taler over NFC is largely a simplification.
+
+Specifically, there are no significant new concerns arising from an
+NFC device possibly losing contact with a point-of-sale system.
+Already for Web payments, Taler employs only 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 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 the
+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 pretty trivial, 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, as after copying a private
+key both parties could spend the coins, but only the first transaction
+will succeed.  Given this crucial limitation
+inherent in sharing keys, we consider it ethically acceptable that
+sharing is not taxable.
+
+Second, there is the {\em transactional} mutually exclusive transfer
+of ownership.  This requires the receiving party to have a {\em
+reserve} with an exchange, and the exchanges would have to support
+wire transfers among them.  If taxability is desired, the {\em
+reserve} would still need to be tied to a particular citizen's
+identity for tax purposes, and thus require similar identification
+protocols as commonly used for establishing a bank account. Thus, in
+terms of institutions, one would expect this setup to be offered most
+easily by traditional banks.  In terms of usability, transactional
+transfers are just as easy as sharing when performed over NFC, but
+more user friendly when performed over the Internet as they do not
+require a secure communication channel: the Taler protocol is by
+design still safe to use even if the communication is made over an
+unencrypted channel. Only the authenticity of the proposed contract
+needs to be assured.
+
+
+\subsection{Usability for merchants}
+
+Payment system security and usability is not primarily 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 (i.e. the card) and to guard a secret
+(i.e. 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}
+
+Thus, we cannot ignore the usability at the merchant site when trying
+to understand the usability of a payment system, especially as for
+deployment we will have to convince millions of merchants that the
+Taler system is advantageous.  The high-level cryptographic design
+already provides the first major advantage, as merchants do never
+receive sensitive payment-related customer information.  Thus, they do
+% FIXME as *it* is ?
+% CG: both are OK in English, ``it'' can be omitted here.
+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 shop 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 business agreement with the exchange.
+This dramatically simplifies setting up a shop, to the point that the
+respective software only needs to be provided with the merchant's wire
+transfer routing information to become operational.
+
+Figure~\ref{listing:presence} shows how easy it is for a Web shop to
+detect the presence of a Taler wallet.  This leaves a few cryptographic
+operations, such as signing a contract and verifying the customer's and
+the exchange's signatures, storing transaction data as well as matching
+sales with incoming wire transfers from the exchange.  Taler simplifies this
+for merchants by providing a generic payment processing {\em backend} for
+the Web shops.
+
+\begin{figure*}[h!]
+\begin{center}
+\begin{tikzpicture}[
+  font=\sffamily,
+  every matrix/.style={ampersand replacement=\&,column sep=2cm,row sep=2cm},
+  source/.style={draw,thick,rounded corners,fill=green!20,inner sep=.3cm},
+  process/.style={draw,thick,circle,fill=blue!20},
+  sink/.style={source,fill=green!20},
+  datastore/.style={draw,very thick,shape=datastore,inner sep=.3cm},
+  dots/.style={gray,scale=2},
+  to/.style={->,>=stealth',shorten >=1pt,semithick,font=\sffamily\footnotesize},
+  every node/.style={align=center}]
+
+  % Position the nodes using a matrix layout
+  \matrix{
+    \node[source] (wallet) {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 (Figure~\ref{fig:system})
+          to deposit coins are not shown.
+          Existing system security mechanisms
+          are used to isolate the cryptographic components (boxes) from
+          the complex rendering logic (circles), hence the communication
+          is restricted to JavaScript signals or HTTP(S) respectively.}
+ \label{fig:frobearch}
+\end{figure*}
+
+Figure~\ref{fig:frobearch} shows how the secure payment components
+interact with the existing Web shop logic.  First, the Web shop
+frontend is responsible for constructing the shopping cart.  For this,
+the shop frontend generates the usual Web pages which are shown to the
+user's browser client frontend.  Once the order has been constructed,
+the shop frontend gives 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 in Figure~\ref{listing:contract}).
+Here, the wallet operates from a secure {\em background} on the client side,
+which allows the user to securely accept the payment, and to perform
+the cryptographic operations in a context that is protected from the
+Web shop. In particular, it is secure against a merchant that
+generates a page that looks like the payment page from the wallet
+(Figure~\ref{subfig:payment}), as such a page would still not have
+access to the private keys of the coins that are in the wallet.  If
+the user accepts, the resulting signed coins are transferred from the
+client to the server, again by a protocol that the merchant can
+customize to fit the existing infrastructure.
+
+Instead of adding any cryptographic logic to the merchant frontend,
+the generic Taler merchant backend allows the implementor to delegate
+handling of the coins to the payment backend, which validates the
+coins, deposits them at the exchange, and finally validates and
+persists the receipt from the exchange.  The merchant backend then
+communicates the result of the transaction to the front\-end, which is
+then responsible for executing the business logic to fulfill the
+order.  As a result of this setup, the cryptographic details of the
+Taler protocol do not have to be re-implemented by each merchant.
+Instead, existing Web shops implemented in a multitude of programming
+languages can rather trivially add support for Taler by {\bf (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 let it know his wire
+transfer routing details, such as an IBAN number.  Ideally, the
+merchant might also want to obtain a certificate for the public key
+generated by the backend for improved authentication.  Otherwise, the
+customer's authentication of the Web shop simply continues to rely
+upon HTTPS/X.509.
+
+
+\section{Discussion}
+
+We will now discuss how customer's may experience relevant operational
+risks and failure modes of Taler, and relate them to failure modes
+in existing systems.
+
+% \smallskip
+\subsection{Security risks}
+
+In Taler, customers incur the risk of wallet loss or theft.  We
+believe customers can manage this risk effectively because they manage
+similar risks of losing cash in a physical wallet.  Unlike physical
+wallets, Taler's wallet could be backed up to secure against loss of a
+device.
+
+Taler's contracts do 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 may receive in
+physical stores, Taler's cryptographically signed contracts ought to
+carry more weight in courts than typical paper receipts.
+
+Point-of-sale systems providing printed receipts have been compromised
+in the past by merchants to embezzle sales
+taxes.~\cite{munichicecream} With Taler, the merchant still generates
+a receipt for the customer; however, the record for the tax
+authorities ultimately is anchored with the exchange's wire transfer
+to the merchant.  Using the subject of the wire transfer, the state
+can trace the payments and request the merchant to provide
+cryptographically matching contracts.  Thus, this type of tax
+fraud is no longer possible, which is why we call Taler {\em
+taxable}.  The mere threat of the state sometimes tracing transactions
+and contracts back to the merchant also makes Taler unsuitable for
+illegal activities.
+
+The exchange operator is obviously crucial for risk management in
+Taler, as the exchange operator holds the customer's funds in a
+reserve in escrow until the respective deposit request arrives\footnote{As
+previously said, this {\it deposit request} is aimed to translate {\it coins}
+into real money and it's accomplished by a merchant after successfully
+receiving coins by a wallet. In other words, it is the way merchants get
+real money on their bank accounts}. To ensure that the exchange operator
+does not embezzle these funds, Taler expects exchange operators to be
+regularly audited by an independent auditor\footnote{Auditors are typically
+run by states}.  The auditor can then verify that the incoming and outgoing
+transactions and the current balance of the exchange match the logs
+with the cryptographically secured transaction records.
+
+
+% \smallskip
+\subsection{Failure modes}
+
+There are several failure modes the user of a Taler wallet may
+encounter:
+
+\begin{itemize}
+\item
+As Taler supports multiple exchanges, there is a chance that a
+merchant might not support any exchange where the customer withdrew
+coins from.  We mitigate this problem by allowing merchants to
+support all exchanges audited by a particular auditor.  We believe
+this a reasonable approach, because auditors and merchants must
+operate with a particular legal and financial framework anyways.  We
+note that a similar failure mode exists with credit cards, where not
+all merchants accept all issuers, especially 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 that the coins were previously spent, so the
+wallet can verify that the exchange and merchant are behaving honestly.
+However, this gives rise to another subsequent failure mode,
+namely that ...
+
+% 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 invariants.  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 the user that the balance was inaccurate due to
+inconsistencies from recovery, and overall insufficient for payment.
+For the user, this failure mode appears equivalent to an insufficient
+balance or credit line when paying with cards.
+\end{itemize}
+
+\subsection{Comparison}
+
+The different payment systems discussed make use of different security
+technologies, which has an impact on their usability and the
+assurances they can provide.  Except for Bitcoin, all payment systems
+described involve an authentication step.
+% FIXME alternative for the following sentence:
+% With Taler, the authentication is implicit when withdrawing, since
+% the user has to login into his bank's Web portal in the first place,
+% and no further authentication is required during the whole payment
+% experience.
+% CG: Not exactly, as the authentication to the bank is still
+% a very explicit authentication step. It's just more natural.
+With Taler, the authentication itself is straightforward, as the customer is
+at the time visiting the Web portal of the bank, and the authentication is
+with the bank (Figure~\ref{fig:taler-withdraw}).  With PayPal, the
+shop redirects the customer to the PayPal portal (step 5 in
+Figure~\ref{fig:paypal}) after the user selected PayPal as the payment
+method. The customer then provides the proof of payment to the
+merchant.  Again, this is reasonably natural.  The 3DS workflow
+(Figure~\ref{fig:cc3ds}) has to deal with a multitude of banks and
+their different implementations, and not just a single provider.
+Hence, the interactions are more complicated as the merchant needs to
+additionally perform a lookup in the card scheme directory and verify
+availability of the bank (steps 8 to 12).
+
+The key difference between Taler and 3DS or PayPal is that
+in Taler, authentication is done ahead of time.
+After authenticating once to withdraw digital coins, the customer can
+perform many micropayments without having to re-authenticate.  While
+this simplifies the process of the individual purchase, it shifts the
+mental overhead to an earlier time, and thus requires some planning,
+especially given that the digital wallet is likely to only contain a
+% FIXME line below: which 'funds'? Coins or real money? (If they are
+% coins, recall that the wallet withdraw all the coins from a fresh
+% reserve, so there is no 'fraction' of user's available funds; at
+% least in the current implementation)
+% I originally wrote ``wealth'' or ``net value'', but given that
+% most customers are in debt today, that makes little sense, so
+% I changed it to ``available funds'', but I meant _all_ the money
+% he has.
+small fraction of the customer's available funds.  As a result, Taler
+improves usability if the customer is able to withdraw funds once to
+then facilitate many micropayments, while Taler is likely less usable
+if for each transaction the customer first visits the bank to withdraw
+funds.  This is deliberate, as Taler can only achieve reasonable
+privacy for customers if they do keep a balance in their wallet,
+thereby breaking the association between withdrawal and deposit.
+% FIXME the sentence above can be in contrast with how the exchange
+% actually deposits funds to merchants, that is through 'aggregate
+% deposits' that may add unpredictable delays (but that doesn't affect
+% this article too much)
+% CG: I think mentioning aggregation here would distract.
+
+Bitcoin's payment process (Figure~\ref{fig:bitcoin}) resembles that of
+Taler in one interesting point, namely that the wallet is given
+details about the contract the user is to enter (steps 7 to 11).
+However, in contrast to Taler, here the Bitcoin wallet(s) are expected
+to fetch the ``invoice'' from the merchant, while in Taler the browser
+provides the Taler wallet with the proposed contract directly.  In
+PayPal and 3DS, the user is left without a cryptographically secured
+receipt.
+
+Card-based payments (including 3DS) and PayPal also extensively rely
+on TLS for security.  The customer is expected to verify that his
+connections to the various Web sites are properly authenticated using
+X.509, and to know that it is fine to providing his 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 fully wallet-generated pages, hence
+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 now valid.  In Taler, merchants
+obtain a non-repudiable confirmation of the payment.  With 3DS and
+PayPal, the confirmation may be disputed later (i.e. in case of
+fraud), or accounts may be frozen arbitrarily~\cite{diaspora2011}.
+Payments in cash require the merchant to assume the risk of receiving
+counterfeit money.
+% FIXME what about (for the following sentence): merchants should care
+% about maintaining change and depositing the money earned
+% CG: No, it's not optional, ``should'' doesn't come into the equation
+% here. It's a mandatory business expense.
+Furthermore, merchants have the cost maintaining change and depositing
+the money earned.  With Bitcoin, there is no definitive time until a
+payment can be said to be confirmed (step 19, Figure~\ref{fig:bitcoin}),
+leaving merchants in a bit of a tricky situation.
+
+\section{Conclusion}
+
+Customers and merchants should be able to easily adapt their existing
+mental models and technical infrastructure to Taler.  In contrast,
+Bitcoin's payment models fail to match common expectations, be it in
+terms of performance, durability, security, or privacy.  Minimizing
+the need to authenticate to pay fundamentally improves 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.  A key
+question for the future is thus whether this data collection will be
+done on behalf of the citizens and under their control, or on behalf
+of the Reich of big data corporations.
+
+We encourage readers to try our prototype for Taler
+at \url{https://demo.taler.net/}, and to ponder why the billion dollar
+e-commerce industry still relies mostly on TLS for security, given
+that usability, security and privacy can clearly {\em all} be improved
+simultaneously using a modern payment protocol.
+
+% These APIs are all RESTful in the modern sense because that greatly
+% simplify integrating Taler with web shops and browsers.
+
+\section*{Acknowledgements}
+
+Removed for anonymous submission.
+
+%\newpage
+
+\bibliographystyle{abbrv}
+\bibliography{ui,btc,taler,rfc}
+
+\end{document}
+
+
+
+
+
+
+
+
+
+
+
+
+% \smallskip
+\subsection{Anonymity}
+
+We strongly recommend that the user use Tor Browser to protect their
+% FIXME wasn't the use of Tor discouraged to login into personal things?
+IP address, both initially when withdrawing coins and later during
+purchases.
+
+There are lingering risks that anonymous coins can be correlated to
+customers using additional information.
+
+After withdrawing coins, customer should usually wait before spending
+them, as spending them immediately ....
+% wallet determines coin denominations
+
+
+
+
+
+
+
+Wallet provides isolation
+  Near copy from EXIST proposal?
+- Limits user risk
+- Nearly eliminates risk for merchant and exchange
+  - lower transaction fees
+- Reserves simplify things
+
+Denomination choice
+- Anonymity refresh protocol
+- Withdraw automates like ATMs
+
+Browser extension
+- RESTful vs Bitcoin, OpenCoin, etc.
+  - Retrying RESTful transactions always works
+- minimizing dialog
+- see & pay ??
+- TBB integration
+  - Needed anyways
+- Other browser integration?
+  - Is it wise?  Ok if not worried about anonymity  Taler is still better
+  - Is tor2web worse?
+- W3C
+
+Autopay?  pat payment recognition?
+- dangerous?
+- high charges
+- good for funny money
+
+NFC
+
+
+
+
+
+
+
+
+
+
+
+
+
+% \smallskip
+\subsection{Risks}
+
+A Taler exchange's need not face significant financial risks beyond
+the risk of losing a denomination signing key.  Exchanges can limit that
+risk by carefully tracking how much they issue in each denomination.
+Taler merchant's risks are limited primarily by depositing coins
+quickly and stating contracts accurately.