integration to on device application (EAP-AKA)

[mengan]

Problem description
From: Mike at T-Mobile USA.
the current solution is a GET and POST which functionally works for server's that leverage device IP's to identify the phone number of the device the call has originated from. but this only works were the user is connected to the Mobile network. Meanwhile an increasing number of our subscribers leverage their Home or office Wifi for their data traffic. leading to a larger number of users where the ip lookup does not work.

Possible evolution
T-Mobile is proposing a APP and APP-clip which will register the same URL/path as the number verification/get number.
When a third party application or webpage makes a call to the url it would/could get caught by the carrier app or appclip which would leverage eap-aka to process the request and return the value.

There are the following hurdles.

1. Instead of returning an HTTP 200 with data. the HTTP request will get intercepted and the user context will switch to the carrier app/appclip So the third party will get EITHER (http response means it hit ip lookup server) or (Redirect back to third party with URL parameters with carrier response) For this to work the third party would construct their GET/POST with a redirect url and state variable. which the third party should register as a universal link in the case of a third party app.

2. we need to authenticate the Third party. our recommendation is to leverage the OIDC carrier assertion. this way the client has a consistent method to call and would make the ciba or on device flow match. ie.....
   GET https://carrier.com/auth?request=

Request is signed by client and contains
{
client_id:xxx
scope:"phone_number"
redirect_url:client.com
state=xxxx
nonce=xxxx
responce=token
}

the solution could then leverage IP lookup or eap-aka if caught by an ondevice application or app clip which has the carrier.com url registered for the universal link.

3. we want to potentially encrypt the response so that user data does not transit in simple http url's/ or bodies. For this our suggestion is that instead of issuing the ID_token as a JWT, we would issue the ID_token as a JWE using the same client's public key to verify the client_assertion/request object. (a client uses the same key to construct/sign the request as to decrypt the response)

4. we have a variety of other Camara api's where user consent may be required. We are interested in following the same approach so that when a third party is making a call. they can EITEHR use a ciba flow where a login hint must be present and the carrier must create a push ecosystem. OR the client who does not have the login hint could construct the same request locally (a oidc call) and that could get caught by the same carrier APP or APPclip on the running users device. LIKEWISE the carrier themselves. In the case of a CIBA request to a phone number that does not yet have the carrier app... the carrier can create an SMS with a link that link could then trigger the local APPclip for any consents and then uses as a vehicle to get the user to install the full carrier application for future requests down the push path instead of sms.

[mengan]

so someone just pointed me to the assets/uml.jpg which does like I suggest include a connection to oidc call.. but the current swagger and markdown don't include that access_token in the body(or headers) of the get/post.

the oauth flow suggested in the uml.jpg could leverage an appclip/carrier app to leverage eap-aka for the identity.

[DT-DawidWroblewski]

Hi @mengan !

we're finalizing specification at GSMA that delivers e2e solution for this problem -> Authorization Server Authenticator Capabilities Group

It should be released end of April (currently under GSMA approval process).

It covers use cases like:

1. Number Verify
2. Native App auth (eIDAS)
3. Camara OpenGateway

Additionally, flow contains participants like:

1. 3rd party app
2. TS.43 client (app on a device)
3. MNO Entitlements Configuration Server
4. MNO Authorization Server
5. Aggregator

It would be great to discuss this topic with in in future :)

Regards,
David

[bigludo7]

Document published here: https://www.gsma.com/newsroom/gsma_resources/asac-01-v1-0/

Specific issue(s) to be created.

[bigludo7]

Reopen following discussion with @AxelNennker .
Keep it open to have an issue open until NumberVerification has operatorToken implemented or decided not to implement it.

[chrishowell]

The interesting thing about this topic is that it's not really anything to do with the Number Verification API; it's to do with the authorisation phase of the front-end flow and the generation of an auth code/access token.

@bigludo7 / @AxelNennker has there been any movement on this since May? Is this the best sub-project for this discussion to continue within?

[AxelNennker]

I think we are getting there camaraproject/IdentityAndConsentManagement#145

We should re-read the NumberVerification APi description whether it somehow prohibits operator tokens.
https://github.com/camaraproject/NumberVerification/blob/main/code/API_definitions/number-verification.yaml
Or the API definition should explicitely mention operator token.

[AxelNennker]

e.g. this text should be changed

Number Verification API performs real-time checks to verify the phone number of the mobile device being used to access a service provider (SP) service, where the mobile device is accessing the service provider over a mobile network (WiFi connections are out of this API scope) either by getting the comparison result or receiving the phone number of the device that it is used, so they can verify it themselves.

Please suggest new text that does not state that WiFi is out-of-scope.