taler/wallet-core
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Activity

misc edits based on Neal's comments

Browse Source
This commit is contained in:
Christian Grothoff 2016-05-15 17:21:49 +02:00
parent 9bdc4bbdbf
commit 6b851bd4e1
1 changed files with 130 additions and 127 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

257
articles/ui/ui.tex
View File

@ -41,7 +41,7 @@ Email: FIRSTNAME.LASTNAME@inria.fr
\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
significantly better usability. This paper first 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
@ -54,58 +54,55 @@ by the modern Web.
\section{Introduction}
The future Internet needs a secure, usable and privacy-preserving
micropayment system that is not backed by a ``crypto currency''.
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}
As transactions on the Internet, such as sending an e-mail or reading
trade~\cite{quantitytheory1997volckart} instead of speculation~\cite{lewis_btc_is_junk}.
As Internet transactions, 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
payment systems to handle these 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
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 on Taler, a new free software payment
The focus of this paper is 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
the customer remains anonymous while the merchant is taxable. Here,
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
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
{\em refresh} protocol 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/}}, 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.
protocols\footnote{Details of the protocol are documented
at \url{https://api.taler.net/}} and instead focuses on how a modern
payment system using blind signatures could practically be integrated
with the modern Web. This includes the challenge of hiding the
cryptography from the users. Our goal is to show that existing {\em
mental models} users have from existing widespread payment systems
apply naturally to Taler.
Key contributions of this paper are:
\begin{itemize}
\item A description of different payment systems using
common terminology, allowing us to analytically compare
common terminology, which allows 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
@ -113,7 +110,7 @@ Key contributions of this paper are:
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.
within the constraints of modern browsers.
\item A publicly available free software
reference implementation of the proposed architecture.
\end{itemize}
@ -121,25 +118,25 @@ Key contributions of this paper are:
\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. Detailed interaction diagrams for some
of the payment systems discussed here can be found in the Appendix.
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,
and crucially also provide an indication as to how we can relate
Taler's workflow to existing {\em mental models} that users already
have. Detailed interaction diagrams for some of the payment systems
discussed here can be found in the Appendix.
\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.
to sellers with each seller then becoming a buyer. Thus, cash is
inherently a {\em peer-to-peer} payment system as participants all
appear in the both buyer and seller roles, just at different times.
However, this view is both simplified and
somewhat dated.
In today's practice, cash is frequently first {\em withdrawn} from
ATMs by customers, who then {\em spend} it with merchants, who finally
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
@ -154,23 +151,23 @@ 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}
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
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 limit their risks to the
amount of cash they carry or accept at a given time~\cite{Bankrate}.
Against most attacks, customers and merchants limit their risks to the
amount of cash that they carry or accept at a given time~\cite{Bankrate}.
Additionally, customers are advised to choose the ATMs they use
carefully, as malicious ATMs may attempt to 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
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.
bank.
% \smallskip
@ -179,25 +176,24 @@ bank of the customer.
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
combinations including both secret information, which are usually PINs, and
physical security devices such as TANs~\cite{kobil2016tan}, cards with an EMV chip~\cite{emv}, and
the customer's mobile phone~\cite{mtan}.
A typical modern Web payment process involves
{(1.)} the merchant offering a ``secure'' communication channel
using TLS based on the X.509 public key infrastructure,\footnote{Given
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}, the security
provided by TLS is at best questionable.}
{(2.)} selecting a {\em payment method},
{(2.)} selecting a {\em payment method};
{(3.)} entering the credit card details like owner's name,
card number, expiration time, CVV code, and billing address,
card number, expiration time, CVV code, and billing address; and
{(4.)} (optionally) authorizing the transaction via mobile TAN, or
by authenticating against the customer's bank,
often on a Web site that is operated by the payment
processor and {\em not} the customer's bank. Figure~\ref{fig:cc3ds} in the
% FIXME why "..on the Web today using.." and not just "..on the Web using.."
Appendix shows a typical card-based payment process on the Web today using the
Appendix 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 diagram nicely illustrates the
complexity of the common 3-D secure (3DS) process.
@ -207,18 +203,18 @@ 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 {(5.)} the payment being rejected for a
variety of reasons, from false positives in fraud detection to the
merchant not accepting the particular card issuer.
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 hence to shift dispute liability to the issuer of the card, who
is 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
Even in cases where the issuer or the merchant remains legally first in
line, 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
@ -226,13 +222,13 @@ 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
receipts for the customers, which enables 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
result, customers must remain wary about using their card, which limits
their online shopping~\cite[p. 50]{ibi2014}.
% There is nevertheless a trend towards customers preferring cards
% over cash even in face-to-face purchases \cite{} in part because
@ -257,8 +253,8 @@ their online shopping~\cite[p. 50]{ibi2014}.
\subsection{Bitcoin}
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
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
@ -266,21 +262,23 @@ 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}.
%
puzzle, which 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}.
rewards. The latter process is also what provides initial accumulation
for BTC.~\cite{nakamoto2008bitcoin} 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
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, possibly
including additional metadata to be associated with the transfer and
from one of his accounts to the account of the merchant. He could possibly
include additional metadata to be associated with the transfer and
embedded into the global public ledger.
% Technically the following is not true, there are
% wallets that run purely in the browser and store
@ -304,25 +302,27 @@ 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}
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 being
unstable.~\cite{lehmann_btc_fools_gold,jeffries_economists_v_btc,lewis_btc_is_junk}. % exacerbating risk
unstable.~\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
There are several examples of Bitcoin's pseudononymity being broken
by investigators~\cite{BTC:Anonymity}.
by investigators~\cite{BTC:Anonymity}. This has resulted in the
development of new protocols with better privacy protections.
Zerocoin \cite{miers2013zerocoin}, an extension of Bitcoin, affords protection
against this, but at non-trivial additional computational costs even for
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
with mobile devices.
%
Bitcoin's pseudononymity applies equally to both customers and
merchants, making Bitcoin highly amen\-able to tax evasion, money
merchants, which makes Bitcoin amen\-able to tax evasion, money
laundering, and sales of contraband. As a result, anonymity tools
like mixnets do not enjoy particularly widespread support in the
Bitcoin community where many participants seek to make the currency
@ -342,12 +342,12 @@ appear more legitimate.
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
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
(see Figure~\ref{fig:paypal}). In these payment systems, the provider
basically acts like a bank with accounts carrying balances for the
various users. In contrast to traditional banking systems, both
customer and merchant are forced to have an account with the same
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
@ -357,8 +357,8 @@ 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
As with card payment systems, 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
@ -367,21 +367,22 @@ 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
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}. 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.
signatures}~\cite{chaum1983blind}. Since their discovery thirty years
ago, cryptographers have viewed blind signatures as the optimal
cryptographic primitive for consumer-level transaction systems.
However, previous transaction systems based on blind signatures have
failed to see widespread adoption. This paper details strategies for
hiding the cryptography from users and integrating smoothly with the
Web, thereby providing crucial steps to bridge the gap between good
cryptography and real-world deployment.
%\subsection{Design overview}
@ -412,32 +413,33 @@ 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
{\em Customers} use a digital wallet to withdraw,
hold, and spend coins. Wallets also manage the customer's accounts
at the exchange, and keep receipts in a transaction history. Wallets can be
realized as browser extensions, mobile Apps or even in custom
hardware.
hardware. If a user's digital wallet is compromised, the current
balance may be lost just like with an ordinary wallet for cash.
\item
{\em Exchanges}, run by for-profit financial service providers, enable
customers to withdraw anonymous digital coins
{\em Exchanges}, which are run by financial service providers, enable
customers to withdraw anonymous digital coins,
and merchants to deposit digital coins, in exchange for
bank money. Coins are signed by the exchange using
a blind signing scheme \cite{chaum1983blind}. Thus only
a blind signing scheme~\cite{chaum1983blind}. Thus, only
the exchange can issue new coins, but coins can't be traced back
to the customer that withdrew them.
Furthermore, exchanges learn the amounts withdrawn by customers
and deposited by merchants, but they do not learn the relationship
between customers and merchants. Exchanges perform online detection
of double spending, thus providing merchants instant feedback,
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
{\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
@ -465,21 +467,21 @@ paper, we focus on Web payments for an online shop.
% \smallskip
\subsection{Web payment workflow}
We explain how the actors in the Taler system interact by documenting
a typical payment.
In this section, we explain how the actors in the Taler system
interact by way of a typical payment.
Initially, the customer must once install the Taler wallet extension
for their browser. Naturally, this step may become superfluous if
Initially, the customer installs the Taler wallet extension
for their browser. This only needs to be done once
per browser. Naturally, this step may become superfluous if
Taler is integrated tightly with browsers in the future. Regardless,
installing the extension involves one or two clicks to confirm the
operation once the user was pointed to the correct Web site.
Restarting the browser is not required.
operation. Restarting the browser is not required.
\paragraph{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 online banking portal of their bank. Here, the bank will
visit the bank's online portal. Here, the bank will
typically require some form of authentication, the specific method
used depends on the bank (Figure~\ref{subfig:login}).
@ -512,21 +514,21 @@ used depends on the bank (Figure~\ref{subfig:login}).
The next step depends on the level of Taler support offered by the bank:
\begin{itemize}
\item If the bank does not offer integration with Taler, the
customer needs 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
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, this is
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.
\item Hence, if the bank properly integrates with Taler, the
customer has a form in the online banking portal where they can specify
usability reason.
\item Hence, if the bank fully supports Taler, the
customer has a form in the online banking portal in which they can specify
an amount to withdraw (Figure~\ref{subfig:withdraw}).
The bank then triggers an interaction with
the wallet to allow the customer to select an exchange
@ -542,10 +544,10 @@ 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
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.
customers, and may help create a competitive market.
\paragraph{Spending coins}
% \tinyskip
@ -584,13 +586,13 @@ currency issued by the respective exchange
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
Usually these details do not matter for the customer, as we expect
most merchants to allow most accredited exchange providers, and for
exchanges to operate with transaction fees acceptable to most
merchants. If transaction fees are higher than what is covered by the
merchant, the customer may choose to cover them.
As with traditional Web transactions, the customer first selects which
As with traditional Web transactions, customers first select which
items they wish to buy. This can involve building a traditional
shopping cart, or simply clicking on a particular link for the
respective article (Figure~\ref{subfig:cart}). As with card payments,
@ -604,7 +606,7 @@ signed {\em contract proposal} to the wallet extension
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
visual representation. In case the transaction fees need to be
covered by the customer, these are shown together with the rest of the
proposed contract.
@ -616,12 +618,13 @@ the information in its local database, and redirects the browser to a
(Figure~\ref{subfig:fulfillment}).
% FIXME: technically this is not entirely true, if you
% allow CORS ...
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.
%
% FIXME: can we do better with the description?
Instead, the server-side of the fulfillment page usually first detects
that the contract has not yet been paid by checking the merchant's
@ -634,7 +637,7 @@ 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
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
@ -656,14 +659,14 @@ client side of the result.
% 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
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 special
effectively spending the coins first using Taler's
% FIXME(dold): Do we properly introduce/discuss refreshing before?
``refresh'' protocol. In this case, later deposits by the merchant
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
operation via the transaction history, or demand a refund (see
below). Handling these errors does not require the customer to give
up his privacy.
\item If the payment fails due to the exchange
@ -691,9 +694,9 @@ 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}
\subsection{Bookmarks and deep links}
This particular architecture also enables smooth use of the payment
Taler's architecture also enables smooth use of 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.