commit bc22228188ef41fab6cb65633d78c4c26903a2f4 parent 8192da3b7cee2ea4a86165eaffe2620321f394ef Author: Joel-Haeberli <haebu@rubigen.ch> Date: Wed, 15 May 2024 18:33:31 +0200 chore: automated setup and poster Diffstat:
20 files changed, 275 insertions(+), 43 deletions(-)
diff --git a/Makefile b/Makefile @@ -0,0 +1,32 @@ +C2EC_HOME ?= ${HOME} +C2EC_USER ?= $(shell whoami) +C2EC_DB_ADMIN_PW ?= secret +C2EC_DB_OPERATOR_PW ?= secret +C2EC_DB_API_PW ?= secret +C2EC_FILE_PERMISSIONS ?= 660 + +dependencies-check: + go version + psql --version + ls ${C2EC_HOME} + +build: dependencies-check + go build -C ./c2ec/ -o ${C2EC_HOME} + +install: dependencies-check + cp ./c2ec-config.yaml ${C2EC_HOME}/c2ec-config.yaml + chmod ${C2EC_FILE_PERMISSIONS} ${C2EC_HOME}/c2ec-config.yaml + chown ${C2EC_HOME}/c2ec-config.yaml ${C2EC_USER} + cp ./c2ec-config.conf ${C2EC_HOME}/c2ec-config.conf + chmod ${C2EC_FILE_PERMISSIONS} ${C2EC_HOME}/c2ec-config.conf + chown ${C2EC_HOME}/c2ec-config.conf ${C2EC_USER} + touch ${C2EC_HOME}/c2ec-log.txt + chmod ${C2EC_FILE_PERMISSIONS} ${C2EC_HOME}/c2ec-log.txt + chown ${C2EC_HOME}/c2ec-log.txt ${C2EC_USER} + echo "you may want to alter the current configuration of your installation at ${C2EC_HOME}/c2ec-config.conf" + +cli: dependencies-check + go build -C ./cli/ -o ${C2EC_HOME} + +simulation: dependencies-check + go build -C ./simulation/ -o ${C2EC_HOME} diff --git a/README b/README @@ -1,22 +1,64 @@ # Cashless to E-Cash -In order to buy Taler using a terminal, transactions must be verified with the terminal operator. -This repository contains the code for the verification of such transactions. It stores a nonce generated -by the terminal operator and the reserve public-key for the withdrawal reserve. It implements long-polling to -the terminal operators backend in order to have an atomic proof that the transaction got through and -the exchange got the guarantee that the payment will eventually reach the exchanges bankaccount. - -The flow establishes trust not with the final transaction, but the authenticated guarantee, that the -terminal operator will eventually pay the amount to the bankaccount of the exchange. - +This project realizes a framework to enable withdrawal of digital cash for GNU Taler through a trusted third party. The integration addresses a report commissioned by the European Central Bank (ECB), which identified the universal acceptance as one of the most important aspects of a digital euro. This will lead to better acceptance of GNU Taler by better integrating its ecosystem into the existing systems. The following tree describes the structure of the document and a rough description of each directory ``` . -├── data : contains sql -├── docs : contains the thesis (LaTeX) -├── infra : contains configs for running the components -├── nonce2ecash : contains code of the nonce2ecash component -├── schemaspy : contains erd using schemaspy -└── specs : contains specifications +├── bruno : contains some manual http requests for the bruno rest client. +├── c2ec : contains code of the c2ec component +├── cli : contains code of the management cli +├── docs : contains the thesis +├── install : contains scripts for the installation of c2ec +├── Makefile : Makefile contains build commands for creating c2ec executable and +├── poster : containes the poster (requirement of the BFH for all their thesis projects) +├── README : this file +├── schemaspy : contains the schema of the database +├── simulation : contains code of the c2ec simulation (testing) +├── specs : contains various specifications (also old stuff) +└── wallee-c2ec : contains the source code of the Wallee PayDroid app ``` + +## Installation + +1. Clone this repository +2. Define variables + 2.1 C2EC_HOME: Everything that is installed here. (default: $HOME) + 2.2 C2EC_USER: The user owning c2ec. (default: current user (whoami) + 2.3 C2EC_DB_ADMIN_PW: The admin password of the database user + 2.4 C2EC_DB_OPERATOR_PW: Password of the operator database user + 2.5 C2EC_DB_API_PW: Password of the api database user + 2.6 C2EC_FILE_PERMISSIONS: The permissions of the files created during the installation (executable, config, log, etc.) +3. Execute: `make install` + +## Running C2EC + +Execute: `.$C2EC_HOME/c2ec &` + +## Managing Providers and Terminals + +To manage providers and terminals, use the CLI. + +Therefore build the CLI first and run it. It uses the same variables as the installation. + +1. Execute: `make cli` +2. Run CLI: `.$C2EC_HOME/c2ec-cli` + +## Testing + +For testing, a simulation is available which allows simulation against the C2EC component. Before running the simulation make sure to register the simulation provider (which will setup the simulation client at C2EC. Be aware, that the simulation can only be run when the production flag in the c2ec-config is set to `false`). You can setup the simulation provider and terminal using the cli (execute the following commands in the cli): + +1. connect to database: `db` or set PG env variables +2. setup registration: `sim` +3. Note the terminal user id and the access token (in a password manager or similar) + +It's best to use the c2ec_operator user to connect to the db when using the cli. + +Build the simulation and run. It uses the same variables as the installation. + +1. Execute: `make simulation` +2. Edit the configuration of the simulation at `$C2EC_HOME/simulation-config.yaml` +3. Restart the c2ec process `.$C2EC_HOME/c2ec &` +4. Execute: `.$C2EC_HOME/c2ec-simulation $C2EC_HOME/simulation-config.yaml` + + diff --git a/c2ec/db/access.sql b/c2ec/db/access.sql @@ -0,0 +1,28 @@ +BEGIN; + +SELECT _v.register_patch('setup_users', ARRAY['versioning', '0001-c2ec-schema', 'proc-c2ec-payment-notification-listener', 'proc-c2ec-retry-listener', 'proc-c2ec-status-listener', 'proc-c2ec-transfer-listener'], NULL); + +SET search_path TO c2ec; + +CREATE USER c2ec_admin WITH ENCRYPTED PASSWORD ADMIN_PASSWORD; +--For CLI (managing terminals and providers): +CREATE USER c2ec_operator WITH ENCRYPTED PASSWORD OPERATOR_PASSWORD; +--For the API (handling withdrawals): +CREATE USER c2ec_api WITH ENCRYPTED PASSWORD API_PASSWORD; + +GRANT ALL PRIVILEGES ON DATABASE DB_NAME TO c2ec_admin; + +GRANT USAGE ON SCHEMA c2ec TO c2ec_operator; +GRANT ALL PRIVILEGES ON c2ec.terminal TO c2ec_operator; +GRANT ALL PRIVILEGES ON c2ec.provider TO c2ec_operator; + +GRANT USAGE ON SCHEMA c2ec TO c2ec_api; +GRANT ALL PRIVILEGES ON c2ec.withdrawal TO c2ec_api; +GRANT SELECT ON c2ec.terminal TO c2ec_api; +GRANT SELECT ON c2ec.provider TO c2ec_api; +GRANT EXECUTE ON FUNCTION c2ec.emit_withdrawal_status TO c2ec_api; +GRANT EXECUTE ON FUNCTION c2ec.emit_payment_notification TO c2ec_api; +GRANT EXECUTE ON FUNCTION c2ec.emit_retry_notification TO c2ec_api; +GRANT EXECUTE ON FUNCTION c2ec.emit_transfer_notification TO c2ec_api; + +COMMIT; +\ No newline at end of file diff --git a/c2ec/db/test_wire_gateway.sql b/c2ec/db/test_wire_gateway.sql diff --git a/c2ec/db/test_wire_gateway_cleanup.sql b/c2ec/db/test_wire_gateway_cleanup.sql diff --git a/c2ec/taler-wire-gateway-test.sh b/c2ec/taler-wire-gateway-test.sh @@ -0,0 +1,21 @@ +#!/bin/bash + +# you must have the taler gateway client installed to execute these tests. +# do some tests using the taler gateway client: +# https://docs.taler.net/manpages/taler-exchange-wire-gateway-client.1.html + + +### Instead of adding testing endpoints, prepare testdata using sql + + +### INCOMING HISTORY +taler-exchange-wire-gateway-client + +### TRANSFER +taler-exchange-wire-gateway-client + +### OUTGOING HISTORY +taler-exchange-wire-gateway-client + + +### cleanup test data +\ No newline at end of file diff --git a/docs/content/architecture/overview.tex b/docs/content/architecture/overview.tex @@ -2,7 +2,7 @@ \begin{figure}[h] \centering - \includegraphics[width=0.7\textwidth]{pictures/diagrams/components_image.png} + \includegraphics[width=0.7\textwidth]{pictures/diagrams/components_images.png} \caption{Involved components and devices} \label{fig-logo-components} \end{figure} diff --git a/docs/content/implementation/e-security.tex b/docs/content/implementation/e-security.tex @@ -11,7 +11,7 @@ The database is very important as it decides wether to allow a withdrawal or not \subsubsection{Storing credentials} -Even if a database leak occurs, it shall be very hard for the attacker to access the API using the credentials stored in the database. This is why credentials are stored using PBKDF \textit{argon2}. \textit{Argon2} is the winner of the password hashing competition initiated by the cryptographer Jean-Philippe Aumasson \cite{argon2}. It is a widely adopted best practice approach for hashing passwords. Storing the hash of the credentials makes stealing credentials very hard and therefore prevents the abuse of credentials gathered through a database leak. The CLI described in \autoref{sec-implementation-cli} implements operations which will register providers and terminals also hashing the credentials using \textit{argon2}. +Even if a database leak occurs, it shall be very hard for the attacker to access the API using the credentials stored in the database. This is why credentials are stored using PBKDF \textit{argon2} \cite{password-competition-argon2}. \textit{Argon2} is the winner of the password hashing competition initiated by the cryptographer Jean-Philippe Aumasson \cite{password-competition-argon2}. It is a widely adopted best practice approach for hashing passwords. Storing the hash of the credentials makes stealing credentials very hard and therefore prevents the abuse of credentials gathered through a database leak. The CLI described in \autoref{sec-implementation-cli} implements operations which will register providers and terminals also hashing the credentials using \textit{argon2}. \subsubsection{Access data through correct user} @@ -53,6 +53,17 @@ 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{Wallee User Access rights} + +In order for Wallee to successfully authorize the user's requests, the API user must have the corret access rights. The C2EC Wallee API user must be able to access the transaction service for reading transactions and the refund service to write create refunds at the Wallee backend. Therefore following rigths must be assigned to the API user: + +\begin{enumerate} + \item Refund-service + \item Transaction-Service +\end{enumerate} + +These rights can be assigned on Wallee's management interface by creating a role and assigning the rights to it. The role must then be added to the API user. The assignment of the roles must be done for the space context (Three different contexts are available. The relevant context is the space context, since requests are scoped to a space). + \subsection{API access} \textbf{Terminals API} diff --git a/docs/content/implementation/f-cli.tex b/docs/content/implementation/f-cli.tex @@ -1,7 +1,7 @@ \section{C2EC CLI} \label{sec-implementation-cli} -The management of providers and terminals is not part of the thesis but since writing and issueing SQL statements is cumbersome and error-prone a small cli was implemented to abstract managment tasks. The cli tool was also shows the concepts a future implementation of the provider managment can use to integrate seamlessly with the present features. The cli can be extended with more actions to allow the management of other providers and its terminals. Also the cli allows to setup the simulation terminal and provider which can be used for testing. Before commands can be executed, the user must connect the tool to the database which can be done throught the \textit{db} command. With the aim to not introduce security risks by storing configuration state of the cli, the credentials must be entered after each startup of the cli. This can be surpassed by specifying postgres specific environment variables \texttt{PGHOST}, \texttt{PGPORT}, \texttt{PGUSER} and \texttt{PGPASSWORD} but remember that these environment variables might leak database credentials to others if not cleaned properly or set for the wrong users shell. +The management of providers and terminals is not part of the thesis but since writing and issueing SQL statements is cumbersome and error-prone a small cli was implemented to abstract managment tasks. The cli tool was also shows the concepts a future implementation of the provider managment can use to integrate with the present features. The cli can be extended with more actions to allow the management of other providers and its terminals. Also the cli allows to setup the simulation terminal and provider which can be used for testing. Before commands can be executed, the user must connect the tool to the database which can be done throught the \textit{db} command. With the aim to not introduce security risks by storing configuration state of the cli, the credentials must be entered after each startup of the cli. This can be surpassed by specifying postgres specific environment variables \texttt{PGHOST}, \texttt{PGPORT}, \texttt{PGUSER} and \texttt{PGPASSWORD} but remember that these environment variables might leak database credentials to others if not cleaned properly or set for the wrong users shell. The cli was implemented to be usable and as it was out of scope of the thesis, the focus was on the functionality and tasks needed for the thesis. This included features to manage wallee provider and terminals and the simulation. Additionally the tool implements commands to activate and deactivate a terminal, which makes the task much easier than writing and executing SQL by hand. Also it eliminates mistakes by reducing problems to bugs in the implementation of the cli. @@ -19,4 +19,5 @@ To deactivate the terminal, the command \textit{dt} must be issued. It will ask \subsection{Setting up the Simulation} -The Simulation provider and terminal allow to simulate transactions and interactions of the terminal with the API of C2EC. Therefore the command \textit{sim} will setup the needed provider and terminal including the credentials of the simulation terminal, which must be saved to the operator in order to test API using the simulation terminal. +The Simulation provider and terminal allow to simulate transactions and interactions of the terminal with the API of C2EC. Therefore the command \textit{sim} will setup the needed provider and terminal including the credentials of the simulation terminal, which must be saved and supplied to the operator through a secure channel. These credentials allow to test the Terminals API using the simulation terminal. The simulation client will not be available in productive environments to reduce the attack surface due to unnecessaty features. +s +\ No newline at end of file diff --git a/docs/pictures/diagrams/components_images.png b/docs/pictures/diagrams/components_images.png Binary files differ. diff --git a/docs/pictures/diagrams/logical_model_relations.png b/docs/pictures/diagrams/logical_model_relations.png Binary files differ. diff --git a/docs/thesis.pdf b/docs/thesis.pdf Binary files differ. diff --git a/install/grant_privileges.sh b/install/grant_privileges.sh @@ -0,0 +1,32 @@ +#!/bin/bash + +if [ "$#" -ne 4 ]; then + echo "Usage: $0 <db-username> <db-password> <db-name> <source-root>" + exit 1 +fi + +DB_USERNAME=$1 +DB_PASSWORD=$2 +DB_NAME=$3 +REPO_ROOT=$4 + +SQL_SCRIPTS=( + "$REPO_ROOT/db/versioning.sql" +) + +execute_sql_scripts() { + for script in "${SQL_SCRIPTS[@]}"; do + echo "Executing SQL script: $script" + PGPASSWORD=$DB_PASSWORD psql -U $DB_USERNAME -d $DB_NAME -f $script + if [ $? -ne 0 ]; then + echo "Failed to execute SQL script: $script" + exit 1 + fi + done + PGPASSWORD="" +} + +execute_sql_scripts +if [ $? -ne 0 ]; then + exit 1 +fi diff --git a/install/setup_db.sh b/install/setup_db.sh @@ -1,7 +1,13 @@ #!/bin/bash -if [ "$#" -ne 4 ]; then - echo "Usage: $0 <db-username> <db-password> <db-name> <source-root>" +if [ "$#" -ne 7 ]; then + echo "Usage: $0 <db-username> <db-password> <db-name> <source-root> <new-db-admin-pw> <new-db-operator-pw> <new-db-api-pw>" + exit 1 +fi + +if [[ ($5 = $6) || ($6 = $7) || ($5 = $7) ]]; then + echo "PROBLEM: passwords for db admin, operator and must be different..." + echo "Usage: $0 <db-username> <db-password> <db-name> <source-root> <new-db-admin-pw> <new-db-admin-pw> <new-db-admin-pw>" exit 1 fi @@ -10,13 +16,28 @@ DB_PASSWORD=$2 DB_NAME=$3 REPO_ROOT=$4 +ADMIN_PASSWORD=$5 +OPERATOR_PASSWORD=$6 +API_PASSWORD=$7 + +ACCESS_WITHOUT_PASSWORD="$REPO_ROOT/db/access.sql" +ACCESS_WITH_PASSWORDS="$REPO_ROOT/db/access-with-passwords.sql" + +cp $ACCESS_WITHOUT_PASSWORD $ACCESS_WITH_PASSWORDS + +sed -i "s/ADMIN_PASSWORD/$ADMIN_PASSWORD/g" $ACCESS_WITH_PASSWORDS +sed -i "s/OPERATOR_PASSWORD/$OPERATOR_PASSWORD/g" $ACCESS_WITH_PASSWORDS +sed -i "s/API_PASSWORD/$API_PASSWORD/g" $ACCESS_WITH_PASSWORDS +sed -i "s/DB_NAME/$DB_NAME/g" $ACCESS_WITH_PASSWORDS + SQL_SCRIPTS=( "$REPO_ROOT/db/versioning.sql" - "$REPO_ROOT/db/0001-c2ec_schema.sql" + "$REPO_ROOT/db/0001-c2ec_schema.sql" "$REPO_ROOT/db/proc-c2ec_status_listener.sql" "$REPO_ROOT/db/proc-c2ec_payment_notification_listener.sql" "$REPO_ROOT/db/proc-c2ec_retry_listener.sql" "$REPO_ROOT/db/proc-c2ec_transfer_listener.sql" + "$REPO_ROOT/db/access-with-passwords.sql" ) execute_sql_scripts() { @@ -29,6 +50,7 @@ execute_sql_scripts() { fi done PGPASSWORD="" + rm $ACCESS_WITH_PASSWORDS } execute_sql_scripts diff --git a/install/test.sh b/install/test.sh @@ -0,0 +1,28 @@ +#!/bin/bash + + +REPO_ROOT=./../c2ec #/home/joel/studies/thesis/cashless2ecash/c2ec +DB_NAME=c2ec +ADMIN_PASSWORD=secret +OPERATOR_PASSWORD=secret2 +API_PASSWORD=secret3 + +if [[ ($ADMIN_PASSWORD = $OPERATOR_PASSWORD) || ($OPERATOR_PASSWORD = $API_PASSWORD) || ($ADMIN_PASSWORD = $API_PASSWORD) ]]; then + echo "PROBLEM: passwords for db admin, operator and must be different..." + echo "Usage: $0 <db-username> <db-password> <db-name> <source-root> <new-db-admin-pw> <new-db-admin-pw> <new-db-admin-pw>" + exit 1 +fi + +ACCESS_WITHOUT_PASSWORD="$REPO_ROOT/db/access.sql" +ACCESS_WITH_PASSWORDS="$REPO_ROOT/db/access-with-passwords.sql" + +cp $ACCESS_WITHOUT_PASSWORD $ACCESS_WITH_PASSWORDS + +sed -i "s/ADMIN_PASSWORD/$ADMIN_PASSWORD/g" $ACCESS_WITH_PASSWORDS +sed -i "s/OPERATOR_PASSWORD/$OPERATOR_PASSWORD/g" $ACCESS_WITH_PASSWORDS +sed -i "s/API_PASSWORD/$API_PASSWORD/g" $ACCESS_WITH_PASSWORDS +sed -i "s/DB_NAME/$DB_NAME/g" $ACCESS_WITH_PASSWORDS + +cat $ACCESS_WITH_PASSWORDS + +rm $ACCESS_WITH_PASSWORDS +\ No newline at end of file diff --git a/poster/cashless2ecash_poster.pdf b/poster/cashless2ecash_poster.pdf Binary files differ. diff --git a/poster/cashless2ecash_poster.tex b/poster/cashless2ecash_poster.tex @@ -29,55 +29,66 @@ %showframe, %Gitter einblenden. Für Platzierung häufig hilfreich }] - \begin{posterboxenv}[BFH-abstract,title=Introduction]{name=intro,column=1,row=1,span=3, rowspan=2} + \begin{posterboxenv}[title=Motivation]{name=intro,column=1,row=1,span=2,rowspan=2} - In a report commissioned by the ECB (European Central Bank) the universal acceptance was identified as one of the most important aspects of a digital euro. The report published in 2022 is the result of a focus group concerning the acceptance of a digital euro as new payment system. The universal acceptance was even identified as the most important property amongst the general public and tech-savvy people in the report. + This thesis realizes a framework to enable withdrawal of digital cash for GNU Taler through a trusted third party. This addresses a report commissioned by the European Central Bank (ECB), which identified the universal acceptance as one of the most important aspects of a digital euro. This will therefore lead to better acceptance of GNU Taler by better integrating its ecosystem into the existing systems. - To expedite the adoption and widespread use of Taler's digital cash, this thesis strives to unlocking new ways to cashless withdrawals. By enhancing user convenience and accessibility, the adoption and expansion of the Taler payment ecosystem ins increased. To achieve this, the seamless integration of cashless payment processes into the Taler payment infrastructure is necessary - which is the core of this thesis. - - Therefore the new cashless-to-ecash component establishes a trustworthy relationship, which makes it possible for the Exchange to issue digital cash to a customer. Therefore the Exchange is not putting his trust on cash received but rather on the promise of a trusted third party (a terminal provider) to put the received money in a location, controlled by the Exchange eventually (e.g. a bank account owned by the Exchange). + Therefore the new cashless-to-ecash (C2EC) component establishes a trustworthy relationship, which makes it possible for the Exchange to issue digital cash to a customer. Therefore the Exchange is not putting his trust on cash received but rather on the promise of a trusted third party (a terminal provider) to put the received money in a location, controlled by the Exchange eventually (e.g. a bank account owned by the Exchange). This enables a broader group of people to leverage Taler for their payments. Which eventually leads to a wider adoption of the payment system Taler. \end{posterboxenv} - \begin{posterboxenv}[BFH-abstract,title=Report]{name=intro,column=4,row=1,span=1, rowspan=2} + \begin{posterboxenv}{name=flow-diagram,column=3,row=1,span=2,rowspan=2} - \includegraphics[width=\linewidth]{report_qr_code.png} - \captionof{figure}{QR Code to the report commissioned by the ECB} + \includegraphics[width=\linewidth]{components_images.png} \end{posterboxenv} - \begin{posterboxenv}[BFH-abstract,title=Terminals API]{name=api,column=2,row=3,span=3} - To allow the withdrawal of digital cash using Taler, the newly introduced Terminals API must be implemented by the Exchange. It specifies the requests needed by a third party terminal to setup and process the the withdrawal. Therefore the setup of the withdrawal operation must implement the generation of a cryptographically sound nonce. It will allow the withdrawal operation and links the customers reserve public key to the withdrawal, which eventually allows the withdrawal. To fully integrate into the Taler ecosystem, implementing parties are adviced to add their payto target type with the GANA (GNU Assigned Numbers Authority) if needed. This prevents conflicts with other technologies and integrations in the future. + \begin{posterboxenv}[title=Terminals API]{name=api,column=2,row=3,span=3} + To allow the withdrawal of digital cash using Taler, the newly introduced Terminals API must be implemented. The Terminals API is responsible to setup a withdrawal operation identifier and to cover the needs of a terminal, concerning the withdrawal process: + + \begin{enumerate} + \item Setup withdrawal + \item Trigger Exchange side confirmation of the transaction (attestation) + \item Abort the withdrawal (if needed) + \end{enumerate} + \end{posterboxenv} - \begin{posterboxenv}[BFH-abstract]{name=api,column=1,row=3,span=1, rowspan=1} - - \includegraphics[width=\linewidth]{taler_docs_terminals_api.png} - \captionof{figure}{Terminals API Specification} + \begin{posterboxenv}{name=taler-news,column=1,row=3,span=1, rowspan=1} + + \includegraphics[width=\linewidth]{taler_news_terminals_api.png} + \captionof{figure}{GNU Taler announcement of C2EC (further reading)} \end{posterboxenv} - \begin{posterboxenv}[BFH-abstract,title=Integrating Wallee]{name=wallee, column=2, row=4, span=3, span=3} + \begin{posterboxenv}[title=Implementing PayDroid POS Terminal App (Wallee A50)]{name=wallee, column=2, row=4, span=3, span=3} To show that the specification is able to capture the needs for third party withdrawals and therefore allow the integration for theoretically any means of payment, an integration was done for the payment provider Wallee. Therefore an android app was implemented on the Wallee platform. The newly created withdrawal application sets up the withdrawal and awaits the registration of the withdrawal parameters (the reserve public key) through the Taler Wallet. After the parameters were registered, the terminal authorizes the payment by letting the customer present his credit card, which will trigger the attestation of the payment at the provider backend through the C2EC component. \end{posterboxenv} - - \begin{posterboxenv}{name=flow-diagram,column=1,row=5,span=4, rowspan=1} + \begin{posterboxenv}[title=Setup Withdrawal]{name=flow-diagram,column=1,row=5,span=1, rowspan=1} \includegraphics[width=\linewidth]{flow_diagram_simple.png} \end{posterboxenv} - \begin{posterboxenv}[BFH-abstract,title=Integrate your platform!]{name=Integrate your platform, column=1,row=6,span=2,rowspan=2} - C2EC is designed to be extensible. Therefore the component defines two interfaces which must be implemented in order to make use of the C2EC components. The first interface defines the interface between the transaction of the provider and the C2EC components. This includes the definition of the transaction state mapping between the provider specific states and the states defined by the Taler API. This step is crucial since, when implemented wrong, can lead to issues concerning the securities on the side of the Taler Exchange. This means that digital cash is withdrawn by the customer, when the counter payment was not yet fully secured. The second interface defines the integration of the provider backend into the C2EC component. This includes the requests necessary to load the state of the transaction on the side of the provider and the request to trigger refunds. + + \begin{posterboxenv}[title=Register Parameters]{name=flow-diagram,column=2,row=5,span=2, rowspan=1} + + \includegraphics[width=\linewidth]{flow_diagram_simple.png} + \end{posterboxenv} - \begin{posterboxenv}[title=Flow]{name=flow-diagram,column=3,row=6,span=2,rowspan=2} - \includegraphics[width=\linewidth]{system_overview.png} + \begin{posterboxenv}[title=Authorize Payment]{name=flow-diagram,column=4,row=5,span=1, rowspan=1} + + \includegraphics[width=\linewidth]{flow_diagram_simple.png} + + \end{posterboxenv} + \begin{posterboxenv}[title=Integrate your platform!]{name=Integrate your platform, column=1,row=7,span=4,rowspan=1} + C2EC is designed to be extensible. Therefore the component defines two interfaces which must be implemented in order to make use of the C2EC components. The first interface defines the interface between the transaction of the provider and the C2EC components. This includes the definition of the transaction state mapping between the provider specific states and the states defined by the Taler API. This step is crucial since, when implemented wrong, can lead to issues concerning the securities on the side of the Taler Exchange. This means that digital cash is withdrawn by the customer, when the counter payment was not yet fully secured. The second interface defines the integration of the provider backend into the C2EC component. This includes the requests necessary to load the state of the transaction on the side of the provider and the request to trigger refunds. \end{posterboxenv} \end{tcbposter} diff --git a/poster/flow_diagram_simplified.odg b/poster/flow_diagram_simplified.odg Binary files differ. diff --git a/specs/components_images.odg b/specs/components_images.odg Binary files differ. diff --git a/specs/components_images.webp b/specs/components_images.webp Binary files differ.
