diff options
author | Florian Dold <florian.dold@gmail.com> | 2016-05-11 02:00:58 +0200 |
---|---|---|
committer | Florian Dold <florian.dold@gmail.com> | 2016-05-11 02:00:58 +0200 |
commit | 071b4aee7ebd3f80ba7f7c0d6e57373bca7b7bac (patch) | |
tree | 9178703139a7c9ea6400adf846aaa450c9f0d7b9 /articles/ui | |
parent | 5bde0d5b1b4370e796e5e2207b97c5291e22dddc (diff) | |
download | wallet-core-071b4aee7ebd3f80ba7f7c0d6e57373bca7b7bac.tar.xz |
minor edits
Diffstat (limited to 'articles/ui')
-rw-r--r-- | articles/ui/ui_short.tex | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/articles/ui/ui_short.tex b/articles/ui/ui_short.tex index ab964d60c..f1b37b970 100644 --- a/articles/ui/ui_short.tex +++ b/articles/ui/ui_short.tex @@ -91,7 +91,7 @@ system (Figure~\ref{fig:system}). In Taler, customers use a {\em wallet} to withdraw, hold, and spend coins. Withdrawing coins requires the customer to authenticate and to optionally authorize the specific transaction, e.g. via a PIN/TAN method as commonly used -by banks. Afterwards, the customer can anonymously spend his coins by visiting +by banks. Afterwards, the customer can anonymously spend their coins by visiting merchants without having to authenticate for each transaction. The wallet is implemented as a cross-platform browser extension. All @@ -177,7 +177,7 @@ instance of the digital contract with the opportunity to pay for it. The case where a user already payed for a resource and then visits the resource URL (instead of the fulfillment URL) after losing temporary -session state is also handled correctly, since the wallet component will +session state is also handled as expected, since the wallet component will look for contracts that refer to the same resource. While Taler is designed to work well with digital resources on the web, @@ -197,8 +197,8 @@ are being purchased. %\end{figure} -A new payment system must also be easy to deploy for merchants. -Figure~\ref{fig:frobearch} shows how the secure payment components of +A new payment system must also be easy to integrate and deploy for merchants. +Figure~\ref{fig:frobearch} shows how the security critical payment components of Taler interact with the logic of existing Web shops. First, the Web shop front-end is responsible for constructing the shopping cart. For this, the shop front-end generates the usual Web pages which are shown to the @@ -206,8 +206,8 @@ user's browser client front-end. Once the order has been constructed, the shop front-end gives a {\em proposed contract} in JSON format to the payment backend, which signs it and returns it to the front-end. The front-end then transfers the signed contract over the network, and -passes it to the wallet. Here, the wallet operates from a secure {\em -background} on the client side, which allows the user to securely +passes it to the wallet. Here, the wallet operates from a secure +background context on the client side, which allows the user to securely accept the payment, and to perform the cryptographic operations in a context that is protected from the Web shop. If the user accepts, the resulting signed coins are transferred from the client to the server, @@ -235,7 +235,7 @@ contract to the backend and {\bf (8)} executing fulfillment business logic if the backend confirms the validity of the payment. -To setup a Taler backend, the merchant only needs to let it know the +To setup a Taler backend, the merchant only needs to configure it with the respective wire transfer routing details, such as an IBAN number. The customer's authentication of the Web shop continues to rely upon \mbox{HTTPS}/X.509. |