Francisco Corella – Page 13

Must the Site know the Application in a Social Login?

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.

Browsing Real Time Search Results

We have just released a cool new feature of Noflail Search. You can now watch how results change in real time as you use the page menu to browse a result set.

When you leave a page, the results in that page become “old”. Old results are shown with a dimmer grey background, and a page that only has old results has a dimmer grey button in the page menu. Noflail Search checks for new results when you click any button in the page menu. If a page that you’ve already visited has new results, its button is black rather than grey, and the new results are highlighted within that page by a brighter background.

You can control how the result set changes. You can make the results in the current page old without going away by clicking on a button for the current page in the page menu. You can go away without making the results old by holding down the shift key while clicking. And you can stop new results from coming in by freezing the result set. A short YouTube video tutorial goes over all this.

Noflail Search is a multisearch engine, that lets you run a query on many different search engines. It can run a query on an engine’s site and display results in pop-up window as rendered by the engine’s front-end. But for some engines that have a Web API, Noflail Search gets results by default through the API and displays them using the Noflail Search front-end. The new real time feature works for all those engines. I suggest that you try it out on the results provided by the real time search engine Topsy, which change fast for trending topics. But even results from a more traditional search engine such as Bing can be seen changing as you browse them.

This new feature solves an open problem in real time search: how to browse results that change frequently.

Some real time search engines, such as Twitter search (at twitter.com or search.twitter.com) and Google/Realtime (at google.com/realtime) show results ranked by recency in a constantly scrolling display. This shows how results change, but it is not very practical, since the user has to watch many irrelevant results go by before catching a relevant one.

Other real time search engines, such as Topsy (at topsy.com), rank results by both recency and relevance, with a traditional paginated user interface. This makes it easier to find relevant results, but it may be difficult to keep track of what results you have seen. If a result moves from page 2 to page 1 as you go from page 1 to page 2, the user may miss it.

Twitter and Google/Realtime address this open problem by also showing, besides the fast scrolling display, three older more relevant results. This concedes that they do not know how to blend recency and relevance.

Our new feature makes it possible to rank results by a balanced combination of recency and relevance and to use a paginated user interface, while at the same time showing how results change in real time and helping the user keep track of what results have been seen.

This new feature derives from research funded in part by grant 1013594 from the National Science Foundation.

We have patents pending on this and other aspects of Noflail Search.

Thoughts about NSTIC after NIST IDtrust Workshop

I’m back from participating in the NIST IDtrust workshop with Karen Lewison. This was the 10th in a series, but the first I’ve attended. I learned a lot. Presentations and panels can be found online at http://middleware.internet2.edu/idtrust/2011/program.html.

Jeremy Grant made a presentation on the National Strategy for Trusted Identities in Cyberspace (NSTIC). He said the President will make an announcement on April 15, and there will soon be workshops to solicit ideas from the private sector; we are looking forward to that. There was interesting follow up during the workshop. A participant from a financial institution told us in a private discussion that he doubted his institution would be able to delegate authentication to an external identity provider, due to security and liability concerns. Paul Donfried gave a talk about Verizon’s Universal Identity Services. Asked about the business model for providing identity services he said that the identity provider could charge the relying party for a high level of assurance. Elaine Newton, in one of her presentations, talked about NSTIC, and about the Multi-Factor Authentication Initiative.

In the long flight back to San Diego, Karen and I did some brainstorming about all this and we came up with three thoughts.

The first thought is that double redirection would help solve many of the technical challenges of NSTIC. By double redirection I mean the following: instead of the Relying Party (RP) relying on a certificate signed by an Identity or Attribute Provider (IAP) and submitted by the browser, the RP redirects the browser (via a 302 redirect or a form submission) to the IAP, which authenticates the user and redirects the browser back to the RP, passing a token or handle that the RP can use to obtain identity and attribute information from the IAP. Thus the RP relies on the IAP not only to provide credentials to the user, but also to verify credentials presented by the user.

This provides a lot of flexibility. Any RP can gain the high level of assurance provided by complex credentials (e.g. multi-factor authentication including one-time passwords or revocable biometrics) without having to implement verification procedures for those credentials. The user can control what attributes the IAP will disclose to the RP without having to juggle many attribute certificates. The RP can use multiple IAPs, providing different attributes, in the same transaction. And last but not least, Paul Donfried’s business model becomes possible, since the IAP is aware of the transaction.

There have been quite a few double redirection protocols: MS Passport (now Windows Live ID), SAML Browser SSP Profile, Shibboleth, OpenID, OAuth, etc. Some of them have serious security issues, but the PKAuth protocol that we presented in our poster provides strong security, without requiring the IAP and the RP to have prior knowledge of each other. PKAuth is designed for social login, so it has the potential to unify the goals of NSTIC with the requirements of social networks.

The second thought is to use what we could call “vacuous certificates”. By a vacuous certificate I mean a certificate that contains no information about the subject of the certificate. It contains only a public key and CA information, including revocation information. The CA that issues the certificate is not an identity provider, it is just, so-to-speak, a revocation provider. The user acquires a vacuous certificate, and registers it with any number of identity providers, which associate identity data or attributes with the certificate. In other words, the identity data and attributes are metadata external to the certificate, rather than data internal to the certificate.

This provides the obvious benefit that the user only needs to keep track of one private key and certificate. Also, no certificates need to be revoked and reissued when identity data or attributes change. And this also seems to solve the liability problem: the user can register the vacuous certificate with his or her bank, so that the bank can be the identity provider for its own transactions. In a transfer of funds between two banks, both banks would be identity providers for the same transaction.

The third thought goes back to double redirection. NSTIC emphasizes both security and privacy. For some transactions, the IAP must authenticate the RP, for security reasons. For other transactions, the IAP must not know the identity of the RP, for privacy reasons. Direct presentation of credentials by the browser to the RP ensures the latter; but it might be possible to enjoy the benefits of double redirection while keeping the RP anonymous. That would require an extension of the HTTP protocol to support a form of double redirection where the browser hides the identity of the initiator of the transaction (the RP).

Social Login without Application Registration

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.

Welcome to the Pomcor Blog

Welcome to the Pomcor blog! This will be a continuation of the Noflail Search blog previously hosted on wordpress.com, extended to also cover our research on other areas of Web technology, including security and social login.

We have recently concluded Phase I of an ambitious NSF SBIR project and we will soon be reporting on several exciting results from that work. Stay tuned!