In the first part of this post, I explained why user-defined passwords are not a sustainable mean for making the Web a safer place for private matters or business. So what? As there’s no going back in the use of the Internet – on the opposite, whole sectors of our activity continue to shift online – authentication needs to be fixed in some reliable, standard, future-proofed way. Here are some thoughts on realistic paths to take – and some dead-ends to skip.

Killing some myths

Online authentication has drawn a huge number of entrepreneurs in the past 15+ years, and has been the field of countless initiatives. Ever heard about Passport? OpenID? OATH (in its initial goals)? InfoCard? IDeNum (not sure I have enough French readers J)? …  Most have failed, not to say all have failed – I hope to be contradicted, but having spent more than 5 years in this industry myself, I’ve witnessed a lot more complete failures than half-successes. The only one I can think about that had a true impact is Facebook Connect. Why is that?

There are a lot of reasons, such as: assuming that users would pay or buy something, or assuming that security is something that users care about… I won’t expand on these long-lasting myths: just don’t build a start-up on these assumptions. But there is one single reason why – with the very few exception(s) mentioned – no single system has yet succeeded to replace passwords for user authentication: the gap between one-sided and two-sided markets.

Top-down is the key word for two-sided markets

Let’s explain this. With passwords, sites don’t have to make any assumption regarding users: you’re asked to create a password, and that’s it. But if a site wants a better authentication, or wants that you don’t have to create a new password, you have to bring something else instead (a certificate, a token, an account with a login service…). That “something else” operates on a two-sided market, on one side the sites supporting it, on the other side the users having it. The big concern with two-sided markets is not price, it’s adoption: sites waiting that enough users have it to support it, users waiting that enough sites support it to care about it and possibly then get it.

How do you get past such a situation if you’ve invented an authentication solution that you’d like the world to use? Well, sadly you don’t. Subsidize the accepting sites? You can’t subsidize the paying party of your business model in order to build it! And, as said, you’d have to pay them more than what you’d expect them to pay you, because the problem with your system is not the price. So this is a complete dead-end (cf. SwissID). Be the first one in the right ecosystem? Yes, it worked for Paypal within the eBay ecosystem, which turned out to be a large enough user base to enable Paypal to convert millions of sites. And this is the reason why it worked too for Facebook Connect; not that they were really the first ones, but they started with a 500M+ user base: which site can resist it? Top-down is the key word for two-sided markets where users don’t pay: it’s just recognizing the fact that an enrolled user base turns a two-sided into a one-sided market.

Social login isn’t the end of the story

Social login (e.g. Facebook Connect or sign in with Google+) is great for social applications – especially mobile Apps. Discovering my network saves time and brings value. That’s the reason why it has got such a huge traction in the last 2/3 years, with hundreds of thousands of sites accepting Facebook Connect (see e.g. these stats).

But that’s not the end of the story. This method for signing up exposes my entire network to applications, which I usually prefer to avoid unless this is the very purpose of the application – and so do my connections. It offers a quite low sign-in security to accepting sites, because it’s still user-defined passwords that won’t probably be unique. And sites that don’t need my social graph have no convincing reason to support social login, so I will still be left with a ton of identities to manage.

Facebook Connect and a few others have won the battle for signing up to social applications. But what about online authentication? I mean authentication for banking, payment, healthcare, gaming, public services, and for the myriad of sites where signing in with your favorite social network doesn’t make any sense?

User-centric and site-centric identity: the future is hybrid!

Let’s consider authentication needs from a site perspective (see the results of our recent survey on this topic here. Note: it will be published in the coming days and the post will be updated with an active link); the market can be roughly segmented in sites that

need social login need a higher login security or prefer to outsource user credentials management, whatever the reason (real money, reputation, privacy…) want to shorten their sign up process don’t care

In order of appearance, authentication for these segments would look like as follows:

social login some form of 2-factor / 2-step authentication, if affordable / securely implemented (see previous post on this topic) social login or a privacy-respectful equivalent, based on something users are already enrolled in (e.g. “sign in with email” initiative by Mozilla Foundation, which entirely observes the top-down constraint that I stressed) login & passwords; realistically, sites where you need to create a password will not disappear overnight. Passwords are there to stay

Well… From a user perspective, this hybrid and segmented authentication future looks even darker than the current, not so bright, situation: maybe not more passwords, but many more ways to authenticate! Are these the sustainable scenarios I teased you with? Where will the rescue come from?

Augmented Personal Clouds

The concept of Personal Cloud is emerging: it’s about giving users a way to choose who their Identity Providers are, that is, who is authenticating them when they sign in to a site. With social login, the Identity Provider must be your social network; with a Personal Cloud, it can be anyone you choose – even yourself if you run an authentication server, this is quite similar to the ‘old’ OpenID model. One of the differences is that this is compatible with a “sign in with email” approach, because it implements a discovery protocol similar to DNS, where your email address can be the entry criteria; with OpenID 2.0, if you wanted to sign in with your email address, your Identity Provider had to be your email provider. Not with Personal Clouds.

What does it change? It’s similar to social login, you wouldn’t need to create a new password with sites accepting such a model, because you would be authenticated by your Personal Cloud Provider.

What are the chances that this model succeeds better than the previous ones? Personal Clouds don’t face the two-sided market problem, among others because they are compatible with a “sign-in with email” approach. They are therefore more likely to flourish. Some organizations, like Respect Network, which inWebo joined this year, are developing a framework and a business model around Personal Clouds.

Can this help defragment authentication? Yes. Sites delegating their authentication will contribute to this objective. But let’s now remind that a Personal Cloud is a service. What if a Personal Cloud Provider was at the same time a secure authentication provider for site-issued identities? And a secure Cloud-based password manager?  Let’s call it an augmented Personal Cloud. Such a service reconciles the various types of authentication from a user perspective. And none of the components faces two-sided markets issues.

Science fiction? Well, we’ll open the doors this year, stay tuned.