aboutsummaryrefslogtreecommitdiff
path: root/contrib/articles/ui/ui_short.tex
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/articles/ui/ui_short.tex')
-rw-r--r--contrib/articles/ui/ui_short.tex268
1 files changed, 268 insertions, 0 deletions
diff --git a/contrib/articles/ui/ui_short.tex b/contrib/articles/ui/ui_short.tex
new file mode 100644
index 000000000..f48dd86e4
--- /dev/null
+++ b/contrib/articles/ui/ui_short.tex
@@ -0,0 +1,268 @@
+
+\title{Taler: \\ Usable, privacy-preserving payments for the Web}
+ \author{
+ Jeffrey Burdges \\ \and
+ Florian Dold \\ \and
+ Christian Grothoff \\ \and
+ Marcello Stanisci
+}
+\date{\today}
+
+\documentclass[twoside,letterpaper]{sigalternate}
+\usepackage[margin=1in]{geometry}
+\usepackage[utf8]{inputenc}
+\usepackage{url}
+\usepackage{tikz}
+\usepackage{listings}
+\usepackage{graphicx}
+\usepackage{wrapfig}
+\usepackage{caption}
+\usepackage{subcaption}
+\usepackage{url}
+%\usepackage{dblfloatfix}
+
+\usetikzlibrary{shapes,arrows}
+\usetikzlibrary{positioning}
+\usetikzlibrary{calc}
+
+\begin{document}
+\maketitle
+
+\section{System overview}
+
+Content and services provided on the internet, such as reading a blog post or
+sending an email, tend to be of very small monetary value compared to
+traditional financial transactions. Currently the majority of online offerings
+are financed via advertisements. Any alternatives must reduce the mental
+and technical overheads of existing payment systems to handle micro-payments.
+Addressing this problem is urgent because advertising revenue is declining,
+% \cite{??peakads??},
+% It's possibly being erroded by ad-blocking technology
+% but arguably ad-blocking is a way to save it. \cite{??AskJeff??}
+and the Big Data business model where citizens pay with their
+private information in combination with the deep state hastens our society's
+regression towards post-democracy~\cite{rms2013democracy}.
+
+Taler is a new electronic online payment system that provides
+anonymity for customers. Here, {\em anonymous} simply means that the
+payment system does not involve any personal information from the
+customer, and that different transactions by the same customer are
+unlinkable. For strong anonymity, Taler usually needs to be used in
+combination with existing techniques, such as Tor and \cite{apod}, to
+avoid circumstances leaking information about the customer's identity.
+The facts that the user does not need to authenticate, and that the merchant
+thus never learns sensitive personal information about the customer,
+improves usability and security: the payment process is simplified, the
+merchant's security requirements are dramatically reduced and the customer's
+risk of identity theft does not accumulate with every (micro-)payment.
+% The preceeding is a run-on but I didn't fix it
+
+Taler uses blind signatures~\cite{chaum1983blind} to create digital
+coins, and a novel ``refresh'' protocol to allow giving change and
+refunds while maintaining unlinkability. We will not go into the
+details of Taler's cryptographic protocols here\footnote{Full
+documentation at \url{https://api.taler.net/}} and instead focus on the
+high-level concepts to explain how the system works from the
+perspective of customers and merchants in the Taler
+system (Figure~\ref{fig:system}).
+% "... and how it contributes to customer privacy"?
+
+\begin{figure}[t!]
+\centering
+\begin{tikzpicture}
+ \tikzstyle{def} = [node distance=3em and 5em, inner sep=1em, outer sep=.3em];
+ \node (origin) at (0,0) {};
+ \node (exchange) [def,above=of origin,draw]{Exchange};
+ \node (customer) [def, draw, below left=of origin] {Customer};
+ \node (merchant) [def, draw, below right=of origin] {Merchant};
+ \node (auditor) [def, draw, above right=of origin]{Auditor};
+
+ \tikzstyle{C} = [color=black, line width=1pt]
+
+ \draw [<-, C] (customer) -- (exchange) node [midway, above, sloped] (TextNode) {withdraw coins};
+ \draw [<-, C] (exchange) -- (merchant) node [midway, above, sloped] (TextNode) {deposit coins};
+ \draw [<-, C] (merchant) -- (customer) node [midway, above, sloped] (TextNode) {spend coins};
+ \draw [<-, C] (exchange) -- (auditor) node [midway, above, sloped] (TextNode) {verify};
+
+\end{tikzpicture}
+\caption{Taler system overview.}
+\label{fig:system}
+\end{figure}
+
+\section{Customer perspective}
+
+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 their coins by visiting
+merchants without having to authenticate for each transaction.
+
+The wallet is implemented as a cross-platform browser extension. All
+cryptographic operations and access to sensitive data are executed in a
+component that is isolated from websites the user visits.
+
+By necessity, the wallet leaks one bit of information to websites that the user
+visits, namely whether the wallet is installed and activated by the user.
+Websites cannot access the customer's balance or purchase history. This
+however also means that all cryptographic tokens of value are kept locally, and
+the customer is responsible for not losing them. Future versions of the wallet
+will provide encrypted backups and synchronization between the wallets of a
+user.
+
+A common activity for online content is sharing and bookmarking.
+Taler specifically provides support to make this easy for the user.
+A resource that was purchased is identified by a unique \emph{fulfillment URL}
+for each purchase of the resource.
+
+
+\begin{figure*}[h!]
+\begin{center}
+\begin{tikzpicture}[
+ font=\sffamily,
+ every matrix/.style={ampersand replacement=\&,column sep=2cm,row sep=2cm},
+ source/.style={draw,thick,rounded corners,fill=green!20,inner sep=.3cm},
+ process/.style={draw,thick,circle,fill=blue!20},
+ sink/.style={source,fill=green!20},
+ datastore/.style={draw,very thick,shape=datastore,inner sep=.3cm},
+ dots/.style={gray,scale=2},
+ to/.style={->,>=stealth',shorten >=1pt,semithick,font=\sffamily\footnotesize},
+ every node/.style={align=center}]
+
+ % Position the nodes using a matrix layout
+ \matrix{
+ \node[source] (wallet) {Taler Wallet};
+ \& \node[process] (browser) {Browser};
+ \& \node[process] (shop) {Web shop};
+ \& \node[sink] (backend) {Taler backend}; \\
+ };
+
+ % Draw the arrows between the nodes and label them.
+ \draw[to] (browser) to[bend right=50] node[midway,above] {(4) signed contract}
+ node[midway,below] {(signal)} (wallet);
+ \draw[to] (wallet) to[bend right=50] node[midway,above] {(signal)}
+ node[midway,below] {(5) signed coins} (browser);
+ \draw[<->] (browser) -- node[midway,above] {(3,6) custom}
+ node[midway,below] {(HTTP(S))} (shop);
+ \draw[to] (shop) to[bend right=50] node[midway,above] {(HTTP(S))}
+ node[midway,below] {(1) proposed contract / (7) signed coins} (backend);
+ \draw[to] (backend) to[bend right=50] node[midway,above] {(2) signed contract / (8) confirmation}
+ node[midway,below] {(HTTP(S))} (shop);
+\end{tikzpicture}
+\end{center}
+ \caption{Both the customer's client and the merchant's server execute
+ sensitive cryptographic operations in a secured
+ background/backend that is protected against direct access.
+ % THIS SENTENCE DOES NOT MAKE SENSE :
+ Interactions between the Taler components
+ (Figure~\ref{fig:system}) are not shown. Existing system
+ security mechanisms are used to isolate the cryptographic
+ components (boxes) from the complex rendering logic
+ of existing Web applications (circles).}
+ \label{fig:frobearch}
+\end{figure*}
+
+% maybe mention division into two phases (a) contract offer/accept
+% and (b) contract execution/replay
+
+% How far does this allow the merchant
+Should the session state that allows the user to access the content be lost,
+visiting the fulfillment URL will transparently restore the session state by
+transparently replaying the payment with the same digital value tokens from the
+user's wallet. Replaying a contract is only allowed from the domain that the
+contract originated from, and thus does not allow arbitrary websites to obtain
+information about previous purchases that the customer made. Sharing the
+fulfillment URL with a user that did not pay for the associated digital
+contract will result in the expected behavior, namely that they receiving a new
+instance of the digital contract with the opportunity to pay for it.
+
+% idea while writing this: why do we need a correlation id
+% if we already have the url? i.e. the non-fulfillment URL
+% that just identifies the resource ...
+
+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 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,
+it can also be used for more traditional purchases. The resource that
+is being payed for then represents the shopping cart of items that
+are being purchased.
+
+%\newpage
+\section{Merchant perspective}
+
+
+
+%\begin{figure}[b!]
+%\includegraphics[width=0.45\textwidth]{figs/taler-pay.pdf}
+%\caption{Payment processing with Taler.}
+%\label{fig:taler-pay}
+%\end{figure}
+
+
+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
+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
+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,
+again by a protocol that the merchant can customize to fit the
+existing infrastructure.
+
+
+
+Instead of adding any cryptographic logic to the merchant front-end,
+the generic Taler merchant backend allows the implementor to delegate
+handling of the coins to the payment backend, which validates the
+coins, deposits them at the exchange, and finally validates and
+persists the receipt from the exchange. The merchant backend then
+communicates the result of the transaction to the front\-end, which is
+then responsible for executing the business logic to fulfill the
+order.
+As a result of this setup, the cryptographic details of the
+Taler protocol do not have to be re-implemented by each merchant.
+Instead, existing Web shops implemented in a multitude of programming
+languages can rather trivially add support for Taler by {\bf (1)} upon
+request, generating a contract in JSON based on the shopping cart,
+{\bf (2)} allowing the backend to sign the contract before sending it
+to the client, {\bf (7)} passing coins received in payment for a
+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 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.
+
+\section{Conclusion}
+
+We encourage everyone to try our prototype for Taler
+at \url{https://demo.taler.net/}.
+
+% FIX ME : Can we say that a HotPETS discussion would be useful somehow?
+% Like explain that we want input on deployment scenarios.
+
+
+% These APIs are all RESTful in the modern sense because that greatly
+% simplify integrating Taler with web shops and browsers.
+
+\section*{Acknowledgements}
+
+This work benefits from the financial support of the Brittany Region
+(ARED 9178) and a grant from the Renewable Freedom Foundation.
+
+
+\bibliographystyle{abbrv}
+\bibliography{ui,btc,taler,rfc}
+
+\end{document}