Re: Extending the WebID protocol with Access Delegation

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

> On 8/14/12 11:53 AM, Henry Story wrote:
>>>> >>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.
> Okay, so we have two puzzle pieces in the form of web documents:
> 
> 1. document where TimBL expresses the secretary relationship

  His WebID profile for the moment (to keep things simple.)

> 2. document where TimBL authorizes secretary to act on his behalf.

  You mean perhaps an ACL document protecting a resource which TimBL has access to. This would not necessarily be a document owned by TimBL, but rather a document usually owned by someone else who wishes to give TimBL access. This document - the ACL - would give access to TimBl and his secretary.

So yes. The question is how? 

a- Is giving access to the secretary enough in the ACL?
b- Or is it important that it know on behalf of whome the secretary is acting in each request? 

For example imagine that your secretary (running on your openlink domain) is running the RESTful mail for a whole company, and so for Joe, Jim, Jack and Johnson. It does a GET on a resource R on the IBM.com web servers. R is meant for Johnson, but not for any other user. If the secretary is given plain access at the same level as Johnson, then how is IBM's guard going to know if it should give the secretary access? Who is she acting for? Or put another way: how does the author of the guard write out the ACL on R so as to allow the secretary to only give the resource to Johnson?

This is where the On-Behalf-Of header comes in.

> If the above is true, why is it inconceivable that TimBL's secretary doesn't receive some notification (e.g. Semantic Pingback) about the relationship in question? Doing so would result in the inverse relationship in the profile document of his secretary.

The information being in the profile won't help the server decide for whome at that moment the secretary is acting. This is a per request role the secretary needs to take on.

At least: that is the argument in the paper.

>> 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 )
> 
> You know I don't doubt the utility of this endeavor, I am trying to determine if this can be handled via ACLs and a Linked Data crawl :-)
> 
>> 
>> 
>>>> >>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).
> 
> That part is clear, what I see at this juncture is two puzzle pieces (Linked Data docs)  where the one that's tested by an ACL doesn't bear the critical relationship i.e., TimBL's made the claim in his document but said claim doesn't have a reciprocal claim in his secretary's doc. Thus, you try to work around this via the custom HTTP header based hint.

I see where the misunderstanding lies. 
As explained above the reciprocal link in the secretary's webid profile won't help.

> 
> The hint works as a fallback, but I really think dogfooding Semantic Pingbacks basically solves this problem since a pingback notice from TimBL will create the reciprocal relationship in his secretary's profile document. Once this is done, its just a follow-your-nose based URI dereference as part of the SPARQL evaluation.

yep. Pingback is not solving the issue. The secretary could have the link to all the people it is working for, we would - so claims the paper - still need the On-Behalf-Of.


> 
>> 
>>> >
>>>> >>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.
> 
> a single secretary for many individuals, as outlined above, can be handled by a pingback system. The challenge is propagation of the triples expressing the various relationships.

Care to elaborate on this? I don't see how these things work together.

> 
> My system allows many ACLs and precedence controls etc.
>> 
>> 
>>> >
>>>> >>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
>> 
> I am going to read the paper. At this juncture though, I think its ACLs + Semantic Pingbacks.

Sounds intriguing.

> 
> -- 
> 
> 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 17:49:48 UTC