commit 66697e05791cf1eff319036ebf165c2202487344
parent 5f573dd1ff4969c1fb0d36c53fbc324c78a6ae6c
Author: Joel-Haeberli <haebu@rubigen.ch>
Date: Wed, 20 Mar 2024 16:01:06 +0100
docs: fix payto docs
Diffstat:
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git 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 refund of the transaction could also hash every transaction-id on request, but this will possibly lead to bad performance and bad style.
-
-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 transaction identifier.
-
-\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 family, which is still beeing reviewed). This allows the provider of the refund process to choose the applied hash function and the hash can also be migrated to other hashes in case a hash becomes unusable for an arbitrary reason.
+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
@@ -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
Binary files differ.
