This post is continuing a discussion we started in the 3P API SIG.
The goal of this discussion is to be a living document on the different options, tradeoffs, pros and cons for (1) a scheme deploying Mojaloop PISP functionality, and a (2) DFSP implementing the thirdparty APIs to allow PISPs to initiate payments from their user’s accounts.
Decision 1 - DFSP sharing of
The latest iteration of the API includes some potentially private details (account nicknames) to be shared with the PISP before the account linking process can begin.
The PISP can use this information to provide their user with a list and details of the accounts to be linked, as well as the ability to select one or more accounts.
The 3P API supports both WEB and OTP authorization flows. For the WEB flow, this feature is only a convenience, since the DFSP can present their own webpage to the user to select the list of accounts for linking.
For the OTP flow however, we rely upon the PISP to ask the user for the list of accounts they want to link.
A few options:
accountNicknamean optional field, that the DFSP can include to send back. If they send it back, then fine, otherwise the PISP can display “found x accounts with your DFSP” instead of a detailed list.
Additionally, the DFSP could obfuscate some details about the
accountNickname. For example, if the nickname is
Chequing Account, the DFSP could send
accountNicknamefield for the PISP to display to the user.
Rework the OTP flow to require 2 OTPs - one to check the list of accounts, another to link those accounts.
@Henrik suggested that the OTP flow include both the consent to display and the consent to link accounts, and included this flow the following is a flow based on the OpenId Connect Backchannel authentication flow: OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0 draft-03
Decision 2 - DFSP Hosted or Centrally Hosted Auth Service
[ todo - for discussion ]