GSMA Certification

[FabrizioMoggio]

To keep trace of the ongoing GSMA certification process and of the outcomes that could lead to inputs for the API Development.

[StefanoFalsetto-CKHIOD]

At the moment the GSMA is refusing to certificate the CK Hutchison implementation since it us using Client Credentials authentication method. At the same time, they acknowledged the implementation and the API appeared into their website for all the CKH affiliate operators.

[FabrizioMoggio]

The version of the CFS API under certification is the one from Fall24. In Fall24 the ICM text in info.description only refers to 3Legs. In Sping25 the text also refers to 2Legs. So it is more complete, nevertheless, in my view in both the releases Client Credential is allowed.

In both the releases we have this text:

_"The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the provider of the application consuming the API and the operator's API exposure platform, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation.

In cases where personal data is processed by the API and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of three-legged access tokens is mandatory. "_

I read it as: according to the local regulation, according to the specificity of the Service provided and according to the agreement between the Service Provider and the API Producer, IF user consent is required, THEN 3Legs is mandatory. This doesn't exclude to expose the CFS API as 2Legs if there are the right conditions.

In my understanding (more clearly stated in Spring25), according to the specific case, an API can be exposed using 2Legs or 3 Legs. @hdamker, @tanjadegroot, @AxelNennker, what do you think about?

[hdamker]

In my understanding (more clearly stated in Spring25), according to the specific case, an API can be exposed using 2-Legs or 3 Legs.

Client Credentials can be used if agreed by both API consumer and the operator. Derived from that and other reasons GSMA has the position that operators should offer both, 3-legged and optionally 2-legged, to serve also global service provider as API consumers who want consistently use 3-legged across operators (e.g. because of legal regulation they have to follow, to support use cases which are not covered by legitimate interest, or just for compatibility across regions). That's not a technical but rather a business decision.

[FabrizioMoggio]

@StefanoFalsetto-CKHIOD, So the missed certification is not because it has 2legs, but because you implementation ONLY supports 2Legs?

[StefanoFalsetto-CKHIOD]

@FabrizioMoggio that's a good question.
My understanding was that the use of Client Credentials was totally unacceptable for certification, regardless of implementing only 2-legged or both 3-legged and 2-legged methods.

But maybe I am wrong, @hdamker could you please clarify this?

[hdamker]

But maybe I am wrong, @hdamker could you please clarify this?

@StefanoFalsetto-CKHIOD I can't speak for GSMA here, I asked @MarkCornall to chime into the discussion.

[FabrizioMoggio]

@StefanoFalsetto-CKHIOD is the GSMA certification officially closed?

If the certification process is still open, we can still move forward with a tentative v1.0.0 as planned here: #115 (comment)

otherwise, if the certification process is closed with a negative feedback, we should move forward with v0.3.0.

[StefanoFalsetto-CKHIOD]

Hi Fabrizio, unfortunately GSMA didn't started any certification activity of this service, due to the reasons we are talking here.

At the moment they are going to test our implementation of Sim Swap service version 0.4.0, which can be certified, since it is not in meta release (i.e., the use of Client Credentials is accepted).

[MarkCornall]

Dear All,
Essentially as Herbert has expressed. Within certification we are taking the stance that in some markets 3 legged tokens will be required and to ensure we have global interoperability we will only certify the 3-legged deployments which are in the meta release where personal data is involved. We should not create local silos.

[StefanoFalsetto-CKHIOD]

Hi Mark, unfortunately I don't understand the reasons of this stance.
If a country denies the use of a service for legal reasons, does Camara avoid using it in all countries, even those where it is allowed?

[MarkCornall]

The aim in the GSMA Open Gateway program is to have an interoperable APIs. If a country does not allow an API then in that country it will not be deployed for whatever reason. The same for any country that does allow an API but hasn't yet deployed. When the API is deployed then it should be interoperable. The stance remains 3-legged authentication where personal data is involved once a release is in the Meta Release for certification.

[FabrizioMoggio]

@MarkCornall, just to better understand:

The CFS API specification supports both 2Legs and 3Legs, so the API can be used in any country according to the use case and to the local regulations.

If in one Country, the local regulations, allow the use of that API with 2Legs, the API Provider needs anyway to implement 3Legs even if never used?

[MarkCornall]

We are looking to support open gateway and the MoU which says in the first paragraph

GSMA Open Gateway
“GSMA Open Gateway” is a GSMA initiative for the creation of a common interoperable and federated network with open standard interfaces to enable seamless universal connectivity and other technical capabilities."

To support that aim we certify APIs to follow that target of achieving interoperability. That means where in some markets you must have 3 leg authentication. we will only certify 3 leg implementations. As an operator you may also choose to offer a 2 leg flavour if you consider that acceptable in your market but at this time we will not certify that implementation.

[StefanoFalsetto-CKHIOD]

@MarkCornall, we have already discussed this in other contexts. However, for the benefit of others in this group, I will reiterate my perspective.

GSMA seems to be acting as if this were a green field market. But that is not the case. There are Aggregators already using anti-fraud services and existing GSMA protocols (e.g., IDY.56 Client Credentials). By choosing only 3Legs, you would force them to implement additional authentication methods just to obtain the same data. In my view, this approach does not align with the principle of universal connectivity.

[FabrizioMoggio]

Conclusion: it is correct that the CFS API supports both 2Legs and 3Legs. 3Legs is mandatory for the CFS API implementation to be certified by GSMA

Please note: 3Legs is only required for APIs involving personal data (as discussed below)

[bigludo7]

@FabrizioMoggio I disagree a bit on your conclusion if it wide to all CAMARA API (for specifically Call forwading I fully agree)
For me : 3Legs is mandatory for an implementation to be certified by GSMA where personal data is involved.

Using 3-legs for Population Density Data or Region user count make no sense for me.
Hope @MarkCornall is on the same page.

After we have some specific case like OTP Validation or Carrier Billing where I'm really not sure if personal data are involved.

Probably this discussion should be at another level than Call Forwarding ?

[FabrizioMoggio]

@bigludo7 you are totally right, my conclusion was in the context of the APIs that require 3Legs because they involve personal data. This is consolidated and I gave it for granted writing a conclusion that is not general. Thank you for pointing that out. I have updated the above conclusion accordingly.