Giters

mojaloop / mojaloop-specification

This repo contains the specification document set of the Open API for FSP Interoperability

Home Page:https://docs.mojaloop.io/api

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Change Request: New API resources to manage consents

mjbrichards opened this issue · comments

commented

Open API for FSP Interoperability - Change Request

Table of Contents

1. Preface

___

In order to support the extension of Mojaloop to allow PISPs (Payment Initiation Service Providers, like GooglePay) to join Mojaloop schemes, the Open API will need to provide ways to document the negotiations between PISPs and the DFSPs who own the accounts with which the PISP will be authorised to interact. This change request describes the interactions required and proposes a way of supporting them. It is based on design discussions in the PISP development team (Lewis Daly, JJ Geewax, Adrian Hope-Baillie, Michael Richards.)

1.1 Change Request Information

| Requested By | Michael Richards, ModusBox |
| Change Request Status | In review ☒ / Approved ☐ / Rejected ☐ |
| Approved/Rejected Date | |

1.0 Document Version Information

Version Date Author Change Description
1.0 2020-05-04 Michael Richards Initial version - out for review.

2. Problem Description

___

2.1 Background

In order for a PISP to be authorised to access a customer's account with an account-holding DFSP, a number of actions need to be completed:

  1. The PISP needs to find out which DFSPs in a given Mojaloop scheme support PISP access.
  2. The PISP needs to find out which accounts a customer holds with a given DFSP.
  3. The PISP needs to find out from the customer which account(s) the customer wants to give the PISP access to, and what kind of access that should be (examples might be: transfer funds from my account, see my account balance.)
  4. The PISP needs to inform the account holding DFSP what kind of access is required, and which account(s) access is required for.
  5. The account holding DFSP needs to satisfy itself that its customer has approved the PISP's request for access to the customer's account.
  6. The account holding DFSP needs to inform the PISP that its request has been approved (or, indeed, rejected.)

This change request is intended to address the requirements described in items 4, 5 and 6.

To meet the requirements of item 4, the following questions need to be decided:

  1. What should the form of an access request be?
  2. What kinds of access should be supported?
  3. Should it be possible to ask for more than one form of access to an account in the same request?
  4. Should it be possible to ask for access to more than one account in the same request?
  5. How should the request be made?
  6. How can the DFSP to whom the request is addressed be confident that the PISP who makes the request is authorised to make it, and what is the extent of the authorisation?
  7. Should the DFSP respond immediately to say that the request has been received and is being processed, or should it delay its response until the request has been accepted or rejected by all parties?

To meet the requirements of item 5, the following questions need to be decided:

  1. How should authorisation be requested?
  2. How should the response to the authorisation be returned?
  3. How can the DFSP be confident that the response really did come from the customer?

To meet the requirements of item 6, the following questions need to be decided:

  1. Should the result of the access request be a response to the origiinal request or a separate message?
  2. What information needs to be included in the response?
  3. The PISP should use a unique identifier to access the customer's account. Should this be given a new identifier type?
  4. Who should create the identifier and how should it be communicated to the other party?
  5. Does the identifier need to be stored in the ALS, given that it will already be known to both parties?

2.2 Current Behaviour

There is no current behaviour. This is an addition to the API

2.3 Requested Behaviour

The current state of the design is given here:

PISP Account Linking design

3. Proposed Solution Options

We are thinking in terms of two additional API resources:

  1. An consentAuthorizations resource to be used by the PISP to ask the DFSP to give the PISP access to the customer's account. Assent to this by the DFSP means that the association process has been initiated.
  2. A consents resource to be used by the DFSP to inform the PISP of the consent(s) that have been granted or refused for the account(s) requested.

More detail will be added about content.

commented

Michael, did you forget to update the information in Section 2.2 and onwards? Only up to 2.1 seem to be filled in, the rest seem to be from the example change request. The "This change request describes the interactions required and proposes a way of supporting them." from Section 1 leads me to believe that there should be more information...

commented

Great. The issue saved itself in the format you see it. I went on and inserted the whole of the rest of the document, now GitHub has thrown it away. So that's an afternoon wasted.

commented

Not sure whether notifications have been sent, but I have now updated the content of the issue

commented

The type of consent could include some of this

  • KYC Consent (This can be in some levels of basic or full)
  • Transaction History Consent(Also basic or full for a duration of time),
  • Debit Consent to allow debit of the account at future time.

I would restrict access to one form to ensure that the customers are clear on any approval provided to be for a specific data/transaction consent request
Where there is justified need to combine consent request we could have an option for combined (KYC, Transaction, Debit)

Just like in an asynchronous design, the PISP should be notified on received request and await result. DFSP respond immediately to say that the request has been received and is being processed

commented

@mjbrichards Could you please attach the flow in Section 2.3 as a puml file instead? The exported image is too wide, making the FSP invisible in the flow.

commented

@ehenrka Probably better if I attach a reference to the PISP repository in Github. This should have the current versions: https://github.com/mojaloop/pisp/tree/master/docs/transfer

commented

Thanks @mjbrichards, I assume you mean https://github.com/mojaloop/pisp/tree/master/docs/linking instead as your link points to how the transfer can be performed.

It is pretty difficult to review this change request in detail as it is lacking quite a few details. On a high-level, the consent request looks fine if this is another API spec than the FSP Interoperability spec (the proposed API here is quite different).

Based on the proposed solution proposal, am I correct to assume that the /authorizationRequests and /authorizations in the flows should be renamed to /consentRequests and /consents? The names including consent sounds much better as they will then not be confused with authorizations in the FSP API.