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

addressing comments

Browse Source
This commit is contained in:
Christian Grothoff 2016-08-23 10:09:47 +02:00
parent 2638d30e7a
commit 1c7aeaf3b7
1 changed files with 20 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
articles/ui/ui.tex
View File

@ -280,8 +280,7 @@ code, and billing address; and {(4.)} (optionally) authorizing the
transaction via mobile TAN, or by authenticating against the transaction via mobile TAN, or by authenticating against the
customer's bank, often on a Web site that is operated by the payment customer's bank, often on a Web site that is operated by the payment
processor and {\em not} the customer's bank. Figure~\ref{fig:cc3ds} processor and {\em not} the customer's bank. Figure~\ref{fig:cc3ds}
% FIXME why "..on the Web today using.." and not just "..on the Web using.." shows a typical card-based payment process on the Web using the
shows a typical card-based payment process on the Web today using the
UML style of the W3C payment interest group~\cite{pigs}. Most of the details UML style of the W3C payment interest group~\cite{pigs}. Most of the details
are not relevant to this paper, but the diagram nicely illustrates the are not relevant to this paper, but the diagram nicely illustrates the
complexity of the common 3-D secure (3DS) process. complexity of the common 3-D secure (3DS) process.
@ -757,8 +756,7 @@ 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 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 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 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 of the terms and price. In case that transaction fees need to be covered by the
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. 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
@ -853,7 +851,6 @@ Various failure modes are considered:
failure persists and is between the customer and the merchant, the wallet failure persists and is between the customer and the merchant, the wallet
will try to recover control over the coins at the exchange by will try to recover control over the coins at the exchange by
effectively spending the coins first using Taler's effectively spending the coins first using Taler's
% FIXME(dold): Do we properly introduce/discuss refreshing before?
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
@ -868,20 +865,16 @@ Various failure modes are considered:
the user to export the relevant cryptographic data to be used in the user to export the relevant cryptographic data to be used in
court. If the exchange's proofs were correct and coins were court. If the exchange's proofs were correct and coins were
double-spent, the wallet informs the user that its database must have double-spent, the wallet informs the user that its database must have
% FIXME what about giving an example of an out-of-date DB? Put in been out-of-date (e.g. because it was restored from backup),
% this way, it appears that Taler has viable ways to fail. In other updates the database and allows the user to retry
% words, that it's normal to get such a failure. Instead, that failure
% can occur due to coins not spent for *years* (or some other corner case),
% that saves Taler from being "blamed"
been out-of-date, updates the database and allows the user to retry
the transaction. the transaction.
\end{itemize} \end{itemize}
While our design has a relatively high number of roundtrips, While our design has a few extra roundtrips,
it has the following advantages: it has the following 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 other users has the expected behavior
@ -1191,7 +1184,8 @@ payment. Usually the wallet can trivially check this before beginning
a transaction, but when double-spending is detected this may also a transaction, but when double-spending is detected this may also
happen after the wallet already initiated the payment. This would happen after the wallet already initiated the payment. This would
usually only happen if the wallet is unaware of a backup operation usually only happen if the wallet is unaware of a backup operation
voiding its internal invariants. If a payment fails in-flight due to voiding its internal invariant of knowing which coins have already
been spent. If a payment fails in-flight due to
insufficient funds, the wallet can use Taler's refresh protocol to insufficient funds, the wallet can use Taler's refresh protocol to
obtain a refund for those coins that were not actually double-spent, obtain a refund for those coins that were not actually double-spent,
and then explain to the user that the balance was inaccurate due to and then explain to the user that the balance was inaccurate due to