Solution Proposal: Track proximate sender for inter-scheme transfers

[MichaelJBRichards]

[Change ID] -- [Change Request Name]

---

Open API for FSP Interoperability -- Solution Proposal

Table of Contents

• 1. Preface
  • 1.1 Solution Proposal Information
  • 1.2 Document Version Information

• 2. Change Request
  • 2.1 Background
• 3. Proposed Solution
  • 3.1 Specify how IDs can be generated
  • 3.2 Add quote ID to POST /transfers data model
• 4. Other Considered Solutions
  • 4.1 Add transaction ID to the POST /transfers data model
  • 4.2 Force the Payer FSP to use the transaction ID as transfer ID

1. Preface

___

This section contains basic information regarding the solution proposal.

1.1 Solution Proposal Information

Change Request ID	Not used
Change Request Name	Track Proximate Sender for Inter-scheme Transfers
Prepared By	Michael Richards, INFITX
Solution Proposal Status	In review [X] / Approved [ ] / Rejected [ ]
Approved/Rejected Date

1.2 Document Version Information

Version	Date	Author	Change Description
1.0	2024-05-22	Michael Richards	Initial version of Proposal. Sent out for review.

2. Change Request

2. Change Request

___

2.1 Background

In an inter-scheme context, a payment may be forwarded between a number of schemes before it arrives at its eventual destination. Its overall origin and destination are designated in the FSPIOP-Source and FSPIOP-Destination parameters in the header, and both of those form part of the non-repudiation signature. Mojaloop wants, if at all possible, to retain the original non-repudiation signature so that the recipient (and, indeed, any intermediaries) can confirm that the message really did originate from the source DFSP, and that it has not been altered in transit.

On the other hand, Mojaloop switches which receive messages in what may be an inter-scheme context need some way to understand whether the message was forwarded to them via a proxy; and, if so, which proxy it was. This will enable the switch to store an association between the sending DFSP and the proxy, so that it can route subsequent responses to that DFSP via the correct proxy.

We would therefore like to have an FSPIOP-specific parameter in the header with the following characteristics:

1. It does not form part of the material over which the non-repudiation signature is taken.
2. A proxy can set the value of the parameter to its FSP idea in the scheme where it is forwarding the message. This will inform the switch:

• That the message was forwarded by a proxy.
• Which proxy forwarded the message.

3. An ordinary DFSP needs to know nothing of this mechanism. If a message is forwarded without the parameter, or with a null value in the parameter, then the switch should assume that the message was forwarded by a DFSP.

3. Proposed Solution

Table 1 of the specification should have another parameter added to it, as described in Section 3.1.2 below.

Example:

FSPIOP-Proxy: Proxy1

3.1.1 Current text

There is no current text.

3.1.2 New proposed text

• The name of the parameter will be FSPIOP-Proxy
• The content of the parameter will be the FSP ID of the proxy which forwarded the message, in the scheme to which the message was forwarded. For example: PROXY1.
• The parameter will be optional (Cardinality 0..1)
• The description of the parameter will be something like: The FSPIOP-Proxy header field is a non-HTTP standard field used by the API for HTTP header-based routing of requests and responses to the destination. If the message is being forwarded by a proxy, the field must be set by the proxy, so that any entities between the client and the server, as well as the server itself, can recognise that the message has been forwarded by a proxy, and which proxy it was which forwarded it. The server can therefore take action accordingly. If the message is being sent by a DFSP, an FXP or any other type of entity, then this parameter should be omitted or, if not omitted, left blank.

This change will be a non-breaking change. Existing calls in a single-scheme context will continue to work as they do now.

3.2.1 Addition to the HTTP Request header fields table (Table 1)

Field	Example	Cardinality	Description
FSPIOP-Proxy	Proxy1	0..1	The FSPIOP-Proxy header field is a non-HTTP standard field used by the API for HTTP header-based routing of requests and responses to the destination. If the message is being forwarded by a proxy, the field must be set by the proxy, so that any entities between the client and the server, as well as the server itself, can recognise that the message has been forwarded by a proxy, and which proxy it was which forwarded it. The server can therefore take action accordingly. If the message is being sent by a DFSP, an FXP or any other type of entity, then this parameter should be omitted or, if not omitted, left blank

4. Other Considered Solutions

___

We considered using the X-Forwarded-For parameter defined by W3C to hold an IP address for the proxy. After discussion, this was felt to be too complex and vulnerable to the value being changed by intermediaries for their own purposes.