Re: Extending the WebID protocol with Access Delegation

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

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

The problem is that you cannot do what we are proposing by using only documents. This is
per request problem. You need to read the paper to see this.

Notice that we are not the first to do this. CORS is dealing with a very similar
problem and its Origin: header is very similar to our On-Behalf-Of header, as argued
in the paper.


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

You need the server serving resources to realise that this reduces the load on his machine, 
because the client can do the same thing otherwise by just creating public keys for each
request. So this reduces the TLS load.

I think in our paper we still need to calculate when this becomes problematic, and to what
extent. My feeling is that this is the type of reason that could explain why Identica and 
such services have problems with WebID: it may require them to open up too many TLS 
connections. (one can never tell because they rarely come out and make clear statements)

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

This does not help with the core use case we are describing in our paper that the resource requested by the secretary may have different representations depending on which of the users is asking for the information. It may be a little too early to speak about this here, given that we don't yet have any servers that do client negotiated access control (though Bergi is trying to build access control rules at the triple level - which seems too complicated to me, but that would certainly have the effect described). 

Still this paper is thinking a little bit ahead of where we are now, just so we can make sure that there are some possible solutions when we get there.

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

Social Web Architect
http://bblfish.net/

Received on Friday, 17 August 2012 06:40:33 UTC