[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-donau] branch master updated: thesis small fixes
|
From: |
gnunet |
|
Subject: |
[taler-donau] branch master updated: thesis small fixes |
|
Date: |
Wed, 12 Jun 2024 19:48:58 +0200 |
This is an automated email from the git hooks/post-receive script.
johannes-casaburi pushed a commit to branch master
in repository donau.
The following commit(s) were added to refs/heads/master by this push:
new 2cc902c thesis small fixes
2cc902c is described below
commit 2cc902c24cd2b7f20a60016857f07764e6334fdb
Author: Casaburi Johannes <johannes.casaburi@students.bfh.ch>
AuthorDate: Wed Jun 12 19:48:39 2024 +0200
thesis small fixes
---
doc/thesis/abstract.tex | 7 ++
doc/thesis/chapters/approach/concept.tex | 6 +-
doc/thesis/chapters/background/blindsign.tex | 3 +-
doc/thesis/chapters/implementation/android.tex | 14 +++-
doc/thesis/chapters/implementation/arch.tex | 11 ++-
doc/thesis/chapters/implementation/donau.tex | 108 +++++++++++++++++++------
doc/thesis/chapters/protocol/definitions.tex | 9 ++-
doc/thesis/chapters/results/conclusion.tex | 31 +++++--
doc/thesis/chapters/results/future.tex | 30 ++++++-
doc/thesis/chapters/results/results.tex | 1 -
doc/thesis/thesis.pdf | Bin 2214703 -> 2215964 bytes
11 files changed, 176 insertions(+), 44 deletions(-)
diff --git a/doc/thesis/abstract.tex b/doc/thesis/abstract.tex
index e482ab8..ad71d65 100644
--- a/doc/thesis/abstract.tex
+++ b/doc/thesis/abstract.tex
@@ -22,5 +22,12 @@ donor can provide this donation statement to the tax
authority which
can check its validity and can then approve the tax deduction.
%motivation
+Providing evidence of charitable donations for tax deductions often requires
+sensitive personal information, raising privacy concerns.
+Donors may wish to anonymize receipts while still beeing able to make
+legitimate donations to recognized charities.
+Deductions for unrecognized charities or failure to deduct valid foreign
+donations also occur. A system allowing anonymous yet verifiable donation
+receipts would address these issues.
\end{abstract}
diff --git a/doc/thesis/chapters/approach/concept.tex
b/doc/thesis/chapters/approach/concept.tex
index 61a4985..3e3dd02 100644
--- a/doc/thesis/chapters/approach/concept.tex
+++ b/doc/thesis/chapters/approach/concept.tex
@@ -81,7 +81,7 @@ Upon receiving the signed issue request from the charity, the
Donau must verify
the charity signature and check that the yearly donation limit of the charity
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
+is then sent via the charity back to the Donor (See figure \ref{fig:issue
receipt response}).
The donor now unblinds the signature from the Donau to make it valid for the
unblinded receipt (for more information on blind signatures see section
\ref{blind_signatures}).
@@ -113,7 +113,7 @@ have accumulated any number of these 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:
+Donau, summarizing all the donation receipts of a year (see figure
\ref{fig:summarize receipts}).
This step combines the amounts of the donation receipts in a single total
amount.
@@ -166,7 +166,7 @@ donation receipts.
\section{Validation}\label{validation}
Once the donor has received the donation statement signature, he can summarize
them in a QR code. The donor must submit the QR-Code with his tax documents,
-in order to claim the tax reduction (see figure:\ref{fig:validation}).
+in order to claim the tax reduction (see figure \ref{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.
diff --git a/doc/thesis/chapters/background/blindsign.tex
b/doc/thesis/chapters/background/blindsign.tex
index edbc3a3..adaf610 100644
--- a/doc/thesis/chapters/background/blindsign.tex
+++ b/doc/thesis/chapters/background/blindsign.tex
@@ -47,5 +47,6 @@ trip is no longer significant.\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.
+security level of 128 bits. The exact processes of this signature scheme do not
+need to be understood in order to understand this thesis.
diff --git a/doc/thesis/chapters/implementation/android.tex
b/doc/thesis/chapters/implementation/android.tex
index d5e1013..788570f 100644
--- a/doc/thesis/chapters/implementation/android.tex
+++ b/doc/thesis/chapters/implementation/android.tex
@@ -1,5 +1,15 @@
\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}).
+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
\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 str [...]
+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/implementation/arch.tex
b/doc/thesis/chapters/implementation/arch.tex
index dee4987..4239855 100644
--- a/doc/thesis/chapters/implementation/arch.tex
+++ b/doc/thesis/chapters/implementation/arch.tex
@@ -1,10 +1,15 @@
\section{System Architecture}\label{system_architecture}
-As the charity backend and donor wallet implementation are not yet developed
the following architecture is reduced to the Donau backend.
+As the charity backend and donor wallet implementation are not yet developed
+the following architecture is reduced to the Donau backend.
\begin{figure}[ht]
\includegraphics[width=1\textwidth]{donau_system_arch}
\caption{Donau system architecture} \label{fig:donau_system_arch}
\end{figure}
-The Donau backend implements the REST API and HTTP handler which communicates
with the database plugin. The postgresql database is further described in
section \ref{donau_database} of the thesis.
-The HTTP handler includes a key handler that interacts with the three secmod
processes. The secmod processes generate the keys. Only they have access to the
private keys.
+The Donau backend implements the REST API and HTTP handler which communicates
+with the database plugin. The postgresql database is further described in
+section \ref{donau_database} of the thesis.
+The HTTP handler includes a key handler that interacts with the three secmod
+processes. The secmod processes generate the keys. Only they have access to the
+private keys.
diff --git a/doc/thesis/chapters/implementation/donau.tex
b/doc/thesis/chapters/implementation/donau.tex
index 8ad19e1..69ee49b 100644
--- a/doc/thesis/chapters/implementation/donau.tex
+++ b/doc/thesis/chapters/implementation/donau.tex
@@ -1,13 +1,25 @@
\section{Donau}\label{donau}
-The Donau is written in C as it reuses parts of the codebase from the exchange
of GNU Taler \ref{taler}. The Donau has a similar architecture and uses
crypographic blinded signatures in a similar way as the exchange does.
+The Donau is written in C as it reuses parts of the codebase from the exchange
+of GNU Taler (see section \ref{taler} for more information about GNU Taler).
+The Donau has a similar architecture and uses
+crypographic blinded signatures in a similar way as the exchange does.
\subsection{REST API} \label{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:
+The detailed REST API specificatoin of the Donau backend is publicy available
+under the following URL: \url{https://docs.taler.net/core/api-donau.html}. The
+following are the main API endpoints:
\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 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
\ref{donor_requests_a_donation_statement_from_the_donau}).
+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 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
+\ref{donor_requests_a_donation_statement_from_the_donau}).
-The following is an example response of a \lstinline{curl 127.0.0.1:8080/keys}
command. Some parts of the following example respones are truncated (denoted by
\texttt{...}) to make them more readable.
+The following is an example response of a \lstinline{curl 127.0.0.1:8080/keys}
+command. Some parts of the following example respones are truncated (denoted by
+the three dots '\texttt{...}') to make them more readable.
\begin{lstlisting}
{
@@ -55,16 +67,24 @@ The following is an example response of a \lstinline{curl
127.0.0.1:8080/keys} c
\end{lstlisting}
\subsubsection{\texttt{/charities}}
-In order for a charity to be able to issue receipts by a specific Donau it
must be registered by this Donau. To do so the Donau provides an API to manage
charities. It is expected that only the Donau administrator can manage the
registered charities.
-The charity itself should be able to request their issued donation receipt to
keep track of the set donation limit.
-The response includes the maximum donation amount and the current donated
amount for the charity of the current year.
+In order for a charity to be able to issue receipts by a specific Donau it must
+be registered by this Donau. To do so the Donau provides an API to manage
+charities. It is expected that only the Donau administrator can manage the
+registered charities.
+The charity itself should be able to request their issued donation receipt to
+keep track of the set donation limit.
+The response 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}
-The following is an example response of a \lstinline{curl
127.0.0.1:8080/charities} command. There is only one charity named
\texttt{example} registered with a donation limit of 10 euros.
+The following is an example response of a
+\lstinline{curl 127.0.0.1:8080/charities} command.
+There is only one charity named
+\texttt{example} registered with a donation limit of 10 euros.
\begin{lstlisting}
{
@@ -81,7 +101,9 @@ The following is an example response of a \lstinline{curl
127.0.0.1:8080/chariti
}
\end{lstlisting}
-To insert a charity a POST request can be sent using \lstinline{curl -d
@charity.json -X POST http://127.0.0.1:8080/charities}.
+To insert a charity a \texttt{POST} request can be sent using
+\lstinline{curl -d @charity.json -X POST http://127.0.0.1:8080/charities}.
+
\begin{lstlisting}[title=charity.json]
{
"charity_pub": "ABETNXT9ZF606FRF3WD5...",
@@ -102,10 +124,19 @@ The response consists of the charity ID generated by the
database.
\subsubsection{\texttt{/batch-issue}}
-Only recognized charities are allowed to issue receipts for their donors (see
section \ref{issuing_donation_receipts}).
-An \texttt{POST} issue receipt request includes an array of \texttt{BKP}s. A
\texttt{BKP} consists of a \texttt{BUDI} and a hash of a public donation unit
key (see section \ref{notation_and_definitions}).
-The charity also signs the request with its own EdDSA private key. The
corresponding public key was given to the Donau in the registration process of
the charity.
-After the Donau checked the signature from the charity it signs the
\texttt{BUDI}s 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 section
\ref{donau_database}).
+Only recognized charities are allowed to issue receipts for their donors (see
+section \ref{issuing_donation_receipts}).
+A \texttt{POST} issue receipt request includes an array of \texttt{BKP}s. A
+\texttt{BKP} consists of a \texttt{BUDI} and a hash of a public donation unit
+key (see section \ref{notation_and_definitions}).
+The charity signs the request with its own EdDSA private key. The
+corresponding public key was given to the Donau in the registration process of
+the charity.
+After the Donau checked the signature from the charity it signs the
+\texttt{BUDI}s 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 section
+\ref{donau_database}).
\begin{figure}[ht]
\includegraphics[width=1\textwidth]{donau_flow_issue_receipt}
@@ -113,7 +144,8 @@ After the Donau checked the signature from the charity it
signs the \texttt{BUDI
\end{figure}
The following is an example response of a \\
-\lstinline{curl -d @issue.json -X POST http://127.0.0.1:8080/batch-issue/1}
request. The number at the end of the URL is the charity ID.
+\lstinline{curl -d @issue.json -X POST http://127.0.0.1:8080/batch-issue/1}
+request. The number at the end of the URL is the charity ID.
\begin{lstlisting}[title=issue.json]
{
@@ -146,13 +178,21 @@ The following is an example response of a \\
\end{lstlisting}
\subsubsection{\texttt{/batch-submit}}
-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 (see section
\ref{notation_and_definitions}), 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 of the year, 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 section \ref{donau_database}).
+The batch-submit route is used by the donor to summarize their donation
+receipts into one donation statement EdDSA signature.
+The request is composed of the donation receipt (see section
+\ref{notation_and_definitions}), the corresponding year and the hash of the
+salted tax ID.
+When 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 of the year, the hash of the salted tax ID and
+the year forms the donation statement. The donation statement and the receipts
+are stored in the Donau database (see section \ref{donau_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.
+The donation statement will not be returned after a submit request, a
+donation statement get request can be made for a specified year and tax ID.
\begin{figure}[ht]
\includegraphics[width=1\textwidth]{donau_flow_submit_receipt}
@@ -160,7 +200,9 @@ Even the donation statement will not be returned after a
submit request, a donat
\end{figure}
The following is an example of a \\
-\lstinline{curl -d @submit.json -X POST http://127.0.0.1:8080/batch-submit}
request. If successful, the Donau returns the \texttt{HTTP 201} status code
with an empty response.
+\lstinline{curl -d @submit.json -X POST http://127.0.0.1:8080/batch-submit}
+request. If successful, the Donau returns the \texttt{HTTP 201} status code
+with an empty response.
\begin{lstlisting}[title=submit.json]
{
@@ -194,17 +236,29 @@ The last parameter of the URL is the salted hash of the
donor tax ID.
}
\end{lstlisting}
\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 \label{rest_api}.
+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 chapter \label{rest_api}.
\subsection{Donau Database}\label{donau_database}
-The Donau database contains five tables as shown in figure
\ref{fig:db_physical_model}. 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 p [...]
+The Donau database contains five tables as shown in figure
+\ref{fig:db_physical_model}. 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 (generated by \url{dbdiagram.io})}
\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.
+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
@@ -246,7 +300,9 @@ Contains all issued donation receipts sent to the Donau.
\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.
+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.
@@ -257,7 +313,9 @@ Contains all submitted donation receipts sent to the Donor.
By storing the signa
\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.
+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
diff --git a/doc/thesis/chapters/protocol/definitions.tex
b/doc/thesis/chapters/protocol/definitions.tex
index b17b428..5bd2452 100644
--- a/doc/thesis/chapters/protocol/definitions.tex
+++ b/doc/thesis/chapters/protocol/definitions.tex
@@ -1,7 +1,14 @@
+This chapter describes the Donau protocol. In the first section notations and
+definitions are established which are then used in the later section where
+the protocol details are described.
+To fully comprehend the cryptographic concepts discussed in this chapter, the
+reader may need prior knowledge or background in this field.
+
\section{Notation \& Definitions}\label{notation_and_definitions}
\subsection{Notation}\label{notation}
+The following are notations used in the following pages of this chapter.
\begin{itemize}
- \item $\langle a, b, ... \rangle$ : Pair/tuple
+ \item $\langle a, b, ... \rangle$ is used to represent a Pair or tuple
\end{itemize}
\subsection{Definitions}\label{definitions}
diff --git a/doc/thesis/chapters/results/conclusion.tex
b/doc/thesis/chapters/results/conclusion.tex
index b40373a..a496043 100644
--- a/doc/thesis/chapters/results/conclusion.tex
+++ b/doc/thesis/chapters/results/conclusion.tex
@@ -1,10 +1,31 @@
\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.
+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 some tax departments still rely on
outdated, paper-based systems or 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.
+Unfortunately, it occured to us that some tax departments still rely on
+outdated, paper-based systems or 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.
-The adoption of free and open-source software (FOSS) presents a compelling
solution. FOSS solutions offer several advantages, including
cost-effectiveness, customizability, and the ability to scrutinize the
underlying code for security and transparency purposes. By embracing FOSS, tax
departments can modernize their systems, streamline processes, and enhance data
integrity, ultimately fostering greater transparency and trust with the public.
+The adoption of free and open-source software (FOSS) presents a compelling
+solution. FOSS solutions offer several advantages, including
+cost-effectiveness, customizability, and the ability to scrutinize the
+underlying code for security and transparency purposes. By embracing FOSS, tax
+departments can modernize their systems, streamline processes, and enhance data
+integrity, ultimately fostering greater transparency and trust with the public.
-The Donau system supports tax justice. The Donau not only manages to anonymize
user data, so that everyone is treated equally, but also helps the donor to
make use of their right to deduct donations from taxes. Because the donation
receipts are stored in a central location and can even be deposited in the
Donau, the likelihood of losing or forgetting to submit the receipts is reduced.
+The Donau system supports tax justice. The Donau not only manages to anonymize
+user data, so that everyone is treated equally, but also helps the donor to
+make use of their right to deduct donations from taxes. Because the donation
+receipts are stored in a central location and can even be deposited in the
+Donau, the likelihood of losing or forgetting to submit the receipts is
+reduced.
-Of course, bureaucracy and federalism can hinder the introduction of such a
system. Especially when it comes to the recognition of charities. But the Donau
could provide a first step into a more standardized system that handels
donations in a secure and privacy preserving way.
+Of course, bureaucracy and federalism can hinder the introduction of such a
+system. Especially when it comes to the recognition of charities. But the Donau
+could provide a first step into a more standardized system that handels
+donations in a secure and privacy preserving way.
diff --git a/doc/thesis/chapters/results/future.tex
b/doc/thesis/chapters/results/future.tex
index 5dce7f7..4959f7b 100644
--- a/doc/thesis/chapters/results/future.tex
+++ b/doc/thesis/chapters/results/future.tex
@@ -1,10 +1,34 @@
\section{Future work}\label{future_work}
\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 num [...]
+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}\label{charity_backend}
-Each registered charity needs to communicate with the donors and the Donau.
The Taler merchant backend needs to be modified to incorporate 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 incorpora [...]
+Each registered charity needs to communicate with the donors and the Donau. The
+Taler merchant backend needs to be modified to incorporate 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 incorporate the charity logic. Meaning the signing of
+BKP's sent to the charity and also the communication with the donor. The
+charity should return a list of Donaus where the charity is registered, so that
+the donor can choose the appropriate Donau for tax deduction.
+%thesis christian blättler
\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.
+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
index 6e03ba7..d331a34 100644
--- a/doc/thesis/chapters/results/results.tex
+++ b/doc/thesis/chapters/results/results.tex
@@ -24,7 +24,6 @@ The tax authority emphasises user convenience and simplicity
in a system like
the Donau. The tax authority also mentioned the challanges that arise when
operating such a system in the federalism. Each party often has different
requirements that a system like the Donau should fulfill.
-
Although the Donau is in its early stages and the prototype has not yet been
deployed, the tax authority Zürich definitely sees potential in the user
convenience side of the Donau.
diff --git a/doc/thesis/thesis.pdf b/doc/thesis/thesis.pdf
index fb9a5be..e300dc0 100644
Binary files a/doc/thesis/thesis.pdf and b/doc/thesis/thesis.pdf differ
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-donau] branch master updated: thesis small fixes,
gnunet <=