Re: Extending the WebID protocol with Access Delegation

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
2. document where TimBL authorizes secretary to act on his behalf.

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.


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

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.

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

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.

-- 

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