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.