[taler-cashless2ecash] branch master updated: docs: fix payto docs

[gnunet]

This is an automated email from the git hooks/post-receive script.

joel-haeberli pushed a commit to branch master
in repository cashless2ecash.

The following commit(s) were added to refs/heads/master by this push:
     new 66697e0  docs: fix payto docs
66697e0 is described below

commit 66697e05791cf1eff319036ebf165c2202487344
Author: Joel-Haeberli <haebu@rubigen.ch>
AuthorDate: Wed Mar 20 16:01:06 2024 +0100

    docs: fix payto docs
---
 docs/content/architecture/overview.tex |  20 +++++++++-----------
 docs/project.bib                       |   7 +++++++
 docs/thesis.pdf                        | Bin 1384056 -> 812625 bytes
 3 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/docs/content/architecture/overview.tex 
b/docs/content/architecture/overview.tex
index 58f60c8..46a3d62 100644
--- a/docs/content/architecture/overview.tex
+++ b/docs/content/architecture/overview.tex
@@ -79,24 +79,22 @@ The nonce is leveraged by all components to establish the 
connection to an entry
 The Wallet gains the nonce value when scanning the QR code at the Terminal and 
then sends the nonce (and the other parameters) to the Exchange.
 
 \subsubsection{Nonce creation}
-Besides the entropy needed to establish a correct nonce, the hash function 
leveraged must be specified. (TODO - possibly one of FIPS 180-4 or FIPS 202 
families)
+Besides the entropy needed to establish a correct nonce, the hash function 
leveraged must be specified. (TODO - e.g. FIPS 180-4 \cite{fips-180-4} (SHA-1 
and SHA-2 families) or FIPS-202 \cite{fips-202} (SHA-3 family, which is still 
beeing reviewed))
 
 \subsection{Reserve Public Key}
 The reserve public key is created by the Wallet and sent to the Exchange to 
establish the mapping between the nonce and the reserve public key. The reserve 
public key, can then be retrieved by the Terminal and used during the payment. 
The reserve public key is used to eventually create a reserve at the exchange 
which contains the money. The Wallet can then withdraw the money from this 
reserve using the withdrawal process of the wallet \cite{wallet-withdrawal}.
 
-\subsection{Payto REFUND extension}
-RFC 8905 \cite{rfc8905} specifies a URI scheme (complying with RFC 3986 
\cite{rfc3986}), which allows to address a creditor with theoretically any 
protocol that can be used to pay someone (such as IBAN, BIC etc.) in a 
standardized way. Therefore it introduces a registry which holds the specific 
official values of the standard.
+\subsection{Payto wallee-transaction extension}
+RFC 8905 \cite{rfc8905} specifies a URI scheme (complying with RFC 3986 
\cite{rfc3986}), which allows to address a creditor with theoretically any 
protocol that can be used to pay someone (such as IBAN, BIC etc.) in a 
standardized way. Therefore it introduces a registry which holds the specific 
official values of the standard. The registry is supervised by the GANA (GNUnet 
Assigned Numbers Authority) \cite{gnunet-gana}.
 
-For the case of refunds, which might occur in case a credit card transaction 
does not succeed, a new \textit{target type} called REFUND is registered. It 
takes a transaction identifier as \textit{target identifier} which identifies 
the transaction for which a refund process shall be triggered. The idea is that 
the receiver of the payto URI is able to deduct the transaction and handle the 
specific process. Like this any refund process can be handled through this 
single \textit{target type}.
+For the case of refunds, which might occur in case a credit card transaction 
does not succeed, a new \textit{target type} called \textit{wallee-transaction} 
is registered. It takes a transaction identifier as \textit{target identifier} 
which identifies the transaction for which a refund process shall be triggered. 
The idea is that the handler of the payto URI is able to deduct the transaction 
from the payto-uri and trigger the refund process.
 
-The transaction identifier is not provider agnostic. This means that the 
identifier can be sourced by various formatted identifiers, depending on the 
originating system. Therefore, the transaction identifier is a hash of the 
actual identifier allowing a standardized format for the \textit{target 
identifier}. This requires the owner of the process triggering the refund to 
maintain a mapping of the \textit{target identifier} and the respective hash. 
The owner of the process triggering the  [...]
-
-The idea of the REFUND \textit{target type} is to trigger a refund process by 
the owner of the refund process without other services needing to deal with the 
refund logic. Therefore transactions which allow refund but the receiver cannot 
directly execute the refund, the payto REFUND \textit{target type} can be used 
to advice the owner to of the refund process, to execute the refund linked to 
the transaction identifier supplied using the \textit{target identifier}, which 
is a hash of the  [...]
-
-\subsubsection{Refund Target Identifier Hash}
-In order to allow a generic adoption of the REFUND \textit{target type}, the 
transaction identifier must be transformed to a general format. Therefore a 
hash function can be leveraged. This hash function must be configurable and 
therefore the \textit{generic option} called \textit{instruction} holds the 
name of the hash function. The name shall correspond to one of the offical 
terms used in e.g. FIPS 180-4 \cite{fips-180-4} (SHA-1 and SHA-2 families) or 
FIPS-202 \cite{fips-202} (SHA-3 fa [...]
+The idea of the \textit{wallee-transaction target type} is to trigger a refund 
process by the owner of the refund process without other services needing to 
deal with the refund logic. Therefore transactions which allow refund but the 
receiver cannot directly execute the refund, the payto 
\textit{wallee-transaction target type} can be used to advice the owner to of 
the refund process to start the refund process.
 
 \subsubsection{Payto refund using Wallee}
-Wallee allows to trigger refunds using the Refund Service of the Wallee 
backend. The service allows to trigger a refund given a transaction identifier. 
Therefore the nonce2ecash component can trigger the refund using the refund 
service if needed, and the payto-uri retrieved as debit account by the 
wirewatch gateway API, is leveraged to delegate the refund process to the 
Wallee Backend using the Refund Service.
+Wallee allows to trigger refunds using the Refund Service of the Wallee 
backend. The service allows to trigger a refund given a transaction identifier. 
Therefore the nonce2ecash component can trigger the refund using the refund 
service if needed, and the payto-uri retrieved as debit account by the 
wirewatch gateway API, is leveraged to delegate the refund process to the 
Wallee Backend using the Refund Service and parsing the transaction identifier 
of the payto-uri.
+
+\subsubsection{Extensibility}
+The flow is extensible and other providers than Wallee might be added. They 
just register their own refund payto-uri with the GANA and they can implement 
the refund process likewise.
 
 \pagebreak
\ No newline at end of file
diff --git a/docs/project.bib b/docs/project.bib
index bfe51b3..c8cae9b 100644
--- a/docs/project.bib
+++ b/docs/project.bib
@@ -105,6 +105,13 @@
     howpublished = {\url{https://doi.org/10.6028/NIST.FIPS.202}},    
 }
 
+@misc{gnunet-gana,
+    author = {GNUnet Project},
+    title = {The GNUnet Assigned Numbers Authority (GANA)},
+    url = {https://gana.gnunet.org/},
+    howpublished = {\url{https://gana.gnunet.org/}}
+}
+
 @misc{wallet-withdrawal,
     author       = {Taler},
     title        = {Withdrawal},
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
index 4eca76e..ec29fae 100644
Binary files a/docs/thesis.pdf and b/docs/thesis.pdf differ

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.