Social login lets people login into a Web service with their social identities from Facebook, Twitter, Google, LinkedIn, and so on. Web service developers love it for two big reasons:

1. Social login reduces friction. When users show up at your service, they don't have to create accounts or remember a new password.
2. Social login reduces the amount of overhead code that needs to be written. Writing good authentication code that supports password reset, works well, and is secure is hard. And it has nothing to do with your product differentiation.

As a consequence, social login is the primary way that modern Web 2.0 services provide authentication.

When we were planning SquareTag, naturally we discussed supporting social login. We determined that for the beta we would not. Our reasons were philosophical, trumping the practical considerations I provide above.

In a nutshell, SquareTag is based on a system that we have architected to give users control over how their personal information is used and shared. We support privacy by design. We felt that supporting social login for SquareTag sent the wrong message about how we wanted to treat our user's data. While social login is presented to users as an authentication step, it is actually an authorization step and any site you "login into" using social login is also authorizing the site to access your Facebook or Twitter data.

Social login has been a boon for a handful of what are known in the industry as "identity providers" or IdPs. While any site with users can serve as OAuth-based IdP, only a handful have the number of users necessary to warrant a place on the login page of most Web services. Consequently the natural positive feedback of that loop creates natural monopolies around those IdPs. Less than 10 companies now control the user populations for much of the Web and consequently most Web services and mobile apps. I think that's a dangerous situation.

Most of these same companies also control a browser, an ad network, or both. They use their power as IdPs to serve their own interests, naturally, and that means to sell more ads. This creates a great conflict of interest between their duty as custodians of user data and their desire to use that data to "target" ads at people.

The problem is there's no alternative that has the features I list above. Drummond Reed wrote a nice description of the theory behind what the alternative needs to look like:

What Phil and Doc called "sovereign identity" means that an individual who wants to assert their identity does not need to rely on—or be subject to—any third-party "identity provider". No matter how big or benevolent that identity provider.

To be truly "free", the individual needs to be able to be their own identity provider, which is why at least some of us are focused on personal cloud login—using your own personal cloud as your "identity provider".

Once you arrive at that architecture, then the requirements become pretty clear—how a P2P personal cloud network works, what the P2P trust mechanisms are, and how relying parties start using it. That's what we're doing with the Respect Network, and which other P2P trust networks may be undertaking as well.

Decentralized solutions don't provide developers with the trust they need to rely on the authentication. To be your own IdP, to have sovereign identity, there has to be some framework that allows relying parties to trust your assertions. I hope that we'll have some discussions around this problem at the upcoming IIW in May.

In the meantime, Kynetx has determined that before we leave beta, we will support social login. The pain has been too great. "UNCLE!" As a compromise, we will allow people to create accounts if they don't want to use social login and also provide a link to an explanation of why we are doing that.