[rdfweb-dev] FOAF & Privacy
scott at dragonflylodge.org
Fri May 7 19:16:33 UTC 2004
B.K. DeLong wrote:
> In order to deal with privacy and trust, it looks like the master FOAF
> file of any person needs to be encrypted with their public key -
> provided they have one. There's too much information that could be
> incredibly useful that the user needs to be able to set TRUST with
> RELATIONSHIPS to share certain info. Not only with People....but with
> Groups and potentially online accounts.
> So it's almost like we need some sort of Java application that manages
> one's FOAF and has the ability to encrypt and decrypt based on the
> user's private key
You've identified an excellent design goal for an application I think we
absolutely need, but I'd suggest the actual design go in a different
direction. :) (For one thing, what happens when two disjoint groups
have access to the same sensitive bit of your FOAF file? Does it get
encrypted twice with different keys? With ten or twenty groups, does it
get encrypted ten or twenty times?)
Access control on FOAF data will be required to greater or lesser degree
for everyone. Rather than encrypting the data and putting it out there
for almost everyone to throw away, I suggest only giving the data to
those who have permission to see it. So instead of having a simple web
server serving a simple file with really complex encryption to limit
access, you have a smart server serving RDF triples with a simple
public-key authentication/access control system to limit access.
Marc Canter wrote:
>I know that many here felt that FOAF was a persistent store of dynamic processes, agents and 'intelligent' that would then get used by other dynamic processes. That kind of shook up my world, and made mne think "Gee how could we be so out of sync?"
>FOAF immediately seemed to me to be the world standard for "About Me" pages. That's how I've always thought of it. So getting PPD in there - was key.
I'm firmly in the "dynamic processes" camp. I believe much of the data
will be very dynamic, the users will have very active clients
intermediating the data for them, and the transport that best serves
both ends will allow fine-grained data access. (More like SOAP, and
less like getting/parsing a whole FOAF.txt to find where they keep their
headshot.jpg. Or, for that matter, getting and parsing a whole
MeNowDocument.txt to find out what IRC channel they're on.)
There is a lot of great stuff that can happen for users before this
becomes fully realized, and a static file is plenty good enough for the
short and perhaps even medium term. But things will be a lot harder in
the future if the model is split now into "static" and "dynamic"
portions -- the eventual system will be completely dynamic, and static
files are the necessary, and completely laudable engineering compromise
There will always be a need for a http-accessible "about me" page -- but
I think it'll be dynamically generated from a triple store.
This is all, of course, just my view, and I in no way wish to step on
any toes, or imply anything less than huge respect and thanks for all
those who've actually done work here. Huge. Really big. Superlative,
to say the least.
I wrote some notes [<a
this, which lots of people read and nobody commented on. If you have a
moment and some spare generosity, I'd love to know if YOU (yes you,
there at the keyboard, with the soda) think my little brain dump is A)
completely irrelevant and orthogonal to the concerns of the list, B)
woefully confused and wrong, C) a vision of the far future and not
currently worth considering. (I suppose "D) real nifty" is an option
too. :) )
More information about the foaf-dev