NicoDuvenage
commented
4 years ago Issue Discussion Reference - Michael Richards
Distinguishing PISP permissions from DFSP permissions
Issues and proposal
Introduction
The current work to extend the Mojaloop product to support PISPs has given rise to a new architectural problem.
The Mojaloop product is being extended to allow PISPs to become participants in Mojaloop schemes. Although PISPs do not have direct control of accounts, they are allowed, subject to the consent of the account owners, to ask the DFSPs who control the accounts to move funds out of those accounts, subject to confirmation by the account holders. The system is expected to be extended in the future to include additional functions, such as the ability to request an account balance or to ask for a statement, or to retrieve an account's KYC status.
It is expected that this process will consist of two separate phases. In the first phase, the PISP will contact the account-holding institution and request access to an account on behalf of a client. The account-holding institution will satisfy itself that its customer really has granted permission to the PISP; and, subject to that, it will register the PISP as allowed to make requests to debit the customer's account(s).
Some of these changes will require new API resources. Others will require changes to existing API resources. In all cases, a participant with a PISP role will be allowed to access resources which a participant with a DFSP role will not, and vice versa. This is a significant change from the existing architecture of a Mojaloop scheme, in which all participants are given access to all resources.
Possible approaches
Two possible approaches to the problem have been identified, as described below
Single API, access segmented by resource
We could simply extend the existing Open API definition to accommodate the new and changed requirements. This would require changes to existing implementations, although it might be that schemes which did not intend to implement the PISP model would need to make only minimal changes.
The changes to the API would be simple in that they could all be done in one place, and schemes could decide whether or not to implement the new version of the API. This might, however, cause problems for upgrading where implementers are not on the most recent version of the API and new functionality which they do wish to take advantage of is later included in the API.
Checks to see whether a sender was entitled to use a particular resource could be done using role-based authentication to give access to the API itself. This technique is already used to confirm that a participant is a member of the scheme, and it is not expected that the addition of a resource-based check would add significantly to the processing overhead in this area.
Implementing this form of check for a single API would require the POST /transactionRequests resource to be split, since the only way at present of distinguishing whether this resource is being called by a PISP or a DFSP (for MRTP) is to look at the body of the message and see whether the payee DFSP is the same as the sender of the message. If it is, then this is an MRTP; if it is not, then the request is a PISP request. Interrogating the body of the message would add very significantly to the cost of evaluating a request, and we would therefore expect to introduce a new resource to the API (currently proposed as /thirdPartRequests) which would only be available to PISPs. PISPs would not be given access to the existing /transactionRequests resource.
Separate APIs, access segmented by API
We could create a new API solely for the use of PISPs. The PISP API would contain both the new resources specific to PISP operations and those existing resources that PISPs as well as DFSPs are allowed to use.
In this case, implementers could decide whether they wanted to add PISP support or not, and would only need to support the PISP API if they did. Role-based authorisation would be performed at the API level rather than the resource level; this is not expected to make any substantial difference to the resource cost of evaluation.
This proposal would not mean that there would be no PISP-related resources in the DFSP API. The DFSP API will still need to contain, for instance, resources to allow the DFSP to send requests to the PISP or to receive requests from the PISP. The segmentation currently described for the separation of function between PISP and DFSP will continue to apply, and DFSPs who intend to support PISP will need to include support for those resources. It would be possible to split those resources out into a third API, specific to DFSPs who support PISP; but it's possible to imagine this situation becoming quite complicated in the longer term.
In cases where resources are shared by both the PISP and DFSP (e.g. GET /parties,) the $ref key can be used in both Swagger definitions to point to a single definition of the objects that are shared.
Both DFSPs and PISPs would send messages via their normal API. The switch would recognise the API used by the recipient for the requested resource and would route the messages through that API. For instance:
- A PISP issues a GET /parties request through the PISP API for identify the payee DFSP for a proposed transfer.
- The switch obtains the payee DFSP from the ALS.
- The switch routes the request to the payee DFSP through the payee's Open API interface.
- The payee DFSP responds via the Open API interface
- The switch routes the response to the PISP through the PISP's interface.
Proposal
Subject to agreement on the architectural support for role-based authorisation to access an API, and on a method to register the roles which a participant is allowed by the scheme to accept and to make these available both to the authorisation process and to the switch so that it can route messages through the correct interface, we recommend the use of separate APIs. The second approach has the following advantages:
- There is no additional overhead associated with the authorisation process.
- The existing Open API can remain as it is, with no immediate requirements for change by schemes and participants who do not wish to support PISP functionality.
- Participants can add support for PISP by adding support for a new API. They will not need to adjust to new versions of the existing API until they want to.
- It will be simpler to segment new functionality in general in the future.
The proposal has the following drawbacks:
- It will be more complex to administer.
- As new roles are added, their management will become more complicated.
- At present, we assume that the switch will always be able to determine which API to call with a given message, based solely on the recipient. This implies that each participant will only have access to a given resource via a single API. We should design a solution which can accommodate situations in which the question is more complicated (for instance, where a DFSP also wants to function as a PISP.)
lewisdaly
Request:
Answer the question of whether to have a separate API for PISP, or simply extend the existing Open API
Artifacts:
4x API options discussion:
Decision(s):
Follow-up:
Accountability:
Notes: