From 12a12d883aae49a9dcedc8b487121b9926cff0fa Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sun, 8 May 2016 10:27:04 +0200 Subject: 2-page version --- articles/ui/ui_short.tex | 218 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 218 insertions(+) create mode 100644 articles/ui/ui_short.tex (limited to 'articles') diff --git a/articles/ui/ui_short.tex b/articles/ui/ui_short.tex new file mode 100644 index 000000000..8c30d4027 --- /dev/null +++ b/articles/ui/ui_short.tex @@ -0,0 +1,218 @@ + +\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{eurosym} +\usepackage{listings} +\usepackage{graphicx} +\usepackage{wrapfig} +%\usepackage{caption} +\usepackage{subcaption} +\usepackage{url} + +\usetikzlibrary{shapes,arrows} +\usetikzlibrary{positioning} +\usetikzlibrary{calc} + +\begin{document} +\maketitle + +\section{System overview} + +Transactions on the Internet, such as sending an e-mail or reading a +Web site, tend to be of smaller value than traditional transactions +involving the exchange of physical goods. Thus we are faced with the +challenge of reducing the mental and technical overheads of existing +payment systems to handle micro-payments. Addressing this problem is +urgent: ad-blocking technology is eroding advertising as a substitute +for micro-payments, 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 which provides +anonymity for customers. Here, {\em anonymous} simply means that the +payment system does not require 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~\cite{apod}) to avoid +circumstances leaking information about the customer's identity. The +fact that the user does not need to authenticate and that the merchant +thus never learns sensitive personal information about the customer +improves usability: the payment process is simplified and the +merchant's security requirements are dramatically reduced. + +Taler uses blind signatures~\cite{chaum1983blind} to create digital +coins, and a new ``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 interaction sequences to explain how the system works from the +perspective of customers and merchants in the Taler +system (Figure~\ref{fig:system}). + +\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} + +\newpage +\section{Customer perspective} + +In Taler, customers use a {\em wallet} to withdraw (Figure +~\ref{fig:taler-withdraw}), hold, and spend (Figure~\ref{fig:taler-pay}) +coins. Withdrawing coins requires the customer to authenticate +and to optionally authorize the specific transaction. +Afterwards, the customer can anonymously spend his coins by +visiting merchants without having to authenticate for each +transaction (Figure~\ref{fig:taler-pay}). + +\begin{figure}[h!] +\includegraphics[width=0.45\textwidth]{figs/taler-withdraw.pdf} +\caption{Withdrawing coins with Taler.} +\label{fig:taler-withdraw} +\end{figure} + + +\begin{figure*}[t!] +\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. + 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*} + + +\begin{figure}[b!] +\includegraphics[width=0.45\textwidth]{figs/taler-pay.pdf} +\caption{Payment processing with Taler.} +\label{fig:taler-pay} +\end{figure} + +\newpage +\section{Merchant perspective} + +A new payment system must also be easy to deploy for merchants. +Figure~\ref{fig:frobearch} shows how the secure 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 {\em +background} 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 let it know 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/}. + +% 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. + + +%\newpage + +\bibliographystyle{abbrv} +\bibliography{ui,btc,taler,rfc} + +\end{document} -- cgit v1.2.3