Discussions on feedback and comments from Technoforte (MOSIP) on the MVP requirements | Discussion on how functional ID will be created: Functional ID will be a combination of the program owner (entity) ID + program application ID + the ID token provided by the ID BB that is unique for an individual. The token is necessary so that the root foundational ID of the individual is not exposed. This functional ID will reside in the program application. In summary, each functional system has a user database with their own specific functional data and the token that is generated by the foundational ID is just a proof that the person really exists as an individual.
Another implicit assumption which is made in the USCT use case that needs to be stated is that we are already assuming that the Program (USCT) is already created in the system, i.e., it has already been assigned a program ID which will be needed for the functional ID creation. So that's an implicit assumption in in that use case. Thus, at enrolment time, the application has to use the functional ID of the individual and pass on respective configuration information pertaining to the individual to respective building blocks. This business logic has not been thought through in any building block because it has been kept outside the building block and is something that should sit inside the application layer. To fetch personal data fields in absence of real biometric auth (e-KYC), we could mock the biometric auth process as well as consent flow in the MVP happy flow. In the long run, we will necessarily have to use the consent BB. For the MVP, we can assume a pass-through process to access individuals’ personal data. It would be better is this done through a consent plug-in stub which can be later replaced by the actual consent BB application as and when it is ready. We will also need to determine if the auth step needs to be done inside the Consent BB or outside by the application.
For other MVP steps too, we need to identify and agree what needs to be mocked in current flow for onboarding the individual as it relates to the authorization, validation, and enrolment of the individual as well as obtaining the required consent. In the current happy flow path for the MVP, we should mock the consent flow clearly stating that this step is presented due to its importance, but it is mocked in absence of a real application.
|
Discussions on feedback and comments from Mifos (MIFOS) on the MVP requirements | For the purpose of linking the ID into the Account mapper, it is necessary that the verification of eligibility of the individual into the USCT program is already performed. Only upon verification of the individual, the account mapper should be invoked. The process flow should take this into account. Here, the Registration building block collects the payment mapper related information and provides to the Payment BB via onboarding interface/ ingress Mapper API exposed by the Payments BB to populate the account mapper. This is a push call from the Registration BB and not a pull call from the Payments BB. Finally, post eligibility verification, at enrolment time the individual’s information will need to be provided to all relevant building blocks. This includes information that is collected during the registration process, such as the Payments BB will require the payment channel option provided by the individual, or perhaps, messaging BB may need to know the preferred messaging channel for the individual, and so on, likewise there could be dependencies for other different building blocks. For the happy flow case, we are not looking at bulk cases. For bulk cases, we need to identify how to keep information in the Registration BB regarding individuals whose details are already onboarded onto the Account Mapper - perhaps maintain some kind of flag to indicate the status of account mapper onboarding needs to be maintained.
Notification of payments needs more clarity. The Payments BB would know when the payment actually happened as it is interacting with the FSP's. However, we need clarity on which interfaces should be used to notify the status of the payment back to the registration BB? How will this notification be initiated? There are 3 possible alternatives for the notification: 1) Publish that to the caller BB that initiated this payment communicating the status of the request token. 2) The application could poll an exposed API by providing a specific token that that was given during the payment request and emit the status. 3) Put the status message of the particular token into the PubSub to which the caller has also subscribed to get notifications on a particular token number.
The above alternatives have been discussed from the architecture perspective. We need to determine what makes practical sense and is easier to implement for the USCT MVP. Perhaps the easiest alternative would be to use option 1) where the endpoint ID of the caller is known and the status and can directly communicated to the endpoint URL. This has a dependency on the Registration BB which is the caller BB that has to declare an API endpoint. The Payments BB can consume it to notify the status. For the current MVP, we don’t have PubSub implemented in the XRoad. So, though the PubSub option 3) is better from a scalability perspective, it is not possible to demonstrate in the MVP. For payment related status updates, there could be other security related issues with using PubSub as everyone can see the payment status.
|
