The user authentication market as we know it is about to change. There’s one digital device in existence that has more users than any other in the market. It’s in use from the rural villages of India to the sprawling metropolis of the world – the mobile phone. Wouldn’t it be great if you could leverage your phone, which basically never leaves your side, to authenticate to and access online services? Now you can, thanks to Mobile Connect.

GSMA and Mobile Connect

GSMA represents the interests of mobile operators worldwide. There are several working groups under the GSMA advancing different mobile based technologies, best practices and standards. Under the Personal Data Working Group, there’s a program called Mobile Connect. At the core of Mobile Connect, there’s an adapted version of the OpenID Connect protocol with the aim to create a federated and global mobile identity ecosystem. Let’s take that last sentence apart to get more sense into the techno gibberish.

Mobile Connect is Global

In some parts of the world, the mobile phone is a very basic device. In some other parts, most people will walk their nose pointed firmly towards the ground (and the 5” screen) as they check their latest snaps, Facebook updates, or try to get through to the next level in Clash of Clans. The global aspect of Mobile Connect takes this into account and allows mobile operators to choose the method of user authentication that is appropriate for their subscribers. More basic devices could use a simple SMS based or non-PKI SIM based authentication, whereas more advanced devices could use an app and the fingerprint to authenticate users to online services.

The GSMA calls these authenticators. An authenticator is the piece of technology that provides the means for the end user to establish his identity. An authenticator always uses a device that has an MSISDN (that’s the phone number in plain English). This is the first clever bit of Mobile Connect. The MSISDN can be considered as a unique attribute or identifier.

Online services connect to an operator Identity Gateway using the standardized Mobile Connect protocol. The Identity Gateway connects to the authentication server. The authentication server takes care of the actual authentication event by sending the authentication request to the authenticator and validating the response. The type of authenticator(s) selected by the operator defines what kind of authentication servers are required. Sometimes the Identity Gateway and the authentication service come from different vendors. The selection of authenticators is a local issue.

As the communication between the online service provider and the identity gateway is standardized, it is straightforward to connect online services and identity gateways on a global scale.

Mobile Connect is Federated

The second clever part of Mobile Connect is in the federation. Federation is a technology (and agreements) that allow users to move between independent domains without re-authentication. In the Mobile Connect concept, it allows a subscriber of an operator in India for example, to log into an online service in the UK. The key to this capability is something called the discovery service.

The normal scenario is that the online service provider is connected to the GSMA Discovery Service (and the Identity Gateway). This discovery service provides the login screen for the end user where the phone number will be typed in by the user. Now for the magic part. The discovery service will check the phone number and… erm… discover that it belongs to an India based operator and routes the authentication request to the home operator of the user. The home operator then pushes the authentication request to the user’s mobile device and the user authenticates. Simple.

Enabling the Subscriber

When the operator decides to deploy Mobile Connect they will first have to build the infrastructure. So they acquire/build an identity gateway and choose appropriate authenticators for their subscribers. Deploying the hub of the solution, the identity gateway can be done the easy or the hard way. The easy way could be for example using the Ubisecure Identity Cloud as a managed solution. This can be up and running in two hours after we receive the call. The hard way is to do it in-house and create a development team, try to pass the conformance tests and maintain the in-house solution as the protocol develops and new features are added over time.

Then it’s a question of selecting the authenticator(s). The chosen authenticator is dependent on the market situation and what the subscribers can utilize. There are authenticator options that rely on SMS based technologies and won’t require anything extra to be installed to the user’s phone. The next category would be an authenticator that involves an installation of a small SIM based application, but still using SMS based communication. The larger SIM applications, for example PKI based operations, typically require a new SIM card and means that the subscriber has to visit the operator shop to change his SIM card, however they still use SMS for last leg of the journey from the authentication server to the user device. Then we have smartphone app authenticators (SAA).

The cost of deploying an authenticator is an important fact to consider. SAA deployment and the simple SMS based authenticators have zero deployment costs for the operator. A non PKI based SIM client costs a handful of SMS messages to deploy. If the user needs to swap the SIM and visit the operator shop, the cost of the deployment will be at the 10-20$ range / user.

Level of Assurance (LoA)

Depending on the chosen authenticator, the method will be assigned number (1-4) reflecting the Level of Assurance (LoA) of the authenticator. A multi-factor authenticator will get a higher number as they can be considered stronger. Authenticators that can provide proof that someone pressed “ok” on the mobile phone are assigned a lower number. The online service provider can request a certain level of assurance when they want to authenticate the end user.

It’s worth noting that at this moment the LoA of the Mobile Connect only describes the strength of the authentication method, not the identity. The strength of the identity relates to the registration process itself and how the subscriber has been verified when he acquired his mobile phone subscription. In some markets, pre-paid subscriptions can be acquired without any kind of identity verification. Post-paid (invoiced) subscriptions in most markets require a thorough identity verification.

Mobile Connect has the potential to become a global method of authenticating online users. In the next part of this blog post I will take a look at the benefits of Mobile Connect for end users, service providers and mobile network operators and discuss how to get started with Mobile Connect. We’ll also take a look at edge cases operators need to figure out if they want their Mobile Connect deployment to be successful.

Find out more about Ubisecure’s Mobile Connect solution.