Re: privacy and open data

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