| |
|---|
Updates on discussions for clarifications between MIFOS and Sandbox team regarding MVP process flows (meeting held on Apr 27) | Alignment on 2 key aspects of the MVP Happy flow. Currently the MVP Happy flow considers only a single transaction being passed. However, there was discussion if multiple transactions or payments may be needed? Does the whole MIFOS eco system needs to be in the Sandbox. The Pay BB assumption at the moment is that the FSP will be in Mifos to be more replicable of reality and ease integration.
The MVP is just the first step in the USCT demo. Hence, it is better to keep things very simple and demonstrate a single transaction. For the eventual USCT demo we will need to demonstrate multiple transactions and payment modes. As per the Sandbox team, the purpose of the MVP is to explicitly demonstrate the simulation as well as the interoperability activities in the flow, it is better done if the Sandbox can control the complete flow of simulation (i.e., all interaction points should be located in sandbox). Hence, it is important that only the minimum set of Pay BB functionalities should be included in the MIFOS implementation. However, the MIFOS team suggests that it is better being out of the Sandbox, the rational being that it is not a Pay-BB but FSP functionality. In a real implementation the FSP functionality would be with the FSP. Hence using the MIFOS’s existing FSP infrastructure and just putting the components that we expect for the Pay-BB in your environment would better demo the real-world example for the USCT use case. It also has the advantage of being quicker and simpler as the FSP functionality is in place already in the MIFOS product. Generally, there is shared understanding on where we want to land, but there is need to start moving in a more detail detailed way by mapping all the steps again and identifying already existing API's and those API’s which are still under construction so that get the detail clarity on on the interface level and data level. The most important point is that the MVP happy flow is just a start. The whole USCT use case will have more than one transaction for payment. It is a shared understanding that what we're doing from this MVP flow is just the basic transaction without any negative result, without any exception flow or alternate flows. And while we will be considering the G2P bulk disbursement for this, but we'll be doing that for only one transaction in the MVP happy flow. Going forward once we demonstrate this happy flow; we will try to complete the rest of the USCT use case which will include the complete bulk disbursement as well as the other alternate flows and other conditions within the USCT use case context. However, we definitely have to look the next steps also more deeply, because the concept of integrating into the sandbox is still too vague and is only understood in a general way for now. Similarly, the discussions around connectors or adapters are still gaining shape and the Pay BB and all other building blocks are also developing currently consistent and compliant API specifications. So, it might appear that the next steps might look totally different than the first MVP happy flow journey.
|
Clarifications on aspects related to user onboarding, and registration, functional ID and foundational ID creation. | The role of MOSIP ID BB is to authenticate the individual and based on consent from the individual, share the data. As per Technoforte, the pre-requisites for the MVP flow is that the users must be registered in MOSIP and should have obtained their foundational ID Things to consider in the process flow: 1) Login to SRIS portal - how will the system user log in? Can the foundational ID be used as the Identity Provider? Technoforte suggests using the MOSIP e-Signet module for this purpose which is implemented based on OpenID Connect and OAuth 2.0. e-Signet can be a login provider for a relying party application to enable access to the service without creating yet another set of login credentials (username/password combination). Details can be found in MOSIP eSignet | MOSIP Docs 1.2.0 . User will be re directed to the e-Signet portal where s/he can provide ID and otp for self-authentication. A reference implementation can be provided to implement the same in SRIS. API details are available in GitBook
2) During citizen registration, a re-direct to e-Signet is required. Here, e-Signet can be used for consented data sharing/ e-KYC. Once the individual is authenticated and consent obtained, the information required for user registration can be shared to the SRIS portal. On successful authentication, a partner - user specific token will be generated which will be unique for the individual, this is the token that is necessary to generate the Functional ID and will be returned by the ID BB. Technoforte needs specifications for the partner token that has to be returned. We also need to clarify if there is a need for a Civil Registry for the MVP happy flow as the current assumption of Technoforte is that the users must be registered in MOSIP and should have obtained their foundational ID, and not the civil registry.
To help Sandbox team understand the technical aspects of e-Signet integation and re-direction flow, Technoforte can provide the APIs which that can be used to mock the reference implementation and integrate Signet along with the SRIS portal. Here the data inputs and outputs coming out of the MOSIP system and into the happy flow path and the API that needs to be called by the sandbox UI, needs to be clearly defined by Technoforte. Meelis suggested a working session call with the Technoforte to go over these technical issues, as well as identification of data level requirements and interaction points in more detail (planned for Thursday May 5)
|
Next steps - when can we define a Sprint where the 4 teams can work together to deliver the MVP? | At, at what point of time do we create a Sprint to implement the MVP where all the three teams or four teams including registration are able to collaborate together so that we can see some output. We need some clarity on that Sprints from the sandbox team to initiate this Sprint so that we can also take the other teams work plans into account. Sandbox technical team to identify aspects or understanding that is still missing to start the MVP implementation. Ideate what could be outcomes from the Sprints based on alignment, collaboration effort required from the BB implementation partners.
Sandbox technical team needs the specific endpoints and the configuration of BB’s to be used for the MVP. Specifically, the end points related to the beneficiary on-boarding and updating, checking the payments and for payment disbursement. Along with the API endpoints, details are also needed on how to install and configure the BB’s (MIFOS and MOSIP) into the Sandbox in the desired manner for implementation and testing.
|
