333 lines
14 KiB
TeX
333 lines
14 KiB
TeX
|
\documentclass{scrartcl}
|
||
|
|
\usepackage[a4paper]{geometry}
|
||
|
|
\usepackage{hyperref}
|
||
|
|
\usepackage[dvipsnames]{xcolor}
|
||
|
|
\hypersetup{
|
||
|
|
colorlinks = true,
|
||
|
|
allcolors = {black},
|
||
|
|
linkcolor = DarkOrchid,
|
||
|
|
urlcolor = DarkOrchid,
|
||
|
|
}
|
||
|
|
\usepackage{url}
|
||
|
|
\usepackage[font=footnotesize]{caption}
|
||
|
|
\usepackage{amssymb}
|
||
|
|
\usepackage{amsmath}
|
||
|
|
\usepackage{pdfpages}
|
||
|
|
\usepackage{graphicx}
|
||
|
|
\usepackage{listings}
|
||
|
|
\usepackage{fontspec}
|
||
|
|
\setmonofont[Path = ../fonts/,
|
||
|
|
Extension = .ttf,
|
||
|
|
UprightFont = *-Regular,
|
||
|
|
ItalicFont = *-Italic,
|
||
|
|
BoldFont = *-Bold,
|
||
|
|
Scale=0.85]{RobotoMono}
|
||
|
|
|
||
|
|
\lstdefinelanguage{typescript}{
|
||
|
|
keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break, interface},
|
||
|
|
keywordstyle=\bfseries,
|
||
|
|
ndkeywords={class, export, boolean, number, Amount, string, Timestamp, RelativeTime, EddsaPublicKey, BrandtVickreyAuction, BrandtVickreyAuctionMessage, BrandtVickreyAuctionWinner, EddsaSignature, HashCode, throw, implements, import, this, BrandtVickreyReplayOutcome},
|
||
|
|
ndkeywordstyle=\bfseries,
|
||
|
|
identifierstyle=\color{black},
|
||
|
|
sensitive=false,
|
||
|
|
comment=[l]{//},
|
||
|
|
morecomment=[s]{/*}{*/},
|
||
|
|
commentstyle=\itshape,
|
||
|
|
%stringstyle=\color{red},
|
||
|
|
morestring=[b]',
|
||
|
|
morestring=[b]"
|
||
|
|
}
|
||
|
|
|
||
|
|
\lstset{
|
||
|
|
language=typescript,
|
||
|
|
%backgroundcolor=\color{lightgray},
|
||
|
|
extendedchars=true,
|
||
|
|
basicstyle=\footnotesize\color{NavyBlue}\ttfamily,
|
||
|
|
showstringspaces=false,
|
||
|
|
showspaces=false,
|
||
|
|
%numbers=left,
|
||
|
|
%numberstyle=\footnotesize,
|
||
|
|
%numbersep=9pt,
|
||
|
|
tabsize=2,
|
||
|
|
breaklines=true,
|
||
|
|
showtabs=false,
|
||
|
|
captionpos=b,
|
||
|
|
emphstyle=\bfseries
|
||
|
|
}
|
||
|
|
\newcommand{\TODO}[1]{{\color{orange}#1}\marginpar{{\color{orange}TODO}}}
|
||
|
|
|
||
|
|
\begin{document}
|
||
|
|
|
||
|
|
\title{AP³\\
|
||
|
|
Report for Milestone IV\\
|
||
|
|
NGI Pointer}
|
||
|
|
\author{Özgür Kesim\\
|
||
|
|
Christan Grothoff\\
|
||
|
|
Florian Dold\\
|
||
|
|
Stefan Kügel\\
|
||
|
|
Emmanuel Benoist\\[\bigskipamount]
|
||
|
|
\normalsize Mentor: Mirko Ross \href{mailto:m.ross@digital-worx.de}{<m.ross@digital-worx.de>}\\[\medskipamount]
|
||
|
|
}
|
||
|
|
|
||
|
|
\date{October 29, 2022}
|
||
|
|
|
||
|
|
\maketitle
|
||
|
|
|
||
|
|
\section*{Management summary}
|
||
|
|
\begin{abstract}
|
||
|
|
|
||
|
|
For the \textsc{NGI Pointer} programme, the AP³ project team extended GNU Taler with
|
||
|
|
\begin{itemize}
|
||
|
|
\item age-restricted payments,
|
||
|
|
\item peer-to-peer (P2P) payments and
|
||
|
|
\item a proof-of-concept escrow functionality for
|
||
|
|
privacy-preserving auctions.
|
||
|
|
\end{itemize}
|
||
|
|
|
||
|
|
This document provides the report for the final milestone IV with details on
|
||
|
|
the state of the implementation, the results of user experience studies
|
||
|
|
and projected future work.
|
||
|
|
|
||
|
|
\end{abstract}
|
||
|
|
|
||
|
|
\vfill
|
||
|
|
\hfill {\footnotesize Version: 1.0}
|
||
|
|
|
||
|
|
\thispagestyle{empty}
|
||
|
|
|
||
|
|
\newpage
|
||
|
|
\tableofcontents
|
||
|
|
\newpage
|
||
|
|
|
||
|
|
|
||
|
|
\section{Age Restriction}
|
||
|
|
|
||
|
|
\TODO{}
|
||
|
|
\subsection{Technical details}
|
||
|
|
\TODO{}
|
||
|
|
\subsection{Future Works}
|
||
|
|
\TODO{}
|
||
|
|
\subsection{Links}
|
||
|
|
\TODO{}
|
||
|
|
|
||
|
|
|
||
|
|
\newpage
|
||
|
|
\section{P2P Payments}
|
||
|
|
|
||
|
|
We implemented two styles of P2P payments: \textbf{push payments} where a
|
||
|
|
user sends money to another Taler wallet (which can then accept the
|
||
|
|
payment), and \textbf{pull payments} where a user sends an invoice to
|
||
|
|
another Taler wallet (which can then pay the invoice).
|
||
|
|
|
||
|
|
Both styles of payment only require one asynchronous uni-directional
|
||
|
|
secure communication between the wallets to make the payment. The
|
||
|
|
information that is exchanged is in both cases a short \texttt{taler://}-URI
|
||
|
|
which allows the wallet to obtain further details from the payment service
|
||
|
|
provider. These further details include the contract/invoice that the payment
|
||
|
|
is for. The contract/invoice is stored encrypted at the exchange and thus
|
||
|
|
cannot be learned by the exchange.
|
||
|
|
|
||
|
|
The actual P2P payment works by having the initiator wallet first
|
||
|
|
communicate with the Taler exchange to setup the payment. Then the
|
||
|
|
Taler URI is communicated to the other wallet, for now usually via
|
||
|
|
QR code or NFC transmission; however, users could also copy the URI
|
||
|
|
to the clipboard and exchange it via some (secure) messenger. Upon
|
||
|
|
receiving the URI, the other wallet then again interacts with the
|
||
|
|
exchange to obtain more details and complete the payment.
|
||
|
|
|
||
|
|
If the recipient of a push payment does not accept the payment
|
||
|
|
(say because the message was lost in transmission, or they do not
|
||
|
|
like the attached contract terms) the money is automatically refunded
|
||
|
|
to the payer after some expiration date is reached.
|
||
|
|
|
||
|
|
\subsection{Technical details}
|
||
|
|
|
||
|
|
P2P payments always work by establishing a \textbf{purse} at the
|
||
|
|
exchange. A purse has an expiration date, target amount, minimum age,
|
||
|
|
associated business contract (or invoice), an actual balance and two
|
||
|
|
public-private key pairs representing permissions to operate on the
|
||
|
|
purse. For a push payment, the wallet of the sending user creates a
|
||
|
|
purse (with contract and expiration time) and immediately ensures that
|
||
|
|
the balance of the purse is the target amount. The payer then sends
|
||
|
|
the merge-capability key of the purse to the payee. The payee can
|
||
|
|
then use the merge-capability key to merge (move) the balance of the
|
||
|
|
purse into a KYCed (i.e. know-your-customer ready) reserve of the receiving
|
||
|
|
wallet. A KYCed reserve basically is a long-term public-private key pair that
|
||
|
|
identifies a wallet and a user at an exchange, ensuring income transparency.
|
||
|
|
Once the money is in the reserve, the wallet can then use the reserve private
|
||
|
|
key to withdraw fresh coins.
|
||
|
|
|
||
|
|
When invoicing, the initiator again creates a purse, but this time
|
||
|
|
does not put any money into it and keeps the merge capability key
|
||
|
|
private. The initiator wallet instead immediately specifies its own
|
||
|
|
KYCed reserve as the one the purse should be merged into. The
|
||
|
|
initiator then shares a contract-download capability key with the
|
||
|
|
payer. The payer downloads the contract (including the purse public
|
||
|
|
key) and can then decide to put money into the purse. Once the purse
|
||
|
|
balance reaches the target amount, it is then automatically merged
|
||
|
|
with the initiator's reserve. The initiator's wallet (long) polls the
|
||
|
|
reserve and withdraws the funds as soon as they become available.
|
||
|
|
|
||
|
|
The protocol and implementation includes a few refinements, like fees
|
||
|
|
to be paid to the exchange for managing a purse and age-restrictions
|
||
|
|
on the coins used to pay an invoice.
|
||
|
|
|
||
|
|
\subsection{Future Work}
|
||
|
|
|
||
|
|
The following features (from tiny to major) have been discussed in
|
||
|
|
the team and ought to be implemented as part of future work.
|
||
|
|
|
||
|
|
\begin{itemize}
|
||
|
|
\item \textbf{Wallets:} The wallet UIs currently do not allow the user to actually specify
|
||
|
|
any age-restrictions on the payer when sending P2P pull payment requests
|
||
|
|
(invoicing). This mostly is about adding one more drop-down widget.
|
||
|
|
\item \textbf{Wallets:} The wallet UIs currently do not allow the user to actually specify
|
||
|
|
the expiration date for the purse. Instead, the duration is hard-coded
|
||
|
|
to a few hours (likely too short). This mostly is about adding one more
|
||
|
|
input field.
|
||
|
|
\item \textbf{Auditor:} The Taler auditor was extended to support P2P transactions in
|
||
|
|
its audits, but the code has not been adequately tested (no
|
||
|
|
fault injection).
|
||
|
|
\item \textbf{Exchange:} P2P payments currently only work if both wallets are using the
|
||
|
|
same exchange. If multiple exchanges operate in the same currency
|
||
|
|
domain and the recipient has made their (expensive) KYC process
|
||
|
|
at one exchange and the payer has withdrawn from the other, a
|
||
|
|
direct payment between the wallets is not possible right now. We
|
||
|
|
envision federation protocol using periodic aggregated
|
||
|
|
(``wad'') payments between exchanges should be added to support
|
||
|
|
P2P payments involing multiple exchanges in the future.
|
||
|
|
\item \textbf{Mailbox (NEW):} Currently, sending the payment URI is largely left to the user.
|
||
|
|
We would like to implement a ``mailbox'' service for Taler wallets
|
||
|
|
that would enable wallets to asynchronously exchange URIs over the
|
||
|
|
Internet. Once a wallet knows the mailbox address of another wallet
|
||
|
|
(which would include a public key to encrypt messages to), the user
|
||
|
|
would no longer be required to manually exchange the QR code.
|
||
|
|
\item \textbf{TalDir (NEW):} To lookup the mailbox address of another wallet, we would like
|
||
|
|
to implement a directory service that maps existing addresses like
|
||
|
|
e-mail addresses, phone numbers or accounts in messengers or social
|
||
|
|
media platforms to a mailbox. When establishing the directory service
|
||
|
|
entry, the directory service would validate that the user registering
|
||
|
|
the wallet has control over the respective address. Naturally, the
|
||
|
|
directory service would need to be trusted to return the correct
|
||
|
|
mapping.
|
||
|
|
\item Both the mailbox and the directory service operators could
|
||
|
|
themselves be paid via Taler for their service. That should help
|
||
|
|
ensure a high quality of service from those operators. Naturally,
|
||
|
|
using the mailbox or the directory service would be optional.
|
||
|
|
\item \textbf{Messaging:} In the long term, we would like to see more direct integration
|
||
|
|
of Taler payment functionality with messaging applications, especially
|
||
|
|
for spam prevention (``The recipient has configured its software to
|
||
|
|
demand a payment of 50 cents before displaying a message from an unknown
|
||
|
|
sender to the user. If they like your message, they promise they would
|
||
|
|
refund this attention fee. Do you want to pay to have your message
|
||
|
|
shown? (Y/N)'').
|
||
|
|
\end{itemize}
|
||
|
|
|
||
|
|
|
||
|
|
\subsection{Links}
|
||
|
|
|
||
|
|
\href{https://docs.taler.net/design-documents/013-peer-to-peer-payments.html}{Document
|
||
|
|
013} at \url{https://docs.taler.net/design-documents/} presents the design.
|
||
|
|
The main implementation parts for P2P are distributed over various code
|
||
|
|
locations under \url{https://git.taler.net/wallet-core.git/tree/packages/}
|
||
|
|
(wallet) and \url{https://git.taler.net/exchange.git/tree/src/exchange/}
|
||
|
|
(exchange):
|
||
|
|
\begin{description}
|
||
|
|
\item[Payment operations:] \href{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/operations/pay-peer.ts}{taler-wallet-core/src/operations/pay-peer.ts}
|
||
|
|
\item[Database schema related:] \href{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/db.ts#n2065}{taler-wallet-core/src/db.ts}
|
||
|
|
\item[Transaction list type declarations:] \href{https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/transactions-types.ts#n251}{taler-util/src/transactions-types.ts}
|
||
|
|
\item[WebExtension UI:] \href{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-webextension/src/cta/InvoiceCreate}{taler-wallet-webextension/src/cta/InvoiceCreate} and \href{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-webextension/src/cta/InvoicePay}{InvoicePay}
|
||
|
|
\item[Exchange] \url{https://git.taler.net/exchange.git/tree/src/exchange/},
|
||
|
|
specifically:\\
|
||
|
|
\texttt{taler-exchange-httpd\_purses\_*.c}, \texttt{taler-exchange-httpd\_reserves\_purse\_*.c},
|
||
|
|
\texttt{taler-exchange-httpd\_contract.*},
|
||
|
|
\texttt{taler-exchange-expire.c} (plus related changes in the database, client libraries, history, auditor),
|
||
|
|
and the main test case at
|
||
|
|
\href{https://git.taler.net/exchange.git/tree/src/testing/test\_exchange\_p2p.c}{testing/test\_exchange\_p2p.c}
|
||
|
|
\end{description}
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
\newpage
|
||
|
|
\section{Brandt-Vickrey Auctions}
|
||
|
|
|
||
|
|
\TODO{}
|
||
|
|
\subsection{Technical details}
|
||
|
|
\TODO{}
|
||
|
|
\subsection{Future Works}
|
||
|
|
\TODO{}
|
||
|
|
\subsection{Links}
|
||
|
|
\TODO{}
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
\newpage
|
||
|
|
\section{User Experience Studies}
|
||
|
|
|
||
|
|
For the \textsc{NGI Pointer} programme, the AP³ project team performed a
|
||
|
|
usability study to gather feedback and inform further development of the
|
||
|
|
age-restricted and P2P payment functionalities.
|
||
|
|
|
||
|
|
The BFH ``Digitaltag'' is an annual day-long event where the
|
||
|
|
university presents itself to the public. It is held right next to the
|
||
|
|
central train station of Biel/Bienne, and is open to the general
|
||
|
|
public. It was attended by a mixture of prospective students, normal
|
||
|
|
adults, Swiss executives and retirees.
|
||
|
|
|
||
|
|
We used the opportunity to both present GNU Taler to the public, and
|
||
|
|
to conduct usability studies with interested volunteers.
|
||
|
|
|
||
|
|
\begin{figure}[h!]
|
||
|
|
\includegraphics[width=\textwidth]{pics/digitaltag-ux-setup.jpg}
|
||
|
|
\caption{Our booth, with GNU Taler publications (including on
|
||
|
|
age-restrictions), NGI stickers, and a Taler-enabled coffee machine.}
|
||
|
|
\end{figure}
|
||
|
|
|
||
|
|
|
||
|
|
\subsection{Preparation}
|
||
|
|
|
||
|
|
We prepared several notebooks with a browser running a Taler wallet as
|
||
|
|
well as several Android phones with the Taler Android wallet. We
|
||
|
|
set up the coffee machine and three Taler backends, one for CHF (used
|
||
|
|
by the coffee machine), one for KUDOS (used with age-restrictions in
|
||
|
|
the browser-based setup) and one for Bitcoin (used for P2P payments).
|
||
|
|
We also prepared a rough write-up describing what we would like users
|
||
|
|
to do. These intended user stories are included in the appendix. We
|
||
|
|
note that during the day, we permitted participants to deviate from
|
||
|
|
the script if they desired to do so, sometimes leading them to explore
|
||
|
|
other GNU Taler features (and us learning interesting lessons about
|
||
|
|
those).
|
||
|
|
|
||
|
|
For the UX study, we prepared four tables: two tables with the coffee
|
||
|
|
machine and information materials, and two tables with additional
|
||
|
|
chairs for guests for the actual UX experiment.
|
||
|
|
|
||
|
|
\begin{figure}[h!]
|
||
|
|
\includegraphics[width=\textwidth]{pics/digitaltag-ux-chairs.jpg}
|
||
|
|
\caption{Tables for the UX study with Prof. Benoist.}
|
||
|
|
\end{figure}
|
||
|
|
|
||
|
|
\subsection{Data collection}
|
||
|
|
|
||
|
|
We did not collect any PII on the participants.\footnote{Except for
|
||
|
|
one executive who had come just for our booth from Zug and who gave us
|
||
|
|
his business card as he hopes to collaborate with us in the future.}
|
||
|
|
Instead, each team member wrote down their observations. We
|
||
|
|
afterwards de-duplicated the observations and turned those that could
|
||
|
|
lead to improvements into over 20 new issues on the GNU Taler
|
||
|
|
bug-tracker (\#7334--\#7354).
|
||
|
|
|
||
|
|
\subsection{Key conclusions}
|
||
|
|
|
||
|
|
The day revealed the existence of several previously unknown bugs
|
||
|
|
(like refresh not working properly with the new features) as well
|
||
|
|
as quite a few surprising difficulties of users (not finding the
|
||
|
|
QR code button, not finding the account balance, not understanding
|
||
|
|
that the \texttt{shop.demo.taler.net} page is the shop where they should buy
|
||
|
|
things). We will try to rectify those as soon as possible.
|
||
|
|
|
||
|
|
|
||
|
|
\end{document}
|