W3C home > Mailing lists > Public > public-ldp-wg@w3.org > April 2013

Re: Access Control Requirements

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sun, 21 Apr 2013 16:33:54 -0400
Message-ID: <51744D32.3070408@openlinksw.com>
To: public-ldp-wg@w3.org
On 4/21/13 3:42 PM, Ashok Malhotra wrote:
> I added some material based on our discussion last week and mail from
> Serena and Henry.   If we agree on the direction, what more should we add
> to create the WG Note?
> Access Control
> 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.
> 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.
> For example, as discussed in http://www.w3.org/wiki/WebAccessControl 
> access privileges can be requested as below:
> @prefix acl: <http://www.w3.org/ns/auth/acl#> .
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> [acl:accessTo <card>; acl:mode acl:Read; acl:agentClass foaf:Agent].
> [acl:accessTo <card>; acl:mode acl:Read, acl:Write;acl:agent <card#i>].
> This means that anyone may read card, and <card#i> can write it.
> Typically, Access Control will be provided by the storage mechanism 
> and not the LDP server itself. Thus, requests such as above will need 
> to be mapped to the capabilities of the server.
> The access control mechanism isn't in the purview of the LDP standard, 
> so what can we say about
> access control?  What can we ask the server to provide?
> 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?

Identity, Identity Authentication, and Granting Resource Access to 
verified Identities are three distinct things. Thus, you have the 
following distinct items:

1. Identity Mechanism -- e.g., a WebID (an HTTP URI that denotes an Agent)
2. Identity Authentication -- e.g., WebID+TLS, OpenID, OAuth, etc.. that 
verify Identities
3. Resource Access Controls -- e.g, Web Access Control which can 
contrain Resource access to verified Identities.
> 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.

Sorta, but yes.

> 2. What is the granularity of access control?
> LOW BAR:  RDF resources
> HIGH BAR: A regex that identifies individual triples

Only limited to the logic delivered by an RDF resource.

> We can add these with a MAY or SHOULD when no countervailing security considerations apply.
> 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"
> 4. Ability to discover the access control policy as it applies to some 
> set of resources.
> -- 
> All the best, Ashok

Examples of fine-grained ACLs:

1. http://bit.ly/M7hd4T -- constraining access to a SPARQL endpoint
2. http://bit.ly/NmGbMZ -- similar but scoped to constraining access to 
resources from storage services
3. http://kingsley.idehen.net/DAV/home/kidehen/ -- my personal data 
space front-door showcasing multi-protocol based identity verification 
and acls
4. http://bit.ly/UXZEYV -- multi-identifier and multi-protocol based 
resource access control, leveraging existing Web architecture.



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

Received on Sunday, 21 April 2013 20:34:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:46 UTC