Re: RDFAuth: an initial sketch

Hi Valentine,

It's quite late here, and I just came back from the pub, but I'll  
nevertheless try to answer this  as best as I can. :-)

I think your idea is good, and you clearly weigh the pros and cons.  I  
would like to add the following in defense of the idea being proposed  
here.

First, I think your idea breaks down I think as networks of trust  
start to grow. Indeed you mention this as a point of concern. Imagine  
that Juliette's foaf server decides to trust all the friends of her  
friends up to a depth of three. This could end up being creating a  
network of over a 1000 people, that changes dynamically. In that case  
her server would have to keep regenerating the encrypted foaf file  
very regularly. The bigger the network the more often it would have to  
be encrypted...

Secondly I don't think what is proposerd here should be very difficult  
to set up to tell the truth. RDFAuth is simpler than openid - no need  
for an authentication server. My guess is that with the help of the  
Redland RDF library, it should be a few small perl scripts to implement.

But thanks for adding this point to the discussion. It was something I  
had wondered about at one point.

Others may have more knowledge of PGP and be able to shed more light  
on your thoughts.

all the best from Fontainebleau, France

One thing that is nice is that RDFAuth should spread the use of PGP,  
and the idea of decentralised networks of trust that comes with it. I  
am all for decentralized networks. So once PGP  (or other similar  
public key cryptography systems) become widely used, solutions like  
the one you propose should be a lot easier to deploy :-)

	Henry

On 27 Mar 2008, at 20:12, Valentin Zacharias wrote:
>
>
> 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
>
>
>
>