We’ve just sent to NIST Pomcor’s response to the NSTIC Notice of Inquiry with answers to questions 2.2 and 2.3.
NOI responses will eventually be posted at the NSTIC Web site. In the meantime, you can find ours here. Comments are very welcome. Please leave them below.
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’m back in San Diego after participating with Karen in the Internet Identity Workshop that took place last week in Mountain View. It was a great workshop, with many in-depth discussions of a broad range of topics. The most interesting ones for me were those concerning NSTIC.
I convened the session “How to meet privacy goals of NSTIC” where I presented the contents of the white paper “Achieving the Privacy Goals of NSTIC in the Short Term” and showed companion PowerPoint slides illustrating protocol steps.
There was a lively discussion. One of the points that were debated was whether a Web application that acts as relying party in a social login scenario (e.g. by featuring a button “Log in with Facebook”), could and/or should remain anonymous with respect to the social site (e.g. Facebook). Social login combines authentication and authorization, and the application not only is provided with the user’s identity relative to the social site, but also is given a level of access to the user’s account at the site.
Some people argued that the social site has to protect the user against malicious applications, and must therefore register applications that want to act as relying parties, so that it can revoke the registration of an application that misbehaves. I argued that the user should be allowed to take responsibility for the applications he or she wants to use, that requiring registration gives the social site too much power over applications, and that the identity of the relying party should not be revealed to the social site as a matter of user privacy.
This is an important debate that will no doubt continue. It highlights the contrast between current technology and one of the privacy goals of NSTIC.
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.
