[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-cashless2ecash] branch master updated: docs: fix docs
From: |
gnunet |
Subject: |
[taler-cashless2ecash] branch master updated: docs: fix docs |
Date: |
Wed, 06 Mar 2024 07:37:47 +0100 |
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 01e0c4c docs: fix docs
01e0c4c is described below
commit 01e0c4c299617ceb9224430a7a1c5570dc92727e
Author: Joel-Haeberli <haebu@rubigen.ch>
AuthorDate: Wed Mar 6 07:37:29 2024 +0100
docs: fix docs
---
docs/content/abstract.tex | 2 +-
docs/content/appendix/meeting_notes.tex | 46 +++++++++++++----
docs/content/architecture/cashless2ecash.tex | 5 --
docs/content/architecture/nonce2ecash.tex | 43 ++++++++++++++++
.../architecture/{bigpicture.tex => overview.tex} | 13 +++--
docs/content/glossary.tex | 57 ++-------------------
docs/content/implementation/exchange.tex | 2 +-
docs/content/implementation/terminal.tex | 1 +
docs/content/introduction/introduction.tex | 2 +-
.../listings/specs}/nonce2ecash_api_spec.yml | 11 ++--
docs/pictures/diagrams/db_cashless2ecash_erd.png | Bin 22528 -> 0 bytes
docs/pictures/diagrams/db_nonce2ecash_erd.png | Bin 0 -> 10696 bytes
.../diagrams/nonce2ecash_class_diagram.png | Bin 75089 -> 62429 bytes
docs/thesis.pdf | Bin 1214860 -> 1076156
bytes
docs/thesis.tex | 44 +++++++++++-----
specs/db_cashless2ecash_erd.plantuml | 34 ------------
specs/db_nonce2ecash_erd.plantuml | 22 ++++++++
specs/nonce2ecash_api_spec.yml | 10 ++--
specs/nonce2ecash_class_diagram.plantuml | 25 ++-------
19 files changed, 161 insertions(+), 156 deletions(-)
diff --git a/docs/content/abstract.tex b/docs/content/abstract.tex
index 89d8041..cdcf095 100644
--- a/docs/content/abstract.tex
+++ b/docs/content/abstract.tex
@@ -2,6 +2,6 @@ In order to buy Taler, the Taler Exchange needs guarantees to
legally secure the
direct trust, since cash can be used in order to buy Taler and the transaction
is completed. If you want
to buy Taler using cashless systems like credit cards, the Exchange has no
proof that the payment has succeeded.
In order to fill this cap, this thesis establishes a trust relationship
between the terminal manufacturer Wallee
-and the Taler Exchange through a newly created component called
'cashless2ecash'. This enables a trust relationship
+and the Taler Exchange through a newly created component called
\textit{nonce2ecash}. This enables a trust relationship
between the Taler Exchange and the terminal operator which allows withdrawing
Taler without using cash. The liability for
the money is on the side of the terminal operator and therefore establishes
the guarantees for the Taler Exchange.
diff --git a/docs/content/appendix/meeting_notes.tex
b/docs/content/appendix/meeting_notes.tex
index 0403266..dcb9ce6 100644
--- a/docs/content/appendix/meeting_notes.tex
+++ b/docs/content/appendix/meeting_notes.tex
@@ -87,28 +87,52 @@
\begin{itemize}
\item Task description
\item Deeper understanding of the topic established?
- \item I contacted Florian Jung (alias Windfisch) and we bespoke his work
on cash2ecash.
- \begin{itemize}
- \item Where do we draw the line (scope)?
- \item Florian wants to hand in a "Förderantrag" to integrate the
scan-before-withdraw feature into Taler Wallet.
- \item Can I for the sake of my bachelor rely on his work, he is
planning to do (therefore only adhere to a specified contract)?
- \end{itemize}
+ \item I contacted Florian Jung (alias Windfisch) and we bespoke his work
on cash2ecash.
\end{itemize}
\textbf{Questions}
\begin{itemize}
- \item Repository of Wallee Application will be different than
'cashless2ecash' (bfh gitlab)?
- \item Wallee: Master Password? (Password received by Ben)
+ \item Repository of Wallee Application will be different than
'cashless2ecash'? No
+ \item Wallee: Master Password? Password received by Ben
\item Wallee: Which SDK to use? Till-SDK (API to Wallee-Backend)
+ \item How do we want to handle different currencies? How about currencies
like Bitcoin? Currency is determined by the currency of the exchange.
+\end{itemize}
+
+\textbf{Action points}
+\begin{itemize}
+ \item
+\end{itemize}
+
+\textbf{Decisions}
+\begin{itemize}
+ \item
+\end{itemize}
+
+\subsection*{06.03.2024}
+
+\textbf{Participants}
+
+\begin{itemize}
+ \item Fehrensen Benjamin
+ \item Grothoff Christian
+ \item H\"aberli Joel
+\end{itemize}
+
+\textbf{Topics}
+\begin{itemize}
+ \item API Spec
+\end{itemize}
+
+\textbf{Questions}
+\begin{itemize}
+ \item How can I create a reserve from the mapping table?
\item Taler / Wallee : Which nonce to use? How to generate the nonce? Is
there a preferred kind to generate nonces within taler?
\item Do we add a maximal limit amount for a withdrawal on the side of the
Taler Exchange?
- \item How do we want to handle different currencies? How about currencies
like Bitcoin?
- \item How can I create a reserve from the mapping table?
\end{itemize}
\textbf{Action points}
\begin{itemize}
- \item
+ \item
\end{itemize}
\textbf{Decisions}
diff --git a/docs/content/architecture/cashless2ecash.tex
b/docs/content/architecture/cashless2ecash.tex
deleted file mode 100644
index 596f81c..0000000
--- a/docs/content/architecture/cashless2ecash.tex
+++ /dev/null
@@ -1,5 +0,0 @@
-\section*{nonce2ecash}
-
-\subsection*{Model}
-
-\subsubsection*{Database}
diff --git a/docs/content/architecture/nonce2ecash.tex
b/docs/content/architecture/nonce2ecash.tex
new file mode 100644
index 0000000..d978263
--- /dev/null
+++ b/docs/content/architecture/nonce2ecash.tex
@@ -0,0 +1,43 @@
+\section*{nonce2ecash}
+
+\subsection*{REST API}
+
+The API of the nonce2ecash component mirrors the flow from the creation of a
nonce2ecash mapping to the creation of the reserve. Therefore three endpoints
are implemented.
+
+An openapi specification of the API in yaml format can be found in
\autoref*{appendix-api-spec}.
+
+\subsubsection*{Withdrawal Registration}
+\label{section-api-withdrawal-registration}
+
+With the \textit{withdrawal-registration} endpoint a nonce is registered at
the nonce2ecash component of the Exchange. The \textit{N2CWithdrawalRequest}
contains not only the nonce but also a reserve public key generated by the
Wallet, the amount to withdraw and the provider type (e.g. \textit{WALLEE}).
The provider type shall make the nonce2ecash component provider agnostic. Like
this other providers can be added in the future.
+
+\subsubsection*{Withdrawal Processing}
+
+With the \textit{withdrawal-processing} endpoint, the provider can notify the
Exchange about the payment. Therefore the provider sends a
\textit{N2CPaymentNotification} message to the API. The message contains the
nonce to identify which withdrawal is processed, a provider specific
transaction identifier which allows the nonce2ecash component to verify the
payment at the providers backend and a flag indicating the success or failure
of the payment.
+
+\subsubsection*{Withdrawal Status}
+
+With the \textit{withdrawal-status} endpoint, the status of a mapping can be
retrieved. With a parameter called listenForStatus the consumer can initiate
the a long-polling which will only end if the mapping comes to the requested
state.
+
+\subsubsection*{Database}
+
+The database of the nonce2ecash component is small and only has one table and
two enumerations, which are presented as separate tables themself.
+
+\textbf{n2c\_status}
+
+The \textit{n2c\_status} table represents the enumeration of all possible
states a mapping of a nonce to a reserve public key can be in.
+
+\textbf{n2c\_provider\_type}
+
+The \textit{n2c\_provider\_type} table represents the enumeration of all
accepted providers for the nonce2ecash process. For this thesis, the only
supported provider will be \textit{WALLEE}. In the future more providers might
be implemented.
+
+\textbf{n2c\_nonce\_reservepubkey}
+
+The \textit{n2c\_nonce\_reservepubkey} table represents the mapping of a nonce
to a reserve public key. The table holds the nonce, the reserve public key, the
\textit{n2c\_status}, the \textit{n2c\_provider\_type} and a timestamp which
represents the time of registration of the withdrawal (The time when the
\autoref*{section-api-withdrawal-registration}).
+
+\begin{figure}[h]
+ \centering
+
\includegraphics[width=0.7\textwidth]{pictures/diagrams/db_nonce2ecash_erd.png}
+ \caption{Entity Relation Diagram of the nonce2ecash component}
+ \label{fig-diagram-erd-nonce2ecash}
+\end{figure}
diff --git a/docs/content/architecture/bigpicture.tex
b/docs/content/architecture/overview.tex
similarity index 84%
rename from docs/content/architecture/bigpicture.tex
rename to docs/content/architecture/overview.tex
index ed84e93..3371c7e 100644
--- a/docs/content/architecture/bigpicture.tex
+++ b/docs/content/architecture/overview.tex
@@ -1,4 +1,4 @@
-\section*{Big Picture}
+\section*{Overview}
\subsection*{Components}
@@ -6,7 +6,7 @@
\centering
\includegraphics[width=0.7\textwidth]{pictures/diagrams/component.png}
\caption{Diagram of included components}
- \label{fig:diagram-all-components}
+ \label{fig-diagram-all-components}
\end{figure}
The component diagram shows the components involved by the withdrawal using
the terminal. Besides the credit card owned by the user, two systems are
involved and within each system two components are required to fulfill the
task. We have the Taler system which represents the ecosystem for the Taler
payment system with the Taler Wallet and the Taler Exchange involved in the
withdrawal of Taler coins. In the Terminal system, the terminal and the backend
system of the terminal manufacturer [...]
@@ -15,10 +15,10 @@ The component diagram shows the components involved by the
withdrawal using the
\centering
\includegraphics[width=0.7\textwidth]{pictures/diagrams/nonce2ecash.png}
\caption{Diagram of high level flow}
- \label{fig:diagram-all-sequence}
+ \label{fig-diagram-all-sequence}
\end{figure}
-The diagram in \autoref*{fig:diagram-sequence} shows the high level flow to
withdraw Taler using the credit card terminal. It shows when the components of
\autoref*{fig:diagram-components} interact with each other. It shows the
implementation of the \textbf{nonce2ecash} flow. Terminal, Wallet and Exchange
are linked leveraging a nonce initially generated by the terminal and presented
to the Exchange by the withdrawing Wallet accompanied by a public key.
+The diagram in \autoref*{fig-diagram-all-sequence} shows the high level flow
to withdraw Taler using the credit card terminal. It shows when the components
of \autoref*{fig-diagram-all-components} interact with each other. It shows the
implementation of the \textbf{nonce2ecash} flow. Terminal, Wallet and Exchange
are linked leveraging a nonce initially generated by the terminal and presented
to the Exchange by the withdrawing Wallet accompanied by a public key.
\subsection*{The three parts}
@@ -34,12 +34,11 @@ The Terminal initiates the withdrawal leveraging an
application which works as f
\begin{enumerate}
\item Application creates a nonce
\item The application starts long polling at the Exchange and awaits
the establishment of the nonce (by the Exchange).
- \item Nonce is packed into a QR code (with Exchange and amount)
+ \item Nonce is packed into a QR code (with Exchange and amount entered
by the terminal owner)
\item QR code is displayed
\end{enumerate}
\item The user now scans the QR Code using his wallet.
\item The application receives the establishment notification of the
Exchange.
- \item The owner of the terminal enters the amount the user likes to
withdraw.
\item Terminal calculates fees and shows summary and the Terms of Service
(ToS) of Taler.
\item The user accepts the offer, agrees with the ToS and pays using his
Credit Card.
\item The Terminal executes the payment and presents the result to the
user.
@@ -65,7 +64,7 @@ The Exchange manages the withdrawal using a third party and
seeks guarantees of
The Wallet must attest its presence to the terminal by registering a nonce and
belonging reserve public key which will hold the Taler that can eventually be
withdrawn by the wallet.
\begin{enumerate}
- \item The Wallet scans the QR Code (nonce, Exchange information) on the
Terminal
+ \item The Wallet scans the QR Code (nonce, Exchange information and
amount) on the Terminal
\item It creates a reserve key pair
\item The Wallet sends the reserve public key and the scanned nonce to the
Exchange
\item The Wallet can withdraw money from the created reserve.
diff --git a/docs/content/glossary.tex b/docs/content/glossary.tex
index 180ad41..a096775 100644
--- a/docs/content/glossary.tex
+++ b/docs/content/glossary.tex
@@ -1,54 +1,5 @@
-\newglossaryentry{BibTeX}{
- name={BibTeX},
- description={Program for the creation of bibliographical references and
directories in \TeX or \LaTeX\, documents},
- plural=BibTeXs
-}
-
-\newglossaryentry{zynq}{
- name=Zynq,
- description={\textbf{Zynq} Xilinx' AP SoC. The characteristic feature of
Zynq is that it combines a dual-core ARM Cortex-A9 processor with traditional
Series-7 FPGA logic fabric},
- plural=Zynqs
-}
-
-
-\newglossaryentry{soc}{
- name=SoC,
- description={\textbf{System-on-Chip (SoC)} A single chip that holds all of
the necessary hardware and electronic circuitry for a complete system. SoC
includes on-chip memory (RAM and ROM), the microprocessor, peripheral
interfaces, I/O logic control, data converters, and other components that
comprise a complete computer system},
- plural=SoCs
-}
-
-\newglossaryentry{apsoc}{
- name=AP SoC,
- description={\textbf{All Programmable System-on-Chip (AP SoC)} was
introduced by Xilinx. It represents a IC which comprise a hard-core processor
core surrounded by an FPGA fabric. This type of ICs are highly configurable and
provide algorithm partitioning capabilities. This provides high benefit for
highly scale-able applications as well as fast time-to-market},
- plural=AP SoCs
-}
-
-\newglossaryentry{zbook}{
- name=Zynq Book,
- description={\textbf{Zynq Book} A book that summarizes all the important
aspects when working with Zynq and provides a strong and easy understandable
introduction to the topic. The book has been written by a team of University of
Strathclyde Glasgow in cooperation with Xilinx},
- plural=Zynq Books
-}
-
-\newglossaryentry{zboard}{
- name=ZedBoard,
- description={\textbf{ZedBoard} A low cost development board featuring a
Zynq-700 0 SoC, and a number of peripherals},
- plural=ZedBoards
-}
-
-
-\newglossaryentry{asic}{
- name=ASIC,
- description={\textbf{Application-Specific Integrated Circuit (ASIC)} An
integrated circuit which is designed for a specific use, rather than
general-purpose use},
- plural=ASICs
-}
-
-\newglossaryentry{rtos}{
- name=RTOS,
- description={\textbf{Real-Time Operating System (RTOS)} A category of
operating systems defined by their ability to respond quickly and predictably
for a given task},
- plural=RTOSs
-}
-
-\newglossaryentry{arm}{
- name=ARM,
- description={\textbf{ARM} A family of processor architectures. The hard
processor type which forms the basis of the Zynq processing system is an ARM
Cortex-A9 version. The term ‘ARM’ may also be used to refer to the developer of
the processor, i.e. a company of the same name}
+\newglossaryentry{TEST}{
+ name={TEST},
+ description={TEST},
+ plural=TESTS
}
diff --git a/docs/content/implementation/exchange.tex
b/docs/content/implementation/exchange.tex
index c4285b0..a29328b 100644
--- a/docs/content/implementation/exchange.tex
+++ b/docs/content/implementation/exchange.tex
@@ -1 +1 @@
-\section*{implementing cashless2ecash docs}
\ No newline at end of file
+\section*{implementing nonce2ecash docs}
\ No newline at end of file
diff --git a/docs/content/implementation/terminal.tex
b/docs/content/implementation/terminal.tex
new file mode 100644
index 0000000..d959772
--- /dev/null
+++ b/docs/content/implementation/terminal.tex
@@ -0,0 +1 @@
+\section*{implementing terminal docs}
\ No newline at end of file
diff --git a/docs/content/introduction/introduction.tex
b/docs/content/introduction/introduction.tex
index 75fce42..0cdcc06 100644
--- a/docs/content/introduction/introduction.tex
+++ b/docs/content/introduction/introduction.tex
@@ -63,6 +63,6 @@ As long as the interaction of withdrawal is manual and the
identification and ve
But now we have the problem that the Exchange is not able to proof that the
money was sent to the wallet it was intended for. This leaves the Exchange with
liability weaknesses and makes it unattractive to operate the cashless2ecash
feature for Exchange operators and therefore introduces a weakness.
-Imagine the following situation: A user gets kidnapped and is forced to buy a
certain amount of Taler. But now instead of using the wallet of the kidnapped
user, the kidnapper accesses Exchange with his own wallet and steals the money.
This makes stealing money from someone as hard as making them pay using their
credit card or reveal the credentials to do so (which is totally possible
\autoref*{cc-fraud-types}). Also plain digital attacks are possible (and
probably more likely) where the [...]
+Imagine the following situation: A user gets kidnapped and is forced to buy a
certain amount of Taler. But now instead of using the wallet of the kidnapped
user, the kidnapper accesses Exchange with his own wallet and steals the money.
This makes stealing money from someone as hard as making them pay using their
credit card or reveal the credentials to do so (which is totally possible
\cite{cc-fraud-types}). Also plain digital attacks are possible (and probably
more likely) where the att [...]
This situation can be prevented by leveraging the \textbf{nonce2ecash}
approach proposed by Florian Jung. This approach forces the withdrawing party
to lock their withdrawal to a specific user (public key) before the actual
withdrawal. This approach makes stealing money as hard as gaining control over
the wallet (which is the equivalent to stealing the wallet).
diff --git a/specs/nonce2ecash_api_spec.yml
b/docs/listings/specs/nonce2ecash_api_spec.yml
similarity index 94%
copy from specs/nonce2ecash_api_spec.yml
copy to docs/listings/specs/nonce2ecash_api_spec.yml
index 834eb6a..7731437 100644
--- a/specs/nonce2ecash_api_spec.yml
+++ b/docs/listings/specs/nonce2ecash_api_spec.yml
@@ -45,7 +45,7 @@ paths:
- name: listenForStatus
in: query
description: The status to listen for the given nonce
- required: true
+ required: false
schema:
$ref: '#/components/schemas/N2CStatus'
responses:
@@ -55,6 +55,9 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/N2CMapping'
+ '404':
+ description: Mapping not found
+ ''
tags:
- nonces
tags:
@@ -85,8 +88,6 @@ components:
type: string
success:
type: boolean
- amount:
- type: number
fees:
type: number
N2CStatus:
@@ -94,10 +95,8 @@ components:
type: string
enum:
- ESTABLISHED
- - ESTABLISHMENT_FAILED
- PAYED
- RESERVE_CREATED
- - PAYMENT_FAILED
N2CMapping:
description: Maps a nonce generated by the provider to a reserve public
key generated by the wallet.
type: object
@@ -110,7 +109,7 @@ components:
status:
$ref: '#/components/schemas/N2CStatus'
N2CProviderType:
- description: Signals the exchange which provider is talking to him. Like
this more Providers can be easily supported by adding their verfification flow
to the code of nonce2ecash.
+ description: Signals the exchange which provider is talking to him. Like
this more Providers can be easily supported by adding their verfification flow
to the code of nonce2ecash. This allows to extend the system with various
providers.
type: string
enum:
- WALLEE
diff --git a/docs/pictures/diagrams/db_cashless2ecash_erd.png
b/docs/pictures/diagrams/db_cashless2ecash_erd.png
deleted file mode 100644
index 33f5b84..0000000
Binary files a/docs/pictures/diagrams/db_cashless2ecash_erd.png and /dev/null
differ
diff --git a/docs/pictures/diagrams/db_nonce2ecash_erd.png
b/docs/pictures/diagrams/db_nonce2ecash_erd.png
new file mode 100644
index 0000000..6239178
Binary files /dev/null and b/docs/pictures/diagrams/db_nonce2ecash_erd.png
differ
diff --git a/docs/pictures/diagrams/nonce2ecash_class_diagram.png
b/docs/pictures/diagrams/nonce2ecash_class_diagram.png
index 63e4bec..5b71ff8 100644
Binary files a/docs/pictures/diagrams/nonce2ecash_class_diagram.png and
b/docs/pictures/diagrams/nonce2ecash_class_diagram.png differ
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
index d1f3f8d..58d657e 100644
Binary files a/docs/thesis.pdf and b/docs/thesis.pdf differ
diff --git a/docs/thesis.tex b/docs/thesis.tex
index 13b1b85..79bccee 100644
--- a/docs/thesis.tex
+++ b/docs/thesis.tex
@@ -54,16 +54,6 @@
%---------------------------------------------------------------------------
\graphicspath{{pictures/}{figures/}}
%---------------------------------------------------------------------------
-% Blind text -> for dummy text
-%---------------------------------------------------------------------------
-\usepackage{blindtext}
-\usepackage{letltxmacro}
-\LetLtxMacro{\blindtextblindtext}{\blindtext}
-
-\RenewDocumentCommand{\blindtext}{O{\value{blindtext}}}{
- \begingroup\color{BFH-Gray}\blindtextblindtext[#1]\endgroup
-}
-%---------------------------------------------------------------------------
% Glossary Package
%---------------------------------------------------------------------------
% the glossaries package uses makeindex
@@ -107,6 +97,30 @@
]{hyperref}
%---------------------------------------------------------------------------
+%% yaml style definition
+\lstdefinestyle{yaml}{
+ keywords={true,false,null,y,n}, % ,... all the keyword you want
+ keywordstyle=\color{blue}\bfseries,
+ moredelim=[is][commentstyle]{||}{££}, % invisible custom delimiters
+ identifierstyle=\color{darkgray},
+ sensitive=false,
+ comment=[l]{\#},
+ morecomment=[s]{/*}{*/},
+ commentstyle=\color{gray}\ttfamily,
+ stringstyle=\color{teal}\ttfamily,
+ moredelim=[l][\color{orange}]{\&},
+ moredelim=[l][\color{magenta}]{*},
+ moredelim=**[il][\color{darkgray}{:}\color{teal}]{:},
+ morestring=[b]',
+ morestring=[b]",
+ numbers=left,
+ numberstyle=\color{gray},
+ numbersep=10pt,
+ frame=single,
+ backgroundcolor=\color{gray!5}
+}
+%---------------------------------------------------------------------------
+
%% %% Customize Footer and Headers in Document
%% \KOMAoptions{headsepline,plainheadsepline,footsepline,plainfootsepline}%
%% \setkomafont{headsepline}{\color{BFH-DarkBlue}}% BFH-DarkBlue required
bfhcolors
@@ -125,8 +139,8 @@
%% \cofoot*{cofoot}
%% \rofoot*{rofoot}
%---------------------------------------------------------------------------
-\begin{document}
+\begin{document}
%------------ START FRONT PART ------------
\frontmatter
@@ -164,10 +178,12 @@
\input{content/introduction/goal}
\chapter{Architecture}
-\input{content/architecture/bigpicture}
+\input{content/architecture/overview}
+\input{content/architecture/nonce2ecash}
\chapter{Implementation}
\input{content/implementation/exchange}
+\input{content/implementation/terminal}
\input{content/implementation/wallee}
\chapter{Results}
@@ -200,6 +216,10 @@
%------------ Appendix ----------------
\appendix
\chapter{Appendix A}
+\section*{API}
+\label{appendix-api-spec}
+\lstinputlisting[style=yaml,caption={nonce2ecash API
specification}]{listings/specs/nonce2ecash_api_spec.yml}
+
\chapter{Appendix B}
\section{Meeting notes}
\input{content/appendix/meeting_notes}
diff --git a/specs/db_cashless2ecash_erd.plantuml
b/specs/db_cashless2ecash_erd.plantuml
deleted file mode 100644
index 9a66a94..0000000
--- a/specs/db_cashless2ecash_erd.plantuml
+++ /dev/null
@@ -1,34 +0,0 @@
-@startuml
-enum n2c_status {
- n2c_ESTABLISHED
- n2c_ESTABLISHMENT_FAILED
- n2c_PAYED
- n2c_RESERVE_CREATED
- n2c_PAYMENT_FAILED
-}
-
-entity n2c_nonce_reservepubkey {
- + provider_name: string
- + nonce: number
- + nonce_provider_sig: blob
- + reserve_pubkey: number
- + state: n2cStatus
- + registration_ts: timestamp
-}
-
-enum n2c_provider_attestation_type {
- NONE
- WALLEE
-}
-
-entity n2c_provider {
- + name: string
- + publicKey: blob
- + publicKeySignature: blob
- + attestationType: ProviderAttestationType
-}
-
-n2c_provider --* n2c_provider_attestation_type
-n2c_nonce_reservepubkey --* n2c_status
-n2c_nonce_reservepubkey "m" --> "1" n2c_provider
-@enduml
diff --git a/specs/db_nonce2ecash_erd.plantuml
b/specs/db_nonce2ecash_erd.plantuml
new file mode 100644
index 0000000..bc9603a
--- /dev/null
+++ b/specs/db_nonce2ecash_erd.plantuml
@@ -0,0 +1,22 @@
+@startuml
+entity n2c_status {
+ id: number
+ name: string
+}
+
+entity n2c_provider_type {
+ id: number
+ name: string
+}
+
+entity n2c_nonce_reservepubkey {
+ nonce: number
+ provider_type_id: n2c_provider_type
+ reserve_pubkey: number
+ n2c_status_id: n2c_status
+ registration_ts: timestamp
+}
+
+n2c_nonce_reservepubkey --* n2c_status
+n2c_nonce_reservepubkey --* n2c_provider_type
+@enduml
diff --git a/specs/nonce2ecash_api_spec.yml b/specs/nonce2ecash_api_spec.yml
index 834eb6a..13e0f44 100644
--- a/specs/nonce2ecash_api_spec.yml
+++ b/specs/nonce2ecash_api_spec.yml
@@ -1,7 +1,7 @@
openapi: 3.0.3
info:
title: nonce2ecash API
- description: API managing a mapping table which links a nonce to a public
key. This allows withdrawing from the exchange by the nonce. Additionally it
provides facilities allowing for the Exchange operators to register new
providers or delete obsolete ones.
+ description: API managing a mapping table which links a nonce to a reserve
public key. This allows withdrawing from the exchange by a given nonce.
version: 0.0.1
paths:
/n2c/nonces/withdrawal-registration:
@@ -76,13 +76,14 @@ components:
providerType:
$ref: '#/components/schemas/N2CProviderType'
N2CPaymentNotification:
- description: Notifies the exchange about an executed payment. This will
trigger a provider specific attestation of the payment according to the
ProviderPaymentAttestationType.
+ description: Notifies the exchange about an executed payment. This will
trigger a provider specific attestation of the payment according to the
N2CProviderType. This allows to define the attestation process for each
supported provider individually.
type: object
properties:
nonce:
type: string
providerTransactionId:
type: string
+ description: a unique identifier of the provider which identifies
the transaction in the providers system.
success:
type: boolean
amount:
@@ -94,10 +95,9 @@ components:
type: string
enum:
- ESTABLISHED
- - ESTABLISHMENT_FAILED
- PAYED
- RESERVE_CREATED
- - PAYMENT_FAILED
+ - RESERVE_CREATION_FAILED
N2CMapping:
description: Maps a nonce generated by the provider to a reserve public
key generated by the wallet.
type: object
@@ -110,7 +110,7 @@ components:
status:
$ref: '#/components/schemas/N2CStatus'
N2CProviderType:
- description: Signals the exchange which provider is talking to him. Like
this more Providers can be easily supported by adding their verfification flow
to the code of nonce2ecash.
+ description: Signals the exchange which provider is talking to him. Like
this more Providers can be easily supported by adding their verfification flow
to the code of nonce2ecash. This allows to extend the system with various
providers.
type: string
enum:
- WALLEE
diff --git a/specs/nonce2ecash_class_diagram.plantuml
b/specs/nonce2ecash_class_diagram.plantuml
index d926bf0..05f0564 100644
--- a/specs/nonce2ecash_class_diagram.plantuml
+++ b/specs/nonce2ecash_class_diagram.plantuml
@@ -18,7 +18,7 @@ enum WalleeTransactionState {
}
interface WalleeClient {
- getTransactionState(): WalleeTransactionState
+ getTransactionState(transactionId: string): WalleeTransactionState
}
class PaymentVerifierProxy {
@@ -34,10 +34,6 @@ class WalleePaymentVerifier {
verifyPayment(nonce: string): boolean
}
-class NonePaymentVerifier {
- verifyPayment(nonce: string): boolean
-}
-
interface NonceToReservePubkeyMappingRepository {
createMapping(nonce: string, reservePubkey: byte[])
removeMapping(nonce: string)
@@ -51,39 +47,28 @@ class NonceToReservePubkeyMappingService {
enum Status {
ESTABLISHED
- ESTABLISHMENT_FAILED
PAYED
RESERVE_CREATED
- PAYMENT_FAILED
}
class NonceToReservePubkey {
- + providerName: string
+ nonce: number
- + nonce_provider_sig: byte[]
+ + provider_type: ProviderType
+ reserve_pubkey: number
+ state: Status
+ established_t_s: timestamp
}
-enum ProviderAttestationType {
- NONE
+enum ProviderType {
WALLEE
}
-class Provider {
- + name: string
- + publicKey: byte[]
- + publicKeySignature: byte[]
- + attestationType: ProviderAttestationType
-}
-
-Provider --* ProviderAttestationType
+NonceToReservePubkey --* ProviderType
NonceToReservePubkey --* Status
-NonceToReservePubkey --* Provider
WalleeClient ..> WalleeTransactionState : use
PaymentVerifierProxy --* PaymentVerifier : knows
+WalleePaymentVerifier --o WalleeClient: needs
WalleePaymentVerifier ..> PaymentVerifier : implements
NonePaymentVerifier ..> PaymentVerifier : implements
NonceToReservePubkeyMappingService --> NonceToReservePubkeyMappingRepository:
use
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-cashless2ecash] branch master updated: docs: fix docs,
gnunet <=