Re: Extending the WebID protocol with Access Delegation

On 14 Aug 2012, at 17:39, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 8/14/12 11:03 AM, Henry Story wrote:
>> On 14 Aug 2012, at 14:34, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>> 
>>> On 8/14/12 7:11 AM, Henry Story wrote:
>>>> Of interest to both RWW and WebID group:
>>>> 
>>>> Sebastian Tramp, Andrei Sambra, Philip Frischmuth, Michael Martin, Sören Auer and I have submitted a paper entitled "Extending the WebID protocol with Access Delegation"  for the ISCW 2012, 3rd International Workshop on Consuming Linked Data
>>>>      http://bblfish.net/tmp/2012/08/05/WebID_Delegation.pdf
>>>> 
>>>> The paper has not been accepted yet, and the review process will very likely allow us to revise parts of it. But the review process can start here already. Feedback, ideas and implementations are welcome :-)
>>>> 
>>>> More pointers on the wiki
>>>>        http://www.w3.org/wiki/WebID/Authorization_Delegation#External_pointers
>>>> 
>>>> Sincerely,
>>>> 
>>>> 	Henry
>>>> 
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>> 
>>>> 
>>>> 
>>> Henry,
>>> 
>>> In my previous WebID ACL examples I had a social relationship oriented rule that looked up:
>>> :bob foaf:knows :alice .
>>> 
>>> I might just as well create another that states:
>>> :bob cert:secretary :secretary  .
>> yep. The namespace is currently provisionally the cert namespace.
>> It seems to me that it would be better placed in the auth namespace
>> 
>>    http://www.w3.org/ns/auth/auth#
>> 
>> which Timbl controlls. So hopefully thoughts on this topic here and in the workshop
>> can help settle this topic.
>> 
>> 
>>> Here is my actual Virtuoso or ODS access rule where I just use ^[webid]^ as my placeholder for the WebID being tested:
>>> 
>>> PREFIX sioc: <http://rdfs.org/sioc/ns#>
>>> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
>>> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>>> 
>>> ASK WHERE {^{webid}^ rdf:type foaf:Person;
>>>                    foaf:knows ?s
>>> FILTER (?s IN (<http://www.w3.org/People/Berners-Lee/card#i>,
>>> <http://kingsley.idehen.net/dataspace/person/kidehen#this>,
>>> <http://id.myopenlink.net/dataspace/person/KingsleyUyiIdehen#this>,
>>>                     <http://www.turnguard.com/turnguard>,
>>> <http://bblfish.net/people/henry/card#me>,
>>>                     <http://melvincarvalho.com/#me>))
>>>                    }
>> You are asking this of the foaf profile linked to the WebID Profile of the agent making the request. Or the union of both, right? (Timbl has his foaf in a separate file for example) So you are asking: does the person trying to gain access declare himself as being someone who knows one of the list of people in the FILTER clause.
>> 
>> 
>>> Which becomes:
>>> 
>>> PREFIX sioc: <http://rdfs.org/sioc/ns#>
>>> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
>>> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>>> 
>>> ASK WHERE {^{webid}^ rdf:type foaf:Person.
>>>                   ?s cert:secretary ^[webid]^
>>> FILTER (?s IN (<http://www.w3.org/People/Berners-Lee/card#i>,
>>> <http://kingsley.idehen.net/dataspace/person/kidehen#this>,
>>> <http://id.myopenlink.net/dataspace/person/KingsleyUyiIdehen#this>,
>>>                     <http://www.turnguard.com/turnguard>,
>>> <http://bblfish.net/people/henry/card#me>,
>>>                     <http://melvincarvalho.com/#me>))
>>>                     }
>> 
>> I suppose you are asking this of the webid/foaf profile of the requester as in the previous query (filling in the FROM clause would be useful in the example)
>> 
>> ASK
>> FROM ?webid
>> WHERE { ?webid rdf:type foaf:Person.
>>         ?s cert:secretary ?webid .
>>  FILTER (?s IN (<http://www.w3.org/People/Berners-Lee/card#i>,
>>                 <http://kingsley.idehen.net/dataspace/person/kidehen#this>,
>>                 <http://id.myopenlink.net/dataspace/person/KingsleyUyiIdehen#this>,
>>                 <http://www.turnguard.com/turnguard>,
>>                 <http://bblfish.net/people/henry/card#me>,
>>                 <http://melvincarvalho.com/#me>))
>>        }
>> 
>> where ?webid is bound to the SAN of the X509 certificate.
>> (in Jena and Sesame, one can bind variables on precompiled queries prior to execution - though I never yet tried binding on a variable in a FROM field...)
>> 
>> Here you are allowing anyone access who declares that they have ?s as secretary, where ?s is Tim Berners Lee, you, me, Turnguard, or Melvin. I am not sure these people will be able to take on this job offer. Tim seems to be quite busy running the W3c already, and I think you are well occupied too :-)
>> 
>> The role of the secretarty is more likely to be taken by an agent such as the virtuoso server who is acting on behalf of people who it publishes data for. The following query is closer:
>> 
>> ASK
>> FROM ?webid
>> WHERE { ?webid rdf:type foaf:Person .
>>         ?webid cert:secretary ?s .
>>  FILTER (?s IN (<http://www.w3.org/People/Berners-Lee/card#i>,
>>                 <http://kingsley.idehen.net/dataspace/person/kidehen#this>,
>>                 <http://id.myopenlink.net/dataspace/person/KingsleyUyiIdehen#this>,
>>                 <http://www.turnguard.com/turnguard>,
>>                 <http://bblfish.net/people/henry/card#me>,
>>                 <http://melvincarvalho.com/#me>))
>>        }
>> 
>> But that query would be asking the authenticating agent who it is a secretary for. That would make it
>> too easy for anyone to gain access. I know in your first example the idea was to make it easy to spread the number of people who claim to know any of us as much as possible. But that was a weak access control rule which is perfectly fine. The Delegated Auth though is trying to be precise in who it gives access to a resource in a delegted manner (however strict or weak the access on that resource is). So here this weakness is going to be more confusing than helpful.
> 
> Yes, but my prime concern is about the use of relationship semantics to handle this i.e., I just make an ACL rule and I am done.
> 
>> 
>> Unless the above query is made not on the Profile of the requesting secretary, but on the profile on behalf of whom she is acting.
> 
> The secretary WebID resolves to a profile document that bears the secretary relationship with some other WebID.

that would not be delegated authentication then. For delegated authentorization we need the delegator to specify who he is willing to delegate access to - who his secretary is in the language of the paper. I think you will find this delegated authorisation very useful. ( More below )


>> Then the above query is correct. But it has to go hand in hand with a checking of the On-Behalf-Of header in the request.
> 
> Why?

Because the secretary has to specify on whose behalf she is working: the agent who delegated her the job of fetching things on his behalf. You have to think of a virtuoso server serving 1000 profiles or such, and needing to fetch things for its users (just in order to be able to do access control).

> 
>> Which also brings us to the question - do we need to make that X-On-Behalf-Of?
> 
> I don't think so, hence my question about being just another ACL based on specific entity relationship semantics.

The paper argues why this is not just another ACL issue - though perhaps this could be put more clearly in those terms.  Here are two key points (developed in section 3.2 of the paper)

  - a resource may have different representations depending on who makes the request. So when the secretary is fetching a resource for TimBl it may get one representation, and when I fetch it another (more vs. less information for example)
  - the secretary may be a secretary for a number of different people, some who have access and some who do not.


> 
>> We need to tune this a little bit and bring it to the attention of the HTTP working group.
> 
> If its just another ACL, which is what I believe it is, we are set. It just more dog-fooding en route more "deceptively simple" demos re., WebID utility.

nope, see section 3.2

> 
> 
> Kingsley
>> 
>> Henry
>> 
>>> I am happy to setup this rule for live testing.
>>> 
>>> -- 
>>> 
>>> Regards,
>>> 
>>> Kingsley Idehen	
>>> Founder & CEO
>>> OpenLink Software
>>> Company Web: http://www.openlinksw.com
>>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>>> Twitter/Identi.ca handle: @kidehen
>>> Google+ Profile: https://plus.google.com/112399767740508618350/about
>>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>> 
>>> 
>>> 
>>> 
>>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
>> 
>> 
> 
> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/

Received on Tuesday, 14 August 2012 15:54:02 UTC