aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorFlorian Dold <florian.dold@gmail.com>2016-08-16 17:33:51 +0200
committerFlorian Dold <florian.dold@gmail.com>2016-08-16 17:33:51 +0200
commite7f402550f62e24d8e1ee59fdd6f25ded85ddd19 (patch)
tree9bf6c2ebadbb8e963b229cb43e6f5ff5aea3accc
parent62dbcba15c3290113fc98782ed2f0ddb1f4b392f (diff)
clarification
-rw-r--r--articles/ui/ui.tex37
1 files changed, 21 insertions, 16 deletions
diff --git a/articles/ui/ui.tex b/articles/ui/ui.tex
index 229763453..cc7f2e05d 100644
--- a/articles/ui/ui.tex
+++ b/articles/ui/ui.tex
@@ -684,16 +684,15 @@ 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}).
-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
+
+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
% FIXME(dold): specify what we mean by "correct visual representation"!
-visual representation. In case that transaction fees need to be
-covered by the customer, these are shown together with the rest of the
-proposed contract.
+visual representation. 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
@@ -701,8 +700,6 @@ 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}).
-% FIXME: technically this is not entirely true, if you
-% allow CORS ...
\subsection{Browser security}
@@ -742,11 +739,15 @@ cross-browser extension API, provides.
% design that allows merchant to not store any information
-A purchase that was made by a customer is uniquely identified by a URL, called
-the \emph{fulfillment URL}. When a customer completed a purchase, navigating
-to this URL in a browser should 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.
+A purchase by 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.
+
+When a customer completed a purchase, navigating to this 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
@@ -757,6 +758,10 @@ 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.
+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.
+
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