Existing API standards inside CAMARA

[DT-DawidWroblewski]

---

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 MC can complete CAMARA for Identity and Consent).
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 the market.

Other Alternatives

Can you achieve the same result by 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

[jordonezlucena]

@DT-DawidWroblewski - Here is TEF feedback:

1. Out of the scope of CAMARA. MC is defined by GSMA, so the forum which decides the evolution of MC in one or other direction shall be GSMA (and not CAMARA).
2. OK.
3. Out of the scope of CAMARA. Open Gateway is defined by GSMA, so it is GSMA which needs to take this decision. By the way, CAMARA != Open Gateway (i.e., there are CAMARA APIs such HomeDevicesQoD and DeviceIdentifier which do not implement Open Gateway services).
4. OK.
5. OK.

[bigludo7]

@DT-DawidWroblewski
For Orange, we’re aligned with proposal to remove Mobile Connect API version from CAMARA git hub as it will bring confusion to developer and focus in this git hub only on CAMARA version (points 1, 4 et 5).

We’re also fine with Dawid proposal to continue MC support & work under GSMA/OpenGateway banner to protect our commitment on MC APIs (points 1 & 3).

One question to be tackled outside CAMARA: We probably need this proposal to be shared in GSMA/OpenGateway discussions?

[shilpa-padgaonkar]

With the above alignment, can we close this issue now?

[MarkCornall]

Follow up from my comments in the meeting I have checked in GSMA and would like to provide clarification and correction on the direction of the scope of GSMA Open Gateway going forwards. Initial focus is on maximising API value and adoption making CAMARA APIs available in a federation context. It is further agreed that TMForum APIs will be used for Operate APIs as needed. If there is a specific valid reason that an API can not be brought into CAMARA and it is requested and widely supported by the industry to be included then it and the standards around it would be considered in how it could be included in the GSMA Open Gateway program. However, the aim and commitment today is to consolidate northbound Service APIs of CAMARA and these are the focus of development. In short, if you want an API to be included in the scope of Open Gateway then bring it to CAMARA.

[DT-DawidWroblewski]

@MarkCornall thanks for GSMA feedback on this topic! However, I'm not sure how we should proceed now. Does it mean that new repo has to be created for API service coming from another standard, e.g. Mobile Connect ATP repo? Can you please share guidance on how to tackle a situation, when the standard has a different design than CAMARA (MC APIs has a single endpoint whereas CAMARA has a dedicated endpoint for an API service)? I'd appreciate your feedback and support on how to move forward here.

[gregory1g]

Existing situation when Mobile Connect (MC) API is part of the Camara API together with the Camara API itself already creates a lot of confusions. People do not understand what API they must implement or use if they want to be Camara complaint.
Unlike Camara APIs, MC APIs are rather coupled together, therefore if MC must be kept under Camara umbrella it looks reasonable to extract all MC APIs to a separate camara repository, instead of spreading them through different Camara APIs.

[DT-DawidWroblewski]

... if MC must be kept under Camara umbrella it looks reasonable to extract all MC APIs to a separate camara repository, instead of spreading them through different Camara APIs.

Looks like a solution :)

if our community is happy with this approach, I ask @MarkusKuemmerle to create a Mobile Connect repo and move all related APIs there.

[jgarciahospital]

As stated by Gregory, it may be a good solution in case we decide to maintain MC as part of CAMARA umbrella, but I don't see us being on that decision yet. @DT-DawidWroblewski could we please move back to the original plan you proposed? (CAMARA only taking care of CAMARA APIs)

[gregory1g]

yes, " separate camara repository" is mentioned as "plan B".

[MarkusKuemmerle]

I see CAMARA as first place for developers to find something about all telco northbound customer-facing APIs

• For existing API standards (like MC) only a reference to the original repo is included in CAMARA
• A CAMARA commonalities compliant version of such APIs can be saved and maintained in CAMARA

Could that be a way forward?

[ECORMAC]

As outlined by Gregory above, the separate repository was if "all else failed", agree with Jorge we should strive to remove from Camara. Markus your second bullet, when you state "compliant version of such APIs" - do you mean MC APIs and if so, are we not back to the original problem where we are attempting compliance & compliance control on APIs we are not responsible for?

[MarkusKuemmerle]

I would keep it simple:

• For the original APIs (e.g. existing MC standard) only document the reference (e.g. to the existing GSMA repo)
• If there is a CAMARA compliant version of the API this one should be saved in the CAMARA repo. For MC we've already created commonalities compliant versions, these should be saved and kept in the CAMARA repo.