Android Carrier OpenID API
Issue #630
open
This is a replica of issue #215 in the MODRNA WG.
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):
- 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. - 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.
- 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
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
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.
/** * 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
requestOidcAuthenticationServer(...)
Comments (7)
-
reporter
-
how does registration work? is it assumed that the app already has clients registered for the different MNOs?
With this information we can perhaps work out whether it would be possible to support a FAPI2 flow using this API -
I commented on https://bitbucket.org/openid/mobile/issues/215/android-carrier-openid-api
Hoping that answers the questions.
Regarding the registration question:
With mobileconnect there was a legal framework established that 3rd parties who created a contract with one operator in a market could use the same mobileconnect service(s) from the other MNOs in the same market.
Camara seem to assume that there are aggregators offering the MNOs' APIs and that 3rd Parties register at the aggregator.
But I am not speaking for Camara nor for Deutsche Telekom here. Nore for mobileconnect. :-)
Where end users register and who collects the consent is an age old question. One way this operating system (Android) API can be used is to direct the end user to the MNO, they authenticate there and consent to provide regarding MNO-service X1 (location (verification)) to business customer Y1 (bank) is collected at that MNO. Whether that consent is then valid for MNO-Service1 and Y1, or MNO-Service2 at Y2 is very much dependent on the language chosen to collect the consent and also dependent on the jurisdiction.
Other options are to use the new Carrier OpenID APi to get the openid configuration and using the openid-configuration as a parameter while directing the user to the aggregator who handles consent collection for all services/API it provides.
This new API certainly does not solve all problems but I think it is an important step in the right direction.
Please consider +1-ing here: https://issuetracker.google.com/issues/308240647
And consider adding FAPI use cases to the issue that might benefit if the API is added to Android.
-
reporter
Since the FAPI working group developed the Grant Management for OAuth 2.0 specification, would the use cases in Section 3 applicable to this request or would it be a different scenario (given the addition of the MNO to the use case)?
-
I think that Grant Management use cases do not benefit from this Android feature request. But maybe I am not imaginative enough. So, let’s try. The feature request https://issuetracker.google.com/issues/308240647 Carrier OpenId API allows all mobile applications to find the MNO’s (sim-card provider) openid connect configuration. The openid connection configuration url could be forwarded to the mobile app’s backend and the backend could retrieve the openid connect configuration and examine the grants supported by the MNO, and then use Grant Managemnt to manage the grants this backend (client) or mobile app use. … Thinking out loud
-
- changed status to open
-
-
assigned issue to
Bjorn Hjelm
-
assigned issue to
- Log in to comment
At the FAPI WG call on Nov. 16, 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.