- From: Henry Story <henry.story@bblfish.net>
- Date: Sat, 10 Dec 2011 10:32:07 +0100
- To: "Ed - 0x1b, Inc." <semantics@0x1b.com>
- Cc: WebID Incubator Group WG <public-xg-webid@w3.org>, foaf-protocols@lists.foaf-project.org
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 http://lists.w3.org/Archives/Public/public-xg-webid/ > > 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 http://bblfish.net/tmp/2011/12/06/index-respec.html#publishing-the-webid-profile-document https://bob.example/profile/protected can contain something like @prefix bob: <https://bob.example/profile#> . bob:me foaf:knows paul:simon . Henry Social Web Architect http://bblfish.net/
Received on Saturday, 10 December 2011 09:32:49 UTC