MC solution and guideline alignment

[monamok]

In order to keep track of what we started to discuss in today's meeting I open this issue:

Due to the last decisions that were made in commonalities (based on votes (camaraproject/WorkingGroups#169) related to this issue(camaraproject/WorkingGroups#157)) the current guideline indicates that the API input and output business data would follow the lowerCamelCase notation

Currently there are two flavors in Number Verification and Sim Swap APIs. The argument to include MC proposal was to have a solution that is consistent with the available solution in the market AS-IS. But now, we have to align it to the guidelines so it’s not going to be the AS-IS definition. Mobile Connect APIs (proposed in SIM Swap and Number Verification Sub-Projects) parameters follow snake_case notation and now must be changed to lowerCamelCase.

Maybe it’s the time to reevaluate this part and see what benefits developers can get from having APIs similar to MC but not exactly aligned with them nor with 3GPP/TMF?

[DT-DawidWroblewski]

@monamok @bigludo7 @hazarig - thank you for the great discussion we had around this issue.

There's a proposal for an issue that we have to place in commonalities and later push to the OpenGateway team:
(awaiting your feedback)

@DT-DawidWroblewski : 2 proposal in italic. Thanks for your consideration.

---

name: 🚀 Existing API standards inside CAMARA
about: 💡

Context

What are you trying to do and how would you want to do it differently? Is it something you currently you cannot do? Is this related to an issue/problem?

Currently, CAMARA lacks support for API standards, that had been already defined and are commercially available. SimSwap NumberVerify OTPValidation Working Group members collaborating on CAMARA APIs definition, which is common with Mobile Connect APIs, tackled this issue and identified a need to post an issue inside Commonalities WG on following actions:

1. Keep Mobile Connect APIs as they are - MC services are standardized by GSMA, open to developers, and commercially available, so there is no need to reinvent these and adapt to CAMARA.
2. Keep CAMARA APIs definition as it is, without MC flavor in GIT Repositories: Number Verification, SIM Swap
3. Publish Mobile Connect APIs & others that might come (like TMF, 3GPP, etc.), as a part of OpenGateway in parallel to CAMARA (MC APIs are following the same OAUTH/OIDC framework so this is something that both standards have in common).
4. Ensure CAMARA APIs simplicity and focus on resource definition, for the sake of simplicity for software developers.
5. Adapt local (national) breakouts to CAMARA APIs, that result from e.g. legal/regulatory conditions.

Consequently, this approach leads to a situation in which developers are confident about CAMARA APIs & Mobile Connect APIs definition and creates less confusion on a market.

Alternatives

Can you achieve the same result doing it in an alternative way? Is the alternative considerable?

1. Leave it as it is - creates confusion for developers trying to consume CAMARA APIs. Creates competing APIs - not good for developers & MNOs. Additionally and specifically to Mobile Connect API it should be noted that current version in CAMARA Git Hub reflects one way to deliver Mobile Connect API but other API representation are also fully compliant with MC and not reflected in this Git (MC allow for example several resource name for same usage like premiumInfo, userInfo, SimVerify,etc..)
2. Archive conflicting APIs - lack of support of some APIs inside CAMARA initiative, leave it for other API standards, narrows CAMARA focus to specific 5G APIs; standards/initiatives for archived CAMARA APIs takes the lead for API development (OpenGateway should support other initiatives)
3. (please think of other alternatives)

Has the feature been requested before?

No

If the feature request is approved, would you be willing to submit a PR?

Yes

[bigludo7]

@DT-DawidWroblewski - Thanks !! this is good.
2 proposal in italic. Thanks for your consideration

[monamok]

Here you included two alternatives. The first one is not to touch anything (which we already discarded it for several reasons).
I’m not quite sure if I understand the second alternative:

2. Archive conflicting APIs - lack of support of some APIs inside CAMARA initiative, leave it for other API standards, narrows CAMARA focus to specific 5G APIs; standards/initiatives for archived CAMARA APIs takes the lead for API development (OpenGateway should support other initiatives)

In this one the suggestion is to archive the MC like APIs and keep the CAMARA version or are you suggesting to remove any kind of API for Sim Swap and Number Verification and not covering them at all?

From our meeting I think the understanding was to suggest removing MC like APIs and stick to the CAMARA APIs that we already have in these GIT repositories. If this is what you mean maybe we could rephrase it in order to avoid misunderstanding.

You talked about raising an issue in the commonalities to be discussed in a general forum if besides what we are offering in CAMARA, Open Gateway initiative is going to be just about CAMARA or must another standards be included as well, but not removing the whole working groups.

[DT-DawidWroblewski]

Hi @bigludo7 !

I changed the content of the issue, please let me know if it is clear now and we can push it to Commonalities.

Have a nice long weekend!

[bigludo7]

Thanks @DT-DawidWroblewski - looks good for me.

[monamok]

@DT-DawidWroblewski issue camaraproject/WorkingGroups#200 was kind of resolved but we have still this issue open. Could you please manage the changes?

I can open a PR to sort out and adapt the repository if you prefer.

[DT-DawidWroblewski]

MC cleared