commit 33afa2a15d34bdfa40ceade5a4a401a8b9d55646
parent 26b3cbee88a377ea14833610b8fad27c3dbb9832
Author: Casaburi Johannes <johannes.casaburi@students.bfh.ch>
Date: Tue, 4 Jun 2024 16:10:54 +0200
doc minor changes
Diffstat:
10 files changed, 160 insertions(+), 130 deletions(-)
diff --git a/doc/thesis/chapters/approach/concept.tex b/doc/thesis/chapters/approach/concept.tex
@@ -1,5 +1,5 @@
\section{The Concept}
-The Donau\footnote{short for donation authority} environment includes three stakeholders. Donors, charities and the tax authority. The Donau server itself is operated by the tax authority while maintaining a list of verified charities. Each charity maintains a backend solution that allows it to communicate with the Donau and the donors. See Figure \ref{fig:stakeholders} \pageref{fig:stakeholders}
+The Donau (donation authority) environment includes three stakeholders. Donors, charities and the tax authority. The Donau itself is operated by the tax authority while maintaining a list of verified charities. Each charity maintains a backend solution that allows it to communicate with the Donau and the donors. See Figure \ref{fig:stakeholders} \pageref{fig:stakeholders}
\begin{figure}[ht]
\begin{center}
@@ -25,7 +25,7 @@ The Donau\footnote{short for donation authority} environment includes three stak
\end{figure}
\subsection{Issuing Donation Receipts}
-When donating to a charity the donor sends the payment together with a receipt request to the charity. In order to link the donation to the donor so that the donation receipt cannot be used by someone else, the donor's unique tax identification number is part of the receipt request. The tax id number does not cause a problem for anonymity as the hole receipt with the id number is blinded (see section 2.x). In the picture \ref{fig:issue receipt request} \pageref{fig:issue receipt request} the blinded receipt is illustrated as an envelope. The charity must verify if the payment was successful and if the amount written in the receipt request is lower or equal the amount donated. Next, if the charity approves the receipt request, it signs the untouched request and forwards the request to the Donau. The Donau accepts only issue requests from verified charities. If this is the case, the Donau issues the actual donation receipt by signing the request. This is different from the current model where the charity issues the receipt. By shifting this task to the Donau, the receipts can easily be verified and unlinks the donor from the charity. Because the Donau does only know the amount and the charity it is signing for, this first step of issuing receipts provides anonymity for the donor opposite the Donau (and depending on how it was paid, also opposite the charity).
+When donating to a charity the donor sends the payment together with a receipt request to the charity. In order to link the donation to the donor so that the donation receipt cannot be used by someone else, the donor's unique tax identification number is part of the receipt request. The tax ID does not cause a problem for anonymity as the whole receipt with the tax ID is blinded (see section 2.x). In the figure \ref{fig:issue receipt request} \pageref{fig:issue receipt request} the blinded receipt is illustrated as an envelope. The charity must verify if the payment was successful and if the amount written in the receipt request is lower or equal the amount donated. Next, if the charity approves the receipt request, it signs the unmodified request and forwards the request to the Donau. The Donau accepts only issued requests from verified charities. If the charity signature is valid, the Donau issues the actual donation receipt by signing the request. This is different from the current system donations are made, where the charity issues the receipt. By shifting this task to the Donau, the receipts can easily be verified and unlink the donor from the charity. Because the Donau does only know the amount and the charity it is signing for, this first step of issuing receipts anonymizes the data and provides privacy for the donor. If the payment process also provides anonymity (as the case is in GNU Taler) the donations are fully anonymous.
\begin{figure}[ht]
\begin{center}
@@ -48,7 +48,7 @@ When donating to a charity the donor sends the payment together with a receipt r
\caption{issue receipt request} \label{fig:issue receipt request}
\end{figure}
-Upon receiving the signed issue request from the charity, the Donau must verify the charity signature and checks that the yearly donation limit of a chairty is not exceeded. After successful verification the Donau creates a blinded donation receipt which is sent via charity to the Donor (see figure: \ref{fig:issue receipt response} \pageref{fig:issue receipt response}). The donor now unblinds the signature from the Donau to make it valid for the unblinded receipt (see section 2.x). The unblinded receipt gets saved on the donors device for later. This process repeats for every donation. At the end of the year the donor may have accumulated a bunch of these donation receipts.
+Upon receiving the signed issue request from the charity, the Donau must verify the charity signature and checks that the yearly donation limit of a chairty is not exceeded. After successful verification the Donau blind signs the donation receipt which is then sent via the charity back to the Donor (see figure: \ref{fig:issue receipt response} \pageref{fig:issue receipt response}). The donor now unblinds the signature from the Donau to make it valid for the unblinded receipt (see section 2.x). The unblinded receipt gets saved locally on the donors device for later. This process repeats for every donation. At the end of the year the donor may have accumulated any number of these donation receipts.
\begin{figure}[ht]
\begin{center}
@@ -72,7 +72,7 @@ Upon receiving the signed issue request from the charity, the Donau must verify
\end{figure}
\subsection{Summarize the Receipts}
-When it is time for the tax declaration (usually at the beginning of the next year) the donor has to request a final donation statement signature from the Donau, summarizing all the donation receipts of a year (see figure: \ref{fig:summarize receipts} \pageref{fig:summarize receipts}). This step combines the amounts of the donation receipts in a single total amount. This protects the privacy of the donor because the individual donation amounts could be enough information to link with specific donations. Merging donation receipts reduces the time and effort for the manual verification of the tax authority. The statement signature is made besides the total amount, over the year and the tax id. The donation statement can be requested multiple times during the year for save keeping the donation receipts. The latest donation statement will always contain all the receipts of a year - the old receipts (from a previous statement) and the new donation receipts.
+When it is time for the tax declaration (usually at the beginning of the next year) the donor has to request a final donation statement signature from the Donau, summarizing all the donation receipts of a year (see figure: \ref{fig:summarize receipts} \pageref{fig:summarize receipts}). This step combines the amounts of the donation receipts in a single total amount. This further protects the privacy of the donor as the individual donations could be enough information to link with specific donations to their corresponding charity and donor. Merging donation receipts reduces the time and effort for the manual verification of the tax authority as donor generates a single QR-Code containing the donation statement. The signs over the total amount donated, the year and the tax ID. This is the signature which is used to verify the donation statement by the tax authority. The donation statement can be requested multiple times during the year for save keeping the donation receipts. The latest donation statement will always contain all the receipts of a year - the old receipts (from a previous statement) and the new donation receipts.
\begin{figure}[ht]
\begin{center}
@@ -108,7 +108,7 @@ When it is time for the tax declaration (usually at the beginning of the next ye
\end{figure}
\subsection{Validation}
-Once the donor has received the values, he can summarize them in a QR code. The donor must submit the QR-Code with their tax return in order to claim the donation reduction (see figure:\ref{fig:validation} \pageref{fig:validation}). The final check is made by the tax authority, by checking the donation statement signature. If the signature is valid, this is the proof that the specified donor indeed has donated the claimed amount in the indicated year.
+Once the donor has received the donation statement signature, they can summarize them in a QR code. The donor must submit the QR-Code with their tax documents, in order to claim the tax reduction (see figure:\ref{fig:validation} \pageref{fig:validation}). The final check is made by the tax authority, by checking the donation statement signature. If the signature is valid, this is the proof that the specified donor indeed has donated the claimed amount in the indicated year.
\begin{figure}[ht]
\begin{center}
@@ -134,10 +134,10 @@ Once the donor has received the values, he can summarize them in a QR code. The
\caption{validation} \label{fig:validation}
\end{figure}
-The tax authority will not have any information to what charity the donor has donated money. Everything the tax authority knows is that every donation was made to one of the approved charites in the specified year and the total amount. This way the donor could make an anonymous donation and still have enough proof to deduct the amount from taxes. By keeping track of how much money a charity has received in donations per year and how much a donor has donated throughout the year, tax fraud is essentially eliminated.
+The tax authority will not have any information to which charity the donor has donated money. The tax authority only knows that every donation was made to one of the approved charites in the specified year and the total amount donated to all charities in that list. This way the donor could make an anonymous donation and still have enough proof to deduct the amount from taxes. By keeping track of how much income a charity has generated in donations per year and how much a donor has donated throughout the year, tax fraud is essentially eliminated.
\subsection{Incorporating the Donau}
-Every donor is related to only one specific Donau of his location where he is able to issue and submit donation receipts for deducting taxes. If a charity wants to be accepted in the multiple tax areas, it has to be registered by all the corresponding Donaus. To do so, the charities has to apply to the tax authorities. The region for which a Donau is responsible depends on the tax area of the tax authority and their reglementation of what is charitable. A Donau is maybe responsible for a geographical area like a canton, a country or even a confederation of states. Different Donaus must also be kept for different currencies, but this should not be a problem as most countries have a single currency.
+Every donor is related to only one specific Donau of his location where he is able to issue and submit donation receipts for deducting taxes. If a charity wants to be accepted in multiple tax areas, it has to be registered by all the corresponding donation authorities. To do so, the charities has to apply to the tax authorities. The region for which a Donau is responsible depends on the tax area of the tax authority and their reglementation of what is charitable. A Donau is maybe responsible for a geographical area like a canton, a country or even a confederation of states. Different donation authorities must also be kept for different currencies, but this should not be a problem as most countries have a single currency.
diff --git a/doc/thesis/chapters/implementation/android.tex b/doc/thesis/chapters/implementation/android.tex
@@ -0,0 +1,5 @@
+\section{Android Verification App}
+The android app is part of the verification process used by the tax authority to check the donation statement (see xx).
+
+It is possible to define an URI scheme for an android app. The app opens when the link is activated. The arguments defined in chapter Protocol xx are separated with slashes. To ensure that as many characters as possible can be stored in the QR code, the QR code should be alphanumeric encoded\footnote{alphanumeric encoded QR codes have a capaticity of up to 4296 characters and support only a few special characters}. This means that each argument is stringified. To ensure that no special characters are used for binary data, the hash and the signature are encoded in ASCII using CrockfordBase32.\cite{qrcodedensowavewebsite}
+%TODO: Add Link example
diff --git a/doc/thesis/chapters/implementation/arch.tex b/doc/thesis/chapters/implementation/arch.tex
@@ -0,0 +1,4 @@
+\section{System Architecture}
+As the charity backend and donor wallet implementation are not yet developed the following architecture is reduced to the Donau backend, the client API calls and the API tests.
+% The android app
+% TODO: architecture image
diff --git a/doc/thesis/chapters/implementation/donau.tex b/doc/thesis/chapters/implementation/donau.tex
@@ -0,0 +1,122 @@
+
+\section{Donau}
+The Donau is written in C as it reuses parts of the codebase from the exchange of GNU Taler[xx]. The Donau has a similar architecture and uses crypographic blinded signatures in a similar way as the exchange does.
+
+\subsection{REST API}
+The detailed REST API specificatoin of the Donau backend is publicy available at the following url: \url{https://docs.taler.net/core/api-donau.html}. The following are the main API endpoints:
+
+%json examples
+
+\subsubsection{\texttt{/keys}}
+The \texttt{GET /keys} request returns all valid donation unit public keys offered by the Donau, as well as the Donau's current EdDSA public signing key. Donation units unit keys are used by the Donau to sign blinded messages for an issue receipt request. The signing key is primarily used to create the donation statement signature for the donor (see section xx).
+
+%curl 127.0.0.1:8080/keys
+%\begin{listings}
+% response
+%\end{listings}
+
+\subsubsection{\texttt{/charities}}
+In order for a charity to be able to issue receipts it must be registered by the Donau. To do so the Donau provides an API to manage charities. It is recommended that only the Donau admin can update charities while the charity itself should be able to request their issued donation receipt state to keep track of the set donation limit. The state includes the maximum donation amount and the current donated amount for the charity of the current year.
+
+%curl 127.0.0.1:8080/charities
+%\begin{listings}
+% response
+%\end{listings}
+
+\begin{figure}[ht]
+\includegraphics[width=1\textwidth]{donau_flow_register_charity}
+\caption{flow chart register charity} \label{fig:donau_flow_register_charity}
+\end{figure}
+
+\subsubsection{\texttt{/batch-issue}}
+%TODO describe BUDI, donation unit -> glossary?
+Only recognized charities requesting issue receipts for their donors (see section xx). An post issue receipt request includes an array of BUDI-Key-Pairs. A BUDI-Key-Pair consists of a BUDI and a hash of a public donation unit key. The charity also signs the request with an EdDSA private key. The corresponding public key was given to the Donau at the registration of the charity. After the Donau checked the signature from the charity it signs the BUDIs with the corresponding donation unit private key. Before the signatures are returned to the charity the Donau saves a hash of the request and all donation unit signatures to make the request idempotent (see database section).
+
+\begin{figure}[ht]
+\includegraphics[width=1\textwidth]{donau_flow_issue_receipt}
+%\caption{flow chart issue receipt} \label{fig:donau_flow_issue_receipt}
+\end{figure}
+
+\subsubsection{\texttt{/batch-submit}}
+%TODO describe donation receipt -> glossary?
+The post submit route is used by the donor to summarize his or her donation receipts into one donation statement EdDSA signature. The request is composed of the donation receipt, the corresponding year and the hash of the salted tax id. Processing the request the Donau checks the validity of the donation receipts and searches after more saved donation receipts made in the requested year. The EdDSA signature over the total amount of the value of the donation units of all donation receipts, the hash of the salted tax id and the year forms the donation statement. The donation statement and the receipts are stored in the database (see database).
+
+\subsubsection{\texttt{/donation-statement}}
+Even the donation statement will not be returned after a submit request, a donation statement get request can be made for a specified year and a salted and hashed tax id.
+
+\begin{figure}[ht]
+\includegraphics[width=1\textwidth]{donau_flow_submit_receipt}
+%\caption{flow chart submit receipt} \label{fig:donau_flow_submit_receipt}
+\end{figure}
+
+\subsection{Donau Client}
+The REST client removes some of the complexity of sending requests to the Donau Server. It converts request parameters into JSON and parses JSON responses into a usable C format. What the exact queries are and how they look like is already described in the chapter xx Donau REST API.
+
+\subsection{Donau Database}
+The Donau database contains five tables as shown in the figure below. The \texttt{donation\_units} and \texttt{donau\_sign\_keys} table store the keys necessary for signing and creating donation receipts. Donation receipts that are issued to be signed by the donau are stored in the \texttt{receipts\_issued} table while the receipts that are already signed are stored in the \texttt{receipts\_submitted} table. The \texttt{history} table keeps the donation records of the past years.
+
+\begin{figure}[ht]
+\includegraphics[width=1\textwidth]{db_physical_model}
+\caption{database physical model} \label{fig:db_physical_model}
+\end{figure}
+\subsubsection{charities}
+Each registered charity has an entry in this table. There may be a donation limit imposed by local law which prevents further donations if the limit is reached.
+\begin{itemize}
+ \item \texttt{charity\_id:} Unique ID generated by the database.
+ \item \texttt{charity\_pub:} Charity EdDSA public key
+ \item \texttt{charity\_name:} Name of the charity
+ \item \texttt{charity\_url:} Charity URL
+ \item \texttt{max\_per\_year:} The annual donation limit according to local law.
+ \item \texttt{receipts\_to\_date:} The current amount of donations in the current year. Reset to 0 when incrementing the \texttt{current\_year}.
+ \item \texttt{current\_year:} Current year
+\end{itemize}
+
+\subsubsection{donation\_units}
+Table containing all the valid donation units the Donau knows about.
+\begin{itemize}
+ \item \texttt{donation\_unit\_serial:} Unique ID generated by the database.
+ \item \texttt{h\_donation\_unit\_pub:} Hash value of the donation unit public key \texttt{donation\_unit\_pub}
+ \item \texttt{donation\_unit\_pub:} The donation unit public key. Is either an RSA or CS public key.
+ \item \texttt{validity\_year:} The year, for which the donation unit is valid.
+ \item \texttt{value:} The amount and currency that this donation unit represents.
+\end{itemize}
+
+\subsubsection{donau\_sign\_keys}
+Contains all Donau EdDSA signing keys.
+\begin{itemize}
+ \item \texttt{dsk\_serial:} Unique ID generated by the database.
+ \item \texttt{donau\_pub:} Donau EdDSA public key.
+ \item \texttt{valid\_from:} Year the signing key becomes valid.
+ \item \texttt{expire\_sign:} Year the signing key becomes invalid.
+ \item \texttt{expire\_legal:} Year the signing key legaly expires.
+\end{itemize}
+
+\subsubsection{receipts\_issued}
+Contains all issued donation receipts sent to the Donau.
+\begin{itemize}
+ \item \texttt{receipt\_id:} Unique ID generated by the database.
+ \item \texttt{blinded\_sig:} Array of blinded signatures. These are the \texttt{BKP}'s the Donau blind signed.
+ \item \texttt{charity\_id:} The ID of the charity that received the donation.
+ \item \texttt{receipt\_hash:} Hash value over all the blinded donation receipt received plus the hash of the donation units public key.
+ \item \texttt{amount:} The amount and currency this donation receipt contains.
+\end{itemize}
+
+\subsubsection{receipts\_submitted}
+Contains all submitted donation receipts sent to the Donor. By storing the signature \texttt{donation\_unit\_sig}, the idempotentcy of the API is kept in case the private key is replaced.
+\begin{itemize}
+ \item \texttt{receipt\_id:} Unique ID generated by the database.
+ \item \texttt{h\_tax\_number:} The hash of the tax number and salt.
+ \item \texttt{nonce:} The nonce used in the \texttt{Unique Donor Identifier}
+ \item \texttt{donation\_unit\_pub:} Reference to public key used to sign.
+ \item \texttt{donation\_unit\_sig:} The unblided signature the Donau made.
+ \item \texttt{donation\_year:} The year the donation was made.
+\end{itemize}
+
+\subsubsection{history}
+History of the yearly donations for each charity. This data provides a record of donations each year. It could also provide valuable information that could be used in statistics to analize general donations over the year.
+\begin{itemize}
+ \item \texttt{charity\_id:} Unique ID generated by the database.
+ \item \texttt{final\_amount:} The final amount that was donated to the charity
+ \item \texttt{donation\_year:} The year in which the donations where made.
+\end{itemize}
+
diff --git a/doc/thesis/chapters/implementation/implementation.tex b/doc/thesis/chapters/implementation/implementation.tex
@@ -1,120 +0,0 @@
-In this chapter the architecture and the implementation details of the Donau system are described.
-
-\section{System Architecture}
-As the charity backend and the wallet implementation are not yet developed the followed described architecture is reduced to the Donau backend, the client API calls, the tests and the android app.
-% TODO: architecture image
-
-\section{Donau}
-The Donau is written in C as it reuses parts of the codebase from the exchange of GNU Taler[xx]. The Donau has a similar architecture and uses crypographic blinded signatures in a similar way as the exchange does.
-
-\subsection{Donau REST API}
-The detailed REST API of the Donau backend is publicy available at \url{https://docs.taler.net/core/api-donau.html}. The following are the main API endpoints:
-
-\paragraph{Keys}
-The get keys request returns all valid donation unit public keys offered by the Donau, as well as the Donau's current EdDSA public signing key. Donation units unit keys are used by the Donau to sign blinded messages for an issue receipt request. The signing key is primarily used to create the donation statement signature for the donor (see section xx).
-
-\subsubsection{Manage Charities}
-In order for a charity to be able to issue receipts it must be registered by the Donau. To do so the Donau provides an API to manage charities. It is recommended that only the Donau admin can update charities while the charity itself should be able to request their issued donation receipt state to keep track of the set donation limit. The state includes the maximum donation amount and the current donated amount for the charity of the current year.
-
-\begin{figure}[ht]
-\includegraphics[width=1\textwidth]{donau_flow_register_charity}
-\caption{flow chart register charity} \label{fig:donau_flow_register_charity}
-\end{figure}
-
-\subsubsection{Issue Receipts}
-%TODO describe BUDI, donation unit -> glossary?
-Only recognized charities requesting issue receipts for their donors (see section xx). An post issue receipt request includes an array of BUDI-Key-Pairs. A BUDI-Key-Pair consists of a BUDI and a hash of a public donation unit key. The charity also signs the request with an EdDSA private key. The corresponding public key was given to the Donau at the registration of the charity. After the Donau checked the signature from the charity it signs the BUDIs with the corresponding donation unit private key. Before the signatures are returned to the charity the Donau saves a hash of the request and all donation unit signatures to make the request idempotent (see database section).
-
-\begin{figure}[ht]
-\includegraphics[width=1\textwidth]{donau_flow_issue_receipt}
-%\caption{flow chart issue receipt} \label{fig:donau_flow_issue_receipt}
-\end{figure}
-
-\subsubsection{Submit Receipts}
-%TODO describe donation receipt -> glossary?
-The post submit route is used by the donor to summarize his or her donation receipts into one donation statement EdDSA signature. The request is composed of the donation receipt, the corresponding year and the hash of the salted tax id. Processing the request the Donau checks the validity of the donation receipts and searches after more saved donation receipts made in the requested year. The EdDSA signature over the total amount of the value of the donation units of all donation receipts, the hash of the salted tax id and the year forms the donation statement. The donation statement and the receipts are stored in the database (see database).
-
-\subsubsection{Donation Statement}
-Even the donation statement will not be returned after a submit request, a donation statement get request can be made for a specified year and a salted and hashed tax id.
-
-\begin{figure}[ht]
-\includegraphics[width=1\textwidth]{donau_flow_submit_receipt}
-%\caption{flow chart submit receipt} \label{fig:donau_flow_submit_receipt}
-\end{figure}
-
-\subsection{Donau Client}
-The REST client removes some of the complexity of sending requests to the Donau Server. It converts request parameters into JSON and parses JSON responses into a usable C format. What the exact queries are and how they look like is already described in the chapter xx Donau REST API.
-
-\subsection{Donau Database}
-The Donau database contains five tables as shown in the figure below. The \texttt{donation\_units} and \texttt{donau\_sign\_keys} table store the keys necessary for signing and creating donation receipts. Donation receipts that are issued to be signed by the donau are stored in the \texttt{receipts\_issued} table while the receipts that are already signed are stored in the \texttt{receipts\_submitted} table. The \texttt{history} table keeps the donation records of the past years.
-
-\begin{figure}[ht]
-\includegraphics[width=1\textwidth]{db_physical_model}
-\caption{database physical model} \label{fig:db_physical_model}
-\end{figure}
-\subsubsection{charities}
-Each registered charity has an entry in this table. There may be a donation limit imposed by local law which prevents further donations if the limit is reached.
-\begin{itemize}
- \item \texttt{charity\_id:} Unique ID generated by the database.
- \item \texttt{charity\_pub:} Charity EdDSA public key
- \item \texttt{charity\_name:} Name of the charity
- \item \texttt{charity\_url:} Charity URL
- \item \texttt{max\_per\_year:} The annual donation limit according to local law.
- \item \texttt{receipts\_to\_date:} The current amount of donations in the current year. Reset to 0 when incrementing the \texttt{current\_year}.
- \item \texttt{current\_year:} Current year
-\end{itemize}
-
-\subsubsection{donation\_units}
-Table containing all the valid donation units the Donau knows about.
-\begin{itemize}
- \item \texttt{donation\_unit\_serial:} Unique ID generated by the database.
- \item \texttt{h\_donation\_unit\_pub:} Hash value of the donation unit public key \texttt{donation\_unit\_pub}
- \item \texttt{donation\_unit\_pub:} The donation unit public key. Is either an RSA or CS public key.
- \item \texttt{validity\_year:} The year, for which the donation unit is valid.
- \item \texttt{value:} The amount and currency that this donation unit represents.
-\end{itemize}
-
-\subsubsection{donau\_sign\_keys}
-Contains all Donau EdDSA signing keys.
-\begin{itemize}
- \item \texttt{dsk\_serial:} Unique ID generated by the database.
- \item \texttt{donau\_pub:} Donau EdDSA public key.
- \item \texttt{valid\_from:} Year the signing key becomes valid.
- \item \texttt{expire\_sign:} Year the signing key becomes invalid.
- \item \texttt{expire\_legal:} Year the signing key legaly expires.
-\end{itemize}
-
-\subsubsection{receipts\_issued}
-Contains all issued donation receipts sent to the Donau.
-\begin{itemize}
- \item \texttt{receipt\_id:} Unique ID generated by the database.
- \item \texttt{blinded\_sig:} Array of blinded signatures. These are the \texttt{BKP}'s the Donau blind signed.
- \item \texttt{charity\_id:} The ID of the charity that received the donation.
- \item \texttt{receipt\_hash:} Hash value over all the blinded donation receipt received plus the hash of the donation units public key.
- \item \texttt{amount:} The amount and currency this donation receipt contains.
-\end{itemize}
-
-\subsubsection{receipts\_submitted}
-Contains all submitted donation receipts sent to the Donor. By storing the signature \texttt{donation\_unit\_sig}, the idempotentcy of the API is kept in case the private key is replaced.
-\begin{itemize}
- \item \texttt{receipt\_id:} Unique ID generated by the database.
- \item \texttt{h\_tax\_number:} The hash of the tax number and salt.
- \item \texttt{nonce:} The nonce used in the \texttt{Unique Donor Identifier}
- \item \texttt{donation\_unit\_pub:} Reference to public key used to sign.
- \item \texttt{donation\_unit\_sig:} The unblided signature the Donau made.
- \item \texttt{donation\_year:} The year the donation was made.
-\end{itemize}
-
-\subsubsection{history}
-History of the yearly donations for each charity. This data provides a record of donations each year. It could also provide valuable information that could be used in statistics to analize general donations over the year.
-\begin{itemize}
- \item \texttt{charity\_id:} Unique ID generated by the database.
- \item \texttt{final\_amount:} The final amount that was donated to the charity
- \item \texttt{donation\_year:} The year in which the donations where made.
-\end{itemize}
-
-\section{Android Verification App}
-The android app is part of the verification process used by the tax authority to check the donation statement (see xx).
-
-It is possible to define an URI scheme for an android app. The app opens when the link is activated. The arguments defined in chapter Protocol xx are separated with slashes. To ensure that as many characters as possible can be stored in the QR code, the QR code should be alphanumeric encoded\footnote{alphanumeric encoded QR codes have a capaticity of up to 4296 characters and support only a few special characters}. This means that each argument is stringified. To ensure that no special characters are used for binary data, the hash and the signature are encoded in ASCII using CrockfordBase32.\cite{qrcodedensowavewebsite}
-%TODO: Add Link example
diff --git a/doc/thesis/chapters/results/discussion.tex b/doc/thesis/chapters/results/discussion.tex
diff --git a/doc/thesis/chapters/results/future.tex b/doc/thesis/chapters/results/future.tex
@@ -0,0 +1,10 @@
+\section{Future work}
+%donor client
+%charity merchant backend
+%spa
+%
+The donor client implementation needs to be implemented in the Taler wallet. This is a necessary step to be able to use the Donau together with the Taler payment system. Then donations could be made fully anonymous.
+
+Each registered charity needs to communicate with the donors and the Donau. The Taler merchant backend needs to be modified to incrporate the charity backend logic.
+
+For the administrator a single page application is needed to comftably manage the charities. This would include functionality to add, remove and modify charities.
diff --git a/doc/thesis/chapters/results/results.tex b/doc/thesis/chapters/results/results.tex
@@ -0,0 +1,6 @@
+\section{Results}
+Currently the Donau REST API is fully implemented.
+%...
+
+Important components that are needed to operate the Donau are not yet implemented. This includes the charity side and donor client side. Although test where written to ensure that the Donau endpoints operate as expected, there are still some bugs and most likely also unknown bugs, not yet found.
+
diff --git a/doc/thesis/thesis.pdf b/doc/thesis/thesis.pdf
Binary files differ.
diff --git a/doc/thesis/thesis.tex b/doc/thesis/thesis.tex
@@ -39,10 +39,13 @@
\input{chapters/protocol/details}
\chapter{Implementation}
-\input{chapters/implementation/implementation}
+\input{chapters/implementation/arch}
+\input{chapters/implementation/donau}
+\input{chapters/implementation/android}
-\chapter{Results and Outlook}
-\input{chapters/results/discussion}
+\chapter{Results and Future work}
+\input{chapters/results/results}
+\input{chapters/results/future}
\bibliography{bibliography}
\addcontentsline{toc}{chapter}{Bibliography}
