W3C home > Mailing lists > Public > public-xg-webid@w3.org > December 2011

Re: [foaf-protocols] Privacy concern: different FOAF file depending on what website is asking

From: Henry Story <henry.story@bblfish.net>
Date: Sat, 10 Dec 2011 10:32:07 +0100
Cc: WebID Incubator Group WG <public-xg-webid@w3.org>, foaf-protocols@lists.foaf-project.org
Message-Id: <56179D4A-5889-4247-AF22-E54448CC2D4D@bblfish.net>
To: "Ed - 0x1b, Inc." <semantics@0x1b.com>

On 10 Dec 2011, at 02:49, Ed - 0x1b, Inc. wrote:

> btw - the reply-to on the list needs fixin - it goes to the poster, no the list

Check your trash. I think the W3C e-mail server should have sent you a request - 
if you are not already on the W3c mailing list - asking you if you agree to the 
conditions of participation. Otherwise try subscribing from here

> On Fri, Dec 9, 2011 at 7:38 AM, Henry Story <henry.story@bblfish.net> wrote:
>> On 9 Dec 2011, at 13:19, Kingsley Idehen wrote to the foaf-protocols mailing
>> list:
>> We need a property in a owl:subPropertyOf relation with rdfs:seeAlso that
>> offers a pathway to an ACL protected resource.
>> +1
>> I think something like this would be the simplest.
>> You can also use owl:sameAs relations, but that brings in a need for
>> reasoning capability on the part of a WebID verifier. This issue is
>> basically ultimately about authorization that factors in pseudonyms via
>> handling of co-references etc..
>> Kingsley
> Don't you just deliver a different FOAF file depending on the
> requester?

In order for that to work, the server serving the WebID profile, would need
to know who is asking. If the server asked at the point of serving the 
WebID profile for the identity of the client, and the client had the same
policy of requiring identification before serving the page, there would be
a deadlock. 

We probably need to explain this more clearly in the spec.

> It is OK to have a URI that dynamicly matches across
> multiple RDF files right? so LinkedIN just gets a very short RDF file
> when you submit your WebID. If the ACL isn't transparent to the
> requester you have information leakage and if you serve up a detailed
> FOAF to a spider, well that's a teachable moment.. but I don't see a
> way around it.

As I see it the profile served should not request webid authentication of 
the client for the reasons given above. Now could the new relation call it say
authSeeAlso point to the same resource?

   <> authSeeAlso <> .

Well the problem is if the server is not meant to ask for authentication of
the client when serving that resource, how is he going to ask for authentication
the second time it is loaded? I think things just get a bit weird there, so it is
better to distinguish.

This is not a problem the protected resource in our example 

https://bob.example/profile/protected can contain something like

@prefix bob: <https://bob.example/profile#> .

bob:me foaf:knows paul:simon .


Social Web Architect
Received on Saturday, 10 December 2011 09:32:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:50 UTC