NSTIC has very ambitious privacy goals. Today’s third-party login
solutions do not come close to meeting them. Privacy-enhancing
technologies that could meet them have yet to be deployed
successfully. And Facebook’s social login is preempting the
password-reduction benefit of NSTIC while severely reducing privacy.
Can NSTIC succeed?
We believe that the key to success is to build privacy-enhancing
technologies into the fabric of the Web, so that little effort is
required of users, relying parties, identity providers and social
sites to take advantage of them. In the white paper
we propose an NSTIC architecture based on extensions of two core
protocols of the Web, TLS and HTTP, and we describe a range of use
cases to show how it meets the goals of NSTIC.
The paper is still a first draft, and we hope you’ll help us improve
it by leaving your comments below.
I was happy to read Dmitry Shapiro’s blog post about Altly, a startup
that plans to challenge Facebook on privacy grounds. We need
competitors to Facebook for all the reasons mentioned by Dmitry, plus
a few others.
Facebook uses OAuth to implement social login (“Facebook Connect”, now
called “Login with Facebook”). OAuth is insecure, because it allows
an authorization code to be sent in the clear from Facebook to the
relying party (the application or site that features the Login with
Facebook button). If you log in with Facebook in a cafe, an attacker
may be able to intercept the code and use it to impersonate you.
Another problem with OAuth is that it requires prior registration of
the relying party with Facebook. This means that, if Login with
Facebook becomes ubiquitous, Facebook will have the unchecked power to
effectively disable most Web applications by revoking their
The registration requirement is also an additional barrier to entry
for Facebook competitors such as Altly. To implement “Login with
Altly” competitively, Altly will have to persuade over a million sites
and applications to register with it.
To address this competitive barrier we have suggested a social login
protocol, called PKAuth, that does not require prior registration. We
would be happy to work with Altly and any other social site (including
Facebook) that would be interested in implementing PKAuth, writing
open source libraries for relying parties, and codifying the protocol
as a Web standard.
Tonight I’m in Washington DC with Karen Lewison for the NIST IDTrust workshop, which takes place tomorrow and the day after (April 6-7). We’ll be showing a poster on PKAuth, our proposed social login protocol. By social login I mean the buttons that allow you to log in to Web applications with your identity at a social network such as Facebook, LinkedIn or Twitter, giving the application access to your social context at the site. I believe the term social login was coined by Janrain.
Today social login uses the OAuth protocol, which requires prior registration of the application with the social site. The registration process establishes a shared secret that the site later uses to authenticate the application, and provides the site with information that it later uses to identify the application to the user at it asks permission to grant the application access to the user’s social context.
The problem with that is that the social site gains the power to disable the application by revoking its registration. Why is that a problem? Because social login is becoming so popular that the day may come when all applications have to register with the dominant social site (currently Facebook) just to be able to authenticate their users. The dominant social site will then have the power to disable any Web application by revoking its registration. That would be bad for users, for applications, and for the dominant social site itself, which would no doubt face registration by multiple governments.
That’s why we are proposing PKAuth. In PKAuth registration is optional. A site will be able to require registration for special applications that need, say, administrative access to the user’s account, while not requiring it for others. Applications that only want to delegate user authentication should not have to register.
Instead of registration, PKAuth relies on the Web’s public key infrastructure, using the application’s ordinary SSL certificate to authenticate the application and identify it to the user.
We have just published a revised version of the PKAuth white paper and I will be talking about other benefits of PKAuth in future posts.