docs: add implemenation docs for c2ec

13 files changed, 364 insertions, 25 deletions

diff --git a/c2ec/provider-client.go b/c2ec/provider-client.go
index 22da076..023586d 100644
--- a/c2ec/provider-client.go
+++ b/c2ec/provider-client.go
@@ -2,6 +2,7 @@ package main
 
 type ProviderTransaction interface {
 	AllowWithdrawal() bool
+	AbortWithdrawal() bool
 	Bytes() []byte
 }
 
diff --git a/cli/README b/cli/README
index 6572a52..1d6df82 100644
--- a/cli/README
+++ b/cli/README
@@ -1,10 +1,10 @@
 # C2EC Management CLI
 
-This allows adding Providers and Terminals to the database using the command line.
+This cli allows adding Providers and Terminals to the database and deactivating terminals, using the command line.
 
-Before using the commands which connect to the database, you first need to connect to the database (can be done within the CLI using the `db` command).
+Before using the commands which connect to the database, you first need to connect to the database (can either be done setting `PGHOST` or within the CLI using the `db` command).
 
-It will take care of generating the access tokens for the terminal and hashing the authorization key of the provider backend.
+The CLI will take care of generating the access tokens for the newly registered terminal and hashing the authorization key of the provider backend.
 
 ## Build
 
@@ -12,4 +12,18 @@ It will take care of generating the access tokens for the terminal and hashing t
 
 ## Run 
 
-`./c2ec-cli`
\ No newline at end of file
+`./c2ec-cli`
+
+## Environment
+
+You can set `PGHOST` to connect automatically to the database.
+
+## Actions
+
+The cli offers following capabilities:
+
+Registering Wallee Provider: `rp`
+
+Registering a Wallee Termina: `rt`
+
+Deactivating a Terminal: `dt`
diff --git a/cli/cli.go b/cli/cli.go
index a2fecb8..35b8573 100644
--- a/cli/cli.go
+++ b/cli/cli.go
@@ -18,6 +18,7 @@ import (
 const ACTION_HELP = "h"
 const ACTION_REGISTER_PROVIDER = "rp"
 const ACTION_REGISTER_TERMINAL = "rt"
+const ACTION_DEACTIVATE_TERMINAL = "dt"
 const ACTION_CONNECT_DB = "db"
 const ACTION_QUIT = "q"
 
@@ -37,6 +38,13 @@ var DB *pgx.Conn
 func main() {
 	fmt.Println("What do you want to do?")
 	showHelp()
+	optionalPghost := os.Getenv("PGHOST")
+	if optionalPghost != "" {
+		err := connectDbUsingString(optionalPghost)
+		if err != nil {
+			fmt.Println("error while connecting to database, using connection string from PGHOST. error:", err.Error())
+		}
+	}
 	for {
 		err := dispatchCommand(read("Type command (term in brackets): "))
 		if err != nil {
@@ -80,7 +88,7 @@ func registerWalleeProvider() error {
 	}
 	credsEncoded := base64.StdEncoding.EncodeToString(creds)
 
-	rows, err := DB.Query(
+	_, err = DB.Exec(
 		context.Background(),
 		INSERT_PROVIDER,
 		name,
@@ -91,7 +99,6 @@ func registerWalleeProvider() error {
 	if err != nil {
 		return err
 	}
-	rows.Close()
 
 	return nil
 }
@@ -135,7 +142,7 @@ func registerWalleeTerminal() error {
 	}
 
 	fmt.Println("adding terminal")
-	rows, err = DB.Query(
+	_, err = DB.Exec(
 		context.Background(),
 		INSERT_TERMINAL,
 		hashedAccessToken,
@@ -145,7 +152,6 @@ func registerWalleeTerminal() error {
 	if err != nil {
 		return err
 	}
-	rows.Close()
 
 	fmt.Println("looking up last inserted terminal")
 	rows, err = DB.Query(
@@ -168,6 +174,31 @@ func registerWalleeTerminal() error {
 	return nil
 }
 
+func deactivateTerminal() error {
+
+	fmt.Println("You are about to deactivate terminal which allows withdrawals. This will make the terminal unusable.")
+	tuid := read("Terminal-User-Id: ")
+	parts := strings.Split(tuid, "-")
+	if len(parts) != 2 {
+		return errors.New("invalid terminal-user-id (format=[PROVIDER_NAME]-[NUMBER])")
+	}
+	tid, err := strconv.Atoi(parts[1])
+	if err != nil {
+		return err
+	}
+
+	_, err = DB.Exec(
+		context.Background(),
+		DEACTIVATE_TERMINAL,
+		tid,
+	)
+	if err != nil {
+		return err
+	}
+
+	return nil
+}
+
 func connectDatabase() error {
 
 	u := read("Username: ")
@@ -181,7 +212,11 @@ func connectDatabase() error {
 	d := read("Database: ")
 
 	connstring := PostgresConnectionString(u, pw, h, p, d)
-	dbCfg, err := pgx.ParseConfig(connstring)
+	return connectDbUsingString(connstring)
+}
+
+func connectDbUsingString(connString string) error {
+	dbCfg, err := pgx.ParseConfig(connString)
 	if err != nil {
 		return err
 	}
@@ -197,6 +232,7 @@ func showHelp() error {
 
 	fmt.Println("register wallee provider (", ACTION_REGISTER_PROVIDER, ")")
 	fmt.Println("register wallee terminal (", ACTION_REGISTER_TERMINAL, ")")
+	fmt.Println("deactivate wallee terminal (", ACTION_DEACTIVATE_TERMINAL, ")")
 	fmt.Println("connect database (", ACTION_CONNECT_DB, ")")
 	fmt.Println("show help (", ACTION_HELP, ")")
 	fmt.Println("quit (", ACTION_QUIT, ")")
@@ -260,6 +296,8 @@ func dispatchCommand(cmd string) error {
 		err = registerWalleeProvider()
 	case ACTION_REGISTER_TERMINAL:
 		err = registerWalleeTerminal()
+	case ACTION_DEACTIVATE_TERMINAL:
+		err = deactivateTerminal()
 	default:
 		fmt.Println("unknown action")
 	}
diff --git a/cli/db.go b/cli/db.go
index ef2d2a7..246e858 100644
--- a/cli/db.go
+++ b/cli/db.go
@@ -2,6 +2,7 @@ package main
 
 const INSERT_PROVIDER = "INSERT INTO c2ec.provider (name, payto_target_type, backend_base_url, backend_credentials) VALUES ($1,$2,$3,$4)"
 const INSERT_TERMINAL = "INSERT INTO c2ec.terminal (access_token, description, provider_id) VALUES ($1,$2,$3)"
+const DEACTIVATE_TERMINAL = "UPDATE c2ec.terminal SET active = false WHERE terminal_id=$1"
 const GET_PROVIDER_BY_NAME = "SELECT * FROM c2ec.provider WHERE name=$1"
 const GET_LAST_INSERTED_TERMINAL = "SELECT * FROM c2ec.terminal WHERE terminal_id = (SELECT MAX(terminal_id) FROM c2ec.terminal)"
 
diff --git a/docs/content/architecture/c2ec.tex b/docs/content/architecture/c2ec.tex
index 7bcb587..b8ba67b 100644
--- a/docs/content/architecture/c2ec.tex
+++ b/docs/content/architecture/c2ec.tex
@@ -2,9 +2,9 @@
 
 The C2EC (\textbf{c}ashless\textbf{2ec}ash) 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 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-wirewatch-gateway-api} and the Taler Bank Integration API \cite{taler-bank-integration-api}. 
+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 \cite{taler-c2ec-spec}
+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}
 
 \subsection{C2EC Perspective}
 From the perspective of C2EC, the system looks as follows:
@@ -81,7 +81,7 @@ This API is not specified within the standard Bank Integration API and therefore
 \end{itemize}
 
 \subsection{Taler Wirewatch Gateway API}
-The Taler Wirewatch Gateway \cite{taler-wirewatch-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-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.
 
diff --git a/docs/content/implementation/c2ec.tex b/docs/content/implementation/c2ec.tex
index bc69dda..89e645f 100644
--- a/docs/content/implementation/c2ec.tex
+++ b/docs/content/implementation/c2ec.tex
@@ -1,5 +1,119 @@
 \section{C2EC}
 
-\include{content/implementation/c2ec-db}
+\subsection{Bank-Integration API}
+
+The Bank Integration API was implemented according to the specification \cite{taler-bank-integration-api}. It only implements messages and API specific to the indirect withdrawal operation.
+
+Namely this are the following endpoints:
+
+\begin{itemize}
+    \item GET /config
+    \item GET /withdrawal-operation/[WOPID]
+    \item POST /withdrawal-operation/[WOPID]
+    \item POST /withdrawal-operation/[WOPID]/payment
+    \item POST /withdrawal-operation/[WOPID]/abort
+\end{itemize}
+
+\subsection{Wire-Gateway API}
+
+The Wire-Gateway API delivers the transaction history to the exchange which will create reserves for the specific public keys and therefore allow the customers to finally withdraw the digital cash using their wallet.
+
+Following endpoints are implemented by the wire gateway API implementation:
+
+\begin{itemize}
+    \item GET /config
+    \item POST /transfer
+    \item GET /history/incoming
+\end{itemize}
+
+\subsubsection{Keeping track of transfers}
+
+The Wire-Gateway specification requires the implementor of the API to keep track of incoming transfer requests in order to guarantee the idempotence of the API. Therefore the implementation keeps track of all transfers in the database table \textit{transfers}. It stores a hash of the entire request related to the requests unqiue identifier. If a request with the same UID is sent to the transfer-API, first it is checked that the incoming request is exactly the same as the previous one by comparing the hash of the requests. Only if the hashes are the same, the transfer request is processed further. Otherwise the API responds with a conflict response.
+
+\subsection{Payment Attestation}
+
+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 withdrawal 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.
+
+\subsubsection{Provider Client}
+
+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 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 payment notification message 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}
+
+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.
+
+The provider client interface defines following functions:
+
+\begin{enumerate}
+    \item AllowWithdrawal: This function shall return true, when the transaction received by the provider enters a positive final state. This means that the provider accepted the transaction and could process it.
+    \item AbortWithdrawal: It doesn't mean that if a transaction does not allow to do the withdrawal, that the transaction shall be cancelled immediately. It could also be that the transaction was not yet processed by the provider. In this case we need means to check if the provider transaction is in an abort state if it is not ready for withdrawal, before aborting it. AbortWithdrawal shall therefore answer the question if the provider transaction is in a negative final state, which means the transaction is to be aborted.
+    \item Bytes: This function shall return a byte level representation of the transaction which will be used as proof of the transaction and stored in the exchanges database.
+\end{enumerate}
+
+\subsubsection{Retries}
+
+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.
+
+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. 
+
+\subsection{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}.
+
+As indicated by the provider client interface, we will use two API of the Wallee backend:
+
+\begin{itemize}
+    \item Transaction service: The transaction service aims to provide information about a transaction registered using a Wallee terminal.
+    \item Refund service: The refund service allows to trigger a refund for a given transaction using the transaction identifier. The refund will then be executed by the Wallee backend, back to the Customer.
+\end{itemize}
+
+\subsection{Security}
+
+\subsubsection{API access}
+
+\textbf{Bank-Integration API}
+
+The Bank-Integration API is accessed by Wallets and Terminals. This results in two different device types for the autentication procedure. The Wallet should be able to authenticate against the exchange by using an access token according to the specified authentication flow of the core bank API \cite{taler-bank-core-authentication} which leverages a bearer token as specified by DD-49 \cite{taler-design-document-49}. For terminals the authentication mechanism is based on a basic auth scheme as specified by RFC-7617 \cite{rfc7617}. Therefore a generated access-token used as password and a username which is generated registering the terminal using the cli explained in \autoref{sec-security-registering-providers} are leveraged.
+
+\textbf{Wire-Gateway API}
+
+The wire gateway specifies a basic auth flow \cite{taler-wire-gateway-api-authentication} as described in RFC-7617 \cite{rfc7617}. Therefore the C2EC component allows the configuration of a username and password for the exchange. During the request of the exchange at the wire gateway API, the credentials are checked.
+
+\textbf{Database}
+
+\subsubsection{Authenticating at the Wallee ReST API}
+\label{sec-security-auth-wallee}
+
+The Wallee API specifies four Wallee specific headers which are used to authenticate against the API. It defines its own authentication standard and flow. The flow builds on a MAC (message authentication code) which is built on a version, user identifier, and a timestamp. For the creation of the MAC the HMAC (hash based message authentication code) SHA-512 is leveraged which takes the so called \textit{application-user-key} (which is basically just an access-token, which the user receives when creating a new API user) as key and the above mentioned properties plus information about the requested http method and the exactly requested path (including request parameters) as message \cite{wallee-api-authentication}. The format of the message is specified like: 
+
+\begin{center}
+    \texttt{Version|User-Id|Unix-Timestamp|Http-Method|Path}
+\end{center}
+
+\begin{itemize}
+    \item Version: The version of the algorithm
+    \item User-Id: The user-id of the requesting user
+    \item Unix-Timestamp: A unix timestamp (seconds since 01.01.1970)
+    \item Http-Method: one of \texttt{HEAD}, \texttt{GET}, \texttt{POST}, \texttt{PUT}, \texttt{DELETE}, \texttt{TRACE}, \texttt{CONNECT}
+    \item Path: The path of the requested URL including the query string (if any)
+\end{itemize}
+
+The resulting string must then be UTF-8 encoded according to RFC-3629 \cite{rfc3629}.
+
+\subsubsection{Registering Providers and Terminals}
+\label{sec-security-registering-providers}
+
+A provider may want to register a new Terminal or maybe even a new provider shall be registered for the exchange. To make this step easier for the exchange operators, a small cli program (command line interface) was implemented. The cli will either ask for a password or generate an access token in case of the terminal registration. The credentials are stored has hashes using a PBKDF (password based key derivation function) so that even if the database leaks, the credentials cannot be easily read by the attackers.
+
+\subsubsection{Deactivating Terminals}
+
+A Terminal can be stolen, hijacked or hacked by malicious actors. Therefore it must be possible to disable a terminal immediately and no longer allow withdrawals using this terminal. Therefore the \textit{active} flag can be set to \textit{false} for a registered terminal. The Bank-Integration API which processes withdrawals and authenticates terminals, must check that the requesting terminal is active and is allowed to initiate withdrawals. Since the check for the \textit{active} flag must be done for each request of a terminal, the check can be centralized and is implemented as part of the authentication flow. A Wallee terminal can be deactivated using the cli mentioned in \autoref{sec-security-registering-providers}.
 
-\subsection{Server}
diff --git a/docs/content/implementation/concepts.tex b/docs/content/implementation/concepts.tex
new file mode 100644
index 0000000..6ec2281
--- /dev/null
+++ b/docs/content/implementation/concepts.tex
@@ -0,0 +1,37 @@
+\section{Concepts}
+
+This chapter describes high level concepts which are used in the implementation of the components. The short explanations aim to support the understanding of the reader to faster and better understand the implementation of the components.
+
+\subsection{Consumers and Producers}
+
+The two terms consumer and producer are used through the entire documentation. They describe the role of a component in an interaction with another component. The consumer is the component askig or requesting a producer to gather information or trigger some action. The Producer on the other hand is the component who receives information or call for action of a consumer. 
+
+\subsection{Long-Polling}
+\label{sec-concepts-long-poll}
+
+Long-Polling is the concept of not closing a connection until a a response can be delivered or a given duration exceeds. This allows a consumer to ask for information which it assumes will arrive in the future at the producer. The producer therefore will not close the request of the consumer but instead keep the connection open and respond with the response, once it is available. The consumer and the producer can both close the connection after a certain amount of time, which is called the timeout. This can also happen if the wanted result of the producer cannot be returned to the consumer.
+
+\subsection{Publish-Subscribe Pattern}
+\label{sec-concepts-pub-sub}
+
+The concept of publishers and subscribers is used heavily in the implementation. It allows decoupling different steps of the process and allows different steps to be handled and executed in their own processes. Publishers can also be called notifiers or similar, while the subscriber can also be called listener or similar.
+
+The communication of publishers and subscribers happends through channels. A publisher will publish to a certain channel when a defined state is reached. The subscriber who is subscribed or listens to this channel will capture the message sent through the channel by the publisher and start processing it.
+
+The publish-subscribe scheme enables loose coupling and therefore helps to improve the performance of individual processes, because they cannot be hindered by others.
+
+\subsection{Go Language}
+
+Go comes with handy features to implement the concepts like pub/sub \autoref{sec-concepts-pub-sub} or long polling \autoref{sec-concepts-long-poll}.
+
+\subsubsection{Contexts}
+
+Go standard library contians a package called \textit{context}. You will stumble over this package all the time, even when using third party libraries or when writing your own code. The \textit{context} package allows to control the lifetime and cancellation activities for function and allows concurrent running threads to be executed within the same context. For example if you have a function which can sort a list concurrently and will fail if any thread has a failure, supplying each concurrent execution of the function the same context allows to leave the function early if the context is left by propagating the done signal through the \textit{Done} channel which is part of each context. A context also defines the \textit{cancellation function}. This function shall be called, for each context when it becomes obsolete. The cancellation function will execute cleanup activities related to the specific context. It is a best practice to defer the cancellation function right after the creation of the context \cite{golang-contexts-and-structs}. 
+
+\subsubsection{Go Routines}
+
+In concurrent programs it is a challenge to keep up with the complexity which they add to the code. Also one has to take care of interprocess communication and if memory is accessed in shared manner by the program, the access to the data stored should be mutual exclusive. Go therefore comes with the concept of Goroutines. They are designed to be very cheap, lightweight threads. They share the same address space and are just executed besides each other as simple functions. Also Go encourages the use of channels to communicate between different goroutines. The use of channels makes locking memory for concurrent access obsolete and therefore removes possible concurrency problems by making them impossible by design \cite{golang-share-by-communicating}. 
+
+\subsubsection{Memory safety}
+
+Even when Go is a low level language which compiles to native bytecode directly, it implements a garbage collector and memory management which takes care of allocating and releasing memory as needed. This reduces the risk of memory leaks to bugs in the memory management and the garbage collector.
\ No newline at end of file
diff --git a/docs/content/implementation/c2ec-db.tex b/docs/content/implementation/database.tex
index d012694..db4dc9c 100644
--- a/docs/content/implementation/c2ec-db.tex
+++ b/docs/content/implementation/database.tex
@@ -1,4 +1,4 @@
-\subsection{Database}
+\section{Database}
 
 The Database is implemented using Postgresql. This database is also used by other Taler components and therefore is a good fit.
 
@@ -6,12 +6,12 @@ Besides the standard SQL features to insert and select data, Postgres also comes
 
 This allows the implementation of neat pub/sub models allowing better performance and separation of concerns.
 
-\subsubsection{Schema}
+\subsection{Schema}
 
-For the C2EC component the schema c2ec is created. It holds three tables and three triggers.
+For the C2EC component the schema c2ec is created. It holds three tables, custom types and triggers.
 
-\subsubsection{Triggers}
+\subsection{Triggers}
 
-Two types of triggers are implemented. One type notifies listeners about the update of a withdrawal entry. The trigger runs every time an entry is created using INSERT statements and every time a change of the withdrawal status field is detected.
+Triggers are used to decouple the different sub processes in the withdrawal flow from one another.
 
 The trigger runs a Postgres function which will execute a NOTIFY statement using Postgres built-in function \textit{pg\_notify}, which wraps the statement in a Postgres function allowing to be used more easy.
diff --git a/docs/content/implementation/testing.tex b/docs/content/implementation/testing.tex
new file mode 100644
index 0000000..f226abd
--- /dev/null
+++ b/docs/content/implementation/testing.tex
@@ -0,0 +1,5 @@
+\section{Testing}
+
+Since the program leverages concurrency and operates in a distributed way, it is difficult to test besides unit testing. Therefore a simulation client and simulation program was implemented which allows to test the C2EC component while simulating the different involved parties like the terminal, wallet and the providers backend system. This setup allows to test and therefore proof the functionality of the system.
+
+Besides the automated tests, using the above mentioned simulation, manual test were executed and done.
diff --git a/docs/project.bib b/docs/project.bib
index eda9684..32deea7 100644
--- a/docs/project.bib
+++ b/docs/project.bib
@@ -92,6 +92,13 @@
     howpublished = {\url{https://app-wallee.com/connectors}}
 }
 
+@misc{wallee-api-authentication,
+    author = {Wallee},
+    title  = {Authentication},
+    url    = {https://app-wallee.com/en-us/doc/api/web-service#_authentication},
+    howpublished = {\url{https://app-wallee.com/en-us/doc/api/web-service#_authentication}}
+}
+
 @misc{rfc8959,
     series =    {Request for Comments},
     number =    8959,
@@ -137,6 +144,36 @@
     abstract =  {A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. {[}STANDARDS-TRACK{]}},
 }
 
+@misc{rfc3629,
+    series =    {Request for Comments},
+    number =    3629,
+    howpublished =  {RFC 3629},
+    publisher = {RFC Editor},
+    doi =       {10.17487/RFC3629},
+    url =       {https://www.rfc-editor.org/info/rfc3629},
+    author =    {François Yergeau},
+    title =     {{UTF-8, a transformation format of ISO 10646}},
+    pagetotal = 14,
+    year =      2003,
+    month =     nov,
+    abstract =  {ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.},
+}
+
+@misc{rfc7617,
+    series =    {Request for Comments},
+    number =    7617,
+    howpublished =  {RFC 7617},
+    publisher = {RFC Editor},
+    doi =       {10.17487/RFC7617},
+    url =       {https://www.rfc-editor.org/info/rfc7617},
+    author =    {Julian Reschke},
+    title =     {{The 'Basic' HTTP Authentication Scheme}},
+    pagetotal = 15,
+    year =      2015,
+    month =     sep,
+    abstract =  {This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.},
+}
+
 @misc{fips-180-4,
   author = {Quynh Dang},
   title = {Secure Hash Standard},
@@ -168,18 +205,33 @@
     howpublished = {\url{https://docs.taler.net/core/api-bank-integration.html}}
 }
 
-@misc{taler-wirewatch-gateway-api,
+@misc{taler-wire-gateway-api,
     author = {Taler},
     title = {Taler Wire Gateway HTTP API},
     url = {https://docs.taler.net/core/api-bank-wire.html},
     howpublished = {\url{https://docs.taler.net/core/api-bank-wire.html}}
 }
 
-@misc{taler-c2ec-spec,
-    author = {Joel Häberli},
-    title = {The C2EC RESTful API},
-    url = {https://git.taler.net/docs.git/tree/core/api-c2ec.rst},
-    howpublished = {\url{https://git.taler.net/docs.git/tree/core/api-c2ec.rst}}
+@misc{taler-wire-gateway-api-authentication,
+    author = {Taler},
+    title = {Taler Wire Gateway HTTP API},
+    url = {https://docs.taler.net/core/api-bank-wire.html#authentication},
+    howpublished = {\url{https://docs.taler.net/core/api-bank-wire.html#authentication}}
+}
+
+@misc{taler-bank-core-authentication,
+    author = {Taler},
+    title = {Authentication},
+    url = {https://docs.taler.net/core/api-corebank.html#authentication},
+    howpublished = {\url{https://docs.taler.net/core/api-corebank.html#authentication}}
+}
+
+@misc{taler-design-document-49,
+    author = {Taler},
+    title = {Authentication},
+    url = {https://docs.taler.net/design-documents/049-auth.html},
+    howpublished = {\url{https://docs.taler.net/design-documents/049-auth.html}}
+
 }
 
 @misc{wallet-withdrawal,
@@ -188,3 +240,78 @@
     url          = {https://docs.taler.net/taler-wallet.html#withdrawal},
     howpublished = {\url{https://docs.taler.net/taler-wallet.html#withdrawal}}
 }
+
+@misc{postgres-notify,
+    author = {PostgreSQL},
+    title = {NOTIFY},
+    url = {https://www.postgresql.org/docs/current/sql-notify.html},
+    howpublished = {\url{https://www.postgresql.org/docs/current/sql-notify.html}}
+}
+
+@misc{postgres-listen,
+    author = {PostgreSQL},
+    title = {LISTEN},
+    url = {https://www.postgresql.org/docs/current/sql-listen.html},
+    howpublished = {\url{https://www.postgresql.org/docs/current/sql-listen.html}}
+}
+
+@misc{golang-contexts-and-structs,
+    author       = {Jean de Klerk, Matt T. Proud},
+    title        = {Contexts and structs},
+    year         = {2021},
+    month        = {February},
+    day          = {24},
+    url          = {https://go.dev/blog/context-and-structs},
+    howpublished = {\url{https://go.dev/blog/context-and-structs}}
+}
+
+@misc{golang-share-by-communicating,
+    author = {Go},
+    title  = {Share by communicating},
+    url    = {https://go.dev/doc/effective_go#sharing},
+    howpublished = {\url{https://go.dev/doc/effective_go#sharing}},
+}
+
+@misc{golang-goroutines,
+    author = {Go},
+    title  = {Goroutines},
+    url    = {https://go.dev/doc/effective_go#goroutines},
+    howpublished = {\url{https://go.dev/doc/effective_go#goroutines}},
+}
+
+@book{loosley-coupled,
+    author = {Kaye, Doug},
+    title = {Loosely Coupled: The Missing Pieces of Web Services},
+    year = {2003},
+    isbn = {1881378241},
+    publisher = {RDS Press},
+    doi = {10.5555/996526}
+}
+
+@article{ieee-soa-architecture-patterns,
+    author = {Stal, Michael},
+    title = {Using Architectural Patterns and Blueprints for Service-Oriented Architecture},
+    year = {2006},
+    issue_date = {March 2006},
+    publisher = {IEEE Computer Society Press},
+    address = {Washington, DC, USA},
+    volume = {23},
+    number = {2},
+    issn = {0740-7459},
+    abstract = {Some experts view service-oriented architecture simply as a stack of XML Web services protocols. From a more conceptual point of view, however, SOA represents a paradigm consisting of a set of architectural principles for building loosely coupled software systems. Actually, the SOA paradigm applies not only to XML Web services but also to other technologies such as email clients and servers and message-oriented middleware. Software patterns can express almost all architecture principles that span SOA technologies. This architecture-centric approach offers the means to understand service-oriented infrastructures and to build SOA applications that meet operational and developmental properties. Additionally, best practice pattern systems and catalogs can be derived from these architectural principles to illustrate how to implement SOA applications effectively and efficiently. Last but not least, an architectural description of SOA helps to change or extend the paradigm when necessary--for example, to address additional problems such as the support of integrative and adaptive SOA approaches.This article is part of a special issue on software architecture.},
+    journal = {IEEE Softw.},
+    month = {mar},
+    pages = {54–61},
+    numpages = {8},
+    keywords = {Distributed Applications, Distributed Objects, Middleware/Business Logic, Patterns, Software Architecture},
+    doi = {10.5555/1128592.1128710}
+}
+
+@book{event-driven-architecture,
+    author = {Rocha, Hugo},
+    year = {2022},
+    month = {01},
+    title = {Practical Event-Driven Microservices Architecture: Building Sustainable and Highly Scalable Event-Driven Microservices},
+    isbn = {978-1-4842-7467-5},
+    doi = {10.1007/978-1-4842-7468-2}
+}
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
index 5881787..71efce5 100644
--- a/docs/thesis.pdf
+++ b/docs/thesis.pdf
diff --git a/docs/thesis.tex b/docs/thesis.tex
index 8d3665e..9a50d03 100644
--- a/docs/thesis.tex
+++ b/docs/thesis.tex
@@ -195,6 +195,8 @@
 \input{content/architecture/wallee}
 
 \chapter{Implementation}
+\input{content/implementation/concepts}
+\input{content/implementation/database}
 \input{content/implementation/c2ec}
 \input{content/implementation/terminal}
 \input{content/implementation/wallet}
diff --git a/simulation/c2ec-simulation b/simulation/c2ec-simulation
index 764e098..df914de 100755
--- a/simulation/c2ec-simulation
+++ b/simulation/c2ec-simulation