DA to discuss native ISO-20022 API design and implementation

[bushjames]

Request Summary:

DA to discuss native ISO-20022 API design and implementation

Request Details:

• Deadline: ASAP
• Impact (Teams): Adopters want this feature ASAP.
• Impact (Components): FSPIOP API, ml-api-adapter etc...

Artifacts:

• Artifact to consider [@contributor]

Dependencies:

• If Applicable

Accountability:

• Owner: @MichaelJBRichards
• Raised By: @bushjames

Decision(s):

• Decision to move to implementation agreed by DA.

• DA will continue to be available to discuss design and implementation issues as and when they arise during initial implementation.

• DA will close this issue upon the first official release of a Mojaloop version which includes native ISO-20022 API support.

• Approved By:

Details

• Actual decision made as a result of discussion

Follow-up:

• Actions to implement the decisions

[bushjames]

Discussed at DA meeting on 2024-08-28: @MichaelJBRichards gave a status update: Version of ISO-20022 Mojaloop API spec is complete in openapi/swagger, although some iteration is likely to address one or two specific issues/omissions (synchronous error response bodies). Various other related points were discussed around market alignment with our approach, scheme specific customisations being possible/necessary on openapi/swagger specs.

[bushjames]

This work is moving to implementation phase.

Leaving ticket open to facilitate discussion during implementation.

[bushjames]

Discussed in DA meeting 2024-11-27 0900 UTC: @PaulGregoryBaker and @vijayg10 raised a question regarding party identifier types and sub identifiers. Should we use ISO identifier types for our ISO API rather than the existing FSPIOP enum? Given that we already have precedent in the API for supporting all ISO4217 currencies, we could support all ISO20222 identifier types; however the list of identifier types changes more frequently than e.g. currencies in 4217. @PaulGregoryBaker proposes to add the ISO identifier types to the enum, but keep supporting the existing FSPIOP types. This eliminates a lot of work in changing existing tests and places where the FSPIOP enum is already used. Several options and possibilities were discussed. We should try to keep the ability to run existing tests, which use the FSPIOP enum against the ISO implementation. Should we make the enum a string so anyone can use any identifier types?...probably not, this is a barrier to interop across schemes, but it may be a reasonable compromise. How about translation/mapping between FSPIOP ID types and ISO ID types?...The question of supporting multiple protocol/message types in a single scheme is possibly relevant here...should we reopen this discussion? @MichaelJBRichards will open a PR to continue discussion about a possible new invariant. @PaulGregoryBaker and @vijayg10 will open continuing discussion on DA slack channel. DA group will meet in coming days if a decision is urgently required as to how to proceed.

[bushjames]

Discussed again in DA meeting 2024-12-11 0900 UTC:

@MichaelJBRichards is against supporting multiple message formats (FSPIOP and/or ISO) in a single scheme. @PaulGregoryBaker says it would have been helpful when developing the ISO20022 implementation as the ability to run existing tests, which may use a particular format, would enable easier testing...if we support only one protocol at a time we have to used tests that support the "under development" protocol....it IS possible to use existing tests so long as JWS is not enabled during tests.

@MichaelJBRichards "canonicalisation" may offer a solution to end-to-end non-repudiation (enabled by JWS) but this is not ideal as orgs need to interpret messages which may lead to issues, especially given a strong dependency on the correctness of a canonicalisation scheme and implementation.

@PaulGregoryBaker suggests signature layering. @MichaelJBRichards suggests that partial signing has major problems as all parts of a message have importance for DFSPs in making decisions about what to do at any point in a flow.

Discussion ensued regarding signing across a "transaction object" that could contain all pertinent fields. Problem with this is that we are replacing the content of the message with other format.... @MichaelJBRichards says this is a "xeno" API....and just pushes the same concern to a different place.

@bushjames argues that creating a canonical form is just pushing the same issue down a layer.

More discussion about standards, creating a new standard (canonical) form for payment info .... but this is equivalent to ISO...

ILP is some way towards a canonical "embedding" of transfer terms, why do we need ILP? The crypto lock on payment terms is fundamentally important, but in mojaloop this doesn't have to be ILP; also our ILP packet does not contain all quote/terms information...we could use any hash over a pre-determined format of terms data, so long as all pertinent data is contained and the crypto hash is across quote and transfer phases.

@PaulGregoryBaker 3rd option (xeno API) should not be written off as implementations might go this way...with layered signatures...

Other issues remain e.g. hub adding fees...

@PaulGregoryBaker : Plan A is still ISO-20022...stick with that for now. @MichaelJBRichards appreciates the convenience of this change but it is wrong for the architecture.

@bushjames : summary: We will stick with current stance that we will not support "xeno" API and layered signatures until a really strong push comes from the market / adopters, at which time we can re-open this discussion.