Update API to use latest Interledger formats about mojaloop-specification HOT 11 OPEN

@adrianhopebailie Sorry for the confusion, I thought you meant multiple lower-value transfers to the Payee which are then combined into one transaction, not multiple transfers along the way through different networks to the Payee which are needed for cross-border and cross-currency.

from mojaloop-specification.

Unless I misunderstand something, the change in interledger/rfcs@3b28059 changes this CR completely, as it seems like we still need the ILP Packet to be encoded to follow ILPv4 correctly?

• Old text: ILPv4 packets SHOULD be encoded using the ASN.1 Octet Encoding Rules.
• New text: ILPv4 packets MUST be encoded using the ASN.1 Canonical Octet Encoding Rules. Implementations MAY accept packets encoded in a non-canonical form.

Please correct me if I'm wrong..

from mojaloop-specification.

Some comments:

• The name of the API is not Mojaloop.
• "Use Payee.PartyIdInfo.PartySubIdOrType header to hold the ILP address of payee and remove the length restriction on the data type." I do not like removing length restriction so that there is no limit at all, for security reasons all string parameters should have a maximum length. Please indicate a suitable length restriction if the current restriction of 128 is not enough.
• "Mojaloop /transaction API" in the table should say "FSPIOP /transfer API" or similar.
• In the earlier change request in Word you mentioned that the payload (the transaction) should be base64 encoded, is that still valid? Does not seem like that based on the above. Could you please clarify?
• I asked you earlier to look at sending back data in the callback PUT /transfers, the data that is currently sent as part of PUT /transactions. The current GET /transactions request was added to the API as Interledger v1 did not support sending back data together with the fulfilment in the PUT /transfers. This seems to be supported in ILP v4 now (https://interledger.org/rfcs/0027-interledger-protocol-4/, ILP Fulfill), is my understanding correct? Can we please include the data in PUT /transfers instead, so that the /transactions resource can be deprecated?

from mojaloop-specification.

I'm concerned about the use of the Payee.PartyIdInfo.PartySubIdOrType field to hold the ILP address of the payee (I assume that it is the item in the Transfer object that is meant, though it says "header"; or have I misunderstood?) The specification shows examples of how this item might be used for other purposes (see Section 5.2,) and these use cases would be impossible if we were to insist that the SubIdOrType field were to contain the ILP address of the party. In my view, it would be better to separate the two purposes from each other, and store the ILP address in a separate subfield of the PartyIdInfo structure (as it might be, an optional field called Payee.PartyIdInfo.PartyIlpAddress.)

I also agree with Henrik: this field should have an appropriate maximum length.

from mojaloop-specification.

@MichaelJBRichards Using a separate optional element instead of PartySubIdOrType sounds good, would make it easier to explain in the documentation and therefore also easier to understand.

from mojaloop-specification.

@ehenrka and @MichaelJBRichards I have addressed some of your comments by editing the issue.

@ehenrka asked:

In the earlier change request in Word you mentioned that the payload (the transaction) should be base64 encoded, is that still valid? Does not seem like that based on the above. Could you please clarify?

There is a separate conversation going on about the need for this. The primary requirement is for a piece of data that can be the input to the condition generation algorithm that is the same in both the quote and transaction. This allows the payee to return some data that is sent back in the transaction and can be used to regenerate the fulfilment.

I have attempted to address this in #14

asked you earlier to look at sending back data in the callback PUT /transfers, the data that is currently sent as part of PUT /transactions. The current GET /transactions request was added to the API as Interledger v1 did not support sending back data together with the fulfilment in the PUT /transfers. This seems to be supported in ILP v4 now (https://interledger.org/rfcs/0027-interledger-protocol-4/, ILP Fulfill), is my understanding correct? Can we please include the data in PUT /transfers instead, so that the /transactions resource can be deprecated?

Thanks for raising this again.
I hadn't anticipated that you'd want to deprecate the /transactions API completely.

In the callback for /transactions the following fields are present:

Do you anticipate the /transfer callback containing a new field (e.g.transactionResponse) that contains this data?

from mojaloop-specification.

Thanks @adrianhopebailie.

I will have a look at #14.

The GET /transactions and related PUT /transactions was only added because ILP did not support transferring any data in the transfer callback (PUT /transfers). We had a requirement to be able to return a OTP code for some use cases, for example in a vending machine where you could input the code after the transaction was completed. If the code can be returned as part of PUT /transfers instead, then I do not see any purpose of keeping the /transactions resource. The parameters completedTimestamp and extensionList are already part of PUT /transfers, transactionState should not differ from transferState more than by the state names. It would simplify the API to remove a resource which is not really needed. But maybe other members of the CCB would like to keep it?

from mojaloop-specification.

@ehenrka are some of these fields required for both the transfer and transaction in the case where the transaction may consist of multiple transfers?

Proposal 1:

Maybe we should use the same pattern as the request and put the transaction result inside the transfer?

Where TransactionResult is:

Proposal 2:

from mojaloop-specification.

Thanks @adrianhopebailie. There is no explicit support in the API for having multiple transfers for one single transaction today. I have not heard any requirements for it either, as all transactions are low-value transactions anyways (at least for now).

Proposal 1 is clean to reuse the same pattern as in POST /transfers, and reuse the current PUT /transactions data model, as well as more future proof if more elements are required to be added in the future to avoid cluttering the PUT /transfers data model.

(In reality I don't think we need the completedTimestamp in both PUT /transfers and the TransactionResult, it should be exactly the same. Additionally transactionState in the TransactionResult should be the same as for the transfer (the transferState) but with another name. If the transfer is successful (COMMITTED) then the state of the transaction must be COMPLETED. If the transfer failed for some reason, then there should be no TransactionResult. But for backwards compatility we can keep it like the proposal unless someone insists to clean up).

from mojaloop-specification.

There is no explicit support in the API for having multiple transfers for one single transaction today. I have not heard any requirements for it either, as all transactions are low-value transactions anyways (at least for now).

This is the whole purpose of having Interledger addresses in the transfers so that they can form part of a chain of transfers addresses to entities that may be in other networks.

We have already built two POCs to demonstrate this:

1. Cross-border: The first transfer is from the Payer FSP to an FSP that offers a gateway into the next network (called a Cross-Network Provider in the documentation). The second transfer is from the CNP to the Payee FSP on the second network.
2. Cross-currency: The first transfer is made in one currency (e.g. USD) from the Payer FSP to the FX provider (an FSP on the same network). The second transfer is made from the FXP to the Payee FSP in the second currency (e.g. TSH).

I also prefer proposal 1 but suggest we review the design of TransactionResult as you suggest.

from mojaloop-specification.

NOTE: As discussed on the CCB call on 11 June we plan to close this issue on 18 June if there are no further comments.

from mojaloop-specification.