mojaloop / design-authority-project

This is the Issue and Decision Log for tracking mojaloop and related Designs
1 stars 2 forks source link

Understand and Define Mojaloop Roles for PISP, x-network, etc. use cases #44

Closed lewisdaly closed 2 years ago

lewisdaly commented 4 years ago

Request:

As part of the PISP workstream, we have mostly agreed that a PISP DFSP is still a 'participant' in a Mojaloop switch, but a participant that has special properties.

In the x-network stream, we have also been talking about the new roles of CNP and FXP, which a DFSP might be able to adopt.

The goal of this ticket is to better define roles within Mojaloop so we can start to make decisions about what roles can access what resources within the Mojaloop API(s), and how such access controls can be implemented.

We might also choose to break-down the existing concept of a DFSP into more than one role which may be composed to allow for more fine-grained control of what a DFSP can and can't do.

To get us thinking, here are a few actions that a role may or may not have I've been thinking about. They are well and truly up for debate.

  1. Create Party
  2. Lookup Party
  3. Get Quote
  4. Initiate P2P Transfer
  5. Initiate Merchant Request To Pay
  6. Initiate 3rd Party Request to Pay

PISP#277 tracks this on the PISP side.

Decision(s):

Follow-up:

Dependencies:

Accountability:

Notes:

lewisdaly commented 4 years ago

This doc from the pisp work is the first attempt at breaking down the DFSP and PISP roles.

lewisdaly commented 4 years ago

Discussed in today's meeting.

The DA is happy for workstreams to go ahead and split out new APIs and Role definitions (e.g. Thirdparty API, CNP API etc.)

Next steps: