Change Request: Should the response to a GET /parties contain a correlation ID?
MichaelJBRichards opened this issue · comments
Open API for FSP Interoperability - Change Request
Table of Contents
1. Preface
___This section contains basic information regarding the change request.
1.1 Change Request Information
| Requested By | Michael Richards, Infitx |
| Change Request Status | In review ☒ / Approved ☐ / Rejected ☐ |
| Approved/Rejected Date | |
1.2 Document Version Information
| Version | Date | Author | Change Description |
|---|---|---|---|
| 1.0 | 2023-05-18 | Michael Richards | Initial version. Sent out for review. |
2. Problem Description
___2.1 Background
At present, the response to a GET /parties or a GET /participants request does not contain a correlation ID. Although the recipient can ascertain from the non-repudiation signature that the sender was the institution they purported to be, and that the message had not been modified in transit, there is no ready way to distinguish different responses from each other. This may become a question of importance if disputes arise, for instance, about how participant DFSPs respond to requests to transfer funds to a customer whose account is in the process of suspension or reinstatement.
2.2 Current Behaviour
At present, neither the PUT /parties response nor the PUT /participants response contains an identifier. It is not possible, therefore, to distinguish responses from each other.
2.3 Requested Behaviour
Explain how you would like the API to behave.
The response to a request for information about a customer should be accompanied by a correlation ID which will allow both parties to identify the response which was used as the basis for an action.
3. Proposed Solution Options
___Include an optional identificationId (of type CorrelationId) in the PUT /parties and PUT /participants API definitions.
Thanks @MichaelJBRichards, I'm not exactly following why this is necessary though from the sentence below:
This may become a question of importance if disputes arise, for instance, about how participant DFSPs respond to requests to transfer funds to a customer whose account is in the process of suspension or reinstatement.
The /parties and /participants resources are not meant for transferring. If the Payee's account is for example suspended or blocked, then the the Payee FSP should just reject the quote. Can you please explain the use case for a correlation ID in these resources in more detail?
There's also an issue (when we were using word documents at CCB) when this (or similar) issue raised. I lost access to some earlier docs but may be @henrka or @MichaelJBRichards you still have that Change request in word document form.
As discussed in the FSPIOP API SIG meeting today, the proposal is to close this one as you could use #71 to trace the messages if required.
Closing as discussed on today's call