Change Request: Modification to transaction request resources
mjbrichards opened this issue · comments
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
| Version | Date | Author | Change Description |
|---|---|---|---|
| 1.0 | 2020-05-19 | Michael Richards | Initial version of request |
2. Problem Description
___2.1 Background
At present, the Mojaloop switch makes no distinction between the roles that participants can have. It is an implicit assumption that, once a participant is onboarded to a Mojaloop system, it can have access to all of the resources that the API provides; indeed, actual schemes may make it a condition of participation that a DFSP should handle all the resources that the API defines.
The addition of PISP services to the use cases supported by Mojaloop opens a new set of questions about the resources that a participant is allowed to support. A PISP does not offer account services to its users, and therefore ahould not be able to access a relatively large number of API resources: for instance, it should not be able to initiate a quote or a transfer, nor should it be able to respond to them directly. The Mojaloop switch will therefore need to be able to distinguish between participants based on the roles they perform, and to deny access to participants who are attemtoing to use API resources to which their role does not allow them access.
It is not clear how this functionality will, or should, operate in a peer-to-peer environment. Presumably, in a peer-to-peer environment, it would be the responsibility of the recipient of a message to satisfy itself that the sender had a role which allowed it to send that message, and to reject the message if it did not believe that the originator was allowed to send it.
Although the immediate requirement for this functionality is to support PISP, there are other expected types of participation which will also require access to API resources to be restricted for the institutions that fulfil them: FX services and Cross-network services are examples.
There are (at least) two pressing consequences to this requirement.
First, segmenting access to API resources by role type will require the switch (or a participant in a peer-to-peer network) to assess every message which it receives for validity. Depending on implementation, it may be possible to exempt some kinds of resources (e.g. GET /parties) from checking; but, in any case, the check will need to be performed at the message level. There is therefore a significant opportunity for the overall performance of the switch to be impaired if the functionality is not implemented in the most efficient way possible.
Second, there will need to be a method for defining the types of role that a scheme will support, the resources that each role is allowed to access, and the role(s) that any given participant has. This will be relatively slowly changing information, and we may therefore decide that there is no need to extend the API to allow participants to set or get that information. On the other hand, it may be valuable for participants (or a switch) to be able to obtain information about the participants who fulfil a particular role in a scheme: for instance, to be able to find out which participants provide FX services - or, indeed, DFSP services. If these facilities are required, then the API will need to be extended to accommodate them.
2.2 Current Behaviour
This is new functionality. It is not currently covered in the API.
3. Proposed Solution Options
___ The most effiicent way of performing a test on the message is expected to be to check at the API entry point, rather than passing the message to the switch and asking it to make the check. In any case, it will certainly be simpler and more efficient if we can test at the resource level, rather than needing to look at the content of the message.In most cases, it will be clear which resources a PISP is allowed to use. The exception is the /transactionRequests resource. This is used both by a merchant request to pay (which only a DFSP is allowed to issue) and by a PISP request. The only current way of distinguishing between them is by checking the content of the message to see whether the payee DFSP is also the sender of the message. If it is, this is a merchant request to pay; if it isn't, it's a PISP request.
In order to be able to distinguish between these types of request, we could add a new resource (say /thirdPartyRequests, which a PISP would be allowed to use but a DFSP would not. This would allow requests to be sifted efficiently at the API level. We might want to reinforce things further by removing the payee element from the POST /transactionRequests resource: since it would now only be used by MRTP, the payee could only ever be the same as the sending DFSP.
We could assume for the moment that the information required to specify the types of role supported by the system and the assignment of resource access to roles will be managed internally by the switch, without needing to modify the API. Additional services could be added if required to give participants access to the list of participants who fulfilled a given role (or, in a P2P network ti find if a given participant had a given role.)
Current thinking on the assignment of resources to roles is given here: mojaloop/pisp-project@376f064
I think this should be addressed in an architecture that is API first where and API gateway is used to manage the access to the APIs.
In that way single API do not need to be modified to include roles related parameters that would be validate at the switch
For requesting a transaction from a PISP, I would like to use a separate resource for PISPs as this should be in a separate API from the FSP Interoperability API. This resource can then be customized for PISP requests. The name /thirdPartyRequests is very vague though, I would like something more concrete which explains what the resource should do.
It is not clear how this functionality will, or should, operate in a peer-to-peer environment. Presumably, in a peer-to-peer environment, it would be the responsibility of the recipient of a message to satisfy itself that the sender had a role which allowed it to send that message, and to reject the message if it did not believe that the originator was allowed to send it.
At least our platform will always make sure that the sender is allowed to perform the request, no matter the environment. The PISP in this case needs to be a registered user in our platform, which can then be given the correct permissions.
What sort of name do you think would be sufficiently concrete, @ehenrka? I left it open like that because we're expecting it to cover a number of request types in the future (balance enquiry, statement etc. as well as funds transfer.) Do you have a suggestion?
The request types that you mention are all related to a specific account that you are performing the request on, so a simple suggestion is to use the base resource /accounts. Under that resource you will then have a number of endpoints for the different types of request, for example /accounts/{account ID}/balance to get the balance from an account, or /accounts/{account ID}/transfer to transfer from an account.
Please also keep in mind that these new functionalities will have a lot of similarities with the GSMA MM (Mobile Money) API (https://developer.mobilemoneyapi.io/). Some kind of cooperation with GSMA and reuse between these APIs would be very beneficial, and would hopefully decrease the amount of implementation work that existing adopters of the GSMA MM API needs to do. I would not like to create a direct competitor to the GSMA MM API, even if its a subset of the functionality, I would much rather support cooperation between Mojaloop and GSMA.
@ehenrka and @jmssebunnya - this is not an initiative in the projects list for consideration this PI discussion, however that doesn't mean its not something to be more formally tracking as part of the product leadership work. It might be something we take into that space? Are you interested in contributing to validating/shaping what we think 6 months on first from a product/why perspective before we think about actual work to do? the GSMA team might contribute too?
Sorry, @lavaughan, I don't think this is a live issue any more. We have taken the decision, as I said yesterday, to use separate APIs for different areas, and we're proceeding on that basis. I'll get this issue tidied up
@mjbrichards My comment regarding the GSMA MM API was not concerning the use of different APIs or not, it was a general request where ever this API ended up, that we should cooperate with GSMA instead of creating a "competing" API.
I understand this CR covers a wider topic of role-based APIs just on the point discussed by @ehenrka and @lavaughan, thank you for your comments, and I agree there may well be some value in aligning these new APIs you are creating for Mojaloop with the GSMA Mobile Money API, for the benefit of adopters of both APIs. Although we have not got a role-based approach to API endpoints, it may be possible to align these in some ways, a e.g. for PISP API for transactionRequest, aligning these with the equivalent API which would be used by a payer initiated transaction in the GSMA API. So just a quick note to say if you need any further information or want to discuss further let me know.
Thanks @Viji-GSMA for joining the discussion! It will be great to have your input as well.
@Viji-GSMA, @mjbrichards, @lavaughan, @jmssebunnya, let me try to explain roughly how I envisioned the reuse of the GSMA MM API for the PISP API so that we are aligned on a high level. Please note that this is not a complete solution, just based on my early thinking around this.
You could divide this in three parts:
- Discovery of accounts - This part allows a consumer using the PISP to find their accounts at their FSP. This could use existing APIs from the FSP Interoperability API
- Account linking and authentication - This part is completely new and concerns how the consumer can verify that they own the account(s) at the FSP. This is where GSMA Mobile Connect might be used as one option. FIDO and OpenId Connect are other alternatives. There is also some related work done as part of the GSMA MM API in https://developer.mobilemoneyapi.io/1.1/content/security that could possibly be reused somehow. (Please note that the sequence diagram below is just a very high-level sequence and should just be used as an example to understand my initial thoughts.)
- Use account(s) - This part concerns how the consumer can access their accounts at the FSP from the PISP. For this part, my suggestion is to use Mojaloop as a proxy between the PISP and the FSP, using the GSMA MM API as the API, exemplified by a balance check and a transfer below. By using Mojaloop as a proxy, there is no need for the PISP to integrate directly to the FSP.
The benefit of this is that we are reusing an existing API that is already supported by many of the technology providers. Please note that Ericsson does not currently support the GSMA MM API, so this suggestion is not a direct benefit for my company, rather for the benefit of the industry, interoperability, and for financial inclusion in general. The implementation in Mojaloop should be very easy as well, as Mojaloop is only acting as a proxy between the PISP and the FSP.
Some adjustments to the GSMA MM API would be necessary to align them. As an example, the call flow routing using FSPIOP-Destination and -Source would be good to have in the GSMA MM API as well. Another example is the regular expression for the amount, this has become more similar in GSMA MM API v1.1, and my hope is that they will be the same in v2.0. It will also be necessary to make the GSMA MM API more strict, as it is currently a very open API that is not very good for interoperability between systems (but makes it easy to implement as you have more freedom how to implement it). The FSP Interoperability API is much more strict in what you can send and how the flow is implemented. This could either be done in a specific Mojaloop version of the GSMA MM API that adds some extra requirements on top of the standard, or the GSMA MM API itself could be updated.
Thanks Henrik @ehenrka for a very comprehensive explanation (and @lavaughan , @Viji-GSMA , for your inputs).
Can I propose this to be taken up as the first ever item of the new PISP SIG, @lewisdaly , @MichaelJBRichards :-) ? If you agree, I'll work with Lewis on getting it started.
Thanks @elnyry-sam-k, for me it sounds good to continue this in the PISP SIG, as this is more related to that SIG.
@jmssebunnya Yes, it should be similar to UPI, though with some slight differences as I think that UPI is more in control of the actual transaction than what I suggest above. As an example, (as far as I can remember) it is UPI that requests both Payer and Payee FSPs to perform the financial transaction. In this case Mojaloop would be more of a proxy between the PISP and the FSP, and then used as normal for interoperability transfers between FSPs.