Application unbundling & Native SSO

You used to have a single application on your phone from a single social provider, you likely now have multiple.

Where the was Google Drive, there is now Sheets, Docs, and Slides - each individual application optimized for a particular document format.

Where the chat function used to be a tab within the larger Facebook application , there is now Facebook Messenger - a dedicated chat app.

LinkedIn has 4 individual applications.

The dynamic is not unique to social applications.

 According to this article

Mobile app unbundling occurs when a feature or concept that was previously a small piece of a larger app is spun off on it’s own with the intention of creating a better product experience for both the original app and the new stand-alone app.

The unbundling trend seems mostly driven by the constraints of mobile devices - multiple functions hidden behind tabs may work on a desktop browser, but on a small screen, they may be hidden and only accessible through scrolling or clicking.

That was the stated justification for Facebook's unbundling of Messenger

We wanted to do this because we believe that this is a better experience. Messaging is becoming increasingly important. On mobile, each app can only focus on doing one thing well, we think. The primary purpose of the Facebook app is News Feed. Messaging was this behavior people were doing more and more. 10 billion messages are sent per day, but in order to get to it you had to wait for the app to load and go to a separate tab. We saw that the top messaging apps people were using were their own app. These apps that are fast and just focused on messaging. You're probably messaging people 15 times per day. Having to go into an app and take a bunch of steps to get to messaging is a lot of friction.

Of course, unbundling clearly isn't for everybody ....

I can't help but think about unbundling from an identity angle. Do the math - if you break a single application up into multiple applications, then what was a single authentication & authorization step becomes multiple such steps. And, barring some sort of integration between the unbundled applications (where one application could leverage a 'session' established for another) this would mean the user having to explicitly login to each and every one of those applications.

The premise of 'one application could leverage a session established for another' is exactly that which the Native Applications (NAPPS) WG in the OpenID Foundation is enabling in a standardized manner. NAPPS is defining both 1) an extension and profile of OpenID Connect by which one native application (or the mobile OS) can request a security token for some other native application 2) mechanisms by which the individual native applications can request and return such tokens.

Consequently, NAPPS can mitigate (at least one of) the negative implications of unbundling.

The logical end-state of the trend towards making applications 'smaller' would appear to be applications that are fully invisible, ie those that the user doesn't typically launch by clicking on an icon, but rather receives interactive notifications & prompts only when relevant (as determined by the application's algorithm). What might the implications of such invisible applications be for identity UX?

Sticky Fingers

Digits is a new phone-number based login system from Twitter.

Digits is a simple, safe way of using your phone number to sign in to your favorite apps.

Note that Digits is not just using your phone to sign in (there are a number of existing mobile-based systems), but your phone number. 

Digits is an SMS-based log in system (unlike mobile OTP systems like Google Authenticator). When trying to login to some service, the user supplies their phone number, at which they soon receives an SMS, this SMS carrying a one-time code to be entered into the login screen. After Twitter's service validates the code, the application can be (somewhat) confident that the user is the authorized owner of that phone number.

Now, the above makes it clear that Digits relies on only a single factor, ie a 'what you have' of the phone associated with the given phone number. This post even brags that you need not worry about any additional account names or passwords. But that same post claims that Digits is actually more than a single factor

Digits.com, an easy way for your users to manage their Digits accounts and enable two-factor authentication

As much as I squint, I can see no other factor in the mix. (And it sure isn't the phone number.)

Digits apparently also has privacy advantages.

Digits won't post on your behalf, so what you say and where you say it is completely up to you

Well, to be precise, Digits can't post on your behalf ... And is it not somewhat ironic that Twitter touts as an advantage of Digits the fact that it is not hooked into your Twitter account??

Presumably this is presented in contrast to the existing 'Sign-in with Twitter' system, use of which can allow a user to authorize applications to post to Twitter on their behalf (as the system is based on OAuth 1.0).

But of course, 'Sign-in with Twitter' allows applications to post on behalf of users only because Twitter made the business decision to make this permission part of the default set of authorizations. Twitter could have chosen to make their consent more granular and tightened up the default.

Dick Hardt analyzed Digits and hilited two fundamental issues of using phone numbers as identifier

1. the privacy risk associated with a user presenting the same identifier to all applications (as it enables subsequent correlation amongst those applications without the user's consent). It's pretty trivial to spin up new email addresses (even disposable ones) to segment your online interactions and prevent correlation. Is that viable for phone numbers?
2. that applications generally aren't satisfied with only knowing that who a particular user is, but almost always want to know the what as well, ie their other identity attributes, social streams etc

Dick, having made the second point, perversely then conjectures that it may not be an issue

as mobile apps replace desktop web sites, the profile data may not be as relevant as it was a decade ago

I can't imagine why the native vs browser model would impact something as fundamental as wanting to understand your customer?  

Twitter actually tries to position this limitation as a strength of Digits

Each developer is in control with Digits. It lets you build your own profiles and apps, giving you the security of knowing your users are SMS-verified. 

The motivation for Digits.com becomes a bit clearer when you read more

We built Digits after doing extensive research around the world about how people use their smartphones. What we found was that first-time Internet users in places like Jakarta, Mumbai and São Paulo were primarily using a phone number to identify themselves to their friends.

Twitter must have looked at their share in these markets and determined they needed a different way to mediate user's application interactions.

Source - http://stats.areppim.com/stats/stats_socmediaxtime_afr.htm