Bitwacker Associates

Several weeks ago Leigh Dodds ended his post Thoughts on Linked Data Business Models with the following comment:

…From a technical perspective I’m interested to see how well protocols like OAuth and FOAF+SSL can be deployed to mediate access to licensed Linked Data…

Leigh asks a very subtle question, because choosing between OAuth and FOAF+SSL (I believe) has profound implications on different levels. In short, I believe that OAuth is more suited for organizations that will establish formal licenses with their community of users, and FOAF+SSL, being more in the peer-to-peer, “Web of Trust” vein, may be more suited to ad hoc access control with user webs where the users have particular shared, but not open, interests. In both cases, work must be done to reify licenses into actionable policies that can be implemented by services.

A typical OAuth-based access control use case might be controlling access to a particular value-added, protected data set that has been licensed to a consumer-facing provider. Users, by way of the client service they have authenticated with, experience this data. The OAuth protocol ensures that only the users of the authenticated partners of the protected dataset provider can access the data. Example: A major business journal decides to publish its data in a way that resembles data.nytimes.com but is restricted to paying customers. The protected service is operated as a separate entity; users’ clients gain access to the published data after first authenticating with the “parent” site. As an added measure of privacy (built into the protocol) users’ credentials do not pass on to the data service.

The credentials required for OAuth-based access control are no different than what we see between primary service like Facebook and Twitter and their various value-added partners; the user has an account with the parent service, and will either have separate credentials for that service or have it linked to their OpenID.

Note: This application of OAuth does not really take full advantage of its capabilities. Typically the relying service will ask for read or read/write access to certain user attributes from the user’s primary service — social networking platforms like Twitter or Facebook — in which the user has the choice to grant or deny access to their records in those services. Although we can imagine such applications playing within the linked data world, in today’s post I’d like to focus more on a third-party, valued-added data provider rather than a consumer.

FOAF+SSL is not harder (at least for the user) and is no less secure, but is definitely different! The reader is referred to Henry Story’s many blog posts and this excellent presentation (listen to the audio!) for details, but the basic idea is this: the requesting user is granted access if they have sufficient status in a social graph maintained at the server. “Sufficient status” is my terminology, and means that if the user’s distinguishing URI (their WebID) meets certain conditions within a (e.g.) FOAF graph on the server, such as “is known by two or more members,” then the user will be granted access. Update: As Henry notes in his follow-up comment, his post Sketch of a RESTful photo Printing service with foaf+ssl (Oct 2009) provides a great example of applying FOAF+SSL in this way.

The FOAF+SSL approach is highly original and attractive for a number of applications because it naturally “fits” with the notion of dynamic access control based on community membership, but it seems like it must be stretched a bit to be applied to access control based on explicit terms that have been codified in a license. Still, I believe it can be made to work, and some very novel applications are possible; for example, I can imagine some pretty cool implication-based access control policies! One possible downside is that although I’ve seen many discussions detailing the client/server interactions — thinking that I believe is necessary — I haven’t seen much exploration of the “server-side” policies.

Spending time thinking about FOAF+SSL has naturally brought to mind the policy-aware web (and related) research of Lalana Kagal (MIT CSAIL) and others. The current post only concerns access control and assumes an out-of-band license over the data; a future post will explore how — and whether! — we can determine if an organization’s data usage is complies with the terms under which they’ve licensed it, in a fashion similar to what Kagal and her co-authors Oshani Seneviratne and Tim Berners-Lee described in Policy Aware Content Reuse on the Web. For more general background, readers are encouraged to read The Semantic Web and Policy by Kagal, Berners-Lee and Jim Hendler.

Other updates:

• In his post Signing FOAF files: FOAF files as certificates Bruno Harbulot considers in some depth how to create a FOAF-based Web-of-Trust securely, in a similar way to PGP. Bruno also mentions Jeremy Carroll’s related work on the topic, Signing RDF Graphs.
• The ESW Wiki lists many resources for FOAF+SSL, including this detailed FOAF+SSL HOWTO.
• WebAccessControl (also on the ESW Wiki) describes a “decentralized system for allowing different users and groups various forms of access to resources where users and groups are identified by HTTP URIs.” It uses FOAF+SSL for authentication. One of the listed implementations is the mod_authz_webid Apache WebID authorization module.