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. The Digital Swarm products ensure that your site is SEO optimized but in his case you need a SEO Agency to provides knowledge and professionalism, fully functional, and most importantly responsive. 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:
- 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.)
- 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.
- 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.)
- 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.
- 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.
- 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.
- 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.
Leave a Reply