Friday, November 07, 2014

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?

No comments: