Security & Interop profile - OIDC directive

[ECORMAC]

Hi All - would like to discuss and get some guidance on the subject below.

The Number verification API as per directives from ICM (Security & Interop Profile) "shall adhere to the "OIDC Authorization Code Flow". Thus as per the OIDC specification the scope shall be “openid”. As openid is included an idToken will be returned.

From the perspective of the Number Verification API some guidance on what the idToken can be securely used for would be appreciated. "Normally" the IdToken is used by the consumer to trace the end-user. The operator will specify a value corresponding to the end-user in this token (but not a MSISDN) and the next time the consumer will know it’s the same End-user. But does this "normal" use of said token make sense in the case of Number Verification?

It could be argued that returning an idToken is superfluous to the needs of Number Verification (will anyway require an access token for accessing the resource). However if we shall be compliant to OIDC then this is needed.

Shall we push for an update (e.g., note included) to Security & Interop profile in ICM?

[eric-murray]

The ID token would be useful to the API consumer.

If the API consumer has previously used the Number Verification API successfully to verify the MSISDN of a device, they will then be able to map the sub field of the ID token to that MSISDN. They can then maintain a mapping table of sub to MSISDN for all devices that are verified.

For subsequent access token requests (using the authorisation code flow) that return a sub value in the ID token that is in this mapping table, the API consumer will then know the MSISDN of that user and not need to call the Number Verification API. If the sub is not in their mapping table, the API consumer then calls the Number Verification API as normal.

For a bit of additional complexity on the API consumer side, this can reduce the latency to verify the MSISDN of regular users of the API consumer's application.

[ab-ip]

That will be challenge from billing point of view.
Does it mean that both Auth and NumberVerification (CAMARA) endpoints will be chargeable?
If consumers can connect (map) msisdn - sub then they will call NumberVerification API only once and for all future requests they will call just Auth and get result from own cache.
Maybe it will better not to follow OIDC for Auth flow at all, as there is nothing which is providing through ID Token. Or just to provide random sub which can not be connected to user/msisdn, which is again not according to OIDC Specs.
What is the benefit for CAMARA APIs of using OIDC instead of standard OAuth2 Authorization Code?

[eric-murray]

The issue is that the sub claim of the ID token is standardised:

sub REQUIRED. Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client

I would say any API provider returning an ID token should follow the standard, and not provide a useless sub. Rather, they should not provide the ID token at all, which is back to the point from @ECORMAC.

CAMARA does (sort of) allow this if the openid scope is not included by the API consumer. But that is the choice of the API consumer, and not the API provider.

[ab-ip]

It should not be the choice of the API consumer, but decision of the API provider and how they prefer to charge for the API calls. This flow should be standardized and defined in Specs, otherwise it will be very hard for integration if there is a choice for any of party (consumer/provider).

Also creating the sub value according to OIDC Specs is little bit challenging in the Telco environments and can slow down Auth process pretty much.

At a first place, what value can be used as a sub in Telco environment in order to fulfill OIDC Specs: A locally unique and never reassigned identifier within the Issuer for the End-User?

[eric-murray]

Well, that is the current CAMARA standard, and there is even a recommendation for the sub.

This document RECOMMENDS that the sub claim is a Pairwise Pseudonymous Identifier (PPID).

So essentially a MSISDN hash with a client-specific salt.

Discussions such as this one may lead to a change in the CAMARA standard, for otherwise API providers may just choose to anyway implement non-standard solutions to such problems.

[ab-ip]

The problem with MSISDN is that it is recycled, so initial requirement for sub is not matched never reassigned identifier.

There must be something which is unique and never reused, like contract id or some other value related to the user account, but such a value is not easy to provide in most environments, especially in the prepaid markets.

That is why it is not easy to implement sub according to the OIDC specs, so better to rethink one more time about current specs then to finish with something which can not be used in a proper way.

[eric-murray]

This is probably getting a bit "off topic", but mobile operators who have Mobile Connect implementations will already be able to generate a PCR for each user, which is based on the MSISDN. I'd expect them to use that implementation to generate the CAMARA sub.

There is a requirement that a new PCR should be generated should the MSISDN be recycled. In practice, this means "resetting" the salt for MSISDNs that have changed ownership. There is no practical value in trying to maintain PCRs for customers who have changed their MSISDN for some reason, nor in maintaining it for someone who ported their MSISDN to another operator and then ported it back.

[ECORMAC]

Thanks for your comments guys. Was wondering if I should open this as an issue in ICM?

[eric-murray]

@ECORMAC
You should discuss this issue at the next Number Verification sub-project meeting. The Mobile Connect version of this API works in a similar way, so I always assumed providing a valid ID token was a requirement. If it is agreed there is no value to it, you could then discuss in ICM using standard OAuth2 for this type of use case rather than OIDC.

[HuubAppelboom]

The sub field in the ID Token is essential for use case in which the phone number verification is used as a single authentication factor in a login process, and in general for any case where you need to avoid mixing end users.

Because of number portability, and number may end up with another end user in case a subscription has ended. The API Consumer can see this, because the sub field in the ID Token has changed. (if it is the same user, the sub field should every time be the same). This prevents that users may see info that belongs to other users.

The sub field can also help for cases where information is being collected at different time stamps through different APIs by the API consumer, without using number verify each time, so that they know info belongs to the same user.

The only disdavantage that this may be abused to generate a revenue leak, because from the token you can recognize that it is the same user again. API Consumer may only use Number Verify the first time, and after that only use the authorize and token calls to recognise it is the same user again. You can fix this by billing the customers also based on the number of token requests, in stead of only the verify requests.

[HuubAppelboom]

BTW, for KPN we are using the same PCR value under CAMARA as we have under Mobile Connect. Generating a PCR is not that difficult for an API Provider, the complexity comes in in what cases you need to remove the PCR value from your user database, because it has become obsolete.

[ab-ip]

Mobile Connect and CAMARA are distinct solutions designed for entirely different purposes within the telecommunications ecosystem.

Mobile Connect is developed to position telecommunications providers as Identity Providers (IdPs). It is inherently based on the OpenID Connect (OIDC) protocol, which facilitates secure identity management. As defined:

"Mobile Connect is a secure universal identity service offering a simple, trusted way for mobile users to share sensitive data and undertake transactions with confidence."

CAMARA, on the other hand, focuses on exposing telecommunication network capabilities through standardized Web APIs. Its primary objective is to provide access to signals and data without involving user identity management. As described:

"Telco network capabilities exposed through APIs provide a large benefit for customers. By simplifying telco network complexity with APIs and making the APIs available across telco networks and countries, CAMARA enables easy and seamless access."

From the perspective of API security, the use of OIDC for API authorization is generally uncommon. OIDC integrates authentication and identity sharing via ID Tokens, which is not typically suited for pure API authorization. Instead, the OAuth 2.0 authorization framework is the industry standard for securing APIs.

Using OIDC for CAMARA would not only introduce commercial and operational challenges but could also undermine the rationale for CAMARA itself. Many of the signals and data provided via CAMARA could technically be offered through Mobile Connect's OIDC-based ID Tokens, creating overlap and potential conflicts between the two frameworks.

Ultimately, the success of any solution depends on its usability and how effectively it meets the needs of its intended consumers. This usability factor should remain the primary criterion for adoption.

[HuubAppelboom]

@ab-ip Hi Aleksander, I don''t agree with your view that Mobile Connect and CAMARA are designed for different purposes. The scope of CAMARA is wider than that of Mobile Connect, but also includes the API's of Mobile Connect which have been most widely adopted (Number Verify, SIM Swap and Match). CAMARA does not exclude typical identity API's like Match and Age Verification. Because CAMARA has also adapted Number Verify SIM Swap and Match, I doubt that there will be two eco systems in future (but time will tell).

Now back to the discussion of why the SUB field of the Id Token needs to be a persistent identifier, which identifies the combination telco- end user - API Consumer in an unique way. In many use cases you will see that API Consumers start for example at onboarding with a number and email adress verification, simply because they don't want to ask the end user for too mcuh information. Both can be supported by CAMARA now. In a next step, a couple of months later, the aks the end user to start completing their profile with a (verified) name and address, And a couple of months later, the end user wants to access a gaming service for which an age verification check needs to be done.

If all these API calls are executed with an authorize code flow, or the later ones with a CIBA flow, it is of crucial importance that in step 2 and 3 it can be seen that the end user is still the same. If you don't have a persistent identifier, you will have to verify both the phone number (and email address) again at step 2 and 3 to make sure it is still the same user. That is not very developer friendly, so to speak, and that is why a persistent identifier is needed, to enable cross- and upsell in later stages of the customer life cycle.

[AxelNennker]

@ab-ip

From the perspective of API security, the use of OIDC for API authorization is generally uncommon. OIDC integrates authentication and identity sharing via ID Tokens, which is not typically suited for pure API authorization. Instead, the OAuth 2.0 authorization framework is the industry standard for securing APIs.

If you want user authentication and user consent, then you should use OpenId Connect.

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

This specification defines the core OpenID Connect functionality: authentication built on top of OAuth 2.0 and the use of Claims to communicate information about the End-User. It also describes the security and privacy considerations for using OpenID Connect.

Using OIDC for CAMARA would not only introduce commercial and operational challenges but could also undermine the rationale for CAMARA itself.

We seem to have different definitions of the "rationale for CAMARA".

CAMARA wants more APIs (than MobileConnect and more than other initiatives before MC), BUT we cannot be successful if we don't embrace GDPR and consent management, I think.

OAuth2 mentions "consent" once, while OIDC mentions "consent" 47 time.
If your APIs are all client_credentials then OAuth2 might be enough.
If you need the resource-owner/user to be authenticated and be able to manage their consent, then use OIDC e.g. with prompt=consent or prompt=login.