Android Carrier OpenID API

[Axel Nennker]

On behalf of Deutsche Telekom I created a feature request in the Android issue tracker.

https://issuetracker.google.com/issues/308240647

I also created that in the Android Partnermanagement issue tracker.

I assume that most operators use OpenId Connect and would kindly ask you to support this proposal.

Please discuss in MODRNA and provide input

[Axel Nennker]

Feature name: Carrier OpenId API

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(...)

‌

‌

[Bjorn Hjelm]

This issue was discussed at the FAPI WG call on Nov. 16 and, based on the discussion, a replica of this issue was created for the FAPI WG (issue #630).

At the FAPI WG call, there was a question raised about the details of the use case and whether the banking app could get the location from the mobile device or why the location information would have to come from the MNO (Mobile Network Operator). Additional information on details of the use case would help provide input on this issue.

[Axel Nennker]

The location information does not have to come from the MNO. Location-Verification is something that some MNOs provide.

Also location verification is just one example of a MNO provided service that might require user consent in some jurisdictions.

Pick any MNO service from mobileconnect that requires user consent
https://www.gsma.com/identity/mobile-connect/mobile-connect-specifications

or any API offered by Camara that requires user consent

https://github.com/camaraproject/IdentityAndConsentManagement

or even single-operator services that require user consent and you have a use case for this new API.

‌

Back to the questions:

• “whether the banking app could get the location from the mobile device”
  Some MNOs offer getting the phones location but usually location verification is preferred because it is less invasive and misuse easier to detect.
  Often the information the details of the device location is limited e.g. to the city or country level as risk management might require re-authentication or 2FA when the access is from an unusual city or country.
• “why the location information would have to come from the MNO (Mobile Network Operator)“
  Of course it does not have come from the MNO. There are several services offering location (verification) services.
  The question for the customer (e.g. Bank) is whether the service is available in the market they are targeting. MNOs are globally present and more importantly the end user already has a relationship with the MNO. And the MNO “knows” the location of the device anyway e.g. which cell tower the phone is using. So the location information is not collected by an unknown service provider often with jurisdiction of a foreign country.

The use cases in the feature request are just examples. I welcome adding your use case to the feature request.
Or add your use case(s) yourself as a comment to the feature request and please consider to +1 the feature request.

https://issuetracker.google.com/issues/308240647

‌

If you happen to have a Android partner account, please view the same issue in the partner issue tracker:

https://partnerissuetracker.corp.google.com/u/1/issues/308520958
I’ll admit that I do not know who can access that request. Sometimes it looks like is “visible to public”

If you can access the OpenId feature request in the partner issue tracker, please also +1 it there.

Thank you.

‌

[Bjorn Hjelm]

Since you referenced Mobile Connect, would your use case comply to IDY.23, Section 3.4? If there’s a better reference that better describe the use case requirements, please feel free to provide it. There’s also a high-level flow for (3GPP EDGE) authorization based on user consent in 3GPP TR 33.867, Section 7.1.2, that may (or may not) apply to your use case. Any additional (use case) requirements or high-level flow is always appreciated.

[Axel Nennker]

For easier reference https://www.gsma.com/identity/wp-content/uploads/2023/01/IDY.23-v1.0.docx The OpenID Carrier API can be used by MNOs participating in MobileConnect to set the URL that is the result of OpenID Carrier API methods' call to the MobileConnect IDGW. In Germany Deutsche Telekom might set the OpenID Connect Configuration url to https://mobileconnect.telekom.de/.well-known/openid-configuration This, of course, very much depends on the setup in a market where MobileConnect is active. MNO’s participating in MobileConnect are free to configure whatever OpenId Connect configuration url they like but might agree to set the url to the MobileConnect configuration url, which is, of course, OIDC compliant.

[Axel Nennker]

I think, the OpenId Carrier API can be used to onboard users to mobileconnect.