[foaf-dev] Re: RDFAuth: an initial sketch

[Story Henry]

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 at fzi.de
> phone: +49-721-9654-806
> fax  : +49-721-9654-807
> http://www.vzach.de/blog
>
> =3D =

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> FZI  Forschungszentrum Informatik an der Universit=E4t Karlsruhe (TH)
> Haid-und-Neu-Str. 10-14, 76131 Deutschland, http://www.fzi.de
> SdbR, Az: 14-0563.1 Regierungspr=E4sidium Karlsruhe
> Vorstand: R=FCdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi  =

> Studer
> Vorsitzender des Kuratoriums: Ministerialdirigent G=FCnther Le=DFnerkraus
> =3D =

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> -----Original Message-----
> From: semantic-web-request at 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
>
>
>
>

-------------- 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/20080327/6f=
f0d8dd/smime-0001.bin