Discuss the PISP Simulator

[lewisdaly]

Request:

For the PISP worksteam, we need to extend the mojaloop-simulator.

At the moment, we are planning to keep this all in the same repo, and expose the PISP functionality under some config settings.

The new features for the PISP Simulator are:

• Mock FIDO key registration
• Mock FIDO key signing
• new call to POST /thirdPartyRequest/transfer - this is the new PISP equivalent of transactionRequest
• Handle a new POST /authorizations callback
• Handle Mocked OAuth2 Pushed Authorization Request flows:
  • OTP
  • Web redirect based

Artifacts:

• [ ] Artifact to consider [@Contributor]

Decision(s):

• [ ] DA is happy for the PISP work to use and extend the mojaloop-simulator
• [ ] There is an outstanding issue of the sdk-scheme-adapter, and we will likely want to make a new thirdparty-scheme-adapter in the future. That will be followed up in a new ticket.

Follow-up:

• [ ] Should the PISP implementation live in the sdk-scheme-adapter, or should we make a new thirdparty-scheme-adapter? https://github.com/mojaloop/design-authority/issues/51

Dependencies:

• [ ] If Applicable

Accountability:

• Owner: @lewisdaly

Notes:

[lewisdaly]

• Simulator to mock the API calls, no web redirect or otp

[lewisdaly]

This was discussed on 10/06/20 with the following outcomes:

• reusing and extending the mojaloop-simulator for pisp purposes is all good (and preferred)

• As for the sdk-scheme-adapter (which the mojaloop-simulator uses behind the scenes), since the PISP API will be quite a different from the Mojaloop API, we will look to creating a new thirdparty-scheme-adapter (or whatever we want to call it) before the pisp changes are merged back upstream into master.

  For the time being, however, the PISP workstream will work on it's own branch in the sdk-scheme-adapter, and such a division/abstraction of the sdk-scheme-adapter will be revisited at a later date (see https://github.com/mojaloop/design-authority/issues/51)