clarification

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