diff options
Diffstat (limited to 'articles/ui/ui_short.tex')
| -rw-r--r-- | articles/ui/ui_short.tex | 268 |
1 files changed, 0 insertions, 268 deletions
diff --git a/articles/ui/ui_short.tex b/articles/ui/ui_short.tex deleted file mode 100644 index f48dd86e4..000000000 --- a/articles/ui/ui_short.tex +++ /dev/null @@ -1,268 +0,0 @@ - -\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} |