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

fix fulfillment URL description; various fixes

Browse Source
This commit is contained in:
Florian Dold 2016-08-16 16:46:58 +02:00
parent c592c508eb
commit 9390364322
1 changed files with 45 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

83
articles/ui/ui.tex
View File

@ -676,21 +676,21 @@ merchant, the customer may choose to cover them.
\end{figure*} \end{figure*}
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}). As with card payments, respective article (Figure~\ref{subfig:cart}).
the Web shop may then allow the customer to select a payment method, Taler also allows the Web shop to detect
including Taler. Taler also allows the Web shop to detect
the presence of a Taler wallet (Figure~\ref{listing:presence}), so 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}). that the selection of other payment methods can be skipped
if a Taler wallet is installed (as it is in Figure~\ref{fig:shopping}).
If Taler was detected or selected, the Web shop sends a digitally If Taler was detected or selected, the Web shop sends a digitally
signed {\em contract proposal} to the wallet extension signed {\em contract proposal} to the wallet extension
(Figure~\ref{listing:contract}). The wallet then presents the (Figure~\ref{listing:contract}). The wallet then presents the
contract to the user. The format of the contract is in an extensible contract to the user. The format of the contract is in an extensible
JSON-based format defined by Taler and not HTML, as the JSON-based format defined by Taler and not HTML, as the
rendering of the contract is done by the wallet to ensure correct rendering of the contract is done by the wallet to ensure correct
% FIXME(dold): specify what we mean by "correct visual representation"!
visual representation. In case that transaction fees need to be visual representation. In case that transaction fees need to be
covered by the customer, these are shown together with the rest of the covered by the customer, these are shown together with the rest of the
proposed contract. proposed contract.
@ -706,9 +706,10 @@ the information in its local database, and redirects the browser to a
\subsection{Browser security} \subsection{Browser security}
The Taler wallet operates from a secure {\em background} context on The Taler wallet operates from a securely isolated {\em background} context on
the client side. From this background context the wallet allows the the client side. The user interface that displays
user to securely accept the payment. If the user accepts, the 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 resulting signed coins are transferred from the client to the
merchant's server. merchant's server.
@ -720,42 +721,48 @@ 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 rather restrictive set of APIs that WebExtension, a
cross-browser extension API, provides.
\subsection{Managing browser context}
\subsection{Managing browser session state}
% FIXME: this is where we probably want to revise quite a bit, % FIXME: this is where we probably want to revise quite a bit,
% including improving the description AND addressing the JS-less % including improving the description AND addressing the JS-less
% implementation. % implementation.
The wallet cannot directly send the payment to the merchant, as the % Say that this doesn't require accounts!
page showing the contract is provided as a background page controlled % explain that HTTP session state can be restored
by the Web % from the wallet state (replay!)
Extension\footnote{\url{https://developer.chrome.com/extensions}} and
thus submitting coins from the background would not use the % explain repurchase correlation ID
HTTP-context that the Web shop's page requires for session management.
% % contract vs complete fulfillment URL
% FIXME: can we do better with the description?
Instead, the server-side of the fulfillment page usually first detects % design that allows merchant to not store any information
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 A purchase that was made by a customer is uniquely identified by a URL, called
indicates that this customer did not yet pay, the merchant generates a the \emph{fulfillment URL}. When a customer completed a purchase, navigating
page that shows the customer an indication that the payment is being to this URL in a browser should show the resource associated with the purchase.
processed, and tries to interact with the wallet, requesting payment. This resource can be a digital good such as a news article, or simply a
If the wallet is not detected after a few milliseconds, the page confirmation for products that are delivered by other means.
transitions to the card payment process. If the wallet is present,
the page requests payment from the wallet. The wallet then determines In order to ensure that only the paying customer has access to the web
that the customer already confirmed the payment and immediately resources behind the fulfillment URL, the web store's server must check the
transfers the coins to the JavaScript logic of the fulfillment page. browser's session state. Visiting the fulfillment URL for the first
The fulfillment page then transfers the coins to the merchant usually time\footnote{Or after deleting the session state, which e.g. happens when
using an asynchronous HTTP POST request. The request is controlled by privacy conscious users delete their cookies.} triggers the wallet to send the
the merchant's JavaScript and not by the wallet. This ensures that the signed coins that are associated with the contract for the fulfillment URL to
merchant is in full control of the communication between the the merchant. This process can be triggered via a JavaScript API for the
merchant's server and the client-side scripts interacting with the wallet, or by a \emph{HTTP 402 Payment Required} status code.
merchant's server. The interactions with the wallet are thus purely
local interactions within the browser. Upon receipt of the payment Note that due to the limited WebExtensions API, the session
information, the merchant confirms the payment with the exchange, state can only be acquired when the browser navigates to
marks the payment as received, and notifies the JavaScript on the the fulfillment URL (without session state), since the session
client side of the result. state must be set on the same origin as the fulfillment URL.
Various failure modes are considered:
\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