Modifications to Authorizations Resource about mojaloop-specification HOT 7 OPEN

Hi @mjbrichards, please include the proposed flow as discussed in the last CCB meeting.

from mojaloop-specification.

PISP Transfer Model puml.txt

Here is the proposed flow (might not be completely up to date, but should show the proposed new use of /authorizations.)

from mojaloop-specification.

Thanks @mjbrichards,

Please find some initial comments/questions below.

• For my understanding, why is it the FSP that should copy the quote callback to the PISP? Why not the switch which is the entity receiving the original request from the PISP? Having the switch reply to the PISP instead of the FSP would remove the "syntactically ugly" from the proposal, and it would also mean less changes to the FSPs.
• What happens if there is a fee in the Payer FSP if non-disclosing fee and receive amount is used (this fee is not part of the data model for the quote as this is internal to the FSP)?
• What information is really needed in the PISP from the quote (related to above as all information is not available in the quote)?
• From section 2.3: "This information should also include the current balance of the account which will be debited as a consequence of authorisation being obtained." We will never send out an account balance without proper authentication. From the flow I cannot see that the account holder has properly authenticated himself in our system before reply to the POST /authorizations, but maybe I have missed something. From the flow it looks like the authorization happens first as a bearer token when approving the transfer. This would mean account balances can be leaked to anyone requesting a transfer from the PISP. I would like to have some kind of authentication to be done already at the POST /transactionRequests
• What kind of information regarding the transfer is the PISP interested in? I don't really see the need to send the transfer callback to the PISP, which contains a lot of things that it should not care about. A quick suggestion would to use something like PATCH /transactionRequests to update the state of the original transaction request, in line with #29.

In general, I'm not 100% convinced that the suggested POST /authorizations should be part of this API (the FSP Interoperability API).. This part is between the PISP and the Payer FSP, to inform the account holder regarding the transfer and let him reject/accept it through the PISP. My initial reaction is that this seems like another API directly between the PISP and the Payer FSP, without going through a Mojaloop switch and trying to adapt the existing API..

from mojaloop-specification.

Thanks for your detailed comments, Henrik. Let me respond to them in order.

First, the current design no longer requires the Payer DFSP to respond independently to the PISP with the result of the quotation. That is the point of including information about the transfer in the /authorizations resource. I think that the Payer DFSP is the entity that received the original request, not the switch. The switch forwards it, and might even store it for reporting and reconciliation services, but it isn't the recipient in that sense...

Second, if there is a fee charged by the payer DFSP which is not returned in the quote request, then the Payer DFSP should include that fee in the information it sends in the /authorizations request to the PISP. There is no requirement for the content of the transaction object included in the /authorizations request to be identical to the object returned to the Payer DFSP from the /quotes request. It is, however, important that the customer should be aware of all the fees involved in the transfer.

Third, my view is that the transaction object should be the definitive statement of the terms under which the transfer is to be made. If there is relevant information which is not included in the transaction object, then in my view the definition of the transaction object should be expanded to include it.

Fourth, the ability to obtain an account balance at the same time is now proposed to be the subject of a separate agreement between the DFSP and the PISP. We are no longer proposing that the account balance should form part of the POST /authorizations call.

With respect to authentication, the situation is as follows. There will be a prior workflow between the PISP and the DFSP, which will manage the creation of an agreement between them. The DFSP will agree that its customer has properly authorised the PISP to issue transactionRequests against the customer's account(s). The PISP has agreed that it will include a public key shared between them as part of the agreement in future transactionRequests. When the PISP first makes a transactionRequest, it is on that prior agreement that it relies. The DFSP can verify, first, that the transactionRequest did come from the party it purported to come from; second, that it relates to an agreement that the DFSP recognises (right customer ID); and, finally, that it contained the public key exchanged as part of the creation of that agreement. Specific authorisation for the transfer itself has not yet been obtained: that is the very purpose of the /authorizations request.

Next, the PISP needs to be informed whether the transfer has succeeded or failed, so that it can inform its customer. I would expect that the readiest way of doing that would be for the switch to register the PISP as a legitimate party to the transfer who would therefore be informed of the outcome in the same way as the Payer DFSP and (optionally) the Payee DFSP; but that is not the subject of this change request. The route you suggest would also, of course, work.

I confess that I'm surprised to find you suggesting that it would be better to manage this via a point-to-point ad hoc API between the Payer DFSP and the PISP. We envisage the existence of a potentially large number of PISPs in a switch, and the complexities of managing the relationships between them and the (again, potentially many) DFSPs with which they would want to interact seem to me likely to lead to precisely the mess that Mojaloop was designed to avoid. But perhaps I've misunderstood your suggestion.

from mojaloop-specification.

Thanks Michael,

First, the current design no longer requires the Payer DFSP to respond independently to the PISP with the result of the quotation.

Do you have an updated flow that contains the current design? Because my comments are based on the attached flow from #58 (comment).

I think that the Payer DFSP is the entity that received the original request, not the switch.

According to the flow you shared it is the Switch that receives is from the PISP server. Please update the flow with the latest information (if this has been updated) so that it is possible to give relevant comments.

There is no requirement for the content of the transaction object included in the /authorizations request to be identical to the object returned to the Payer DFSP from the /quotes request.

That the transaction object should be included is new information to me (not part of the shared flow).

Third, my view is that the transaction object should be the definitive statement of the terms under which the transfer is to be made. If there is relevant information which is not included in the transaction object, then in my view the definition of the transaction object should be expanded to include it.

All fee information is not included to allow the FSP to keep its internal fees hidden from other FSPs (using the non-disclosing receive amount). There is no purpose in sending these fees to the other FSP, the transaction data model only contains the amount that should be received by the Payee (although the description says "Transaction amount to be sent."). I do not see why another data model object could be used to relay the necessary information to the PISP -> Payer, which only includes the information that the PISP (and Payer) is interested in and should be able to see (the transaction data model is for the FSPs/Switch involved in the transaction)?

With respect to authentication, the situation is as follows. There will be a prior workflow between the PISP and the DFSP, which will manage the creation of an agreement between them. The DFSP will agree that its customer has properly authorised the PISP to issue transactionRequests against the customer's account(s). [continued] ...

Thank you for the information, sounds good on a high-level.

I confess that I'm surprised to find you suggesting that it would be better to manage this via a point-to-point ad hoc API between the Payer DFSP and the PISP. We envisage the existence of a potentially large number of PISPs in a switch, and the complexities of managing the relationships between them and the (again, potentially many) DFSPs with which they would want to interact seem to me likely to lead to precisely the mess that Mojaloop was designed to avoid. But perhaps I've misunderstood your suggestion.

I did not say it would be better, I just said that I'm not 100% convinced that this should be part of the FSP Interoperability API. For example, it could still be a standardized part of the Mojaloop API suite, or we could very well decide that it should be part of the FSP Interoperability API. Additionally, you seem to suggest the same thing in the quote below from your comment, unless I'm misunderstanding. How will the account balance be shared in the separate agreement between the FSP and the PISP, if not via some other API? Why can't the authorization part to the account holder be handled in the same way as the account balance?

Fourth, the ability to obtain an account balance at the same time is now proposed to be the subject of a separate agreement between the DFSP and the PISP. We are no longer proposing that the account balance should form part of the POST /authorizations call.

from mojaloop-specification.

from mojaloop-specification.

@millerabel, our design at present allows the authorisation servers which generate challenges and assess their results to be located either at the switch or at the DFSP. I therefore conclude that a P2P version of Mojaloop including PISP would be architecturally feasible.

from mojaloop-specification.