[foaf-dev] Re: privacy and open data
Benjamin Nowack
bnowack at semsol.com
Tue Mar 25 14:51:08 GMT 2008
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/
>
More information about the foaf-dev
mailing list