search

mojaloop / design-authority-project

This is the Issue and Decision Log for tracking mojaloop and related Designs
Other
1 stars 2 forks source link

DA to discuss native ISO-20022 API design and implementation #113

Open bushjames opened 3 months ago

bushjames commented 3 months ago

Request Summary:

DA to discuss native ISO-20022 API design and implementation

Request Details:

**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 commented 3 months ago

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 commented 2 months ago

This work is moving to implementation phase.

Leaving ticket open to facilitate discussion during implementation.

bushjames commented 5 days ago

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.