[foaf-dev] Re: privacy and open data

Story Henry henry.story at bblfish.net
Tue Mar 25 16:13:27 GMT 2008 

Hi Benji,

This approach looks very promising.

On 25 Mar 2008, at 15:51, Benjamin Nowack wrote:
>
> 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.

could the username be a foaf id? Say in my case:

http://bblfish.net/people/henry/card#me

the personal identifier (password) could then be the URI (+ some  
token?) of the requested resource
encrypted with the pgp private key available from my foaf file

:me  is wot:identity of [ a wot:PubKey;
                           wot:pubkeyAddress <http://bblfish.net/people/henry/henry.pubkey.asc 
 >;
                           wot:fingerprint  
"0DF560B5DADF6D348CC99EA0FD76F60D4CAE10D7";
                           wot:hex_id "4CAE10D7";
                           wot:length 1024 ] .


The server would then just need to get the foaf file, find the pgp  
public key, to verify that the request
does indeed come from the owner of the foaf file.

>
> * 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.).

Sounds like the above interaction would fit your description.

> 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.

I am working on a Semantic Web client called Beatnik at
https://sommer.dev.java.net/
  and would like to implement something like this.

Do you have some more info? Perhaps I can get this implemented before  
May 5 for JavaOne.

Henry

>
>
>
> 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/
>>
>

-------------- 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/20080325/4f9aea0f/smime.bin

More information about the foaf-dev mailing list