WebID and ACL oriented Relations

All,

Summarizing the long thread that centered around valid concerns about 
WebID based ACLs that got a little lost in language.

Sandro's fundamental concern, as I've come to understand it, based on 
what exists across all the relevant specs:

We currently have the :key Relation as the basis WebID based ACLs, so to 
speak. Net effect, A WebID's association with a Public Key (via the :key 
Relation) is the basis for controlled access to protected resources. 
Basically, we have a very restrictive Relation that amounts to the WebID 
being the focal point of ACLs.

The assertion above, if true, is basically consistent with Sandro's 
fundamental point and valid concerns.

On my part, our systems don't work this way, so naturally, I didn't 
instinctively pick up on Sandro's core (and valid) concern.

As I also indicated, these issues have been debated in varying guises 
over the years, most recently, I believe Melvin raised concerns about 
the :key Relation too being that :key is an IFP. Ditto the FOAF 
specificity of the WebID-TLS protocol.

What can we do to fix this?

In our specs, we shouldn't create the illusion of a canonical Relation 
(e.g., :key) for WebID based ACLs. Basically, doing that leads to the 
WebID + Public Key (which is the object of  :key Relation) being the 
sole ACL basis, and that's equivalent to making a WebID the sole basis, 
which is indeed problematic.

At the very least, the specs should showcase alternative relations e.g., 
:account ,  :holdsAccount etc.. If we do that, I believe the problem 
goes away.

Sandro:

Long thread, but we've found ourselves at a point of clarity, I hope :-)


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen