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

editing section 3

Browse Source
This commit is contained in:
Christian Grothoff 2016-08-23 14:20:33 +02:00
parent 1d81549408
commit 4651d62751
1 changed files with 94 additions and 64 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

158
articles/ui/ui.tex
View File

@ -557,7 +557,9 @@ at the exchange, and keep receipts in a transaction history. Wallets can be
realized as browser extensions, mobile Apps or even in custom
hardware. If a user's digital wallet is compromised, the current
balance may be lost, just like with an ordinary wallet containing cash.
A wallet also includes a list of acceptable auditors, and will warn
users against using an exchange that is not certified by one of these
auditors.
\begin{figure}[t!]%[36]{R}{0.5\linewidth}
\subfloat[Bank login. (Simplified for demonstration.)]{
@ -584,7 +586,7 @@ customers to withdraw anonymous digital coins,
and merchants to deposit digital coins, in exchange for
bank money. Coins are signed by the exchange using
a blind signing scheme~\cite{chaum1983blind}. Thus, only
the exchange can issue new coins, but coins cannot be traced back
an exchange can issue new coins, but coins cannot be traced back
to the customer that withdrew them.
Furthermore, exchanges learn the amounts withdrawn by customers
and deposited by merchants, but they do not learn the relationship
@ -595,7 +597,11 @@ of double spending, thus providing merchants instant feedback
\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
exchange used by the customer in return for a bank wire
transfer of their value. While the exchange is determined by
the customer, the merchant's contract specifies the currency,
a list of accepted auditors and the maximum exchange deposit
fee the merchant is willing to pay. Merchants consist of a
{\em frontend}, which interacts with the customer's wallet, and a {\em
backend}, which interacts with the exchange. Typical frontends include
Web shops and point-of-sale systems.
@ -608,6 +614,9 @@ Depending on local legislation, auditors mandate that exchanges
have enough financial reserves before authorizing them to create a given
volume of signed digital coins in order to compensate for potential risks due to
operational failures (such as data loss or theft of private keys) of the exchange.
Auditors certify exchanges that they audit using digital signatures. The
respective signing keys of the auditors are distributed to customer and
merchants.
\end{itemize}
@ -622,7 +631,7 @@ 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
installing the extension involves only one or two clicks to confirm the
operation. Restarting the browser is not required.
@ -683,13 +692,13 @@ customers, and may help create a competitive market.
% \tinyskip
\begin{figure}[t!]
\subfloat[Select article. (Generated by Web shop.)]{
\subfloat[Select article. \\ Generated by Web shop.]{
\includegraphics[width=0.30\textwidth]{figs/cart.png}
\label{subfig:cart}} \hfill
\subfloat[Confirm payment. (Generated by Taler wallet.)]{
\subfloat[Confirm payment. \\ Generated by Taler wallet.]{
\includegraphics[width=0.30\textwidth]{figs/pay.png}
\label{subfig:payment}} \hfill
\subfloat[Receive article. (Generated by Web shop.)]{
\subfloat[Receive article. \\ Generated by Web shop.]{
\includegraphics[width=0.30\textwidth]{figs/fulfillment.png}
\label{subfig:fulfillment}}
\caption{Required steps in a Taler checkout process.}
@ -751,35 +760,42 @@ merchant, the customer may choose to cover them.
As with traditional Web transactions, customers first select which
items they wish to buy. This can involve building a traditional
shopping cart, or simply clicking on a particular link for the
respective article (Figure~\ref{subfig:cart}).
Taler also allows the Web shop to detect
the presence of a Taler wallet (Figure~\ref{listing:presence}), so
that the selection of other payment methods can be skipped
if a Taler wallet is installed (as it is in Figure~\ref{fig:shopping}).
respective article (Figure~\ref{subfig:cart}). Once the articles have
been selected, the Web shop directs the user to the {\em offer} URL,
where the payment details are negotiated. The process usually starts
by allowing the user to select a {\em payment method} from a set of
methods supported by the Web shop. Taler also allows the Web shop to
detect the presence of a Taler wallet (Figure~\ref{listing:presence}),
so that the selection of alternative payment methods can be skipped if
a Taler wallet is installed (as it is in Figure~\ref{fig:shopping}).
Web pages can initiate payments by sending a \emph{contract proposal} to the
wallet, either via the status code HTTP 402 Payment Required, or via a
JavaScript API. The wallet then presents the contract to the user. The format
of the contract is in an extensible JSON-based format defined by Taler and not
HTML, as the rendering of the contract is done by the wallet to ensure correct
visual representation of the terms and price. In case that transaction fees need to be covered by the
customer, these are shown together with the rest of the proposed contract.
% FIXME: add figure for 402 payment!
The offer URL of the Web shop can then initiate payments by sending a
\emph{contract proposal} to the wallet, either via the HTTP status
code {\tt 402 Payment Required}, or via Taler's JavaScript API
(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 of the terms and prices. In case that transaction fees
need to be covered by the customer, these are shown together with the
rest of the proposed contract.
If the customer approves the contract by clicking the ``Confirm
Payment'' button (Figure~\ref{subfig:payment}), their wallet signs the
contract with enough coins to cover the contract's cost, stores all of
the information in its local database, and redirects the browser to a
{\em fulfillment} URL provided by the merchant
(Figure~\ref{subfig:fulfillment}).
the information in its local database, and transmits the payment to
the {\em payment} URI of the Web shop. Once the Web shop confirms the
payment, the wallet redirects the browser to the {\em fulfillment} URL
provided by the merchant (Figure~\ref{subfig:fulfillment}).
\subsection{Browser security}
The Taler wallet operates from a securely isolated {\em background} context on
the client side. The user interface that displays
the contract and allows the user to confirm the payment is displayed by
this background context. If the user accepts, the
resulting signed coins are transferred from the client to the
merchant's server.
The Taler wallet operates from a securely isolated {\em background}
context on the client side. The user interface that displays the
contract and allows the user to confirm the payment is displayed by
this background context. If the user accepts, the resulting signed
coins are transferred from the client to the merchant's server.
By running in the background context, the wallet can perform the
cryptographic operations protected from the main process of the Web
@ -789,10 +805,9 @@ that generates a page that looks like the wallet's payment page
access to the private keys of the coins that are exclusive to the
background context.
The current Taler specification is written to accommodate for
the rather restrictive set of APIs that WebExtension, a
cross-browser extension API, provides.
%The current Taler specification is written to accommodate for
%the rather restrictive set of APIs that WebExtension, a
%cross-browser extension API, provides.
\subsection{Managing browser session state}
@ -810,38 +825,48 @@ cross-browser extension API, provides.
% design that allows merchant to not store any information
A purchase by a customer, completed or in progress, is uniquely identified by a URL, called
the \emph{fulfillment URL}. The information contained in the fulfillment
URL must allow the merchant to restore the full contract that was associated
with purchase, either directly or indirectly from an identifier in a database%
\footnote{Storing information about incomplete purchases potential for abuse from malicious customers.}.
A purchase by a customer, completed or in progress, is uniquely
identified by a URL, called the \emph{fulfillment URL}. The
information contained in the fulfillment URL must allow the merchant
to restore the full contract that was associated with the purchase,
either directly from the URL or indirectly from an identifier in a
database. Efficiently reconstructing the contract entirely from the
URL instead of using costly database transactions can be important, as
costly disk operations for incomplete purchases make merchants
more susceptible to denial-of-service attacks from adversaries
pretending to be customers.
When a customer completed a purchase, navigating to the fulfillment URL in a browser
will show the resource associated with the purchase. This resource can be a
digital good such as a news article, or simply a confirmation for products that
are delivered by other means.
When a customer completed a purchase, navigating to the fulfillment
URL in a browser will show the resource associated with the purchase.
This resource can be a digital good such as a news article, or simply
a confirmation for products that are delivered by other means.
In order to ensure that only the paying customer has access to the web
resources behind the fulfillment URL, the web store's server must check the
browser's session state. Visiting the fulfillment URL for the first
time\footnote{Or after deleting the session state, which e.g. happens when
privacy conscious users delete their cookies. Some user agents (such as the TOR browser)
do not support persistent (non-session) cookies.} triggers the wallet to send the
signed coins that are associated with the contract for the fulfillment URL to
the merchant. This process can be triggered via a JavaScript API for the
wallet, or by a \emph{HTTP 402 Payment Required} status code.
In order to ensure that only the paying customer has access to the Web
resources behind the fulfillment URL, the Web store's server must
check the browser's session state. If the merchant can confirm that
the visitor has paid, the respective Web resource is returned. If the
merchant cannot confirm that the visitor has paid for the contract,
for example because the session state was lost,\footnote{This can
happen when when privacy conscious users delete their cookies.
Also, some user agents (such as the TOR browser) do not support
persistent (non-session) cookies.} it {\em again} triggers a payment
process (either via JavaScript or using {\tt 402 Payment Required}).
If the wallet remembers paying for the contract previously, this
causes the wallet to retransmit the signed coins that are associated
with the purchase to the merchant.
When a user visits a fulfillment URL without having the associated contract
in their wallet, the wallet redirects the browser to the offer URL for that
purchase, if applicable. This behavior is useful when a user wishes to
send a fulfillment link to another user.
When a user visits a fulfillment URL without having the associated
contract in their wallet, the wallet redirects the browser to the {\em
offer} URL for that purchase, if applicable. This behavior is
useful when a user wishes to share a fulfillment link with another
user to point him to the same resource.
Note that due to the limited WebExtensions API, the session
state can only be acquired when the browser navigates to
the fulfillment URL (without session state), since the session
state must be set on the same origin as the fulfillment URL.
Various failure modes are considered:
Various failure modes are considered in this design:
\begin{itemize}
\item If the payment fails on the network, the request is typically
@ -860,7 +885,7 @@ Various failure modes are considered:
refresh protocol. In this case, later deposits by the merchant
will simply fail. If the merchant already succeeded with the payment
before the network failure, the customer can either retry the
operation via the transaction history, or demand a refund (see
operation via the transaction history kept by the wallet, or demand a refund (see
below). Handling these errors does not require the customer to give
up his privacy.
\item If the payment fails due to the exchange
@ -876,14 +901,15 @@ Various failure modes are considered:
the transaction.
\end{itemize}
While our design has a few extra roundtrips,
it has the following advantages:
\noindent
While our design requires a few extra roundtrips,
it has the following key advantages:
\begin{itemize}
\item It works in the confines of the WebExtensions API.
\item It supports restoring session state for bookedmarked
web resources when session state is cleared in the user agent.
\item Sending deep links to other users has the expected behavior
\item Sending deep links to fullfilment or offer pages to
other users has the expected behavior
of asking the other user to pay for the resource.
\item Asynchronously POSTing coins from injected JavaScript costs
one roundtrip, but does not interfer with navigation and allows
@ -895,13 +921,16 @@ it has the following advantages:
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}.
\item The architecture supports security-conscious users that may have
disabled JavaScript, as it is not necessary to execute JavaScript
originating from Web pages to execute the payment process.
\end{itemize}
% \smallskip
\subsection{Giving change and refunds} % FIXME: maybe leave out change entirely?
\subsection{Giving change and refunds}
An important technical difference between Taler and previous
An important cryptographic difference between Taler and previous
transaction systems based on blind signing is that Taler is able to
provide unlinkable change and refunds. From the user's point of view,
obtaining change is automatic and handled by the wallet, i.e., if the
@ -1060,7 +1089,7 @@ shops.
Figure~\ref{fig:frobearch} shows how the secure payment components
interact with the existing Web shop logic. First, the Web shop
frontend is responsible for constructing the shopping cart. For this,
the shop frontend generates the usual Web pages, which are transmitted
the shop frontend generates the customary Web shop pages, which are transmitted
to the customer's browser. Once the order has been constructed, the
shop frontend provides a {\em proposed contract} in JSON format to the
payment backend, which signs it and returns it to the frontend. The
@ -1087,7 +1116,8 @@ for a contract to the backend; and, {\bf (8)} executing fulfillment
business logic if the backend confirms the validity of the payment.
To setup a Taler backend, the merchant only needs to configure the
wire transfer routing details, such as the merchant's IBAN number.
wire transfer routing details, such as the merchant's IBAN number, as
well as a list of acceptable auditors and limits for transaction fees.
Ideally, the merchant might also want to obtain a certificate for the
public key generated by the backend for improved authentication.
Otherwise, the customer's authentication of the Web shop simply