W3C home > Mailing lists > Public > semantic-web@w3.org > March 2008

RE: RDFAuth: an initial sketch

From: Valentin Zacharias <Zacharias@fzi.de>
Date: Thu, 27 Mar 2008 20:12:33 +0100
Message-ID: <0EF30CAA69519C4CB91D01481AEA06A00BDA9E@judith.fzi.de>
To: "Story Henry" <henry.story@bblfish.net>, "foaf-dev of a Friend" <foaf-dev@lists.foaf-project.org>, "Semantic Web" <semantic-web@w3.org>


Hi!

All approaches I've seen discussed in this thread (some very interesting!)
break the 'web friendliness' of FOAF, with these approaches I can no longer
treat a FOAF file like an html file but need quite complex software
mediating the access to the foaf file. This may be the way to go, but we
could also approach the problem from a totally different angle:

By the time i create/change the foaf file I know who should be able to
access it; and lets for a moment assume that these people are identified by
a foaf file that contains a public key. Then i could simply use public key
encryption and include for everyone that should be able to see private data
this data encrypted with his/her public key. Then I get a (pretty large)
file that i could treat like any foaf file and that would not need a
software mediating access to it. Anyone authorized to see (some) private
data would have the private key to decrypt it. 

So, this approach has some serious drawbacks 
 * the foaf file is computational expensive to create and change (but
computers are getting faster all the time and this is even a task that is
naturally paralizable for tomorrows many core computers)
 * it could be large, but don't think this would be too large to handle (at
least not for the friends and faimily scenario) and it could be split up
into separate files easily
 * granting access to groups that are not characterised by a key pair and
that have shifting memberships is hard (impossible?)
 * If someone changes his key pair (e.g. because it has been compromised) I
will not immediately recognize this. 

On the plus side it saves us from lots of complexity in safeguarding private
foaf files and mediating access to parts of it. 

Nevertheless this could be the simplest thing that can work - or what do you
think?


greetings from karlsruhe

valentin

--
email: zacharias@fzi.de
phone: +49-721-9654-806
fax  : +49-721-9654-807
http://www.vzach.de/blog

=======================================================================
FZI  Forschungszentrum Informatik an der Universität Karlsruhe (TH)
Haid-und-Neu-Str. 10-14, 76131 Deutschland, http://www.fzi.de
SdbR, Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
=======================================================================

-----Original Message-----
From: semantic-web-request@w3.org on behalf of Story Henry
Sent: Thu 3/27/2008 1:06 PM
To: foaf-dev of a Friend; Semantic Web
Subject: RDFAuth: an initial sketch
 
Hi,

I would like to put the following forward as a sketch of what is  
needed to allow a resource to return different representations  
depending on the identity of the requester. We are looking for some  
security experts and others to help out here.

There may be other standards that can be used, but it would help to  
see how far one can get with a very clean system to start off with. At  
least this should help understand what is needed.

The idea is simple. We have 4 resources here.

1. A Semantic Web client owned by Romeo ( something like Beatnik,  
Tabulator or Knowee )
2. Juliette's foaf file resource controlled by a slightly intelligent  
web service (one that knows to show which parts of the graph to show  
to whom)
3. Romeo's foaf file (perhaps also controlled by an intelligent web  
service, but there is no need for this here)
4. Romeo's public key. This could be part of the foaf file, but  
assuming that it does not change that often, it would be better placed  
at a separate resource in order to be more easily cacheable
Received on Thursday, 27 March 2008 19:13:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:21 GMT