Re: Extending the WebID protocol with Access Delegation

On 8/14/12 1:49 PM, Henry Story wrote:
> 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.

Yes, but that using an HTTP header to deliver information missing from 
the graph resolved from WebID in the SAN of the cert. presented by the 
user agent seeking access to a resource.

A semantic pingback could place this in triple form in the secrataries 
profile in the form of a reciprocal triple.

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

To me I read: this is a shortcut negating the need to have more triples 
expressing the semantics of this form of relationship.
I also note in the paper a reference to OntoWiki making use of Semantic 
Pingbacks etc..

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

One triple one help since it doesn't handle the granularity of the 
situation, several triples can express said granularity though.

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

It only deals with getting the missing relationships into the 
secretary's profile graph so that the ACL engine has a starting point 
for a  Linked Data crawl.

In my eyes, its about putting enough puzzle pieces together en route to 
a more complete understanding of a specific kind of relationship, and 
its implications.

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

On-Behalf-Of is a "leap of literal faith" tucked into an HTTP header :-)


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

Propagate the critical triple to the secretary's profile document so 
that an ACL engine can crawl and then better understand this 
relationship via its semantics.
>
>> 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.

This excerpt from the paper hovers around what I am trying to describe, 
I think:

"A first use-case for WebID access delegation within OntoWiki arises 
from an important functionality within OntoWiki, namely import of 
external data. Since WebID profiles can contain personal information 
that is in need of protection, access to such data should be restricted 
with the WebID protocol. Although a user may (or may not in the case of 
a periodically executed automatic syn- chronization process) initiate 
the import procedure manually via the OntoWiki user interface, the 
actual fetching is done in the background. An OntoWiki in- stance does 
not know of any private keys of users of the system. Thus the system is 
not able to use that information when requesting data. With WebID access 
delegation though, the profile can be fetched on behalf of the user instead.

Another use-case where access delegation can be employed is within the 
Se- mantic Pingback protocol [12]. With Semantic Pingback owners of 
resources can be notified when for example a link to such a resource is 
created elsewhere on the web. In order to protect the protocol against 
spam attacks, a Pingback server will fetch the desired resource and 
check, whether the stated link is indeed contained in the data. The 
source resource that links to the target resource and thus is fetched by 
a Pingback server might be access restricted, for example in a scenario 
where a friending process is initiated [10]. For privacy reasons the 
owner of the WebID profiles will very likely hide the triples in 
question (e.g. foaf:knows) on anonymous access attempts. With WebID 
access delegation again, the resources can be fetched by the Pingback 
server on behalf of the resource owner.

This will require some further changes to the delegation protocol 
discussed up to now. Specifically the :secretary relation currently does 
not distinguish what kind of responsibilities the principal wishes to 
give to the secretary. It is currently assumed that the secretary has 
full rights. For ontowiki knowing the social network may be all that is 
needed to make access control decisions. Full delegation powers may not 
be needed. The ability to describe more limited secretary relations 
could be very helpful here. "

Remember, OntoWiki is Virtuoso based albeit not exploiting all of 
Virtuoso's functionality in this real. For instance, Virtuoso has its 
own key store as well as being able to use pkcs#12 file references for 
user agent level identification when performing Linked Data crawls via 
follow-your-nose patterns.


Suggestion:

Why don't we make a live experiment. Someone generates a WebID for a 
secretary using a data space that supports semantic pingbacks while 
others assign resource authorizations to the designated secretary that 
are propagated to the secretary's profile doc via semantic pingbacks. 
Net effect, the secretary profile has the minimal data required for 
enabling an ACL engine perform a de-reference to the profile docs where 
delegation details reside.


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