future.tex (2170B)
1 \section{Future work}\label{future_work} 2 3 \subsection{Client implementation}\label{client_implementation} 4 The donor client implementation needs to be implemented in the Taler wallet. 5 This is a necessary step to be able to use the Donau together with the Taler 6 payment system. Then donations could be made fully anonymous. The necessary 7 functionality must be implemented in the \texttt{taler-wallet-core}. This 8 includes the option to make donations and request for the final donation 9 statement. If the donor wants to be able to deduct the donations from taxes, 10 the user is asked to input his tax number. Hidden from the user are the 11 generation of the various elements such as \texttt{DI}, \texttt{UDI}, 12 \texttt{BUDI} and \texttt{BKP}. The blinding and unblinding implementation must 13 also be present. 14 15 \subsection{Charity backend}\label{charity_backend} 16 Each registered charity needs to communicate with the donors and the Donau. The 17 Taler merchant backend needs to be modified to incorporate the charity backend 18 logic. To do this it is necessary to add a charity information table to the 19 merchant database. This table should contain information like the charity 20 public key, domain, base URL, currency and instance. The instance being a 21 number as there could be different instances running. The merchant backend 22 needs to be extended to incorporate the charity logic. Meaning the signing of 23 BKP's sent to the charity and also the communication with the donor. The 24 charity should return a list of Donaus where the charity is registered, so that 25 the donor can choose the appropriate Donau for tax deduction. A system similar 26 to the one described in the thesis of Christian Blättler is to be implemented \cite{taler-sub}. 27 28 \subsection{Donau SPA}\label{donau_spa} 29 For the administrator a single page application is needed to comfortably manage 30 the charities. This would include functionality to add, remove and modify 31 charities. This setup could include a reverse proxy, which authenticates the 32 Donau admin. Once the identity has been confirmed the proxy can access the 33 Donau endpoint to manage a charity. The proxy would hold a bearer token, in 34 order to authenticate itself.