Change Request: Modification to transaction request resources

[mjbrichards]

Open API for FSP Interoperability - Change Request

Table of Contents

• 1. Preface
  • 1.1 Change Request Information
  • 1.2 Document Version Information
• 2. Problem Description
  • 2.1 Background
  • 2.2 Current Behaviour
  • 2.3 Requested Behaviour
• 3 Proposed Solution Options

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: https://github.com/mojaloop/pisp/pull/5/commits/376f06423b7b1eabe5516e8a5c77836836a64bf7