Re: Access Control Requirements

On 21 Apr 2013, at 22:33, Kingsley Idehen <kidehen@openlinksw.com> wrote:

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

Some other examples:

[] wac:agentClass <http://bblfish.net/2013/05/07/ouishare#grp>,
                  <http://www.w3.org/2005/Incubator/webid/team#we>;
   wac:accessTo <couch>;
   wac:mode wac:Read .

Members of the OuiShare Group and the WebID Incubator Team can find out about my couch, 
namely wheter it can be surfed.

[] wac:accessToClass [ wac:regex ".*" ];
   wac:agent <card#me>;
   wac:mode wac:Write, wac:Read . 

I can read and write all files under this directory ( btw:  the wac:regex needs to be worked on )


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

+1

You could even allow descriptions that don't require WebID by for example having a WAC such as 

     []  acl:accessTo <card>; 
         acl:mode acl:Read, acl:Write;  
         acl:agent [ foaf:mbox <joe@simson.org> ],
                   [ foaf:openid <http://jane.org/> ] .


Of course verifying the email would require it's own protocol ( could be done through sending an e-mail ),
and openid would be a lot less efficient than WebID. But the WAC need not require an specific authentication 
protocol. All that is required is agreement on the ontology.


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

I would not go to indenitification of individual triples at this point, and that
seems to be part of a filtering technology rather than an Access Control one.

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

yes, a simple ontology for this would be great.

>> 
>> 4. Ability to discover the access control policy as it applies to some set of resources.

yes, a header 

Link: <https://localhost:8443/2013/card.acl>; rel=acl

would be I think the best way to go there.


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

Social Web Architect
http://bblfish.net/

Received on Thursday, 9 May 2013 15:32:50 UTC