[foaf-dev] RDFAuth_Sketch: what are we trying to solve

Story Henry henry.story at bblfish.net
Tue Apr 1 12:17:04 BST 2008 

Dan Brickley asked the following question:
 > I'd like to see a 1 page "here's the problem we're trying to solve"  
that doesn't itself specify any protocol design.
 > Borrowing from Stefan Decker's page at http://www.stefandecker.org/the-heilmeier-catechism.html 
  quoting George Heilmeier:

I had partly answered some of these in the blog post on (the  
controversially named) RDFAuth [1]
But let me organize them as suggested by Dan:

  1. What is the problem, why is it hard?
  ---------------------------------------

The problem can be stated either in general terms as a result of  
requirements on Linked Data or by giving a specific example of a  
Linked Data application. Let me start with a concrete example: Social  
Networks.

In order to break out of the current Social Networking (SN) data  
silos, where each SN is a world into itself and users cannot link to  
users in other SN, we require Linked Data. This can be built using  
vocabularies such as FOAF in an open manner and one can use these to  
build Social Network browsers such as Beatnik [2] and servers such as  
Knowee [3]. Social Networks users though demand some levels of  
privacy. They want some information to be protected, available only to  
subgroups of people, to be determined by them. For example I may only  
wish to allow friends of my friends to have access to my network of  
friends. Strangers may only get my basic business information. Or you  
may wish only members of your (extended) family to have access to your  
family tree.

   In order to make privacy controls possible in a Distributed  
Network, Resource Servers needs a way to identify the User Agent  
Owner. This has to itself be done in a distributed ( non centralized )  
way if we are not to create another bottleneck or control point.

   A Distributed Social Network such as the one here described will be  
very decentralized. Every one of Tim Berner's Lee's acquaintances, as  
described in his foaf file, has a URL on a different domain. If when  
browsing the network of Tim's acquaintances a User Agent had to log  
into each service with a new password the software would be of no  
interest to anyone. So the protocol cannot assume that the initial  
authentication cost can be large because it can then be recovered over  
a long session. In fact with protected resources the authentication  
cost has to be very low, because it may be difficult for a User Agent  
to know in advance if it has access to a resource or not.

   The Resource Server may not know the User Agent Owner by name, but  
may wish to determine whether to allow the User Agent access by  
understanding the owner's relation to other people in a Social  
Network. It must be possible for the protocol to find a flexible  
description of the User Agent Owner.

   If privacy controls are to be important then one needs to think a  
little wider. It is not just that the Resource Server wishes to  
protect information about the Resource Server Owner. The User Agent  
Owner may also not wish everyone to know what software he is using or  
whom he is asking  protected information about.

  2. How is it solved today?
  --------------------------

  I don't think this has been solved today.

  The closest protocol I know that attempts to create a single sign on  
is OpenId. It makes it possible for a person to have one single global  
identifier and log onto any service on the web. The problems of this  
protocol are ( as described in [1] )
  - the cost of authentication is very high. It was designed with the  
limitations of current web browsers in mind. As a result an  
authentication request requires the browser owner to log in with his  
openid.
  - The information about the User Agent available to the Web Service  
is quite limited. It can only be property value pairs. Neither is it  
easily extensible.
  - It does not work well with Semantic Web standards
  - It does not fit well into web architecture (REST)
  - the authentication server, and attribute server are points of  
control. The owner of these will know what services the User is  
logging into. Though one can deploy one's own attribute server this is  
not easy at all. (Many services seem to only accept ids with specific  
authentication servers)

   Another protocol, oAuth that has some relevance, requires services  
to agree before hand on how authorization can work on a case by case  
basis. This is not realistic in an open distributed social network.  
Things have to be much more flexible than this.


  3. What is the new technical idea; why can we succeed now?
  ----------------------------------------------------------

   As with OpenId we use a URL to identify a Person (or more generally  
any Agent) globally. But instead of requiring an Identity server we  
use PGP asymmetric key cryptography to identify the User Agent Owner.  
This is similar to the mutual authentication using client certificates  
of https, except that we link the client certificates into a Web Of  
Trust tied together with Linked Data and we publish the public key at  
a URL accessible via the User Id. The solution is RESTful and can make  
use of the Network Effect of Linked Data. We build on well established  
standards: HTTP for the protocol, REST for the architeture, URI for  
the naming, RDF for the semantics, PGP for encryption.

Why can it succeed now? Semantic Web tools have now grown to be of  
good enough quality to develop this in pretty much every language and  
on any platform. The Social Networking Data Silo problem is very real,  
and will soon be felt by millions of people [4]. These new  
applications don't need to work around web browser limitations either.  
These applications can be built from scratch, and so they can develop  
the protocols that are needed to solve this problem.


  4. What is the impact if successful?
  ------------------------------------

   We have the first hyperdata applications for the masses: open  
distributed social networks browsers and servers.

  5. How will the program be organized?
  -------------------------------------

   It has to be open, patent free and open sourceable. The details  
have to be determined.

  6. How will intermediate results be generated?
  ----------------------------------------------

   Beatnik, Knowee, Tabulator, openqabal can be used to test the  
protocol.

  7. How will you measure progress?
  ---------------------------------

    By 100s of thousands of users joining the network.

  8. What will it cost?
  ---------------------

    To be determined by people with some experience in this.


	Henry Story


NOTES
=====

[1] http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword
[2] https://sommer.dev.java.net/ search the page for Beatnik
[3] http://knowee.org/
[4] http://blogs.sun.com/bblfish/entry/2008_the_rise_of_linked
     but also the Economist article
     http://www.economist.com/business/displaystory.cfm? 
story_id=10880936
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2429 bytes
Desc: not available
Url : http://lists.usefulinc.com/pipermail/foaf-dev/attachments/20080401/88159912/smime.bin

More information about the foaf-dev mailing list