Re: Extending the WebID protocol with Access Delegation

On 8/17/12 2:34 AM, Henry Story wrote:
> 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.

I've read the paper, and I still disagree. What's a SPARQL Protocol HTTP 
GET? A non request?
>
>
>>>> 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)

Have you looked at this from the SPARQL protocol, over TLS perspective?

>
>>>> 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 doesn't matter. An ACL rule can deal with whatever. The key is being 
able to analyze the data delivered by the SPARQL protocol which is HTTP 
based.

The secretary is trying to access a resource associated with an ACL. The 
format of the resource simply doesn't matter. What matters is whether 
the identity in question passes the conditions tested by the ACL.


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

"There are no servers that do client negotiated access control." What 
does that mean?

For instance, do you mean:

1. client asking a server to give it access to a resource because its 
acting on behalf of some identity?
2. client using something like a TCN (transparent content negotiation) 
algorithm to request access to a resource from a server?

If via ODBC (circa. 1992) we could do stuff like:

only allow user "henry" access an Oracle table (in update mode) if he is 
using Microsoft Access from a Windows machine at a give IP address or 
subnet mask, otherwise, the connection is read-only etc.. Why wouldn't 
we be able to achieve that and much more via SPARQL and Linked Data 
resources?

The key to the above is identity:

1. user -- Henry
2. application -- Microsoft Access (yes, we drive that from Windows 
since it has identifiers for each application)
3. IP address of subnet mask -- derived from the TCP/IP
4. modality -- handling by a mapping rule.

This is all about ACL based rules, and the combination of HTTP, SPARQL, 
and Linked Data resources takes this capability to a whole new level.

Kingsley

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


-- 

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