Re: Extending the WebID protocol with Access Delegation

On 8/15/12 4:21 AM, Sebastian Tramp wrote:
> On Tue, Aug 14, 2012 at 02:25:50PM -0400, Kingsley Idehen wrote:
>
>>> 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.
> Kingsley, the On-Behalf-Of request header is a triple (in form of a HTTP header
> field) which relates the current HTTP request with a WebID.

Yes, I understand how you are trying to use this pattern.
>   Since HTTP requests
> are really short living, I do not see where we should materialize the triple
> outside the request packet itself (and we do not have a request URI anyway).

The concern here is that custom headers introduce adoption challenges. 
Self describing documents don't have this problem. Notification services 
can be used to trigger generation of new triples in relevant documents 
as part of a protocol.

>
>> On-Behalf-Of is a "leap of literal faith" tucked into an HTTP header :-)
> We have to work in the environment we have and literal header fields is the
> only representation we have at the moment.

Yes, but it doesn't scale easily as too many parties need to be 
convinced to come on board.

>
>> A semantic pingback could place this in triple form in the secrataries
>> profile in the form of a reciprocal triple.
> I believe we discuss different issues here. Semantic Pingback is a low
> footprint protocol to enable publishers of semantic data to communicate the
> Linked Data network connections (object properties) they have created.  Of
> course, Semantic Pingback can be extended with access delegation (as outline in
> the paper and quoted by you here in the thread) but any other HTTP request can
> be extended in the same way.

If it can propagate relationships such as foaf:knows it can do so for 
others.

Sequence goes as follows:

1. I determine the URI of my secretary
2. I express the secretarial relationship in my data space -- this would 
include all the triples describing the relationship between the 
designated secretary and I
3. Pingback pushes the triple based claim to the secretaries data space 
-- the acknowledgement here (in form of actual triple creation) is vital
4. Secretary attempts to access a resource
5. Server ACL processor de-references the WebID in the secretary's cert
6. Follows link back to my data space and then tests against its ACL 
based data access rules
7. Done.

The server is able to verify the identity of all the players and the 
semantics of their relationship.

As I suggested to Henry, this is worth an actual experiment as it always 
the best way to get down to the real issues etc..

What I am suggesting will not incur the inevitable costs of adding a new 
client request header to HTTP combined with the push for adoption across 
existing Web users and developers. Everything happens in the data 
delivered by document content.

>
> Best
>
> ST
>


-- 

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