2022-10-29 20:12:16 +02:00
\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}
2022-10-29 23:51:01 +02:00
\usepackage { tikz}
\usetikzlibrary { tikzmark}
\usetikzlibrary { shapes,arrows,arrows.meta}
\usetikzlibrary { positioning,patterns}
\usetikzlibrary { calc}
2022-10-29 20:12:16 +02:00
\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} } }
2022-10-29 23:51:01 +02:00
\include { definitions}
2022-10-29 20:12:16 +02:00
\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}
2022-10-29 23:51:01 +02:00
\noindent
For the \textsc { NGI Pointer} programme, the AP³ project team extended GNU Taler with
2022-10-29 20:12:16 +02:00
\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
2022-10-29 23:51:01 +02:00
the results of our usability study, the state of the implementation of
the features and projected future work.
2022-10-29 20:12:16 +02:00
\end { abstract}
\vfill
\hfill { \footnotesize Version: 1.0}
\thispagestyle { empty}
\newpage
\tableofcontents
\newpage
\section { Age Restriction}
2022-10-29 23:51:01 +02:00
We designed and implemented a scheme for age restriction in GNU Taler based on
the following basic ideas:
Parents/warden can choose to \textbf { commit} a certain maximum age out of a
predefined list of age groups and bind that commitment to a particular coin.
The minors receive those coins and can now \textbf { attest} a required minimum
age (provided that age is less or equal to the committed age of the coins) to
merchants, who can \textbf { verify} the minimum age. For the rest values
(change) after an transaction, the minor/ward can \textbf { derive} new
age-restricted coins. The exchange can \textbf { compare} the equality of the
age-restriction of the old coin with the new coin (in a zero-knowledge
protocol $ \DeriveCompare $ , that gives the minor a 1/$ \kappa $ chance to raise
the minimum age for the new coin).
The following figure gives an overview of the scheme for age restriction
detached from the payment flow:
\begin { figure} [h]
\begin { center} \footnotesize
\begin { tikzpicture} [scale=.8]
\node [circle,minimum size=25pt,fill=black!15] at ( 0:0) (Client) { $ \Child $ } ;
\node [circle,minimum size=25pt,fill=black!15] at ( 60:5) (Exchange) { $ \Exchange $ } ;
\node [circle,minimum size=25pt,fill=black!15] at ( 0:5) (Merchant) { $ \Merchant $ } ;
\node [circle,minimum size=25pt,fill=blue!15] at (130:3) (Guardian) { $ \Guardian $ } ;
\draw [orange,<->] (Client) to node[sloped,below,align=center]
{ \orange { $ \DeriveCompare $ } } (Exchange);
\draw [blue,->] (Client) to node[sloped, below]
{ \blue { $ ( \attest _ \minage , \commitment ) $ } } (Merchant);
\draw [->] (Guardian) to [out=150,in=70, loop] node[above]
{ $ \Commit ( \age ) $ } (Guardian);
\draw [->] (Guardian) to node[below,sloped]
{ ($ \commitment $ , $ \pruf _ \age $ )} (Client);
\draw [->,blue] (Client) to [out=-50,in=-130, loop] node[below]
{ \blue { $ \Attest ( \minage , \commitment , \pruf _ { \age } ) $ } } (Client);
\draw [->,blue] (Merchant) to [out=-50,in=-130, loop] node[below]
{ \blue { $ \Verify ( \minage , \commitment , \attest _ { \minage } ) $ } } (Merchant);
\end { tikzpicture}
\end { center}
\caption { Scheme of the age restriction performed between a guardian
$ \Guardian $ , a child $ \Child $ , a merchant $ \Merchant $ and an exchange
$ \Exchange $ , using the functions $ \Commit $ , $ \Attest $ , $ \Verify $ and
the zero-knowledge protocol $ \DeriveCompare $ which is based on
functions $ \Derive $ and $ \Compare $ . $ \commitment $ is the age
commitment for a maximum age $ \age \in \{ 1 ,..., \Age \} $ and
$ \pruf _ { \age } $ is the corresponding proof. $ \attest _ { \minage } $ is an
attestation of a required age $ \minage \leq \age $ .}
\end { figure}
2022-10-29 20:12:16 +02:00
\subsection { Technical details}
2022-10-29 23:51:01 +02:00
Our implementation of the five functions $ \Commit $ , $ \Attest $ , $ \Verify $ ,
$ \Derive $ and $ \Compare $ is based on the following main building blocks:
\begin { itemize}
\item The exchange $ \Exchange $ defines and publishes M+1 different
\textit { age groups} of increasing order: $ 0 < a _ 1 < \ldots <
a_ M$ with $ a_ i \in \mathbb { N} $ . The zeroth age group is
$ \{ 0 , \ldots ,a _ 1 - 1 \} $ .
\item An \textit { unrestricted} age commitment is defined as a vector of
length $ \Age $ of pairs of
\href { https://docs.taler.net/design-documents/024-age-restriction.html#edx25519} { Edx25519}
public and private keys on Curve25519. In other words: one key
pair for each age group after the zeroth: $ \bigl \langle ( p _ 1 ,
q_ 1), \ldots , (p_ M, q_ M) \bigr \rangle $ . ( Here, $ p_ i$ are
\textit { private} and $ q _ i $ are public keys).
\item A \textit { restricted} age commitment to age group m (or m-th age
group) is derived from an unrestricted age commitment by
removing all private keys for indices larger than m:
\[
\bigl \langle (p_ 1, q_ 1), \ldots , (p_ m, q_ m),
\, (\perp , q_ { m+1} ),
\ldots , (\perp , q_ M)\bigr \rangle
\] F.e. if none of the private keys is provided, the age
commitment would be restricted to the zeroth age group. Note
that the action of dropping private keys is performed by the
guardian $ \Guardian $ .
\item An \textit { age commitment} (without prefix) is just the vector of
public keys: $ \commitment : = \langle q _ 1 , \ldots , q _ M \rangle $ .
Note that from just the age commitment one can not deduce if it
was originated from an unrestricted or restricted age
commitment (and what age).
\item A child $ \Child $ receives the commitment $ \commitment $ along with
the proof, the restricted vector\\
$ \pruf _ \age : = ( p _ 1 , \ldots ,p _ \age , \perp , \ldots , \perp ) $ .
The child can now create an \textit { attestation}
$ \attest _ \minage $ for age group $ \minage \leq \age $ , which is
simply a signature to some message with the private key
$ p _ \minage $ .
\item An age commitment $ \commitment $ is bound to a particular coin
$ C _ p $ by incorporating the SHA256 hash value of $ \commitment $
into the signature of the coin. So, instead of signing the
full-domain-hash $ \text { FDH } ( C _ p ) $ with the RSA private key of
a denomination, the exchange signs $ \text { FDH } ( C _ p,
\orange { H(\commitment )} )$ .
\end { itemize}
The schemes for age restriction and the scheme for payment in GNU Taler
(protocols \textsf { withdraw} , \textsf { purchase} , \textsf { deposit} and
\textsf { refresh} ) are integrated as sketched in the following figure:
\begin { figure} [h]
\begin { center} \footnotesize
\begin { tikzpicture} [scale=.8]
\node [circle,minimum size=25pt,fill=black!15] at ( 0:0) (Client) { $ \Child $ } ;
\node [circle,minimum size=25pt,fill=black!15] at ( 60:5) (Exchange) { $ \Exchange $ } ;
\node [circle,minimum size=25pt,fill=black!15] at ( 0:5) (Merchant) { $ \Merchant $ } ;
\node [circle,minimum size=25pt,fill=blue!15] at (130:3) (Guardian) { $ \Guardian $ } ;
\draw [<->] (Guardian) to node[sloped,above,align=center]
{ \textsf { withdraw} \orange { , using} \\ $ \FDH ( C _ p \orange { , H ( \commitment ) } ) $ } (Exchange);
\draw [<->] (Client) to node[sloped,below,align=center]
{ \textsf { refresh} \orange { + } \\ \orange { $ \DeriveCompare $ } } (Exchange);
\draw [<->] (Client) to node[sloped, below]
{ \textsf { purchase} \blue { + $ ( \attest _ \minage , \commitment ) $ } } (Merchant);
\draw [<->] (Merchant) to node[sloped, above]
{ \textsf { deposit} \orange { + $ H ( \commitment ) $ } } (Exchange);
\draw [->] (Guardian) to [out=70,in=150, loop] node[above]
{ $ \Commit ( \age ) $ } (Guardian);
\draw [->] (Guardian) to node[below,sloped]
{ ($ \commitment $ , $ \pruf _ \age $ )} (Client);
\draw [->,blue] (Client) to [out=-50,in=-130, loop] node[below]
{ \blue { $ \Attest ( \minage , \commitment , \pruf _ { \age } ) $ } } (Client);
\draw [->,blue] (Merchant) to [out=-50,in=-130, loop] node[below]
{ \blue { $ \Verify ( \minage , \commitment , \attest _ { \minage } ) $ } } (Merchant);
\end { tikzpicture}
\end { center}
\caption { Sketch of the integration of the schemes for age restriction
and payment in GNU Taler.}
\end { figure}
\filbreak
The cut-and-choose protocol $ \DeriveCompare $ is defined roughly as follows:
\begin { center}
\parbox { 0.75\textwidth } {
\begin { enumerate}
\item $ \Child $ derives commitments $ ( \commitment _ 1 , \dots , \commitment _ \kappa ) $
from $ \commitment _ 0 $ \\
by calling $ \Derive ( ) $ with blindings $ ( \beta _ 1 , \dots , \beta _ \kappa ) $
\item $ \Child $ calculates $ h _ 0 : = H \left ( H ( \commitment _ 1 , \beta _ 1 ) || \dots ||H ( \commitment _ \kappa , \beta _ \kappa ) \right ) $
\item $ \Child $ sends $ \commitment _ 0 $ and $ h _ 0 $ to $ \Exchange $
\item $ \Exchange $ chooses $ \gamma \in \{ 1 , \dots , \kappa \} $ randomly
\item $ \Child $ reveals $ h _ \gamma : = H ( \commitment _ \gamma , \beta _ \gamma ) $ and all $ ( \commitment _ i, \beta _ i ) $ , except $ ( \commitment _ \gamma , \beta _ \gamma ) $
\item $ \Exchange $ compares $ h _ 0 $ and
$ H \left ( H ( \commitment _ 1 , \beta _ 1 ) ||...||h _ \gamma ||...||H ( \commitment _ \kappa , \beta _ \kappa ) \right ) $ \\
and evaluates $ \Compare ( \commitment _ 0 , \commitment _ i, \beta _ i ) $ .
\end { enumerate} }
\end { center}
The proposed solution maintains the guarantees of GNU Taler with respect to
anonymity and unlinkability. Precise formulations of the functions, protocols,
requirements and security guarantees---together with proofs---can be found in
our paper
\href { https://taler.net/papers/esorics2022-age-restriction.pdf}
{ \textit { Zero-Knowledge Age Restriction for GNU Taler} } ,
published in the
\href { https://link.springer.com/chapter/10.1007/978-3-031-17140-6\_ 6}
{ proceedings to ESORICS 2022} .
2022-10-29 20:12:16 +02:00
\subsection { Future Works}
2022-10-29 23:51:01 +02:00
\begin { description}
\item [Complete support for all GNU Taler protocols:] So far, age restriction is
only implemented for the GNU Taler protocols \textsf { withdraw} ,
\textsf { purchase} , \textsf { deposit} and \textsf { refresh} . We
will extend the support for age restriction in GNU Taler to
include the protocols for P2P payments, tipping and refund.
\item [Support for minors with bank accounts:] The current design
of age restriction is based on the assumption that only
adults can have bank accounts. That is: wire transfers to the
exchange are assumed to be originated by adults.
However, in some countries, like Germany, it is possible for
minors to have bank accounts, too, starting from a certain age.
In those cases, the wire transfer record will indicate that the
originating account is owned by a minor.
We plan to extend the current design and implementation of age
restriction to handle those situations as well: After the
exchange receives a wire transfer from a bank account of a
minor, it will require in a zero-knowledge-proof for a) the
presence of age restriction and b) the appropriate
\textit { maximum} age for the age commitment during the
\textsf { withdraw} protocol.
\item [Legal certification of our age restriction scheme:] We are in
correspondence with the
\href { https://www.kjm-online.de/en/} { German Commission for the
Protections of Minors in the Media (KJM)} which evaluates and
recommends concepts for protection of minors. GNU Taler has
been recognized as a potential candidate in the so-called
``cross-channel concepts for the protection of minors''.
We will prepare a white paper about GNU Taler's age restriction
as input for the commission's next meeting on December 7, 2022,
in Berlin. Our goal is to convince the commission of GNU
Taler's age restriction scheme as a legally acceptable form of
age verification and add it to its list of
\href { https://www.kjm-online.de/aufsicht/technischer-jugendmedienschutz/uebergreifende-konzepte} %
{ positively evaluated concepts} .
\end { description}
2022-10-29 20:12:16 +02:00
\subsection { Links}
2022-10-29 23:51:01 +02:00
Our scheme for age restriction in GNU Taler has been
\href { https://link.springer.com/chapter/10.1007/978-3-031-17140-6\_ 6} { published
in the proceedings to ESORICS 2022} .
In addition,
\href { https://docs.taler.net/design-documents/024-age-restriction.html} %
{ document 24} at \url { https://docs.taler.net/design-documents} also lays out
the design. The implementation is distributed across multiple repositories:
{ \small
\begin { description}
\item [Exchange:] The following REST endpoint handlers and their
accompanying helper functions in
\url { https://git.taler.net/exchange.git/tree/src} :
\begin { itemize}
\item \href { https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_ deposit.c} { \texttt { TEH\_ handler\_ deposit} }
\item \href { https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_ melt.c} { \texttt { TEH\_ handler\_ melt} }
\item \href { https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_ refreshes_ reveal.c} { \texttt { TEH\_ handler\_ reveal} }
\item \href { https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_ recoup.c} { \texttt { TEH\_ handler\_ recoup} }
\item \href { https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_ recoup-refresh.c} { \texttt { TEH\_ handler\_ recoup\_ refresh} }
\end { itemize}
Under \url { https://git.taler.net/exchange.git/tree/src/exchangedb} :\\
\href { https://git.taler.net/exchange.git/tree/src/exchangedb/common.sql} { common.sql} ,
\href { https://git.taler.net/exchange.git/tree/src/exchangedb/exchange-0001.sql} { exchange-0001.sql} ,
\href { https://git.taler.net/exchange.git/tree/src/exchangedb/plugin\_ exchangedb\_ postgres.c} { plugin\_ exchangedb\_ postgres.c} .
\item [Merchant:]
Under \url { https://git.taler.net/merchant.git/tree/src/} ,
\begin { itemize}
\item schema changes in
\href { https://git.taler.net/merchant.git/tree/src/backenddb/merchant-0001.sql} { backenddb/merchant-0001.sql} and\\
\href { https://git.taler.net/merchant.git/tree/src/backenddb/plugin_ merchantdb_ postgres.c} { backenddb/plugin\_ merchantdb\_ postgres.c}
\item functions \verb |process_ pay_ with_ exchange| and \verb |parse_ pay| in\\
\href { https://git.taler.net/merchant.git/tree/src/backend/taler-merchant-httpd_ post-orders-ID-pay.c} { backend/taler-merchant-httpd\_ post-orders-ID-pay.c}
\end { itemize}
\item [Wallet:]
Under \url { https://git.taler.net/wallet-core.git/tree/packages/taler-util}
\begin { itemize}
\item low-level cryptographic primitives in
\href { https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/nacl-fast.ts} { \texttt { crypto\_ edx25519} } and
\href { https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/talerCrypto.ts#n851} { namespace \texttt { Edx25519} }
\item high-level cryptographic primitives in
\href { https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/talerCrypto.ts#n966} { namespace \texttt { AgeRestrictions} }
\item API changes to wallet-core RPC API in
\href { https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/walletTypes.ts} { \texttt { restrictAge} }
\end { itemize}
Under \url { https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/}
\begin { itemize}
\item withdrawal and refresh primitives in \href { https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/crypto/cryptoImplementation.ts} { \texttt { crypto/cryptoImplementation.ts} }
\item wallet database requests and HTTP requests in \\
\href { https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/db.ts} { \texttt { db.ts} } ,
\href { https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/operations/withdraw.ts} { \texttt { withdraw.ts} } and
\href { https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/operations/refresh.ts} { \texttt { refresh.ts} }
\item coin/denomination selection in
\href { https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/util/coinSelection.ts} { \texttt { util/coinSelection.ts} }
\end { itemize}
\item [Tests:] Under \url { https://git.taler.net/exchange.git/tree/src} :
\begin { itemize}
\item \href { https://git.taler.net/exchange.git/tree/src/util/test\_ crypto.c} { util/test\_ crypto.c}
\item \href { https://git.taler.net/exchange.git/tree/src/util/test\_ age\_ restriction.c} { util/test\_ age\_ restriction.c}
\item \href { https://git.taler.net/exchange.git/tree/src/util/tv\_ age\_ restriction.c} { util/tv\_ age\_ restriction.c}
\item \href { https://git.taler.net/exchange.git/tree/src/testing/test\_ exchange\_ api.c} { testing/test\_ exchange\_ api.c}
\end { itemize}
\end { description}
The definition of Edx25519, a variant of EdDSA that we designed for usage in
our age restriction scheme in GNU Taler, and its implementation is located at
\url { https://git.gnunet.org/gnunet.git/} in file
\href { https://git.gnunet.org/gnunet.git/tree/src/util/crypto\_ edx25519.c} { util/crypto\_ edx25519.c} .
}
2022-10-29 20:12:16 +02:00
\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
2022-10-29 23:51:01 +02:00
\section { Usability Study}
2022-10-29 20:12:16 +02:00
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!]
2022-10-29 20:19:08 +02:00
\includegraphics [width=\textwidth] { pics/b.jpg}
2022-10-29 20:12:16 +02:00
\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!]
2022-10-29 20:19:08 +02:00
\includegraphics [width=\textwidth] { pics/a.jpg}
2022-10-29 20:12:16 +02:00
\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}
