henrka
commented
2 years ago My proposal would be to have the identifier as a new optional element of type CorrelationId (name suggestion authorizationId to make it clear what it will be used for) in the body for the individual creation (POST /participants/type/identifier), to align with other requests within the API. The identifier is only used as part of the URI in callbacks, never in requests in the existing services.
If it is required for bulk creation as well, my suggestion would be to restructure the data model a bit so that it becomes:
- requestId
- partyList (1..10000)
- PartyIdInfo
- Currency
- CorrelationId (containing the authorizationId as for individual creation above)
This would also allow different currencies per party, instead of allowing only one single currency in a batch. Would have to wait until version 2.0 of the API though as it is a breaking change..
MichaelJBRichards
Open API for FSP Interoperability - Change Request
Table of Contents
1. Preface
This section contains basic information regarding the change request.
1.1 Change Request Information
| Requested By | Michael Richards, ModusBox | | Change Request Status | In review ☒ / Approved ☐ / Rejected ☐ | | Approved/Rejected Date | |
1.2 Document Version Information
2. Problem Description
2.1 Background
There is a problem with duplicate identifiers in Mojaloop. There are good reasons why more than one participant in a Mojaloop scheme might claim the same identifier - for instance, when Mobile Money schemes are operated by entities who are not Mobile Network Operators. As part of Mojaloop's efforts to address this issue, we intend to implement a use case which will allow customers themselves to use their DFSP request that their account at a particular DFSP be made the default for transfers to them, and to allow the Mojaloop switch to obtain direct confirmation from the customer that they have assented to the DFSP's request in the form of an OTP.
Use of an OTP requires confirmation via the existing /authorizations endpoint in the FSPIOP API, but this endpoint requires identification of the request (normally a /transactionRequests request) for which authorisation is required. However, the /participants endpoint, which is the FSPIOP API endpoint which is used to request assignment of an identifier to a DFSP, does not currently include a way of identifying a particular request, such as is provided, for instance, by the quoteId field in the /quotes endpoint. We therefore need a way of assigning a unique ID to a request to register an identifier with a DFSP.
2.2 Current Behaviour
At present, there are two ways of requesting assignment of an identifier to a DFSP. The long form, described in Section 6.2.3.3 of the FSPIOP specification, makes the entire request in the command: for instance, POST /participants/MSISDN/123456. The second form, described in Section 6.2.3.2 of the FSPIOP specification, contains one or more identifiers in the body of the request, and uses the simple command form POST /participants. The second form does contain an identifier in the form of the requestId field, but this identifier relates to the batch of requests, and not to the individual request.
2.3 Requested Behaviour
There are a number of ways in which this problem could be solved. One would be to add a unique identifier to the existing endpoints. The long form of assignment might take the form POST /f9357e7f-4552-4b89-966e-b7764419fde8/participants/MSISDN/123456, where f9357e7f-4552-4b89-966e-b7764419fde8 is the unique identifier assigned by the requesting DFSP. The short form of the request might add a unique identifier to each assignment request in the partyList, either by adding a unique identifier to the partyIdInfo object or, probably more securely, by creating a new composite object which contained a correlation ID for the request and a partyIdInfo object. Doubtless other solutions might also work; I leave these for discussion.