Question about compliance with IDY.54 for MC version

[bigludo7]

Hello
A question for @DT-DawidWroblewski

Dawid, when I'm reading https://www.gsma.com/identity/wp-content/uploads/2022/12/IDY.54-Mobile-Connect-Verified-MSISDN-Definition-and-Technical-Requirements-1.0.pdf I have:

The Resource Server is recommended to expose a service-specific Resource endpoint for supporting the Mobile Connect Verified MSISDN Match service OR premiumInfo endpoint should be used

In our current MC Swagger we have none of them (the endpoint is not specific as same than SIM swap and it is not premiumInfo either).

Perhaps a stupid idea but why not use the path used in the examples of the IDY.54 : POST /connect/mc_vm ?

[DT-DawidWroblewski]

Hi @bigludo7!

in our current deployments, we followed a principle to use a premiumInfo/userInfo endpoint instead of a service-specific endpoint.

With this approach, Mobile Connect OIDC Profile is closer to standard OIDC, which exposes /userinfo endpoint.

However, it does not mean that service-specific is bad and we're turning away from this approach. We're planning to expose service-specific endpoints in future in parallel to existing ones to be compliant with CAMARA. In the end, it is up to our customers to judge, what is better.

[bigludo7]

Thanks @DT-DawidWroblewski

I'm right now focusing only on the MC version (not the CAMARA one) as we have a MC implementation in Orange.

My point is that I'm a bit uncomfortable because I got the feeling that what we have in our git here is not strictly aligned with IDY.54 but with an implementation (use of generic /userInfo instead of /premiumInfo or a specific endpoint)

I'm very open to use the MC version but how to avoid having as many endpoint than implementation ?

In DT this is POST openid/userinfo, while in Orange this is POST /msisdn_verify - both are 100% MC compliant but from an app developer we did not deliver the promise no?

Definitely looking for your feedback :)

[DT-DawidWroblewski]

Hi @bigludo7 !

MC specs say that MNOs may choose to also support /userinfo for "backward compatibility", see abbreviation 11 on page 12 of IDY.03 :)

[bigludo7]

HI @DT-DawidWroblewski
This is not the case here - we're not in "backward compatibility" situation as 1/ we're not in a implementation and 2/we define a 'standard".
I'm still in favor to align our MC version with the most standard approach!

[bigludo7]

@DT-DawidWroblewski
I think we should have a discussion on this topic BTW.
Problem statement:
In Orange I got implementation of mobile connect for SIM swap & Number verify that are fully compliant with MC specification. But these are not aligned with the *mobile connect OAS flavor present in CAMARA.

Why ?
Because in CAMARA we have a version of Mobile Connect API done by DT (which is also MC compliant). MC is not enough normative to enforce one OAS (we see that with the endpoint name)

Question:
Should we want in CAMARA to restrict Mobile Connect (for now the DT version)? or should we only indicates that for SIM Swap & number verify it is ok to use MC without enforcing a swagger ?

[ECORMAC]

Hello,

I'm new to the group but interesting discussion on Camara & MC compliance at today's meeting.

As a "newcomer" it has also created confusion for me (e.g. not sure what parts of IDY.54 we would need to comply with and which of the other specs referenced from IDY.54 would be relevant etc).

Is there more detailed info on the Camara flavor like the UML flows stored - this just seems to cover the "MC Verified MSISDN" as indicated in the title?

[bigludo7]

Link to #35

[DT-DawidWroblewski]

MC cleared