- From: Benjamin Nowack <bnowack@semsol.com>
- Date: Tue, 25 Mar 2008 15:51:08 +0100
- To: Story Henry <henry.story@bblfish.net>, foaf-dev Friend of a <foaf-dev@lists.foaf-project.org>, Semantic Web <semantic-web@w3.org>
Hi, Here is the approach I intend to take in the knowee project[1] (called "RDFAuth", still not fully fleshed-out): * Which (parts of) resource descriptions are served to which groups is not public, and not part of the spec, but defined in the app context. * a (partly) protected resource description is served with an additional HTTP Basic Auth (WWW-Authenticate) header to indicate that more information is available. (As has been pointed out on this list, WWW-Authenticate can be sent along a "200 OK".) * A client can send a token (as username) and a personal identifier (as password), encoded as a BasicAuth response. * Based on this information, the server determines the RDFAuth endpoint associated with the sent identifier (via "follow your nose" or a local query of already existing/trusted information), verifies the token against the RDFAuth endpoint, and decides whether the protected information should be served or not, based (again) on available/trusted RDF data and internal rules (e.g. whether the identified client is member of a certain foaf:Group etc.). That's as simple and close to existing mechanisms as I could get it. Unlike OpenID and oAuth, there is no need for redirects, so RDFAuth works for non-browser agents, which was my main requirement. A token can also be generated before the actual request is being made, to further reduce the amount of HTTP requests. The identifier can be an OpenID, a homepage, or some other RDF-friendly personal URI. The token consists of three (encoded) parts: the target realm, the RDFAuth endpoint that generated the token, and the actual token value. What's still missing is the RDFAuth endpoint's protocol, i.e. how exactly a token should be verified, and how the reponse should look like. Best, Benji [1] http://knowee.org/ -- Benjamin Nowack http://bnode.org/ On 25.03.2008 11:12:07, Story Henry wrote: >Dear Semantic Web community, > > We are looking for a way to solve some simple privacy problem in RDF. >We have explored this previously on the foaf list [1], but would like >to have the input from the larger community on this issue as the >problem is a generic one beyond the bounds of foaf. > >We have a simple use case. Foaf allows its users to create open >distributed social networks. This is a addressing a real problem 100s >of millions of people are going to be wanting solved in the near >future. But currently all the data is open for all to see. This is ok >for us researchers, but many people would like some of their >information to be available to select groups of individuals. I know >many for example who are happy to publish information about their >professional life, but would rather their family network remain >available only to their family. > >What is needed now is a way to also enable people to limit who can see >what information about them, in a way compatible with the constraints >of REST and Linked Data. I can think of a couple of methods: > > 1. either return different representations of the requested >resource depending on who is viewing the information > 2. have different resources be responsible for different subsets of >the data and create rdf:seeAlso links between them. Some of these >resources would only be accessible to certain user agents (UA). > >In both cases there has to be some way of identifying the authority of >the UA. As OpenId is easy to understand, let us use that for the >moment. So as an example one could develop an rdf vocabulary to say >the following [2][4] > ><public> rdfs:seeAlso <protected> . > ><protected> readableBy SomeGroup; > login [ = </login>; > a OpenidLoginService ]. > >SomeGroup could be defined for example as being all the friends of >one's friends with openids specified by their foaf file (see the work >done by DIG [3]) > >Is there a working group developing such a vocabulary already? Is >there a standard here we should develop upon? > >Given that this information is to be read by new types of UserAgents >that need to be limited by the functionality of current web browsers, >it is also quite possible to imagine much simpler protocols than >openid. Off the top of my head I thought of a way of using foaf ids, >linked to foaf files, linked to pgp keys to create a much quicker, >cleaner and resource oriented authentication method. see [2] > >It seems to me that it should be quite easy to get something working >here. > > > Yours sincerly, > > Henry > > >[1] http://lists.foaf-project.org/pipermail/foaf-dev/2008-January/008793.html >[2] http://lists.foaf-project.org/pipermail/foaf-dev/2008-January/008820.html >[3] http://dig.csail.mit.edu/breadcrumbs/node/206 >[4] Note that 1. is really a special case of 2. where there is only >one resource that returns different representations depending on the >authority of the user agent. > ><> readableBy SomeGroup; > login [ = </login>; > a OpenidLoginService ]. > >Home page: http://bblfish.net/ >
Received on Tuesday, 25 March 2008 14:51:46 UTC