Links

Social Cash Transfer - Tech Demo

Demonstration of a full stack implementation using a Unconditional Social Cash Transfer (USCT) use case
Unconditional Social Cash Transfer (USCT) programs help families meet their basic needs for well-being and safety and serves as their path to self-sufficiency. USCT are cash payments provided to financially disadvantaged or vulnerable people or households without requiring anything in return (i.e. without conditionality).
This demo covers only a small fraction of a USCT user flow for the purpose of using various Building Block APIs. For a more comprehensive visualization of the use case visit the GovStack USCT simulation.

Which GovStack features are demonstrated?

With this use case implementation, we demonstrate the GovStack approach through...
One possible way to implement the GovStack Specifications
Browse through all the stack components on the left-hand side menu, to explore the technical details on how we put the specifications into practice.
Interoperable Digital Public Infrastructure (DPI)
GovStack Specification compliant and open source licensed
  • BB Identity: MOSIP
  • BB Payment: Mifos Payment Hub
  • BB Information Mediator: X-Road
  • BB Digital Registry: OpenIMIS
  • BB Consent: iGrant
Architectural Best Practices
Reusable and Open Source
Replicate the Frontend, Backend and Building Block (Emulators) or reuse specific components using our DYI section.

How to access?

Data Privacy Note: By clicking on one of the access points you enter web applications operated by the Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH where these Data Protection Notice and Registration Information are valid.
This technical demo does not focus on user experience. For a the full user journey of this use case, visit our GovStack Simulation.

Use Case Frontend Walk Through

Enrollment Officer ID: 9038952310 Payment Officer ID: 2405176278 OTP: 1 1 1 1 1 1
Open the Use Case Frontend and follow these steps to navigate through the demo. In green, read a very simplified version of the BB interactions.
Walk Through Steps
  1. 1.
    Click "Log in with e-signet" The user gets forwarded to the UI of the Identity BB. Demonstrating UI Switching.
  2. 2.
    Click "Log-in here" and enter the ID 9038952310 to login in as Enrollment Officer
  3. 3.
    Enter 1 1 1 1 1 1 as One Time Password (OTP)
  4. 4.
    As fictional Enrollment Officer give consent to using essential personal information (You do not give consent to use your personal data! It is only for demonstration purposes.) The user gets forwarded back to the Use Case Frontend with respective role parameters.
  5. 5.
    Enter the "Candidate Database" The user gets a list of candidates requested by the Use Case Backend from the Registry BB channeled through the Information Mediator BB.
  6. 6.
    Pick a candidate which has given consent or request consent to using their personal information by clicking that person and "request consent" The user requests information from the Consent BB, if candidates approved the usage of their personal data. If approval has not been given yet, the user triggers the Consent BB to request approval from the candidate (in this demo, the approval process is mocked and only takes a few seconds).
  7. 7.
    Enroll any person to any available benefit package and log out. The user triggers the Use Case Backend to request the Registry BB to change the enrollment status of a candidate to "Beneficiary".
  8. 8.
    Repeat the log in procedure with the ID 2405176278 to log in as Payment Officer Again, the user gets forwarded through the UI of the Identity BB.
  9. 9.
    Enter the "Beneficiary Database" and mark (check box) a person to order payment
  10. 10.
    Confirm Payment Order The user triggers the Use Case Backend to request the Payment BB to issue a payment order. They Payment BB returns successful execution of the payment.
View a sequence diagram describing all API requests between BB in the developer documentation

Building Block UIs

Administrative UIs of the Building Block Software (X-Road, MOSIP, Mifos Payment Hub, iGrant) can only be demonstrated by GovStack Initiative staff, until we implemented a secure way to expose the Admin UIs publicly. If you are interested, please contact us.

How are the stack components assembled?

The following diagram shows one use case instance with used applications and Building Blocks.
For more details, browse through the high-level explanation component page or the in-depth documentation and code repositories of the various components.
Component Page
Developer Documentation
Code Repository
X-Road
-
MOSIP
Mifos
-
OpenIMIS + Adapter
iGrant

Data Protection Notice and Registration Information

The following information are valid for all web applications linked in the access points chapter.
Data Protection Notice
The Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH attaches great importance to responsible and transparent management of personal data.
Below we provide users with information as to
  • who they can contact at GIZ on the subject of data protection
  • what data is processed when they visit the web application
  • what rights they have with respect to us
Controller and Data Protection Officer
The responsible body for data processing is the Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH.
Address: Friedrich-Ebert-Allee 32 + 36, 53113 Bonn Dag-Hammarskjöld-Weg 1–5, 65760 Eschborn
If you have specific questions about the protection of your data, please contact GIZ's data protection officer: [email protected]
General
GIZ processes personal data exclusively in accordance with the EU General Data Protection Regulation (GDPR) and the German Federal Data Protection Act (Bundesdatenschutzgesetz, BDSG). Personal data are, for example, name, address, email addresses and user behaviour.
GIZ only processes personal data to the extent necessary. Which data is required and processed for which purpose and on what basis is largely determined by the type of service you use or the purpose for which the data is required.
Cookies
When you visit a web application, small text files, so-called cookies, are stored on your computer. They are used to make the online presence more user-friendly and effective overall Cookies cannot run programs or infect your computer with viruses.
The GIZ website uses cookies that are automatically deleted as soon as the browser in which the page is displayed is closed (so-called temporary cookies or session cookies). This type of cookie makes it possible to assign different requests from a browser to a session and to recognize the browser when you visit the website again (session ID).
Collection of personal data when visiting a web application
When visiting a web application, GIZ itself processes only the data that is automatically transmitted by the browser and technically required in order to display the website correctly and to ensure its stability and security. Each time a web application is accessed, the data stored includes, but is not limited to the following:
  • Date (The date on which the activity occurred.)
  • Time (The time, in coordinated universal time (UTC), at which the activity occurred.)
  • Server IP Address (The IP address of the server on which the log file entry was generated.)
  • Method (The requested action, for example, a GET method.)
  • URI Stem (The target of the action, for example, Default.htm.)
  • URI Query (The query, if any that the client was trying to perform. A Universal Resource Identifier (URI) query is necessary only for dynamic pages.)
  • Server Port (The server port number that is configured for the service.)
  • Client IP Address (The IP address of the client that made the request.)
  • User Agent (The browser type that the client used.)
  • Referrer (The site that the user last visited. This site provided a link to the current site.)
  • HTTP Status (The HTTP status code.)
  • Time Taken (The length of time that the action took, in milliseconds.)
  • Request Body (The transmitted data for demonstration purposes (e.g. fictional person)
The data in the log file is temporary stored. The log retention time depend on amount of requests, service up time and other factors.
Further information on the storage and transfer of data:
GIZ is obliged to store data beyond the time of the visit in order to ensure protection against attacks on the GIZ’s internet infrastructure and the communications technology of the Federal Government (legal basis: Art. 6 (1) (e) GDPR in conjunction with Section 5 BSI Act). In the event of attacks on communications technology, this data is analyzed and used to initiate legal and criminal prosecution.
Data logged when accessing the GIZ's web applications is only transmitted to third parties if there is a legal obligation to do so or if the transmission is necessary for legal or criminal prosecution in the event of attacks on the Federal Government's communications technology. Data will not be passed on in any other cases. This data is not merged with other data sources at GIZ.
Information on opting out
Users who do not agree with the described processing of data cannot access the web applications. For technical reasons, opting out is not possible.
Disclosure to third parties
GIZ does not pass on personal data to third parties unless it is legally obliged or entitled to do so by law.
Transfer of data to countries outside Germany
GIZ does not transfer personal data to third countries. When using social media, the privacy policies of the respective providers apply.
Duration of data retention
User data will not be kept any longer than is necessary for the purpose for which it is processed or as required by law.
IT security of user data
GIZ accords great importance to protecting personal data. For this reason, technical and organisational security measures ensure that data is protected against accidental and intentional manipulation and unintended erasure as well as unauthorised access. These measures are updated accordingly based on technical developments and adapted continuously in line with the risks.
Visitors to the GIZ website have the right
  • To obtain information about their data stored by us (Article 15 GDPR)
  • To have their data stored by us rectified (Article 16 GDPR)
  • To have their data stored by us erased (Article 17 GDPR)
  • To obtain restriction of processing of their data stored by us (Article 18 GDPR)
  • To object to the storage of their data if personal data are processed on the basis of the first sentence of Article 6 (1) 1 f and e GDPR (Article 21 GDPR)
  • To receive their personal data in a commonly used and machine-readable format from the controller such that they can be potentially transmitted to another controller (right to data portability, Article 20 GDPR).
  • To withdraw their consent to the extent that the data has been processed on the basis of consent (Article 6 (1) a GDPR). The lawfulness of the processing on the basis of the consent given remains unaffected until receipt of the withdrawal.
Users also have the right in accordance with Article 77 GDPR to lodge a complaint with the competent data protection supervisory authority. The competent authority is the Federal Commissioner for Data Protection and Freedom of Information (BfDI).
Registration Information
Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH
Registered offices
Bonn and Eschborn Germany
Friedrich-Ebert-Allee 32 + 36 53113 Bonn Germany T +49 228 44 60-0 F +49 228 44 60-17 66
Dag-Hammarskjöld-Weg 1 - 5 65760 Eschborn Germany T +49 61 96 79-0 F +49 61 96 79-11 15
E [email protected] I www.giz.de
Registered at
Local court (Amtsgericht) Bonn, Germany: HRB 18384 Local court (Amtsgericht) Frankfurt am Main, Germany: HRB 12394
VAT no.
DE 113891176
Chairperson of the Supervisory Board
Jochen Flasbarth, State Secretary in the Federal Ministry for Economic Cooperation and Development
Management Board
Thorsten Schäfer-Gümbel (Chair) Ingrid-Gabriela Hoven (Vice-Chair) Anna Sophie Herken