commit ae52212789f735c9215d931d931bc21d09f463d8
parent d8c3aa48b2499fac5dbf82798b0c2909f4303b4d
Author: Matyja Lukas Adam <lukas.matyja@students.bfh.ch>
Date: Thu, 6 Jun 2024 15:08:50 +0200
merge
Diffstat:
15 files changed, 83 insertions(+), 42 deletions(-)
diff --git a/doc/thesis/chapters/approach/concept.tex b/doc/thesis/chapters/approach/concept.tex
@@ -1,4 +1,7 @@
-The Donau 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}
+The Donau 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}
@@ -20,11 +23,22 @@ The Donau environment includes three stakeholders. Donors, charities and the tax
\draw (1,-1) -- (3,-2.5);
\end{tikzpicture}
\end{center}
-\caption{stakeholders} \label{fig:stakeholders}
+\caption{Stakeholders present in the Donau system.} \label{fig:stakeholders}
\end{figure}
-\section{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 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.
+\section{Issuing Donation Receipts} \label{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 does not cause a problem for anonymity as the whole receipt with the tax ID is blinded (see section \ref{blind_signatures}).
+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}
@@ -47,7 +61,11 @@ 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 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.
+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 \ref{blind_signatures}).
+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}
@@ -70,8 +88,15 @@ Upon receiving the signed issue request from the charity, the Donau must verify
\caption{issue receipt response} \label{fig:issue receipt response}
\end{figure}
-\section{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 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.
+\section{Summarize the Receipts}\label{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 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}
@@ -106,8 +131,11 @@ When it is time for the tax declaration (usually at the beginning of the next ye
\caption{summarize receipts} \label{fig:summarize receipts}
\end{figure}
-\section{Validation}
-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.
+\section{Validation}\label{validation}
+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}
@@ -133,10 +161,18 @@ Once the donor has received the donation statement signature, they can summarize
\caption{validation} \label{fig:validation}
\end{figure}
-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.
+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.
-\section{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 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.
+\section{Incorporating the Donau}\label{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 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/background/blindsign.tex b/doc/thesis/chapters/background/blindsign.tex
@@ -1,11 +1,11 @@
-\section{Blind Signatures}
+\section{Blind Signatures}\label{blind_signatures}
One important cryptographic scheme used by the Donau is the blind signature scheme. It is an extension of digital signatures which provides besides authenticity and non-repudiation privacy by allowing a user to obtain a signature for a message, without revealing the contents of the message to the signer. All cryptographic elements used by the Donau where privided by the GNU Taler libraries.
This section only provides an overview of blinded signatures. Detailed information about blinded signature can be found at \url{https://taler.net/papers/cs-thesis.pdf}. Blinded signatures are the key elements to reach privacy for the donor (see chapter xx). With blinded signatures a blinded unrecognizable message was signed. Only the creator of the blinded message is able to unblind the signature and therefore to receive a valid signature for the unblinded message. The Donau system uses blinded signatures to bind the identity to a donation receipt while hiding the identity of the donor. As a result of the property of blindness, the blind signer Donau is not able to link the cleartext message with the made blind signature or the blind with the unblind signature \cite[p.12]{cryptoeprint:2019/877}. There are multiple blind signature schemes. The Donau distinguishes the following two equivalent blind signature schemes:
-\subsection{RSA}
+\subsection{RSA}\label{rsa}
Concrete the RSA-FDH blind signatures are used. Before blinding, to eliminate certain attacks, a Full-Domain Hash on the message is applied. Full-Domain means the hash has the same size as the RSA modulus. The blind signature scheme is similar to the normal RSA signatur scheme. In addition to the normal scheme, the message is blinded with an private and random value. Practically the length of the modulus and therefore for the key size, signature size and the security level is variable. The scheme only has one round trip.\cite{nigelcrypto:2016}
-\subsection{Clause Schnorr (CS)}
+\subsection{Clause Schnorr (CS)}\label{cs}
The Clause Schnorr Signature Scheme differs from the RSA scheme. Initially the blinder needs two random values from the signer party. One random value from the signer and two random private values are required to blind the message once. This process is repeated and the two blinded messages are sent to the signer, who randomly selects a blinded message for blinding. Two blinded messages are needed to prevent an certain type of attack. In comparision to the RSA scheme, the Clause Schnorr Scheme needs an additional round trip to get the inital nonces from the signer. However, the individual crypto operations are so much faster than the operations from the RSA scheme that the additional round trip is no longer significant. See the measurements for this [p.107-121] \cite{DemHeuz2022}. Because clause schnorr signatures are based on elliptic curves, smaller keys can be used. GNU Taler supports one fixed 256 bit key size, which provides an security level of 128 bits.
diff --git a/doc/thesis/chapters/background/eddsa.tex b/doc/thesis/chapters/background/eddsa.tex
@@ -1,3 +1,3 @@
-\section{EdDSA Signatures}
+\section{EdDSA Signatures}\label{eddsa}
With signatures authenticity and non-repudiation want to be achieved. In this context hashes and public key cryptography are used.\cite{hash2012} For this purpose the Donau uses EdDSA signatures. The Edwards-curve Digital Signature Algorithm or for short EdDSA is a scheme for digital signatures based on the twisted Edwards elliptic curves and the Schnorr signature scheme. EdDSA signatures using the curve Curve25519 are also called Ed25519. The Donau only uses Ed25519. Whether Curve25519 or the Edwards-curve, the scheme is very efficient and secure.\cite{BernsteinEd25519}
diff --git a/doc/thesis/chapters/background/hash.tex b/doc/thesis/chapters/background/hash.tex
@@ -1,6 +1,6 @@
The project is based on existing cryptography. This chapter describes only the crucial cryptographic elements used by the Donau.
-\section{Hash Functions}
+\section{Hash Functions}\label{hash}
Hash functions are used to compress input values to a fixed output size. Hash function are deterministic. The same input leads to the same output. The Donau uses hash functions to compress data in order to record less data in the database or to send less data over the network. To be able to clearly recognize the corresponding data from the hash, the hash function has to second-preimage resistant or better collision resistant. With second-preimage resistance no equivalent hash for any input $x'$ to a given hash $h(x)$ with $x \neq x'$ can be found in a reasonable time. Collision resistance is the stronger assumption and even prevents to find $h(x) = h(x')$ with $x \neq x'$. A further important assumption is the Avalanche Criterion. The property defines that a small change in the hash input message leads to a substantially change in the output hash. This criteria makes it hard to guess the input even if a part of the input is known.\cite{hash2012} To protect the donor, his identity is represented as salted hash of the tax identifiaction number. The salt is a small value with high entropy to make it more difficult to guess the hashed value. \\
The Donau uses the SHA-512 hash function. SHA-512 is part of the SHA-2 family and provides a 256 bit security level for collision resistance. The security of the hash function is mathematically approved.\cite{hash-nist}
diff --git a/doc/thesis/chapters/background/taler.tex b/doc/thesis/chapters/background/taler.tex
@@ -1,4 +1,4 @@
-\section{GNU Taler}
+\section{GNU Taler}\label{taler}
GNU Taler is an open protocol for electronic payment system using blind signatures to protect the privacy of the customer.
One key component of the GNU Taler payment system is the exchange which is responsible for exchanging existing money into electronic money. Customers can retrieve funds from the exchange to make anonymous payments. The merchant is not anonymous and thus can not hide the income. This helps to avoid tax evasion and money laundering \cite{Taler}.
diff --git a/doc/thesis/chapters/implementation/android.tex b/doc/thesis/chapters/implementation/android.tex
@@ -1,5 +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).
+\section{Android Verification App}\label{android_verification_app}
+The Android app is part of the verification process used by the tax authority to check the donation statement (see \ref{donor_sends_final_statement_to_a_validator}).
-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}
+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 \ref{donor_sends_final_statement_to_a_validator} 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/introduction/goals.tex b/doc/thesis/chapters/introduction/goals.tex
@@ -1,4 +1,4 @@
-\section{Goals}
+\section{Goals}\label{goals}
The goal of this bachelor thesis is to assess how donations currently work, and to develop and implement a protocol, that aims to improve and standardize how donations are verified and conducted. The Donau should be implemented as free software.
One of the main goals the Donau aims to protect the donors privacy. The donor should still be able to deduct the donations he made from taxes. He should be able to do so without revealing more information than needed to the tax authority. All the tax authority needs is proof that the donation is legitimate.
diff --git a/doc/thesis/chapters/introduction/motivation.tex b/doc/thesis/chapters/introduction/motivation.tex
@@ -1,5 +1,10 @@
+<<<<<<< HEAD
\section{Motivation}
To be able to donate to a charity and deduct that donation from taxes, it is often required to provide evidence. The donor would have to present said evidence in form of a donation receipt which would include information about both the donor and the charity. The donor may want to keep this information private and only provide a receipt that proves that a certain amount was indeed donated to a recognized charity.
+=======
+\section{Motivation}\label{motivation}
+To be able to donate to a charity and deduct that donation from taxes, it is often required to provide evidence. The donor would have to present said evidence in form of a donation receipt which would include information about both the donor and charity. The donor may want to keep this information private and only provide a receipt that proves that a certain amount was indeed donated to a recognized charity.
+>>>>>>> refs/remotes/origin/master
%privacy
There are many reasons why such information can be sensitive and should be hidden from third parties. Both personally and politically this information could be harmful to individuals if not handeled responsably. It is best to reduce and anonymize this information as much as possible, while still having all the necessary information to verify donations and prevent illegal practices.
diff --git a/doc/thesis/chapters/introduction/scope.tex b/doc/thesis/chapters/introduction/scope.tex
@@ -1,4 +1,4 @@
-\section{Scope}
+\section{Scope}\label{scope}
At the start of the project we wrote the REST API specifications together with the database schema and the Donau protocol.
Later tests were written to ensure that the endpoints work correctly without any errors.
During the project we documented the code and created various other documents like presentations and project summaries.
diff --git a/doc/thesis/chapters/protocol/definitions.tex b/doc/thesis/chapters/protocol/definitions.tex
@@ -1,10 +1,10 @@
-\section{Notation \& Definitions }
-\subsection{Notation}
+\section{Notation \& Definitions}\label{notation_and_definitions}
+\subsection{Notation}\label{notation}
\begin{itemize}
\item $\langle a, b, ... \rangle$ : Pair/tuple
\end{itemize}
-\subsection{Definitions}
+\subsection{Definitions}\label{definitions}
\begin{itemize}
\item \textbf{Cryptographic Hash Function}
\begin{displaymath}
diff --git a/doc/thesis/chapters/protocol/details.tex b/doc/thesis/chapters/protocol/details.tex
@@ -1,21 +1,21 @@
-\section{Protocol Details}
+\section{Protocol Details}\label{protocol_details}
-\subsection{Key generation and initial setup}
+\subsection{Key generation and initial setup}\label{key_generation_and_initial_setup}
-\subsubsection{Donau key generation}
+\subsubsection{Donau key generation}\label{donau_key_generation}
\begin{enumerate}
\item The Donau generates a Donau public key $D^{pub}$ and private key $D^{priv}$ for EdDSA signing.
\item The Donau generates the \textbf{Donation Units} consisting of a public key $K_x^{pub}$ and private key $K_x^{priv}$ where $x$ is the associated value.
\end{enumerate}
-\subsubsection{Charity key generation}
+\subsubsection{Charity key generation}\label{charity_key_generation}
\begin{enumerate}
\item The Charity generates a charity public key $(C^{pub}$ and private key $C^{priv})$ and fetches the \textbf{Donation Unit} public keys from the Donau.
\item The Charity transmits its public key $C^{pub}$ and the requested yearly donation limit to the party controlling the Donau (e.g the local tax authority) using a \textbf{secure channel}.
\item The party in charge of Donau administration ensures that the applying charity is authentic and publicly recognized as a charitable organisation. Furthermore, it ensures that all eventual restrictions by law are followed. After the verification was successful the Charity public key $C^{pub}$ together with its requested yearly donation limit are registered in the Donau database.
\end{enumerate}
-\subsection{Donating to a charity}
+\subsection{Donating to a charity}\label{donating_to_a_charity}
% \subsubsection{Donor donates to charity and transmits \textbf{Unique Donor identifiers} (future donation receipts)}
In order to make a donation the donor has to first download the \textbf{Donation Unit} public keys $K_x^{pub}$ from the Donau for the current year.
After that the donor generates his \textbf{Donor Identifier} which is a salted hash of his tax number.
@@ -73,7 +73,7 @@ These individual \textbf{BKP}'s are then put in an array of \textbf{BKP}'s $\vec
The donor sends the array of \textbf{BKP}'s $\vec{\mu}$ as well as the corresponding \textbf{payment} to the charity.
-\subsection{Charity receives donation}
+\subsection{Charity receives donation}\label{charity_receives_donation}
Upon receiving the \textbf{BKP}'s $\vec{\mu}$ with the corresponding payment the charity has to verify that the amount requested (based on the \textbf{Donation Unit} public key hash $h(K_x^{pub})$) for signing is \textbf{lower or equal} to the effective amount of the donation.
If the payment was successful with the correct amount present, the charity signs (using EdDSA) a structure containing all unsigned \textbf{BKP}'s $\vec{\mu}$ coming from the donor.
@@ -85,7 +85,7 @@ Signing the array of BKP's:
The charity sends the \textbf{BKP}'s $\vec{\mu}$ and the signature $\sigma_c$ to the Donau.
-\subsection{Donau creates donation receipt material}
+\subsection{Donau creates donation receipt material}\label{donau_creates_donation_receipt}
The Donau now has received the \textbf{BKP}'s $\vec{\mu}$ previously sent by the charity. The Donau must ensure that the charity signature is valid.
Verifing the charity signature $\sigma_c$:
@@ -106,7 +106,7 @@ Donau blind signing Blinded Unique Donor Identifiers $\overline u_1, \overline u
The signatures $\overline{\beta_1}, \overline{\beta_2}, \overline{\beta_3}$ are then sent back to the charity which inturn forwards them to the donor. This is done out of simplicity as the charity has already a secure channel open with the donor, elmination the need to open another channel.
-\subsection{Donor receives donation receipt material}
+\subsection{Donor receives donation receipt material}\label{donor_receives_donation_receipt}
Upon receiving the Donau signatures $\overline{\beta_1}, \overline{\beta_2}, \overline{\beta_3}$ via the charity, the Donor checks if the blind signatures over the \textbf{Blinded Unique Donor Identifiers} $\overline u_1, \overline u_2, \overline u_3$ is valid:
\begin{align*}
verify\_blind(u_1,\overline{\beta_1}, K_1^{pub}) \\
@@ -132,7 +132,7 @@ Donor creates the final Donation Receipts $r_1, r_2, r_3$
These \textbf{Donation Receipt (DR)} are then stored on the donors device.
-\subsection{Donor requests a donation statement from the Donau}
+\subsection{Donor requests a donation statement from the Donau}\label{donor_requests_a_donation_statement_from_the_donau}
To make the donations tax deductable the donor needs to have a final \textbf{Donation Statement} which can be sent to the tax authority. To get the \textbf{Donation Statement} the donor sends the \textbf{Donation Receipts} $\{r_1, r_2, r_3\}$ accumulated throughout the year to the Donau.
This can be done multiple times during the year. It is not done automatically as to obtain \emph{unlinkability} between the \emph{issuance} of the \textbf{Donation Receipts} (which happens upon donation) and their \emph{submission} for the \textbf{Donation Statement}.
@@ -151,7 +151,7 @@ Donau creates Donation Statement $\sigma_s$:
\sigma_s = sign(\langle i, \texttt{amount}_{Total}, \texttt{year}) \rangle, D^{priv})
\end{align*}
-\subsection{Donor sends final statement to a validator}
+\subsection{Donor sends final statement to a validator}\label{donor_sends_final_statement_to_a_validator}
The Donor uses the \textbf{Donation Statement} $\sigma_s$ to create a QR-Code which then can be included in the tax declaration.
Donor generates a \texttt{QR} code which contains the following:
diff --git a/doc/thesis/chapters/results/conclusion.tex b/doc/thesis/chapters/results/conclusion.tex
@@ -1,4 +1,4 @@
-\section{Conclusion}
+\section{Conclusion}\label{conclusion}
Tax transparency is a crucial aspect of a well-functioning society, as it fosters trust, accountability, and fairness in the relationship between the state and its citizens. Transparency allows for public scrutiny, which can help identify inefficiencies, loopholes, or instances of corruption within the tax system, ultimately leading to necessary reforms and improvements.
Unfortunately, it occured to us that many tax departments still rely heavily on outdated, paper-based systems and legacy software, hindering their ability to operate efficiently and transparently. The lack of digitization not only slows down processes but also increases the risk of errors, data inconsistencies, and potential mishandling of sensitive information.
diff --git a/doc/thesis/chapters/results/future.tex b/doc/thesis/chapters/results/future.tex
@@ -1,13 +1,13 @@
-\section{Future work}
+\section{Future work}\label{future_work}
%donor client
%charity merchant backend
%spa
%
-\subsection{Client implementation}
+\subsection{Client implementation}\label{client_implementation}
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. The necessary functionality must be implemented in the \texttt{taler-wallet-core}. This includes the option to make donations and request for the final donation statement. If the donor wants to be able to deduct the donations from taxes, the user is asked to input his tax number. Hidden from the user are the generation of the various elements such as \texttt{DI}, \texttt{UDI}, \texttt{BUDI} and \texttt{BKP}. The blinding and unblinding implementation must also be present.
-\subsection{Charity backend}
+\subsection{Charity backend}\label{chairty_backend}
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. To do this it is necessary to add a charity information table to the merchant database. This table should contain information like the charity public key, domain, base URL, currency and instance. The instance beeing a number as there could be different instances running. The merchant backend needs to be extended to incrporate the charity logic. Meaning the signing of BKP's sent to the charity and also the communication whith the donor. The charity should return a list of Donaus in which the charity is registered, so that the donor can choose the appropriate Donau for tax deduction.
-\subsection{Donau SPA}
+\subsection{Donau SPA}\label{donau_spa}
For the administrator a single page application is needed to comftably manage the charities. This would include functionality to add, remove and modify charities. This setup could include a reverse proxy, which authenicates the Donau admin. Once the identity has been confirmed the proxy can access the Donau endpoint to manage a charity. The proxy would hold a bearer token, in order to authenticate itself.
diff --git a/doc/thesis/chapters/results/results.tex b/doc/thesis/chapters/results/results.tex
@@ -1,4 +1,4 @@
-\section{Results}
+\section{Results}\label{results}
Currently the Donau REST API is fully implemented. The Donau can manage any number of charities using the \texttt{/charities} endpoint.
All the keys used for singing and blind singing are managed by the Donau thogether with the Secmod helpers.
Overall the Donau is able to issue donation receipts and provide the necessary donation statement to the donor, all while keeping the data anonymized and protecting the privacy of the donor.
diff --git a/doc/thesis/thesis.pdf b/doc/thesis/thesis.pdf
Binary files differ.
