Transforming Communication Service Providers into Personal Information Vaults

Although we see increased collaboration between Hyperscalers and Communication Service Providers (CSPs), a.o. in edge clouds providing infrastructure-as-code to flexibly deploy network functions, they continue to be competitors in the fierce battle for the relationship with consumers and enterprises, who are wondering whom to trust to hold sensitive data.

Who would you trust the most to automatically log in to your bank account : your face-scanning smartphone manufacturer? A Google, Facebook or Microsoft ID? Your Mobile Network Operator? Who would you trust to erase your personal data after your changed smartphone, left the social network or switched to a different #5G provider?

Who would enterprises trust to extend their private clouds with elastic, low-latency, high-throughput edge clouds : GCP, AWS, Azure or 5G CSPs running Network Exposure Functions (NEF) for multi-tenant edge clouds?

One of the considerations in the purchase decision is the "portability" of my data : if I am no longer satisfied with the price/performance/quality of the provider, can I easily stop my customer relationship and move to a different one?

While CSPs have been subject to Mobile Number Portability (MNP) for decades, they have unfortunately seen this as a regulatory burden, rather than an opportunity to accumulate and exchange subscriber information. Contrary to Facebook who saw so much value in the Mobile Number that they acquired Whatsapp already in 2014, basing an entire messaging & voice service on it. More recently Clubhouse was entirely built on the Mobile Number. In fact with multi-factor authentication the whole application and enterprise ecosystem relies heavily on the CSP-owned E.164 MSISDNs.

Regulators also imposed emergency calls, content screening, data retention and lawful interception to the CSPs, but not to the hyperscalers, and to date there's no legislation in place forcing Hyperscalers to collaborate in criminal investigations or the search of missing persons. This is not a level playing field and if no constructive solution is designed, Hyperscalers could face more irrational measures such as being broken up.

The 5G System (cf. TS 23.003) is today permitting to store multiple Generic Persistent Subscription Identifiers (GPSI - "gipsy") for a single Subscription Permanent Identifier (SUPI). A GPSI can be either the traditional E.164 MSISDN or an External ID (EID in the format user@domain). The SUPI can be the traditional E.212 IMSI or a Network Access Identifier (also user@domain). It is supposed to remain internal and concealed (as SUCI) but 3GPP forgot to specify how the UE obtains the public key for that.

You could thus ask your 5G provider to store your Facebook/Google/Microsoft accounts against your mobile phone number and automatically insert them for browser/app access to millions of existing applications - aka HTTP Header Enrichment. Yes, the TLS tunnel must be interrupted, so this must happen in partnerhip with Hyperscalers (your 5G provider's SubCA certificate must be signed once by each Hyperscaler's SubSCA). Encrypted Client Hello (ECH) should be disabled by mutual agreement.

Regulation already imposes the Portability of all your public identifiers today, e.g. in 2G/3G the E.164 numbers for circuit-switched data and fax were also transferred besides the one for voice calls. Gipsies are traveling, so will the 5G GPSIs :-)

The next opportunity is thus the reliable secure portability of the private passwords matching these public IDs. SUPI-IMSIs cannot ported as they contain the 2- or 3-digit Mobile Network Code of the donor. But SUPI-NAIs can contain passwords and can be ported. (3GPP did not specify a standard way to attach application passwords to the SUPI-IMSI).

The GSM Association is best placed to impose the convention that for each GPSI-EID myfacebookid@mycspdomain, the SUPI-NAI would contain [email protected]. For each consumer or enterprise the 5G CSP would thus hold several linked SUPI-NAIs in the UDM/UDR. Authorized Application Function (AF) providers could ask the 5G provider to verify a username/password combination through the brand new Network Exposure Function (NEF) - i.e. in cases where HTTPS Header Enrichment is impractical.

Do I need to switch from 5G Non Stand Alone (NR + LTE) to 5G Stand Alone (NR only) to benefit from the new 5GS identifiers? Not necessarily. My UE could access the 5G System (5GS) via SUCI-NAI over Wi-Fi, and the Evolved Packet System (EPS) via SUCI-IMSI over 5G NSA, concurrently.

Regulators could place interception requests for a GPSI-EID / SUPI-NAI through the standard 5G Lawful Intercept systems being deployed as we speak. URL/SNI screening and data retention systems would work as today. The 5G CSPs truly have a service to sell here to the Hyperscalers.

I have been promoting and patenting globally unique scarce identifiers ("Telecoins") for 5G CSPs to prepare the #SIMless post-telephony era. I think that with SUPI-NAI and GPSI-EID we could accelerate this transition, using unmodified 5G network equipment and creating a new collaboration between CSPs, Hyperscalers and Regulators, to the benefit of Consumers, Enterprises and post-pandemic economic development.