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

clarification

Browse Source
This commit is contained in:
Florian Dold 2016-08-16 17:33:51 +02:00
parent 62dbcba15c
commit e7f402550f
1 changed files with 21 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
articles/ui/ui.tex
View File

@ -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