httpID: adding identity to standard HTTP requests

April 19, 2011 | 17 comments

This is a more technical post than I’ve been writing lately. I’m considering splitting out into two blog channels; let me know if you’d prefer this.

This is a request for comments and ideas. Please let me know what you think in the comments. Thanks!

One of the advantages of the decentralized social web, as opposed to a social network (federated or otherwise), is that identity can, theoretically, be shared with any web page, anywhere. That page doesn’t have to be running any particular software or provide any particular function; it should optionally be able to support identity-related features. That could then be used to tailor the page to the viewing user. (Of course, sharing identity should never be required, for security reasons.) This is part of three broad activities that I see as being part of the social web:

  • Publishing web content in an identity-aware way
  • Consuming web content in an identity-aware way
  • Sharing socially

Much of the decentralized social web development activity to date has been focused on the third point, and on reading and writing as part of a social web application like StatusNet or Diaspora. However, I’d like to look at the first two points with a view to make them web infrastructure, rather than features of a web application.

To achieve this, I’d like to be able to report, as an option, the identity of the person making an HTTP request, as part of the headers to that request. This might come from the browser itself, eg via an identity plugin, or it might come from a web-based identity proxy.

HTTP supports basic authentication, which involves sending a username and password, potentially in the clear. Out of necessity, we’ve moved beyond this, eg for things like API authentication. Often tokens, hashes and encrypted requests are included as extra header values to authenticate a request.

I’d like to use the same general principle for identifying a user. Here’s how it might work:

  1. The user visits a site for the first time. The browser sends a standard HTTP request. (Or, alternately, a HEAD request, if the site content isn’t required.)
  2. The site responds as normal, but with an extra HTTP header indicating that it’s identity-aware, including the URL of a handshaking endpoint. This will be ignored by clients that aren’t looking for it.
  3. If this is a standard browsing scenario, the user’s browser asks if he or she would like to share identity information with the site. For the purposes of this example, the user clicks “yes”. (This step can be left out if this isn’t a standard browsing scenario.)
  4. Via the handshaking endpoint from step 2, the user’s browser gives the site a public and private key, and a URL, through which it can access the user’s identity information as an XRD file (as in Webfinger). This is exactly the same as the public and private key system used to retrieve social information in points 5 and 6, using the same method. The site simply makes a signed request to the user’s identity URL, which can be anywhere.
  5. The browser receives public & private keys for use with this server only. These might be stored in the browser, or in some central identity store that all the user’s browsers access.
  6. Whenever the browser makes a request to the server, it adds extra headers using these keys (and HMAC-SHA-1), signing each request with the user’s identity until he or she says otherwise. It also sends a header to indicate when the user’s identity information was last changed, in order to prompt the site into obtaining new information if it needs to.
  7. If the site in point 4 is associated with a specific person (for example benwerd.com would be associated with Ben Werdmuller), he or she can use the public and private key generated in step 4 to browse the user’s site.

The publisher would get a list of users who have identified with the site, and, depending on their server or content management system, might add some of them to special access control groups that would allow access to different content. The next time the user visited the site, they’d see more privileged content. A notification would probably be sent to them to let them know this had happened, but this is out of scope for what I’m discussing here. (Perhaps notification methods could be shared as part of a user’s identity information?)

Conversely, the user’s XRD file containing their identity information can also change depending on who’s accessing it (as the requesting site always makes a signed request).

This system has a number of advantages:

  • It’s server and system agnostic. It simply uses the building blocks of the web.
  • It’s very easy to build for. Checking and setting HTTP headers are easy to do, and don’t require any front-end work like HTML parsing or JavaScript libraries. This makes it usable for APIs and feeds as well as web pages, and for clients that use web APIs as well as web browsers.
  • The web isn’t just a platform for people to read these days. This method doesn’t depend on anything visual.
  • You don’t need to control the root of a domain to make it work. If you install a script at http://yourdomain/~foobar/banana/hockeystick.php, the system will be happy there too.
  • It’s passive. There are no blockers if you don’t supply identity information – you just see something different.
  • It’s based on similar assumptions to WebID, but doesn’t require SSL certificates in the browser, and it’s as easy for a web app to implement as it is for browser software.

It incorporates the following assumptions:

  • Relationships are assymetrical. (Here, there’s a set of keys for each side of a relationship. If one side stops participating, perhaps by removing the other from an access control group, the other side is still valid.)
  • Privacy isn’t binary. (Everyone gets a different view on a given page or piece of data.)

Let’s call it httpID. I’m looking for feedback on the idea and process. Does it make sense? Have I missed something obvious? Let me know. If there are no major blockers, I’ll firm up the spec and create some libraries.

Geolocation in HTML 5 and Javascript

July 13, 2009 | 3 comments

HTML 5 – as-yet unreleased, but shaping up well – contains a specification for finding the current location of the user. The API, if your browser supports it and you grant the web application access, returns your latitude, longitude, elevation, speed and some other details. (If your web-capable device doesn’t have GPS, these details will be estimated using your IP address and other factors.)

A couple of weeks ago, I created a page to test this feature. If your browser is geo capable, this will reveal exactly what data about your location is being sent to web applications that ask for it.

If you’re a developer, here’s how I created the page.

(more…)

Microsoft Web Applications 2010 bring the cloud to the enterprise

In advance of the announcement later today, I Started Something have uncovered videos about the new Microsoft Office suite.

Microsoft Office turns to the web

As anticipated, Office 2010 includes web-based versions of applications contained in the suite. These don’t have the complete feature set, but are designed so that company employees can create and make changes to documents (including Word documents, Excel spreadsheets and Powerpoint presentations) on the road.

Web applications: now running in the enterprise

Centralized cloud applications have a difficult time gaining traction in most enterprise environments, and Microsoft have wisely taken note of this: it appears that the web-based versions are installed as part of Sharepoint. By doing this, they’ve allowed organizations to keep tight control of their data, as well as legitimizing web-based applications in the enterprise and revitalizing Sharepoint as an organizational product. In other words this is big news, with sweeping implications across the entire software industry.

Open standards must work for everyone

This is another reason why all open web standards must be browser agnostic. I always argue hard for a transparent browser: one that contains support for web standards, but doesn’t carry any extra baggage for any specific purpose. As web applications move into the enterprise, it’s important that a standard that works on a souped-up Firefox or Chrome browser also works great in Internet Explorer. By integrating web applications into Sharepoint, Microsoft are actually leading the industry, and have made themselves relevant on the web again. In doing so, they’ve opened up an important market, and that can’t be ignored.

Here’s a video introduction (although it keeps going down for me): See What’s New in Microsoft Web Applications 2010.

Making the most of the web, right now

June 10, 2009 | 1 comment

I believe a truly decentralized social web is required to fulfill the web’s potential as a platform for business collaboration, and I’m very interested in helping to push the technical and conceptual boundaries in that direction. I spend a lot of time on this blog writing about that, but I think it’s also important to remember that a huge amount is possible using the technologies, standards and ideas that we can currently pick up and use.

Creating a new web tool, or adapting one for your own use, can be a bit like pitching a movie: a lot of people come to me and say things like, “it’s like Delicious meets Youtube, but for the iPhone”. That’s great, and can result in some very interesting ideas, but I think it’s always best to go back to first principles and ask why you need the tool to begin with. My post The Internet is People addressed some key points on this:

  • Your tool must plug into an existing network of users, or be useful for user 1 (the first user to sign up). Delicious lets you save your bookmarks into the cloud; Flickr lets you easily upload photos so other people can see them. Both services come into their own when you connect with other users, but the core of the site is useful before you’ve done so. Facebook is different, but it had the Harvard real-world social network to plug in – and it now acts as a useful aggregation of your other activity on the web, which arguably is useful for user 1.
  • You can’t build a site and assume people will come and use it. It’s a lot of hard work, even when the technology is ready for launch; you need to lead by example, constantly adding content and using the site as you would like it to be used. Not to mention the hours you have to put in promoting it elsewhere.

The feature set itself should be tightly focused:

As each tool should focus on one particular network, or at least type of network, I’d argue that the exact feature set should be dictated by the needs of that network. Educational social networks might need some coursework delivery tools; a network for bakers might need a way to share bread recipes. The one common feature in any social network is people; even profiles may not be entirely necessary.

I mention at the end of the post that these principles were the guiding ideas behind the design of the Elgg architecture. They’re now the principles behind the tools and strategy I develop for my clients.

In this blog you’ll find lots of talk about new technologies, innovative approaches and the ethics of social media. These allow us to build interesting new tools, but they always sit on a firm foundation: the Internet is just people connecting and sharing with each other, and the purpose of web tools is to make that as easy as possible.

Next Page »