Open ID Connect and GSMA Mobile Connect

OpenID Connect (final specs launched Feb 2014) is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message flows with a design goal of “making simple things simple and complicated things possible”. OpenID Connect lets developers authenticate their users across websites and apps without having to own and manage password files. OpenID Connect has been implemented worldwide by Google, Microsoft, Deutsche Telekom, salesforce.com, Ping Identity and others.

The GSMA Mobile Connect service is a mobile operator collaborative initiative to implement a mobile phone number-based authentication mechanism on top of OpenID Connect.  With Mobile Connect the MNO creates a token which is then shared with vendors to verify the customer. The token can be tied to an email address or another user identifier but the GSMA views the MSISDN as the unique identifier for identity aggregation and vendor integrations will be based around mobile phone number. Don’t mention Vodafone360!

The OpenID Connect is built as a simple identity layer on top of the OAuth 2.0 protocol. It allows clients to verify the identity of the end-user based on the authentication performed by an authorisation server.  OpenID Connect supports identity attributes by obtaining basic profile information about the end-user in an interoperable and REST-like manner. OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps which allows the mobile internet device to act as a local authorisation server authenticating applications with the identity provision held within the secure SIM card.

OpenID Connect differs from OAuth which is an access granting protocol and as such has no definition of identity. As an example Facebook extends OAuth with what it calls a ‘signed request’ in order to provide identity on top of authorisation. The ‘signed request’ is conceptually analogous to OpenID Connect’s JWT “ID Token” which works with multiple identity providers by using the IETF JSON Web Signature (JWS). In order to be interoperable Open ID Connect provides a standard way of requesting and responding claims for which Open ID Connect has defined a standard scope, RESTful granular methods for request objects & claims and a JSON based “ID Token”.

Open ID Connect supports identity providers such as Google+ Sign-In and IdPs on to the mobile internet device. In this later case the mobile phone can act as self issuing identity provider (e.g. Janrain). It is in this space that GSMA Mobile Connect will feature strongly supporting both the large Identity Provider (e.g Deutsche Telekom‘s support for OpenID for its Business Marketplace to act as an OpenID 2.0 provider to support single sign-on for applications) and the customer delegated model with identity stored and provided from the phone.

PAYM and Donor Led Mobile Number Porting Use Case

The PAYM mobile payment service enables UK bank customers to transfer money to an individual using their mobile phone number (MSISDN) as the identifier. Currently nine banks and building societies have adopted the PAYM service and customers of these providers can now register to use the service.

The PAYM architecture is based on a centralised database of receiver’s MSISDNs. The terms and conditions as part of signing up to the service require the customer to agree that their “mobile number will be stored on a database managed by a third party on behalf of all the participating banks and building societies”. The customer’s name, MSISDN and bank are then held as records within the centralised database. The sender’s bank accesses the PAYM database to confirm that the recipient is registered with the service and to retrieve their bank or building society account details of the receiving party.

According to the Payments Council’s How Does PAYM Work section “the payment will be processed whether or not the recipient’s phone is on or within coverage. In most cases the payment will reach the recipient’s account almost immediately and they will be able to see it in recent transactions on their account”. This means that there is no check by PAYM that the MSISDN is on the home location register or in use by the receiver.

The sign-up process requires MSISDN validation as part of a 2 factor step-up authentication process implemented by each PAYM supporting bank and building society. This allows the MSISDN to be validated before registration with the centralised database. It is sensible to presuppose that the centralised database ensures uniqueness for the MSISDN so that the same mobile phone number cannot be registered by two individuals.

Because the receiver’s mobile phone number (MSISDN) is used as an identifier which is only validated on registration there is the possibility that the payment receiver may not be the current MSISDN subscriber. Not all customers keep their existing phone number when they move network operators so a receiver may only be using a old phone number as an identifier. In the UK mobile number porting is ‘donor-led’ which requires the customer to initiate things by contacting the donor (first) network operator and asking for a Porting Authorisation Code (PAC code), which is needed to retain a phone number when switching. The customer must then give this to the recipient (second) network operator before things can proceed. If the receiver who changes networks initiates donor-led mobile number porting then all services linked to the mobile phone number will remain linked to the mobile number.  But if the receiver who changes networks does not initiate this process then the PAYM account identifier is tied to an unused mobile phone number.

Mobile phone numbers that are not ported will eventually be recycled and made available to new customers. If the new ‘owner’ of the mobile phone number chooses to register with PAYM they may find that the number is already is use and all therefore be blocked from registering. There is no current process for claiming an already registered mobile number. The process for de-registration or mobile number change is first user driven: “Customers are able to de-register from the service at any time. To de-register customers can change their choice of payment account, the mobile number they have registered for the service and the bank or building society they have joined with at any time. To change your registration from one bank to another, you need to deregister through the bank or building society you have signed up with and then re-register with the new participating bank or building society. The payments council has not implemented a process for this use case.”

The PAYM service would be stronger if it were linked to a synchronous HLR registration service supported and provided by all UK Mobile Network Operators.