Re: Please review the Access Control page

On 20 May 2014, at 13:08, ashok malhotra <ashok.malhotra@oracle.com> wrote:

> Henry:
> The usecases you added allow Eddie to edit the ACGs for resources he owns.
> rather than the webmaster controlling all ACGs.  Is this correct?
> If so, we should add a requirement that agent can edit the ACGs for resources
> he owns.

I think that makes sense. If we start by the root container, we can define the requirements recursively, a bit like this:

  1. the web master is able to edit the ACGs for all resources whose urls match the regex "https://domain.example/.*" 
  2. the web master specifies the ACG for the root LDPC and then gives the rights to do whatever he wants
      to the owner of a created LDPC making him the sub-web master of the created LDPC e.g.,                    
      "https://domain.example/joe/.*"
  3. the owner of the created LDPC <https://domain.example/joe/> can create new LDPCs and give any rights he chooses to them
     some of the rights he can choose to give are:
       - allow anyone to post to a particular container ( perhaps with the restriction that he be authenticated in some way ), but
         not to read the contents of the container
       - allow only friends to post, and edit content in another container
       - allow friends of friends .... 
       ... the use cases from the wiki ...




> Ashok
> 
> On 5/20/2014 6:09 AM, henry.story@bblfish.net wrote:
>> On 19 May 2014, at 17:53, Serena Villata <serena.villata@inria.fr> wrote:
>> 
>>> Dear Ashok, all,
>>> I have just few comments on the Note:
>>> 
>>> - "ACG: An Access Control Graph describes which agents can have some mode of access to a resource, or collection of resources.": I would
>>> substitute this sentence with "ACG: An Access Control Graph describes which features an agents has to satisfy to have some mode of access
>>> to a resource, or collection of resources.". This is to avoid the misunderstanding that only specified lists of agents (or roles of the
>>> agents) are considered while it is also possible to list the attributes of the agents whose access is granted. I see that this point
>>> is mentioned as possible future outcome of an AC WG: "The WG will need to decide whether it also wants to define fine-grained access
>>> control at an attribute level." To me attribute-level AC is more general than specifying AC lists of agents (as you do not always know the
>>> URIs of all the agents that will try to access the resource and maybe they are allowed to). However, I understand that this is a tricky point, and
>>> it is fine with me to leave it as a future option (as it is just a single page :-) ) for a dedicated WG.
>>> 
>>> - "allowing friends of his to POST to a container, but not read the contents of the container": sounds a bit strange to me. Why the constraint that he cannot read the contents of the container?
>> I was thinking of an notification LDPC where one can be notified of a change to a resource ( say someone adds you to their friend profile ). You want to allow people to POST but not necessarily to view all the notifications that have been posted.
>> I updated the uses cases here https://www.w3.org/2012/ldp/wiki/AccessControl
>> 
>> does that help?
>> 
>>> All the best,
>>> Serena
>>> 
>>> 
>>> 
>>> ----- Mail original -----
>>>> De: "Ashok Malhotra" <ashok.malhotra@oracle.com>
>>>> À: "Ted Thibodeau Jr" <tthibodeau@openlinksw.com>, "Serena Villata" <serena.villata@inria.fr>, public-ldp-wg@w3.org
>>>> Envoyé: Lundi 19 Mai 2014 16:57:31
>>>> Objet: Please review the Access Control page
>>>> 
>>>> Serena, Ted:
>>>> The LDP WG is getting ready to publish the Access Control page as a WG note.
>>>> Could you please take a look at
>>>> https://www.w3.org/2012/ldp/wiki/AccessControl
>>>> before we do that?  And it is what it says -- just a single page :-)
>>>> --
>>>> All the best, Ashok
>>>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
> 

Social Web Architect
http://bblfish.net/

Received on Tuesday, 20 May 2014 11:25:00 UTC