commit 35b6b54f5610ff5054e2e3421a6ee8c97256f2d3
parent 2c81cc5e33a9c58ab2131d76c6169b4930175231
Author: Joel-Haeberli <haebu@rubigen.ch>
Date: Wed, 22 May 2024 10:53:28 +0200
poster: enhance text
Diffstat:
2 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/poster/cashless2ecash_poster.pdf b/poster/cashless2ecash_poster.pdf
Binary files differ.
diff --git a/poster/cashless2ecash_poster.tex b/poster/cashless2ecash_poster.tex
@@ -9,7 +9,7 @@
\begin{document}
- \title{Making GNU Taler accessible}
+ \title{Cashless to e-Cash}
\author{Joel Häberli\inst{*}\thanks{habej2@bfh.ch}}
\institute{Berner Fachhochschule, Departement Technik und Informatik, \inst{*}Institute for Cybersecurity and Engineering ICE}
%% \inst kann in den Autor und Institutsfeldern genutzt werden um eine Zuordnung zu ermöglichen. Bei Nummerierung ist der Nutzer dafür verantwortlich Konflikte mit \thanks zu vermeiden.
@@ -31,11 +31,11 @@
\begin{posterboxenv}[title=Motivation]{name=intro,column=1,row=1,span=2,rowspan=2}
- This thesis realizes a framework to enable withdrawal of digital cash for GNU Taler through a trusted third party. This addresses a report commissioned by the European Central Bank (ECB), which identified the universal acceptance as one of the most important aspects of a digital euro. This will therefore lead to better acceptance of GNU Taler by better integrating its ecosystem into the existing systems.
+ This thesis realizes a framework to enable withdrawal of digital cash for GNU Taler through a trusted third party. This addresses a report commissioned by the European Central Bank (ECB), which identified an easy onboarding as one of the most important aspects of a Digital Euro. This will lead to better acceptance of GNU Taler by better integrating its ecosystem into the existing systems.
- Therefore the new cashless-to-ecash (C2EC) component establishes a trustworthy relationship, which makes it possible for the Exchange to issue digital cash to a customer. Therefore the Exchange is not putting his trust on cash received but rather on the promise of a trusted third party (a terminal provider) to put the received money in a location, controlled by the Exchange eventually (e.g. a bank account owned by the Exchange).
+ The new cashless-to-ecash (C2EC) component builds on a trustworthy relationship with an established provider. This enables the Customer to withdraw digital cash to a customer. C2EC implements the UX needed to enable a secure and convenient withdrawal. The trust lies on the final transaction at the provider. The provider must guarantee this finality to C2EC. Otherwise the withdrawal won't be possible. Like this the liability is always on the provider and never on the Exchange. The flow will probably lead to fees which the provider wants to cover, the framework considers fees as optional part of the withdrawal process.
- This enables a broader group of people to leverage Taler for their payments. Which eventually leads to a wider adoption of the payment system Taler.
+ This enables a broader group of people to leverage Taler for their payments. Eventually this helps the payment system Taler to be taken up faster by the society.
\end{posterboxenv}
@@ -45,28 +45,34 @@
\end{posterboxenv}
- \begin{posterboxenv}[title=Terminals API]{name=api,column=2,row=3,span=3}
+ \begin{posterboxenv}[title=Terminals API design requirements]{name=api,column=2,row=3,span=3}
+
To allow the withdrawal of digital cash using Taler, the newly introduced Terminals API must be implemented. The Terminals API is responsible to setup a withdrawal operation identifier and to cover the needs of a terminal, concerning the withdrawal process:
\begin{enumerate}
- \item Setup withdrawal
- \item Trigger Exchange side confirmation of the transaction (attestation)
- \item Abort the withdrawal (if needed)
+ \item Setup withdrawal process and Taler wallet withdrawal operation
+ \item Seek a secure confirmation of the payment at the provider's backend
+ \item Confirm or abort the withdrawal
\end{enumerate}
\end{posterboxenv}
\begin{posterboxenv}{name=taler-news,column=1,row=3,span=1, rowspan=1}
+ Link to bachelor thesis and
+ further material (QR-Code):
+
+ https://taler.net/en/news/2024-08.html
+
\includegraphics[width=\linewidth]{taler_news_terminals_api.png}
- \captionof{figure}{GNU Taler announcement of C2EC (further reading)}
\end{posterboxenv}
- \begin{posterboxenv}[title=Implementing PayDroid POS Terminal App (Wallee A50)]{name=wallee, column=2, row=4, span=3, span=3}
- To show that the specification is able to capture the needs for third party withdrawals and therefore allow the integration for theoretically any means of payment, an integration was done for the payment provider Wallee. Therefore an android app was implemented on the Wallee platform. The newly created withdrawal application sets up the withdrawal and awaits the registration of the withdrawal parameters (the reserve public key) through the Taler Wallet. After the parameters were registered, the terminal authorizes the payment by letting the customer present his credit card, which will trigger the attestation of the payment at the provider backend through the C2EC component.
+ \begin{posterboxenv}[title=PayDroid POS Terminal App (Wallee A50)]{name=wallee, column=2, row=4, span=3, span=3}
+
+ To show that the specification is able to capture the needs for third party withdrawals and allow the integration for theoretically any means of payment, an integration was done for the payment provider Wallee. The Android app was implemented on the Wallee platform. The newly created withdrawal application sets up the withdrawal and awaits the registration at the Terminals API by the Taler wallet. Once the wallet registered itself, the terminal authorizes the payment by letting the customer present their credit card. This triggers the confirmation of the payment at the provider backend through the C2EC backend. Upon the confirmation, the Exchange allows the withdrawal of the digtial cash.
\end{posterboxenv}
-
+
\begin{posterboxenv}[title=Enter Amount]{name=flow-diagram,column=1,row=5,span=1, rowspan=1}
\includegraphics[width=\linewidth]{enter_amount.jpg}
@@ -74,7 +80,7 @@
\end{posterboxenv}
- \begin{posterboxenv}[title=Register Parameters]{name=flow-diagram,column=2,row=5,span=1, rowspan=1}
+ \begin{posterboxenv}[title=Use Taler Wallet]{name=flow-diagram,column=2,row=5,span=1, rowspan=1}
\includegraphics[width=\linewidth]{register_param.jpg}
@@ -87,14 +93,14 @@
\end{posterboxenv}
- \begin{posterboxenv}[title=Withdrawal Summary]{name=flow-diagram,column=4,row=5,span=1, rowspan=1}
+ \begin{posterboxenv}[title=View Summary]{name=flow-diagram,column=4,row=5,span=1, rowspan=1}
\includegraphics[width=\linewidth]{summary.jpg}
\end{posterboxenv}
\begin{posterboxenv}[title=Integrate your platform!]{name=Integrate your platform, column=1,row=7,span=4,rowspan=1}
- C2EC is designed to be extensible. Therefore the component defines two interfaces which must be implemented in order to make use of the C2EC components. The first interface defines the interface between the transaction of the provider and the C2EC components. This includes the definition of the transaction state mapping between the provider specific states and the states defined by the Taler API. This step is crucial since, when implemented wrong, can lead to issues concerning the securities on the side of the Taler Exchange. This means that digital cash is withdrawn by the customer, when the counter payment was not yet fully secured. The second interface defines the integration of the provider backend into the C2EC component. This includes the requests necessary to load the state of the transaction on the side of the provider and the request to trigger refunds.
+ C2EC is extensible. The C2EC backend component defines two interfaces which can be implemented by any provider. This also includes cash to e-cash cases like vending machines. One interface defines the operations for the communication with the provider backend, while the second interface defines the operations to interact with the provider specific transaction format. The operations must implement the correct confirmation process for the specific provider. This means that the implementation must guarantee the finality of the transaction and like this provide the Exchange with the securities it needs to allow the withdrawal of the digital cash. The operatios also allow to trigger a refund when the Exchange closes reserves due to inactivities.
\end{posterboxenv}
\end{tcbposter}
