commit 1e83b73ea47b295f031edf6a95834db8df7996c2
parent 403565732b15171e6f02bea696a9e7125e866003
Author: Joel-Haeberli <haebu@rubigen.ch>
Date: Sun, 26 May 2024 15:48:28 +0200
docs: enhancements
Diffstat:
17 files changed, 119 insertions(+), 52 deletions(-)
diff --git a/docs/content/appendix/api-bank-integration.pdf b/docs/content/appendix/api-bank-integration.pdf
Binary files differ.
diff --git a/docs/content/appendix/api-bank-wire.pdf b/docs/content/appendix/api-bank-wire.pdf
Binary files differ.
diff --git a/docs/content/appendix/api-terminals.pdf b/docs/content/appendix/api-terminals.pdf
Binary files differ.
diff --git a/docs/content/appendix/meeting_notes.tex b/docs/content/appendix/meeting_notes.tex
@@ -238,8 +238,8 @@
\item unix-path-mode
\item etc.
\end{itemize}
- \item For the attestation there is the additional case that neither confirm nor abort is an option and instead retries are required.
- \item Remove doubled abstractions (Abstracting attestation is not necessary)
+ \item For the confirmation there is the additional case that neither confirm nor abort is an option and instead retries are required.
+ \item Remove doubled abstractions (Abstracting confirmation is not necessary)
\end{itemize}
\subsection*{17.04.2024}
@@ -332,6 +332,51 @@
\item Poster
\end{itemize}
+\subsection*{15.05.2024}
+
+\textbf{Participants}
+
+\begin{itemize}
+ \item Fehrensen Benjamin
+ \item Grothoff Christian
+ \item H\"aberli Joel
+\end{itemize}
+
+\textbf{Topics}
+\begin{itemize}
+ \item Poster and Book review
+ \item Wallee was informed about the APK.
+\end{itemize}
+
+\textbf{Action points}
+\begin{itemize}
+ \item Fix Poster
+\end{itemize}
+
+\subsection*{22.05.2024}
+
+\textbf{Participants}
+
+\begin{itemize}
+ \item Fehrensen Benjamin
+ \item Grothoff Christian
+ \item H\"aberli Joel
+\end{itemize}
+
+\textbf{Topics}
+\begin{itemize}
+ \item Poster and Book review
+ \item Setup of C2EC
+\end{itemize}
+
+\textbf{Action points}
+\begin{itemize}
+ \item Logging must be enhanced to log every request
+ \item Document Future Work (setup process, etc.)
+ \item Finalize Poster and Book
+ \item Ask Wallee for the APK review.
+\end{itemize}
+
% TEMPLATE %
\subsection*{TEMPLATE}
diff --git a/docs/content/architecture/c2ec.tex b/docs/content/architecture/c2ec.tex
@@ -1,25 +1,25 @@
\section{C2EC}
-The \textbf{c}ashless\textbf{2ec}ash (C2EC) component is the central coordination component in the cashless withdrawal of digital cash using Taler. It initializes the parameters and mediates between the different stakeholders of a withdrawal, which finally allows the customer to withdraw digital cash from a reserve owned by the \textit{Exchange}. Therefore C2EC provides API which can be integrated and used by the \textit{Terminal}, \textit{Wallet} and the \textit{Exchange}.
+The \textbf{c}ashless\textbf{2ec}ash (C2EC) component is the central component in the cashless withdrawal of digital cash using Taler. It coordinates and initializes the parameters and mediates between the different stakeholders of a withdrawal. This finally allows the customer to withdraw digital cash from a reserve owned by the Exchange. To achieve this, C2EC provides an API which can be integrated and used by the terminal, wallet and the Exchange.
The API of the C2EC (cashless2ecash) component handles the flow from the creation of a C2EC mapping to the creation of the reserve. For the integration into the Taler ecosystem, C2EC must implement the Taler Wirewatch Gateway API \cite{taler-wire-gateway-api} and the Taler Bank Integration API \cite{taler-bank-integration-api}.
-The exact specification can be found in the official Taler docs repository as part of the core specifications of the bank integration \cite{taler-bank-integration-api} and wire gateway \cite{taler-wire-gateway-api}
+The exact specification can be found in the official Taler docs repository as part of the core specifications of the bank integration \cite{taler-bank-integration-api}, wire gateway \cite{taler-wire-gateway-api} or the terminals API \cite{taler-terminal-api}.
\subsection{C2EC Perspective}
From the perspective of C2EC, the system looks as follows:
\begin{itemize}
- \item Is requested by the \textit{Taler Wallet} to register a new \textit{wopid} to reserve public key mapping.
- \item Is notified by the \textit{Terminal} (e.g. a Wallee terminal) about a payment.
- \item Attests a payment by requesting the payment proof at the \textit{Provider Backend} (e.g. Wallee backend)
- \item Supplies the Taler Wire Gateway API that the respective \textit{Taler Exchange} can retrieve fresh transactions and create reserves which are then created and can be withdrawn by the \textit{Taler Wallet}.
+ \item Is requested by the Taler wallet to register a new \textit{wopid} to reserve public key mapping.
+ \item Is notified by the terminal (e.g. a Wallee terminal) about a payment.
+ \item Confirms a payment by requesting the payment confirmation from the payment service provider backend (e.g. Wallee backend)
+ \item Supplies the Taler Wire Gateway API that the respective Taler Exchange can retrieve fresh transactions and create reserves which are then created and can be withdrawn by the Taler wallet.
\end{itemize}
\subsection{Withdrawal-Operation state transitions}
\label{sec-architecture-state-transitions}
-Basically C2EC mediates between the stakeholders of a withdrawal in order to maintain the correct state of the withdrawal. Therefore it decides when a withdrawal's status can be transitioned. The diagram in \autoref{fig-withdrawal-operation-state-transition-diagram} shows the transitions of states in which a withdrawal operation can be and which events will trigger a transition. The term attestation in this context means, that the backend of the provider was asked and the transaction was successfully processed (or not). So if a transaction was successfully processed by the provider, the final state is the success case \textit{confirmed}, where the \textit{Exchange} will create a reserve and allow the withdrawal. If the attestation fails, thus the provider could not process the transaction successfully, the failure case \textit{aborted}, is reached as final state.
+Basically C2EC mediates between the stakeholders of a withdrawal in order to maintain the correct state of the withdrawal. It decides when a withdrawal's status can be transitioned. The diagram in \autoref{fig-withdrawal-operation-state-transition-diagram} shows the transitions of states in which a withdrawal operation can be and which events will trigger a transition. The term confirmation in this context means, that the backend of the provider was asked and the transaction was successfully processed (or not). So if a transaction was successfully processed by the provider, the final state is the success case \textit{confirmed}, where the Exchange will create a reserve and allow the withdrawal. If the confirmation fails, thus the provider could not process the transaction successfully, the failure case \textit{aborted}, is reached as final state.
\begin{figure}[h]
\centering
@@ -30,17 +30,16 @@ Basically C2EC mediates between the stakeholders of a withdrawal in order to mai
\subsection{Authentication}
-Terminals and the Exchange Wire Watch which authenticate against the C2EC API using Basic-Auth \cite{rfc7617} must provide their respective access token. Therefore, they provide a \texttt{Authorization: Basic \$ACCESS\_TOKEN} header, where \texttt{\$ACCESS\_TOKEN} is a basic-auth value configured by the operator of the exchange consisting of the terminal username and password. The header value must begin with the prefix specified in RFC 7617 \cite{rfc7617}: \textit{Basic}.
+Terminals and the Exchange Wire Watch which authenticate against the C2EC API using Basic-Auth \cite{rfc7617} must provide their respective access token. Fot his they provide a \texttt{Authorization: Basic \$ACCESS\_TOKEN} header, where \texttt{\$ACCESS\_TOKEN} is a basic-auth value configured by the operator of the Exchange consisting of the terminal username and password. The header value must begin with the prefix specified in RFC 7617 \cite{rfc7617}: \textit{Basic}.
\subsection{The C2EC RESTful API}
All components involved in the withdrawal process must interact with the C2EC component. Therefore this section describes the various API implemented in the C2EC component. The description contains a short list of the consumers of the respective API. Consumer in this context does not necessarily mean that data is consumed but rather that the consumer uses the API to either gather data or send reqeusts or data to C2EC.
\subsubsection{Terminals API}
+\label{sec-architecture-c2ec-terminals-api}
-That terminal can initiate and serve withdrawals in Taler, the Terminals API \cite{taler-terminal-api} is implemented, which mirrors all actions of a terminal at the C2EC component. This covers following endpoints:
-
-\label{sec-architecture-c2ec-setup-wopid}
+That terminals can initiate and serve withdrawals in Taler, the Terminals API \cite{taler-terminal-api} is specified and implemented. The Terminals API mirrors all actions of a terminal at the C2EC component. This covers following endpoints:
\begin{enumerate}
\item Config (/config)
@@ -52,7 +51,7 @@ That terminal can initiate and serve withdrawals in Taler, the Terminals API \ci
\textbf{Fees}
-An important aspect of the withdrawal flow using established third party providers are the fees. When the withdrawal operation is not supplied by some exchanges as standard service, the provider possibly wants to charge fees to the customer in order to make a profit and cover its costs. It is likely that these costs are rolled over to the customer in form of fees. This means that a terminal must have the capability to inform the Terminals API about fees. This can be achieved through the confirmation request in the Terminals API. For example cashback is causing a lot of fees to the merchants supporting it:
+An important aspect of the withdrawal flow using established third party providers are the fees. When the withdrawal operation is not supplied by some Exchanges as standard service, the provider possibly wants to charge fees to the customer in order to make a profit and cover its costs. It is likely that these costs are rolled over to the customer in form of fees. This means that a terminal must have the capability to inform the Terminals API about fees. This can be achieved through the confirmation request in the Terminals API. For example cashback is causing a lot of fees to the merchants supporting it:
\begin{quote}
\textit{de:}Die Händler zahlen jedoch für den Cashback-Service bereits Gebühren an
@@ -62,13 +61,13 @@ An important aspect of the withdrawal flow using established third party provide
\subsubsection{Taler Bank Integration API}
-Withdrawals by the \textit{Wallet} with a C2EC are based on withdrawal operations which register a reserve public key at the C2EC component. The provider must first create a unique identifier for the withdrawal operation (the \texttt{WOPID}) to interact with the withdrawal operation (as described in \autoref{sec-architecture-c2ec-setup-wopid}) and eventually withdraw digital cash using the \textit{Wallet}. The withdrawal operation API is an implementation of the \textit{Bank Integration API} \cite{taler-bank-integration-api}.
+Withdrawals by the wallet with a C2EC are based on withdrawal operations which register a reserve public key at the C2EC component. The provider must first create a unique identifier for the withdrawal operation (the \texttt{WOPID}) to interact with the withdrawal operation (as described in \autoref{sec-architecture-c2ec-terminals-api}) and eventually withdraw digital cash using the wallet. The withdrawal operation API is an implementation of the \textit{Bank Integration API} \cite{taler-bank-integration-api}.
\subsection{Taler Wirewatch Gateway API}
The Taler Wirewatch Gateway \cite{taler-wire-gateway-api} must be implemented in order to capture incoming transactions and allow the withdrawal of digital cash. The specification of the Taler Wirewatch Gateway can be found in the official Taler documentation \cite{taler-wire-gateway-api}.
-The wirewatch gateway helps the Exchange communicate with the C2EC component using a the API. It helps the Exchange to fetch guarantees, that a certain transaction went through and that the reserve can be created and withdrawn. This will help C2EC to capture the transaction of the Terminal Backend to the Exchange's account and therefore allow the withdrawal by the customer. Therefore the wirewatch gateway API is implemented as part of C2EC. When the wirewatch gateway can get the proof, that a transaction was successfully processed, the exchange will create a reserve with the corresponding reserve public key.
+The wirewatch gateway helps the Exchange communicate with the C2EC component using a the API. It helps the Exchange to fetch guarantees, that a certain transaction went through and that the reserve can be created and withdrawn. This will help C2EC to capture the transaction of the Terminal Backend to the Exchange's account and therefore allow the withdrawal by the customer. Therefore the wirewatch gateway API is implemented as part of C2EC. When the wirewatch gateway can get the proof, that a transaction was successfully processed, the Exchange will create a reserve with the corresponding reserve public key.
For C2EC not all endpoints of the Wire Gateway API are needed. Therefore the endoints which are not needed will be implemented but always return http status code 400 with explanatory error details as specified by the specification.
@@ -80,13 +79,13 @@ The entities of the C2EC component must track two different aspects. The first i
The detailed explanation and ERD can be found in \autoref{sec-implementation-database}.
\subsubsection{Terminal Provider}
-Entity displayed in \autoref{fig-erd-terminal-provider} describing providers of C2EC compliant terminals. The name of the provider is important, because it decides which flow shall be taken in order to attest the payment. For example will the name \textit{Wallee} signal the terminal provider to trigger the attestation flow of \textit{Wallee} once the payment notification for the withdrawal reaches C2EC.
+Entity displayed in \autoref{fig-erd-terminal-provider} describing providers of C2EC compliant terminals. The name of the provider is important, because it decides which flow shall be taken in order to attest the payment. For example will the name \textit{Wallee} signal the terminal provider to trigger the confirmation flow of \textit{Wallee} once the payment notification for the withdrawal reaches C2EC.
\subsubsection{Terminal}
Entity displayed in \autoref{fig-erd-terminal} contains information about terminals of providers. This includes the provider they belong to and an access-token, which is generated by the operator of the C2EC component. It allows authenticating the terminal. A terminal belongs to one terminal provider.
\subsubsection{Withdrawal}
-Entity displayed in \autoref{fig-erd-withdrawal} represents the withdrawal processes initiated by terminals. This table therefore contains information about the withdrawal like the amount, which terminal the withdrawal was initiated from and which reserve public key is used to create a reserve in the Exchange.
+Entity displayed in \autoref{fig-erd-withdrawal} represents the withdrawal processes initiated by terminals. This entity contains information about the withdrawal like the amount, which terminal the withdrawal was initiated from and which reserve public key is used to create a reserve in the Exchange.
\subsubsection{Relationships}
\label{sec-architecture-entities-relationships}
diff --git a/docs/content/implementation/a-c2ec.tex b/docs/content/implementation/a-c2ec.tex
@@ -39,12 +39,12 @@ Following a short list of events and from whom they are triggered and who listen
\item Registered by: Terminal
\item Listened by: Attestor
\end{itemize}
- \item Payment attestation success will send a withdrawal operation status update event.
+ \item Payment confirmation success will send a withdrawal operation status update event.
\begin{itemize}
\item Registered by: Attestor
\item Listened by: Consumers (via Bank-Integration-API)
\end{itemize}
- \item Payment attestation failure will trigger a retry event.
+ \item Payment confirmation failure will trigger a retry event.
\begin{itemize}
\item Registered by: Attestor
\item Listened by: Retrier
@@ -60,7 +60,7 @@ Following a short list of events and from whom they are triggered and who listen
A withdrawal might be aborted through the terminal or the wallet. These cases are implemented through the respective \textit{abort} endpoint in the bank-integration API \autoref{sec-implementation-bank-integration-api-abort} and terminals API \autoref{sec-implementation-terminal-api-abort}. If in doubt whether to abort the withdrawal or not, it should be aborted. In case of abortion and failure cases, the security of the money is weighted higher than the user-experience. If the user must restart the withdrawal in case of a failure in the process, it is less severe than opening possible security holes by somehow processing the withdrawal anyway. On the other hand the system must be as stable as possible to make this error cases very rare. If they occur too often, the customer might not use the technology and therefore would make it worthless.
-The withdrawal can only be aborted, when it is not yet confirmed by the attestation process (described in \autoref{sec-implementation-processes-attestation}).
+The withdrawal can only be aborted, when it is not yet confirmed by the confirmation process (described in \autoref{sec-implementation-processes-confirmation}).
\newpage
\include{content/implementation/a-terminal-api}
diff --git a/docs/content/implementation/a-processes.tex b/docs/content/implementation/a-processes.tex
@@ -3,19 +3,19 @@
This section describes the different processes running in the background transitioning the state of a withdrawal. These transitions are triggered by the because of requests received by one of the components through the respective API.
-\subsubsection{Attestation}
-\label{sec-implementation-processes-attestation}
+\subsubsection{Confirmation}
+\label{sec-implementation-processes-confirmation}
-The attestation of a transaction is crucial, since this is the action which allows the exchange to create a reserve and can proof to the provider and customer, that the transaction was successful and therefore can put the liability for the money on the provider. The attestation process is implemented using a provider client interface and a provider transaction interface. This allows the process to be the same for each individual provider and new providers can be added easily by providing a specific implementation of the interfaces.
+The confirmation of a transaction is crucial, since this is the action which allows the exchange to create a reserve and can proof to the provider and customer, that the transaction was successful and therefore can put the liability for the money on the provider. The confirmation process is implemented using a provider client interface and a provider transaction interface. This allows the process to be the same for each individual provider and new providers can be added easily by providing a specific implementation of the interfaces.
-\subsubsection{Attestation Retrier}
+\subsubsection{Confirmation Retrier}
-If the attestation fails, but the transaction is not in the refund state as specified by the provider's transaction, the problem could simply be that the service was not available or the transaction was not yet processed by the provider's backend. In order to not need to abort the transaction directly and give the system some robustness, a retry mechanism was implemented which allows retrying the attestation step. This retry mechanism is run in a separate process started through the main process.
+If the confirmation fails, but the transaction is not in the refund state as specified by the provider's transaction, the problem could simply be that the service was not available or the transaction was not yet processed by the provider's backend. In order to not need to abort the transaction directly and give the system some robustness, a retry mechanism was implemented which allows retrying the confirmation step. This retry mechanism is run in a separate process started through the main process.
-The retry will only be executed, when the transaction attestation failed because the transaction was not in the abort state or if for some reason the transaction information could not have been retrieved.
+The retry will only be executed, when the transaction confirmation failed because the transaction was not in the abort state or if for some reason the transaction information could not have been retrieved.
\subsubsection{Transfer Retrier}
-The Exchange may send a transfer request to the C2EC component, due to the closing of a reserve or an issue. This will trigger a refund process at the providers backend. This refund process may fail and therefore like in the attestation case to increase the robustness of the system, a retry mechanism is implemented, which will retry the transfer before ultimatively failing the transfer.
+The Exchange may send a transfer request to the C2EC component, due to the closing of a reserve or an issue. This will trigger a refund process at the providers backend. This refund process may fail and therefore like in the confirmation case to increase the robustness of the system, a retry mechanism is implemented, which will retry the transfer before ultimatively failing the transfer.
\textbf{Randomizing delays due to self synchronization}
\ No newline at end of file
diff --git a/docs/content/implementation/a-providers.tex b/docs/content/implementation/a-providers.tex
@@ -6,20 +6,20 @@ This section treats the integration of providers into the system by explaining t
\subsubsection{Provider Client}
\label{sec-provider-client-interface}
-The provider client interface is called by the attestation process depending on the notification received by the database upon receiving a payment notification of the provider's terminal. The specific provider clients are registered at the startup of the component and the attestation process will delegate the information gathering to the specific client, based on the notification received by the database.
+The provider client interface is called by the confirmation process depending on the notification received by the database upon receiving a payment notification of the provider's terminal. The specific provider clients are registered at the startup of the component and the confirmation process will delegate the information gathering to the specific client, based on the notification received by the database.
The provider client interface defines three functions:
\begin{enumerate}
\item SetupClient: The setup function is called by the startup of the application and used to initialize the client. Here it makes sense to check that everything needed for the specific client is in place and that properties like access credentials are available.
- \item GetTransaction: This function is used by the attestation process to retrieve the transaction of the provider system. It takes the transaction identifier supplied with the withdrawal confirmation request and loads the information about the transaction. Based on this information the decision to confirm or abort the transaction is done.
+ \item GetTransaction: This function is used by the confirmation process to retrieve the transaction of the provider system. It takes the transaction identifier supplied with the withdrawal confirmation request and loads the information about the transaction. Based on this information the decision to confirm or abort the transaction is done.
\item Refund: Since the transaction of the money itself is done by the provider, also refunds will be unwind by the provider. This functions mean is to trigger this refund transaction at the provider.
\end{enumerate}
\subsubsection{Provider Transaction}
\label{sec-provider-transaction-interface}
-Since the attestation process is implemented to support any provider, also the transaction received by the provider clients \textit{GetTransaction} function is abstracted using an interface. This interface must be implemented by any provider transaction which belongs to a specific provider client.
+Since the confirmation process is implemented to support any provider, also the transaction received by the provider clients \textit{GetTransaction} function is abstracted using an interface. This interface must be implemented by any provider transaction which belongs to a specific provider client.
The provider client interface defines following functions:
@@ -31,7 +31,7 @@ The provider client interface defines following functions:
\subsubsection{Wallee Client}
-The Wallee client is the first implementation of the provider client interface and allows the attestation of transactions using the Wallee backend system. The backend of Wallee provides a ReST-API to their customers, which allows them to request information about payments, refunds and so on. To access the API, the consumer must authenticate themself to Wallee by using their own authentication token as explained in \autoref{sec-security-auth-wallee}.
+The Wallee client is the first implementation of the provider client interface and allows the confirmation of transactions using the Wallee backend system. The backend of Wallee provides a ReST-API to their customers, which allows them to request information about payments, refunds and so on. To access the API, the consumer must authenticate themself to Wallee by using their own authentication token as explained in \autoref{sec-security-auth-wallee}.
As indicated by the provider client interface, two services of the Wallee backend are leveraged:
diff --git a/docs/content/implementation/a-terminal-api.tex b/docs/content/implementation/a-terminal-api.tex
@@ -35,11 +35,11 @@ Terminals are advised to always set the \textit{amount} field of the request, if
When the terminal setup the withdrawal successful and received the \textit{WOPID}, the terminal wants to wait before effectively authorizing the transaction until the Wallet has registered the parameters for the withdrawal. This endpoint allows this and supports long-polling such that the terminal may directly ask for the status after setting up the withdrawal. The endpoint is an exact replication of the Bank-Integration API status endpoint as described in \autoref{sec-implementation-bank-integration-api-status}
-\textbf{Trigger Attestation (/withdrawals/[WOPID]/check)}
+\textbf{Trigger Confirmation (/withdrawals/[WOPID]/check)}
-Once the terminal authorized the transaction at the providers backend and received the notification, that the transaction was processed at the providers backend, the terminal can trigger the attestation of the transaction by calling this endpoint. This is also the point where the terminal can know the fees of the provider (if any) and send them to the C2EC component.
+Once the terminal authorized the transaction at the providers backend and received the notification, that the transaction was processed at the providers backend, the terminal can trigger the confirmation of the transaction by calling this endpoint. This is also the point where the terminal can know the fees of the provider (if any) and send them to the C2EC component.
-\textbf{Trigger Attestation (/withdrawals/[WOPID]/abort)}
+\textbf{Trigger Confirmation (/withdrawals/[WOPID]/abort)}
\label{sec-implementation-terminal-api-abort}
As long as the withdrawal was not authorized, it can be aborted by the terminal through this API. If the withdrawal was already authorized, the abortion will not work and the refund process might be needed to gain back the authorized money.
diff --git a/docs/content/implementation/b-terminal.tex b/docs/content/implementation/b-terminal.tex
@@ -57,7 +57,7 @@ This screen in \autoref{fig-terminal-screen-register-parameters} displays a QR c
\subsubsection{Authorization Screen}
-The authorization screen will use Wallee's \textit{Android Till SDK} \cite{wallee-till-sdk} to authorize the amount at the Wallee backend. The response handler of the SDK will delegate the response to the implementation of the terminal, which allows triggering the attestation of the payment by C2EC using the Terminals API. When the authorization process is not started and the transaction therefore is created at the backend system of Wallee, the screen \autoref{fig-terminal-screen-authorizing} will be displayed. This signals the user, that the payment authorization must still be done and is about to be started. The user can abort the transaction at this point.
+The authorization screen will use Wallee's \textit{Android Till SDK} \cite{wallee-till-sdk} to authorize the amount at the Wallee backend. The response handler of the SDK will delegate the response to the implementation of the terminal, which allows triggering the confirmation of the payment by C2EC using the Terminals API. When the authorization process is not started and the transaction therefore is created at the backend system of Wallee, the screen \autoref{fig-terminal-screen-authorizing} will be displayed. This signals the user, that the payment authorization must still be done and is about to be started. The user can abort the transaction at this point.
\begin{figure}[h]
\centering
diff --git a/docs/content/implementation/c-database.tex b/docs/content/implementation/c-database.tex
@@ -13,7 +13,7 @@ For the C2EC component the schema c2ec is created. It holds tables to store the
\subsubsection{Terminal Provider}
-The \textit{terminal provider} table holds information about the provider. It contains the information, which payto target type is used to make transactions by the provider. This information is needed in the refund case where the \textit{Exchange} sends a transfer request. It also holds information about the attestation endpoint. Namely the base url and the credentials to authenticate the attestation process against the API of the providers backend. When adding the provider using the cli, the credentials are formatted in the correct way and also encrypted.
+The \textit{terminal provider} table holds information about the provider. It contains the information, which payto target type is used to make transactions by the provider. This information is needed in the refund case where the \textit{Exchange} sends a transfer request. It also holds information about the confirmation endpoint. Namely the base url and the credentials to authenticate the confirmation process against the API of the providers backend. When adding the provider using the cli, the credentials are formatted in the correct way and also encrypted.
\begin{figure}[h]
\centering
@@ -79,11 +79,11 @@ The withdrawal status trigger emits the status of a withdrawal when the status i
\subsubsection{Payment Trigger}
-The payment trigger is triggered through the withdrawal confirmation request of the Terminals API (described in \autoref{sec-implementation-terminal-api}). It will start the attestation of the transaction at the providers backend, through the provider specific attestation process.
+The payment trigger is triggered through the withdrawal confirmation request of the Terminals API (described in \autoref{sec-implementation-terminal-api}). It will start the confirmation of the transaction at the providers backend, through the provider specific confirmation process.
-\subsubsection{Attestation Retry Trigger}
+\subsubsection{Confirmation Retry Trigger}
-If the attestation for a withdrawal fails, this trigger is responsible to notify the retry listener of the application to retry the attestation. Therefore the trigger calls the \textit{emit\_retry\_notification} function which will notify its listener and the retry will eventually be executed.
+If the confirmation for a withdrawal fails, this trigger is responsible to notify the retry listener of the application to retry the confirmation. Therefore the trigger calls the \textit{emit\_retry\_notification} function which will notify its listener and the retry will eventually be executed.
\subsubsection{Transfer Trigger}
diff --git a/docs/content/results/discussion.tex b/docs/content/results/discussion.tex
@@ -1,2 +1,23 @@
\section{Discussion}
What is the significance of your results? – the final major section of text in the paper. The Discussion commonly features a summary of the results that were obtained in the study, describes how those results address the topic under investigation and/or the issues that the research was designed to address, and may expand upon the implications of those findings. Limitations and directions for future research are also commonly addressed.
+
+
+
+\section{Future Work}
+
+As stated in the discussion the implementation of the framework does suffer from some architectural short comings. Also other parts must be further improved. Additionally to such clean up duties, the system can be extended. To give myself and others interested to collaborate some ideas what can be done, I provide a list of future work. The list might not be complete and any new idea is appreciated. I split the future work into two parts. The second list, is a list of ideas how the existing logic can be extended to make the system easier to use or to add new functionality. The second list contains technical debts which I tried to keep low but due to the lack of time could not prevent.
+
+\subsection{Extensions}
+\begin{enumerate}
+ \item Integration of other providers: To make use of the implemented structures, it would be nice to add more payment service providers.
+ \item Management interface for terminals: To allow easier use of the system it might be nice to have a more sophisticated interface to manage terminals. The implemented CLI helps to get an understanding, how such a management interface could add terminals to the system.
+ \item Automated registration: With increasing use, it might be nice for the operator to allow an automatic registration of new terminals.
+ \item Support quotas: To fully support the Terminals API, the quotas endpoints could be implemented.
+ \item Proper packing: To fully integrate into the Taler landscape, C2EC should be packed and installed like other Taler components such as the Exchange.
+\end{enumerate}
+
+\subsection{Technical debt}
+\begin{enumerate}
+ \item C2EC: Remove doubled provider structures. Currently providers are saved to the database and must be configured in the configuration. To make the setup and management easier, the providers could only be configured inside the configuration.
+ \item App: Automatically trigger long poll request for parameter selection. Due to the lack of time, the long-poll request for the parameter selection on the side of the terminal was not implemented to be automatically but will only be sent, when the user clicks on the \textit{authorize} button. The request shall be triggered in the background instead.
+\end{enumerate}
diff --git a/docs/content/results/reflexion.tex b/docs/content/results/reflexion.tex
@@ -0,0 +1,7 @@
+\section{Reflexion}
+
+\subsection{Technically}
+
+\subsection{Methodically}
+
+\subsection{Personally}
+\ No newline at end of file
diff --git a/docs/content/results/results.tex b/docs/content/results/results.tex
@@ -1,9 +0,0 @@
-\section{Results}
-What did you find? – a section which describes the data that was collected and the results of any statistical tests that were performed. It may also be prefaced by a description of the analysis procedure that was used. If there were multiple experiments, then each experiment may require a separate Results section.
-
-
-\section{Future Work}
-
-- Integrate other providers
-- Management interface for Terminals and Operators
-- Automate registration of Terminals
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
Binary files differ.
diff --git a/docs/thesis.tex b/docs/thesis.tex
@@ -53,6 +53,8 @@
\usepackage{parskip}
+\usepackage{pdfpages}
+
%---------------------------------------------------------------------------
% Graphics paths
%---------------------------------------------------------------------------
@@ -211,7 +213,7 @@
\chapter{Results}
\input{content/results/discussion}
-\input{content/results/results}
+\input{content/results/reflexion}
%------------ Authorship declaration translated to main language ------------
\declarationOfAuthorship
@@ -239,9 +241,10 @@
%------------ Appendix ----------------
\appendix
\chapter*{Appendix A}
-\section*{API}
\label{appendix-api-spec}
-\lstinputlisting[style=rst,caption={C2EC API specification}]{listings/specs/api-c2ec.txt}
+\includepdf[pages=-]{content/appendix/api-terminals.pdf}
+\includepdf[pages=-]{content/appendix/api-bank-integration.pdf}
+\includepdf[pages=-]{content/appendix/api-bank-wire.pdf}
\chapter*{Appendix B}
\section*{Project Management}
diff --git a/simulation/c2ec-simulation b/simulation/c2ec-simulation
Binary files differ.
