diff options
Diffstat (limited to 'docs/content/implementation/c2ec.tex')
| -rw-r--r-- | docs/content/implementation/c2ec.tex | 56 |
1 files changed, 42 insertions, 14 deletions
diff --git a/docs/content/implementation/c2ec.tex b/docs/content/implementation/c2ec.tex index a62993f..0899670 100644 --- a/docs/content/implementation/c2ec.tex +++ b/docs/content/implementation/c2ec.tex @@ -1,5 +1,34 @@ \section{C2EC} +\subsection{Decoupling steps} + +To decouple different steps in the withdrawal process an event based architecture is implemented. This means that every write action to the database will represent an operation which will trigger an event. The applications processes are listening to those events. The consumer of the API can wait to be notified by the API, by registering to those events via a long polling request at the API. This long-polling will then wait until the listener receives the event and return the received event to the consumer. + +Following a short list of events and from whom they are triggered and who listens to them: + +\begin{itemize} + \item Registration of the Withdrawal Operation. + \begin{itemize} + \item Registered by: Wallet + \item Listened by: Terminal + \end{itemize} + \item Payment Confirmation sent to the Bank-Integration API of C2EC. + \begin{itemize} + \item Registered by: Terminal + \item Listened by: Attestor + \end{itemize} + \item Payment attestation success will send a withdrawal operation status update event. + \begin{itemize} + \item Registered by: Attestor + \item Listened by: Consumers (via Bank-Integration-API) + \end{itemize} + \item Payment attestation failure will trigger a retry event. + \begin{itemize} + \item Registered by: Attestor + \item Listened by: Retrier + \end{itemize} +\end{itemize} + \subsection{Bank-Integration API} The Bank Integration API was implemented according to the specification \cite{taler-bank-integration-api}. It only implements messages and API specific to the indirect withdrawal operation. @@ -24,11 +53,12 @@ Following endpoints are implemented by the wire gateway API implementation: \item GET /config \item POST /transfer \item GET /history/incoming + \item GET /history/outgoing \end{itemize} \subsubsection{Keeping track of transfers} -The Wire-Gateway specification requires the implementor of the API to keep track of incoming transfer requests in order to guarantee the idempotence of the API. Therefore the implementation keeps track of all transfers in the database table \textit{transfers}. It stores a hash of the entire request related to the requests unqiue identifier. If a request with the same UID is sent to the transfer-API, first it is checked that the incoming request is exactly the same as the previous one by comparing the hash of the requests. Only if the hashes are the same, the transfer request is processed further. Otherwise the API responds with a conflict response. +The Wire-Gateway specification requires the implementor of the API to keep track of incoming transfer requests in order to guarantee the idempotence of the API. Therefore the implementation keeps track of all transfers in the database table \textit{transfers}. It stores the transfer data in the database. If a request with the same UID is sent to the transfer-API, first it is checked that the incoming request is exactly the same as the previous one by comparing the request to the values stored in the database. Only if the hashes are the same, the transfer request is processed further. Otherwise the API responds with a conflict response. \subsection{Payment Attestation} @@ -77,18 +107,6 @@ As indicated by the provider client interface, we will use two API of the Wallee \subsection{Security} -\subsubsection{API access} - -\textbf{Bank-Integration API} - -The Bank-Integration API is accessed by Wallets and Terminals. This results in two different device types for the autentication procedure. The Wallet should be able to authenticate against the exchange by using an access token according to the specified authentication flow of the core bank API \cite{taler-bank-core-authentication} which leverages a bearer token as specified by DD-49 \cite{taler-design-document-49}. For terminals the authentication mechanism is based on a basic auth scheme as specified by RFC-7617 \cite{rfc7617}. Therefore a generated access-token used as password and a username which is generated registering the terminal using the cli explained in \autoref{sec-security-registering-providers} are leveraged. - -\textbf{Wire-Gateway API} - -The wire gateway specifies a basic auth flow \cite{taler-wire-gateway-api-authentication} as described in RFC-7617 \cite{rfc7617}. Therefore the C2EC component allows the configuration of a username and password for the exchange. During the request of the exchange at the wire gateway API, the credentials are checked. - -\textbf{Database} - \subsubsection{Authenticating at the Wallee ReST API} \label{sec-security-auth-wallee} @@ -108,10 +126,20 @@ The Wallee API specifies four Wallee specific headers which are used to authenti The resulting string must then be UTF-8 encoded according to RFC-3629 \cite{rfc3629}. +\subsubsection{API access} + +\textbf{Bank-Integration API} + +The Bank-Integration API is accessed by Wallets and Terminals. This results in two different device types for the autentication procedure. The Wallet should be able to authenticate against the exchange by using an access token according to the specified authentication flow of the core bank API \cite{taler-bank-core-authentication} which leverages a bearer token as specified by DD-49 \cite{taler-design-document-49}. For terminals the authentication mechanism is based on a basic auth scheme as specified by RFC-7617 \cite{rfc7617}. Therefore a generated access-token used as password and a username which is generated registering the terminal using the cli explained in \autoref{sec-security-registering-providers} are leveraged. + +\textbf{Wire-Gateway API} + +The wire gateway specifies a basic authentication scheme \cite{taler-wire-gateway-api-authentication} as described in RFC-7617 \cite{rfc7617}. Therefore the C2EC component allows the configuration of a username and password for the exchange. During the request of the exchange at the wire gateway API, the credentials are checked. + \subsubsection{Registering Providers and Terminals} \label{sec-security-registering-providers} -A provider may want to register a new Terminal or maybe even a new provider shall be registered for the exchange. To make this step easier for the exchange operators, a small cli program (command line interface) was implemented. The cli will either ask for a password or generate an access token in case of the terminal registration. The credentials are stored has hashes using a PBKDF (password based key derivation function) so that even if the database leaks, the credentials cannot be easily read by the attackers. +A provider may want to register a new Terminal or maybe even a new provider shall be registered for the exchange. To make this step easier for the exchange operators, a simple cli program (command line interface) was implemented. The cli will either ask for a password or generate an access token in case of the terminal registration. The credentials are stored has hashes using a PBKDF (password based key derivation function) so that even if the database leaks, the credentials cannot be easily read by an attacker. \subsubsection{Deactivating Terminals} |