Re: Access Control Requirements

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.


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


-- 

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