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 realized as browser extensions, mobile Apps or even in custom
hardware. If a user's digital wallet is compromised, the current hardware. If a user's digital wallet is compromised, the current
balance may be lost, just like with an ordinary wallet containing cash. 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} \begin{figure}[t!]%[36]{R}{0.5\linewidth}
\subfloat[Bank login. (Simplified for demonstration.)]{ \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 and merchants to deposit digital coins, in exchange for
bank money. Coins are signed by the exchange using 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 cannot be traced back an exchange can issue new coins, but coins cannot be traced back
to the customer that withdrew them. to the customer that withdrew them.
Furthermore, exchanges learn the amounts withdrawn by customers Furthermore, exchanges learn the amounts withdrawn by customers
and deposited by merchants, but they do not learn the relationship and deposited by merchants, but they do not learn the relationship
@ -595,7 +597,11 @@ of double spending, thus providing merchants instant feedback
\item \item
{\em Merchants} provide goods or services in exchange for coins held {\em Merchants} provide goods or services in exchange for coins held
by customers' wallets. Merchants deposit these coins at the 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 {\em frontend}, which interacts with the customer's wallet, and a {\em
backend}, which interacts with the exchange. Typical frontends include backend}, which interacts with the exchange. Typical frontends include
Web shops and point-of-sale systems. 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 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 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. 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} \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 their browser. This only needs to be done once per
browser. Naturally, this step may become superfluous if Taler is browser. Naturally, this step may become superfluous if Taler is
integrated tightly with browsers in the future. Regardless, 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. operation. Restarting the browser is not required.
@ -683,13 +692,13 @@ customers, and may help create a competitive market.
% \tinyskip % \tinyskip
\begin{figure}[t!] \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} \includegraphics[width=0.30\textwidth]{figs/cart.png}
\label{subfig:cart}} \hfill \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} \includegraphics[width=0.30\textwidth]{figs/pay.png}
\label{subfig:payment}} \hfill \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} \includegraphics[width=0.30\textwidth]{figs/fulfillment.png}
\label{subfig:fulfillment}} \label{subfig:fulfillment}}
\caption{Required steps in a Taler checkout process.} \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 As with traditional Web transactions, customers first select which
items they wish to buy. This can involve building a traditional items they wish to buy. This can involve building a traditional
shopping cart, or simply clicking on a particular link for the shopping cart, or simply clicking on a particular link for the
respective article (Figure~\ref{subfig:cart}). respective article (Figure~\ref{subfig:cart}). Once the articles have
Taler also allows the Web shop to detect been selected, the Web shop directs the user to the {\em offer} URL,
the presence of a Taler wallet (Figure~\ref{listing:presence}), so where the payment details are negotiated. The process usually starts
that the selection of other payment methods can be skipped by allowing the user to select a {\em payment method} from a set of
if a Taler wallet is installed (as it is in Figure~\ref{fig:shopping}). 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 % FIXME: add figure for 402 payment!
wallet, either via the status code HTTP 402 Payment Required, or via a The offer URL of the Web shop can then initiate payments by sending a
JavaScript API. The wallet then presents the contract to the user. The format \emph{contract proposal} to the wallet, either via the HTTP status
of the contract is in an extensible JSON-based format defined by Taler and not code {\tt 402 Payment Required}, or via Taler's JavaScript API
HTML, as the rendering of the contract is done by the wallet to ensure correct (Figure~\ref{listing:contract}). The wallet then presents the
visual representation of the terms and price. In case that transaction fees need to be covered by the contract to the user. The format of the contract is in an extensible
customer, these are shown together with the rest of the proposed contract. 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 If the customer approves the contract by clicking the ``Confirm
Payment'' button (Figure~\ref{subfig:payment}), their wallet signs the Payment'' button (Figure~\ref{subfig:payment}), their wallet signs the
contract with enough coins to cover the contract's cost, stores all of 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 the information in its local database, and transmits the payment to
{\em fulfillment} URL provided by the merchant the {\em payment} URI of the Web shop. Once the Web shop confirms the
(Figure~\ref{subfig:fulfillment}). payment, the wallet redirects the browser to the {\em fulfillment} URL
provided by the merchant (Figure~\ref{subfig:fulfillment}).
\subsection{Browser security} \subsection{Browser security}
The Taler wallet operates from a securely isolated {\em background} context on The Taler wallet operates from a securely isolated {\em background}
the client side. The user interface that displays context on the client side. The user interface that displays the
the contract and allows the user to confirm the payment is displayed by contract and allows the user to confirm the payment is displayed by
this background context. If the user accepts, the this background context. If the user accepts, the resulting signed
resulting signed coins are transferred from the client to the coins are transferred from the client to the merchant's server.
merchant's server.
By running in the background context, the wallet can perform the By running in the background context, the wallet can perform the
cryptographic operations protected from the main process of the Web 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 access to the private keys of the coins that are exclusive to the
background context. background context.
The current Taler specification is written to accommodate for %The current Taler specification is written to accommodate for
the rather restrictive set of APIs that WebExtension, a %the rather restrictive set of APIs that WebExtension, a
cross-browser extension API, provides. %cross-browser extension API, provides.
\subsection{Managing browser session state} \subsection{Managing browser session state}
@ -810,38 +825,48 @@ cross-browser extension API, provides.
% design that allows merchant to not store any information % 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 A purchase by a customer, completed or in progress, is uniquely
the \emph{fulfillment URL}. The information contained in the fulfillment identified by a URL, called the \emph{fulfillment URL}. The
URL must allow the merchant to restore the full contract that was associated information contained in the fulfillment URL must allow the merchant
with purchase, either directly or indirectly from an identifier in a database% to restore the full contract that was associated with the purchase,
\footnote{Storing information about incomplete purchases potential for abuse from malicious customers.}. 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 When a customer completed a purchase, navigating to the fulfillment
will show the resource associated with the purchase. This resource can be a URL in a browser will show the resource associated with the purchase.
digital good such as a news article, or simply a confirmation for products that This resource can be a digital good such as a news article, or simply
are delivered by other means. a confirmation for products that are delivered by other means.
In order to ensure that only the paying customer has access to the web 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 resources behind the fulfillment URL, the Web store's server must
browser's session state. Visiting the fulfillment URL for the first check the browser's session state. If the merchant can confirm that
time\footnote{Or after deleting the session state, which e.g. happens when the visitor has paid, the respective Web resource is returned. If the
privacy conscious users delete their cookies. Some user agents (such as the TOR browser) merchant cannot confirm that the visitor has paid for the contract,
do not support persistent (non-session) cookies.} triggers the wallet to send the for example because the session state was lost,\footnote{This can
signed coins that are associated with the contract for the fulfillment URL to happen when when privacy conscious users delete their cookies.
the merchant. This process can be triggered via a JavaScript API for the Also, some user agents (such as the TOR browser) do not support
wallet, or by a \emph{HTTP 402 Payment Required} status code. 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 When a user visits a fulfillment URL without having the associated
in their wallet, the wallet redirects the browser to the offer URL for that contract in their wallet, the wallet redirects the browser to the {\em
purchase, if applicable. This behavior is useful when a user wishes to offer} URL for that purchase, if applicable. This behavior is
send a fulfillment link to another user. 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 Note that due to the limited WebExtensions API, the session
state can only be acquired when the browser navigates to state can only be acquired when the browser navigates to
the fulfillment URL (without session state), since the session the fulfillment URL (without session state), since the session
state must be set on the same origin as the fulfillment URL. 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} \begin{itemize}
\item If the payment fails on the network, the request is typically \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 refresh protocol. In this case, later deposits by the merchant
will simply fail. If the merchant already succeeded with the payment will simply fail. If the merchant already succeeded with the payment
before the network failure, the customer can either retry the 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 below). Handling these errors does not require the customer to give
up his privacy. up his privacy.
\item If the payment fails due to the exchange \item If the payment fails due to the exchange
@ -876,14 +901,15 @@ Various failure modes are considered:
the transaction. the transaction.
\end{itemize} \end{itemize}
\noindent
While our design has a few extra roundtrips, While our design requires a few extra roundtrips,
it has the following advantages: it has the following key advantages:
\begin{itemize} \begin{itemize}
\item It works in the confines of the WebExtensions API. \item It works in the confines of the WebExtensions API.
\item It supports restoring session state for bookedmarked \item It supports restoring session state for bookedmarked
web resources when session state is cleared in the user agent. 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. of asking the other user to pay for the resource.
\item Asynchronously POSTing coins from injected JavaScript costs \item Asynchronously POSTing coins from injected JavaScript costs
one roundtrip, but does not interfer with navigation and allows 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 control of the fulfillment page over the transmission of the payment
information minimizes the need for exceptions to handle cross-origin information minimizes the need for exceptions to handle cross-origin
resource sharing~\cite{rfc6454,cors}. 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} \end{itemize}
% \smallskip % \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 transaction systems based on blind signing is that Taler is able to
provide unlinkable change and refunds. From the user's point of view, 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 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 Figure~\ref{fig:frobearch} shows how the secure payment components
interact with the existing Web shop logic. First, the Web shop interact with the existing Web shop logic. First, the Web shop
frontend is responsible for constructing the shopping cart. For this, 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 to the customer's browser. Once the order has been constructed, the
shop frontend provides a {\em proposed contract} in JSON format to 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 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. business logic if the backend confirms the validity of the payment.
To setup a Taler backend, the merchant only needs to configure the 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 Ideally, the merchant might also want to obtain a certificate for the
public key generated by the backend for improved authentication. public key generated by the backend for improved authentication.
Otherwise, the customer's authentication of the Web shop simply Otherwise, the customer's authentication of the Web shop simply