Re: Access Control Requirements

On 18 Apr 2013, at 14:43, Serena Villata <serena.villata@inria.fr> wrote:

> Hi Ashok, all,
> thanks for addressing these issues.
> 
>> Access Control is a mechanism to enable or deny permissions to entities - individuals, groups of individuals or >organizations - to perform operations on resources. The entities have to be authenticated and identified
>> and, perhaps, added to a group.
> 
> I agree, in fact I think we can simply consider the attributes of the user who is accessing the resources. 
> Among these attributes, the group the user belongs to can be specified.

That still makes for a relation from a resource to a set of agents, it's just that you are narrowing the
sets of agents by restrictions on attributes.

> 
>> In the case of LDP the resources are LDP resources but the access control may operate at different granularities: RDF >documents, named graphs or individual >triples. The operations are read, update, create and delete.
> 
> Agreed.
> 
>> Access Control will be provided by the storage mechanism and not the LDP server itself.
>> The access control mechanism isn't in the purview of the LDP standard, 
> 
> Agreed, but I believe we should improve the wiki page about access control.
> For instance, at the moment there are a number of approaches like Shi3ld and the Oracle Triple-based Access Control which are listed among the vocabularies but actually they are AC frameworks. I can take care of updating it.
> 
>> 1. How are entities authenticated?   Can we require the use of WebID or OpenID for example?
>> Can we even recommend that one of these be used?
>> LOW BAR:  The storage system provides its own mechanism for authenticating and identifying entities e.g username/password
>> HIGH BAR: Storage system accepts a URL which points to a set of credentials identifying entities.  Authorization is orthogonal.
> 
> I'd say that WebID and OpenID are the two possible solutions.
> 
>> 2. What is the granularity of access control?
>> LOW BAR:  RDF documents
>> HIGH BAR: A regex that identifies individual triples
> 
> Why don't we say that the granularity are generally speaking resources?
> I mean HTTP resources which are queried, created, deleted and modified via HTTP requests.
> I think "RDF documents" is too much document-oriented.  

+1

> 
>> OTHER REQUIREMENTS .. We can add these with a SHOULD
>> 3. If access is denied, some explanation of why it was denied.  For example, "Could not verify one of user's principals" or "Network problem during authentication" or >"User not authorized to update"
> 
> Agreed. However, we have to keep in mind that it's difficult to find the good degree of granularity to describe the reasons behind the refusal. Beside, sometimes the disclosure of these details must be avoided. It depends on the scenario. I'd propose to have these details with a MAY

+1 for MAY - or SHOULD when no countervailing security considerations apply.

> 
>> 4. Ability to discover the access control policy
> 
> The access control module should manage that, I don't think it's up to the LDP server to do that.

Why? Clients may want to know who SHOULD be able to access a resource. If they do then they can tell
if there is a bug on the server, which is very helpful to the resource owner, as he can be pinged about 
the error.

ACLs are just another LDP resource. There is no reason why they should not be something one can
create, edit or delete using LDP.

> 
> I take advantage of this email to present you the latest version of our authorization framework, Shi3ld.
> We protect HTTP access to triples in scenarios that adopt the SPARQL HTTP Graph Store Protocol. Besides, we provide an authorization module for LDP-like scenarios, where resources are accessed with plain HTTP operations. The link to the web page describing Shi3ld-HTTP is [1].
> 
> Comments are welcome!
> 
> All the best,
> Serena
> 
> [1] http://wimmics.inria.fr/projects/shi3ld-ldp
> 

Social Web Architect
http://bblfish.net/