[Openid-specs-mobile-profile] Android Feature Request

Wed Nov 8 07:14:45 UTC 2023

https://bitbucket.org/openid/mobile/issues/215/android-carrier-openid-api

From: Bjorn Hjelm <blhjelm at gmail.com>
Date: Wednesday, 8. November 2023 at 01:08
To: Nennker, Axel <Axel.Nennker at telekom.de>
Cc: bjorn.hjelm at oidf.org <bjorn.hjelm at oidf.org>, openid-specs-mobile-profile at lists.openid.net <openid-specs-mobile-profile at lists.openid.net>
Subject: Re: [Openid-specs-mobile-profile] Android Feature Request

Axel,
I agree but didn’t want to make an assumption. Would it be possible for you to open an issue in Bitbucket (https://bitbucket.org/openid/mobile<https://bitbucket.org/openid/ekyc-ida/issues/1371/client-registration-metadata>/issues<https://bitbucket.org/openid/ekyc-ida/issues/1371/client-registration-metadata>/) to get the discussion started?

Kind Regards,
Bjorn

On Nov 7, 2023, at 9:08 AM, Axel.Nennker at telekom.de wrote:

Yes, please. MODRNA is THE group in OIDF where OIDF and operators work together by definition.
If MODRNA has no input then who?

Of course, I would very much welcome it if operators discuss this also inside their organization and express their support their partnermanagement.

//Axel

From: Bjorn Hjelm <bjorn.hjelm at oidf.org>
Date: Tuesday, 7. November 2023 at 16:27
To: Nennker, Axel <Axel.Nennker at telekom.de>, openid-specs-mobile-profile at lists.openid.net <openid-specs-mobile-profile at lists.openid.net>
Subject: Re: Android Feature Request
Axel,
Is this an issue that you would like MODRNA to discuss and provide input on?

Kind Regards,
Bjorn
________________________________
From: Axel.Nennker at telekom.de <Axel.Nennker at telekom.de>
Sent: Tuesday, November 7, 2023 7:11 AM
To: Bjorn Hjelm <bjorn.hjelm at oidf.org>; openid-specs-mobile-profile at lists.openid.net <openid-specs-mobile-profile at lists.openid.net>
Subject: Android Feature Request

Hi Modrna,

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.

Kind regards

Axel

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<https://developer.android.com/guide/topics/manifest/uses-sdk-element#ApiLevels>

public

String<https://developer.android.com/reference/java/lang/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<https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/gsma_services/ts43authentication/src/com/android/libraries/ts43authentication/Ts43AuthenticationLibrary.java;drc=46470e17c23a347fca066508844a3dba55f371b7;bpv=1;bpt=1;l=277?gsn=void&gs=KYTHE%3A%2F%2Fkythe%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fsuperproject%2Fmain%2F%2Fmain%3Flang%3Djava%23void%2523builtin>

requestOidcAuthenticationServer<https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/gsma_services/ts43authentication/src/com/android/libraries/ts43authentication/Ts43AuthenticationLibrary.java;drc=46470e17c23a347fca066508844a3dba55f371b7;bpv=1;bpt=1;l=277?gsn=requestOidcAuthenticationServer&gs=KYTHE%3A%2F%2Fkythe%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fsuperproject%2Fmain%2F%2Fmain%3Flang%3Djava%3Fpath%3Dcom.android.libraries.ts43authentication.Ts43AuthenticationLibrary%23891bd20d7a94954077b21a3e4b633d7239ee2cc575fdb37aafd8add9019832e8>(...)

Submitting Company: Deutsche Telekom

_______________________________________________
Openid-specs-mobile-profile mailing list
Openid-specs-mobile-profile at lists.openid.net
https://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20231108/9d6c5b62/attachment-0001.html>