Android Feature Request: Carrier OpenId API

[AxelNennker]

Deutsche Telekom created a feature request in Android that would allow all applications to retrieve the carrier's OpenId Connect configuration.

We believe that vendors of applications using Camara APIs would greatly benefit from the new Carrier OpenId API.

Everytime user consent and user authentication is needed before a Camara API can be "legally" used, this Carrier OpenId API can be used to retrieve the carrier's OpenId configuration.
The OpenId configuration can either be directly used by the application for user authentication and/or consent, or the configuration URL can be forwarded to an aggregator, who then knows which carrier is serving Camara APIs.
Or the carrier can set the aggregator as its openid configuration endpoint.
The options for streamlining Camara business are endless.

I would kindly ask you to +1 the issue and also comment on the issue directly describing how your company is affected by the new Android Carrier OpenId API.

Here is the public issue, everybody can see:
https://issuetracker.google.com/issues/308240647

Here is the feature request for if you are an Android partner. The visibility of this issue sometime changes, so I am not sure who can see it.
https://partnerissuetracker.corp.google.com/u/1/issues/308520958

Thanks for your support,
@AxelNennker

For easier reading, here is a copy of the Android feature request:

Feature name: Carrier OpenId API

What form factor is this feature targeting?:

All Form Factors

Short description:

Applications that e.g. want to make use of carrier APIs are in some cases required to authenticate the user and collect the user’s consent. But application developers currently have no way to determine the carrier’s user authentication endpoint. GSMA standardized OpenId Connect (OIDC) authentication for privileged apps and that is already implemented in Android.
See: https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/gsma_services/ts43authentication/src/com/android/libraries/ts43authentication/Ts43AuthenticationLibrary.java

This feature request is to make OIDC-based user authentication available to all Android apps.
DT proposes an API that allows all Android applications to retrieve the carrier’s OIDC configuration e.g. https://mobileconnect.telekom.de/.well-known/openid-configuration

OpenId Connect is the standard for user authentication and used by carriers and Google.
Deutsche Telekom is a corporate member of the OpenId Foundation.
Google is a sustaining member of the OpenId Foundation. Filip Verley is Google's representative at the OIDF. https://openid.net/foundation/board/
.

Use case(s):

1. A bank wants to implement risk-based authentication for users of their online banking app and the bank wants to know the location of the user’s phone. Privacy-regulations might require the bank to get the user’s consent in some legislations.
   The banking app would retrieve the carrier’s OIDC configuration and direct the user to the carrier’s user authentication page.
2. An application might want to know the mobile device’s status e.g. whether it is roaming. The vendor of the application needs the user’s consent when the vendor request device status information. By retrieving the carriers OIDC configuration the application can direct the user to authenticate at the carrier’s OIDC authentication endpoint, and then consent can be collected.
3. When the new Android phone is run for the first time, Android might redirect the user to the carrier's user authentication. A user account related to the carrier can be created after authentication. That account can then be used by all of the carrier's applications and other applications that use the Android user's online accounts.

If this feature was accepted, what does success look like?:

All Android application can retrieve the carrier’s OIDC configuration.
3rd Parties using carrier APIs like those defined in Camara that need user consent use this new Android API to retrieve the carrier's OIDC configuration. OEMs and other providing first run UX to Android users now have a general way to determine the user authentication endpoint and more of the carrier, and use that to create carrier accounts on the new device.

Impacts to partner/ecosystem (e.g. accelerate build speeds 10x):

This new API makes it possible for the API user to determine the carrier's OIDC configuration.

Detailed description and list of technical documents

getOidcConfiguration

Added in API level 35

public String getOidcConfiguration (int subscriptionId)

Returns the URL as a string for the carrier's OIDC configuration endpoint for subId, or an empty string if not available.

This API is suitable for general apps that needs to e.g. authenticate the user at the carrier's OIDC authentication endpoint and collect consent.

The availability and correctness of the OIDC configuration URL depends whether the carrier has configured this value.
Requires no permission.

Parameters

subscriptionId

int: the subscription ID, or [DEFAULT_SUBSCRIPTION_ID](https://developer.android.com/reference/android/telephony/SubscriptionManager#DEFAULT_SUBSCRIPTION_ID) for the default one.

Returns

[String](https://developer.android.com/reference/java/lang/String)

the URL of the carrier's OIDC configuration or an empty string if not available. This value cannot be null. The OIDC standard requires that this URL is an HTTPS-URL.

Throws

[IllegalStateException](https://developer.android.com/reference/java/lang/IllegalStateException)

if the telephony process is not currently available.

The new Android API might be implemented in SubscriptionManager. As the OIDC configuration is public no PERMISSIONS are needed.
https://developer.android.com/reference/android/telephony/SubscriptionManager

Camara API examples

https://camaraproject.org/device-status/
https://camaraproject.org/device-location/

GSMA Standards

https://www.gsma.com/newsroom/wp-content/uploads/TS.43-v9.0.pdf

OIDF Standards

https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata

TS.43 in Android

https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/gsma_services/ts43authentication/src/com/android/libraries/ts43authentication/Ts43AuthenticationLibrary.java

Similar method in Android

Android's Ts43AuthenticationLibary already has a similar method but retrieving the OIDC configuration allows to get all the information instead of just e.g. the OIDC token endpoint.

See:
https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/gsma_services/ts43authentication/src/com/android/libraries/ts43authentication/Ts43AuthenticationLibrary.java;l=242

/**
* Get the URL of OIDC (OpenID Connect) server as described in
* TS.43 Service Entitlement Configuration section 2.8.2.
* The client should present the content of the URL to the user to continue the authentication
* process.

public void requestOidcAuthenticationServer(...)

[sebdewet]

Hi @AxelNennker,
App will first call the "getSubscriptionId (slotIndex)" ?
Is there a risk with multi-sim ?
could you detailed what is the link between the subscriptionID and the operator ?
It can't use the mnc/mcc or imsi to get the URL of the carrier's OIDC configuration ?
Is there a sequence diagram ?
sorry for all the questions.

[AxelNennker]

HI @sebdewet
hope you +1-ed the feature request. (Feeling like a youtuber asking for a like and a subscription, but please +1 it)

Yes, the subscriptionID is exactly for the the multi-sim case.
This API is for "normal" Android applications, not privileged ones.
https://developer.android.com/reference/android/telephony/SubscriptionManager

The application could also use getActiveDataSubscriptionId or any other methods that results in a subscriptionId being returned, or iterate through all subscriptions and get the OpenId configuration url for each and then use one or all of them.

I think that 3rd-party apps would greatly benefit from knowing which operator could be used to authenticate the user.
And of course create help 3rd-parties in using Camara APIs, authenticating the ueser and collecting consent.
Which OpenId configuration url is returned is configurable by the operator.

I think the number of use cases is only restricted by your imagination.

[sebdewet]

Hi @AxelNennker ,
On Orange side, we are really interested by this feature, but we need to understand it and what it implies.
We also know that it would be only avalaible on Android, it means that on iOS (and Harmony too ?) we can't use the same way to get the operator. And it's always embarassing to not have the same behaviour on each OS.
That's why we were working on EAP-AKA use cases, with privileged rights, on operators apps.

Of couse we understand the benefits, and how it will ease the 3rdParty apps, but if it's only implemented on Android, and we still need a telco Finder for others OS, it will only be profitable to avoid overloading the telco finder.

Do you have a sequence diagram and an example of the content of the subscription_id to see how it is related to each operator ?

[AxelNennker]

These OS feature requests usual take some time and of course the maker of the OS have to be sure that the technology is not deprecated too soon, so they have to deprecate the feature. I think OpenId is very mature and well established in many ecosystems, so that danger is small. And all Camara operators obviously support OIDC. Even aggreators and integrators should support this feature request. Please +1 it.

For operators the benefits are obvious, I think, and go beyond Camara and API ecosystems.

Regarding other operating systems, we should not stop doing the right thing if we do not get 100%.
Android is about 70% and iOS 30% market share in 2023.

I see the API as a competitive advantage for Android and if that is true others will follow.

Regarding the contents of the subscriptionId, that is just an integer.
https://developer.android.com/reference/android/telephony/SubscriptionManager#getActiveDataSubscriptionId()

The java code in the 3rd-Party app on the mobile device could look like this:

int subscriptionId = SubscriptionManager.getActiveDataSubscriptionId();
if (subscriptionId != INVALID_SUBSCRIPTION_ID) {
  // https://accounts.login.idm.telekom.com/.well-known/openid-configuration
  // https://mobileconnect.telekom.de/.well-known/openid-configuration
  // https://agregator.example.com/.well-known/openid-configuration
  String carrierOpenIdConfigurationUrl = getOidcConfiguration(SubscriptionManager.getActiveDataSubscriptionId());
  myBackend.sendCarrierOpenIdConfiguration(carrierOpenIdConfigurationUrl, resultCallback, errorCallback);
} else {
  // try another subscriptionId 
}

// the magic is in the mobile apps backend. e.g. retrieving the "issuer" and then telling the app what to do next in the resultCallback. If the 3rd-party does have client credentials for that issuer than the backend can do whatever those client credentials allow them to do, e.g. get an access token that the mobile app then uses over an on-net connection for numberverify.
(Or get an access token for TS.43 Device App authentication with OperatorToken AcquireOperatorToken for EU DI wallets. I am getting ahead of myself).

Please continue asking your questions. Contact your Android Partnermanagement regarding this feature request. Propose changes to the proposed API...

Create an ICM issue and make this an official ICM WG work item...

//Axel

Ceterum censeo hanc petitionem sustinendum
(please somebody with fresher Latin fu than mine correct this :-)