Oracle Blog

Don't panic !

Identity in the Browser, Firefox style

Mozilla's User Interface chief Aza Raskin just put forward some interesting thoughts on what Identity in the Browser could look like for Firefox. As one of the Knights in search of the Golden Holy Grail of distributed Social Networking, he believes to have found it in giving the browser more control of the user's identity.

The mock up picture reproduced below, shows how Firefox, by integrating identity information into the browser, could make it clear as to what persona one is logged into a site as. It would also create a common user interface for allowing one to log in to a site under a specific Identity, as well as allow one to create a new one. Looking at the Weave Identity Account Manager project site one finds that it would also make it easy to generate automatically passwords for each site/identity, to sync one's passwords across devices, as well as to change the passwords for all enabled sites simultaneously if one feared one's computer had fallen in the wrong hands.
These are very appealing properties, and the UI is especially telling, so I will reproduce the main picture here:

The User Interface

One thing I very strongly support in this project is the way it makes it clear to the user, in a very visible location - the URL bar -, as what identity he is logged in as. Interestingly this is at the same location as the https information bar, when you connect to secure sites. Here is what URL bar looks like when connected securely to LinkedIn:

One enhancement the Firefox team could immediately work on, without inventing a new protocol, would be to reveal in the URL bar the client certificate used when connected to a https://... url. This could be done in a manner very similar to the way proposed by Aza Raskin in the his Weave Account manager prototype pictured above. This would allow the user to

From there it would be just a small step, but one that I think would require more investigation, to foaf+ssl enhance the drop down description about both the server and the client with information taken from the WebID. A quick reminder: foaf+ssl works simply by adding a WebID - which is just a URL to identify a foaf:Agent - as the subject alternative name of the X509 certificate in the version 3 extensions, as shown in detail in the one page description of the protocol. The browser could then GET the meaning of that URI, i.e. GET a description of the person, by the simplest of all methods: an HTTP GET request. In the case of the user himself, the browser could use the foaf:depiction of the user, to display a picture of him. In the case of the web site certificate, the browser could GET the server information at its WebId, and display the information placed there. Now if the foaf file is not signed by a CA, then the information given by the remote server about itself, should perhaps be placed on a different background or in some way to distinguish the information in the certificate, from the information gleaned from the WebId. So there are a few issues to work on here, but these just only involve well developed standards - foaf and TLS - and some user interface engineers to get them right. Easier, it seems to me, than inventing a whole protocol - even though it is perhaps every engineers desire to have developed a successful one.

The Synchronization Piece

Notice how foaf+ssl enables synchronization. Any browser can create a public/private key pair using the keygen element, and get a certificate from a WebId server, such as foaf.me. Such a server will then add that public key as an identifier for that WebId to the foaf file. Any browser that has a certificate whose public key matches that published on the server, will be able to authenticate to that server and download all the information it needs from there. This could be information

about the user (name, depiction, address, telephone number, etc, etc)

a link to a resource containing the bookmarks of the user

his online accounts

his preferences

Indeed you can browse all the information foaf.me can glean just from my public foaf file here. You will see my bookmarks taken from delicious, my tweets and photos all collected in the Activity tab. This is just one way to display information about me. A browser could collect all that information to build up a specialized user interface, and so enable synchronization of preferences, bookmarks, and information about me.

The Security Problem

So what problem is the Weave team solving in addition to the problem solved above by foaf+ssl?

The weave synchronization of course works in a similar manner: data is stored on a remote server, and clients fetch and publish information to that server. One thing that is different is that the Weave team wish to store the passwords for each of the user's accounts onto a remote server that is not under the user's control. As a result that information needs to be encrypted. In foaf+ssl only the public key is stored on a remote server, so there is no need to encrypt that information: the private key can remain safely on the client key chain. Of course there is a danger with the simple foaf+ssl server that the owner of the remote service can both see and change the information published remotely depending on who is asking for it. So an unreliable server could add a new public key to the foaf file, and thereby allow a malicious client to authenticate as the user in a number of web sites.

It is to solve this problem that Weave was designed: to be able to publish remotely encrypted information that only the user can understand. The publication piece uses a nearly RESTful API. This allows it to store encrypted content such as passwords, identity information, or indeed any content on a remote server. The user would just need to remember that one password to be able to synchronize his various Identities from one device to another. There is a useful trick that is worth highlighting: each piece of data is encrypted using a symmetric key, which is stored on the server encrypted with a public key. As a result one can give someone access to a piece of data just by publishing the symmetric key encrypted using one of her public key.

Generalization of Weave

To make the above protocol fully RESTful, it needs to follow Roy Fielding's principle that "REST APIs must be hypertext driven". As such this protocol is failing in this respect in forcing a directory layout ahead of time. This could be fixed by creating a simple ontology for the different roles of the elements required in the protocol: such as public keys, symmetric keys, data objects, etc... This would then enable the Linked Data pattern. Allowing each of the pieces of data to be anywhere on the web. Of course nothing would stop the data from being set out the way specified in the current standard. But it immediately opens up a few interesting possibilities. For example if one wanted a group of encrypted resources to be viewed by the same group of people, one would need only one encrypted symmetric key each of those resources could point to, enabling less duplication.

By defining both a way of getting objects, and their encoding, the project is revealing its status as a good prototype. To be a standard, those should be separated. That is I can see a few sperate pieces required here:

An ontology describing the public keys, the symmetric keys, the encrypted contents,...

Mime types for encrypted contents

Ontologies to describe the contents: such as People, bookmarks, etc...

Only (1) and (2) above would be very useful for any number of scenarios. The contents in the encrypted bodies could then be left to be completely general, and applied in many other places. Indeed being able to publish information on a remote untrusted server could be very useful in many different scenarios.

By separating the first two from (3), the Weave project would avoid inventing yet another way to describe a user for example. We already have a large number of those, including foaf, Portable Contacts, vcard, and many many more... I side for data formats being RDF based, as this separates the issues of syntax and semantics. It also allow the descriptions to be extensible, so that people can think of themselves in more complex ways that that which the current developers of Weave have been able to think of. That is certainly going to be important if one is to have a distributed social web.

Publishing files in an encrypted manner remotely does guard one from malicious servers. But it does I think also reduce the usability of the data. Every time one wants to give access to a resource to someone one needs to encrypt the symmetric key for that user. If the user looses his key, one has to re-encrypt that symmetric key. By trusting the server as foaf+ssl does, it can encrypt the information just in time, for the client requesting the information. But well, these are just different usage scenarios. For encrypting password - which we should really no longer need - then certainly the Weave solution is going in the right direction.

The Client Side Password

Finally Weave is going to need to fill out forms automatically for the user. To do this again I would develop a password ontology, and then markup the forms in such a way that the browser can deduce what pieces of information need to go where. It should be a separate effort to decide what syntax to use to markup html. RDFa is one solution, and I hear the HTML5 solution is starting to look reasonable now that they removed the reverse DNS namespace requirement. In any case such a solution can be very generic, and so the Firefox engineers could go with the flow there too.

I think Gnome Tracker also has a C triple store implementation. It might also be possible to on the Linux desktop at least use a triple store exposed over dbus so that firefox would share it's data with the rest of the OS.

Regarding the final section of the article, "RDF! You crazy?". It seems like the technology used in MIT's RDF browser Tabulator would be more appropriate tech than the virtuoso sql-lite option you mention. Tabulator's code is all open-source, and it has a JS based SPARQL implementation, and includes code for flat file RDF serialisation, for persisting RDF in Firefox. And it is a FF plugin, so probably easier to port, I am not sure but i have a feeling that the code-base is definitely "lighter" than virtuoso ;)

The problem with Kerberos is that it's a very centralised way of managing identities, even when federating multiple realms. You also need both the server and the user to be registered with the KDC (same realm or same federation).
This goes against the principle of the global, decentralised identifier.

Yes, kerberos is already supported by browsers via SPNEGO using the Negotiate header. That is part of the reason I'm viewing it as low hanging fruit!

What is \*not\* already supported in current browsers is a good interface enabling a user to manage a collection of identities. The KIM API I linked to above describes how client tools such as browsers could build such an interface.

This would be a great way to take authentication out of the browser frame and instead put it in the browser 'chrome' as this post suggests.

I agree with your observation that federation between kerberos realms is an impractical way to handle authentication at internet scale. That is best left to organizations that actually have some real-world trust relationship.

Given that fact, I think what I'm describing is a great way for a user to authenticate to an identity provider, but the communication between that identity provider and another service acting as an identity consumer would in most cases have to be accomplished using some other protocol.