Re: Feedback on Access Control Page

Henry:
Thank you for you comments.  I made changes to the Access Control page:

https://www.w3.org/2012/ldp/wiki/AccessControl

using some of your suggestions.

I did not add anything about authentication because, I think, the Access Control facility
should be able to work with any authentication mechanism and use the token it returns in the AVG.  I also did not add the requirement that the access control go beyond the boundary of the LDP server into the Web at large because I don't know how to do that and I think that is beyond our scope.

I also added a very brief outline of a charter for an Access Control WG.

ALL:  Please take a look and comment.

All the best, Ashok
  

On 5/10/2014 12:46 PM, henry.story@bblfish.net wrote:
> On 5 May 2014, at 23:38, Ashok Malhotra <ashok.malhotra@oracle.com> wrote:
>
>> I moved our latest thinking about Access Control to https://www.w3.org/2012/ldp/wiki/AccessControl
>> The old page is at https://www.w3.org/2012/ldp/wiki/OldAccessControlPage
> That's a good place to start.
>
> Some feedback split up by sections of the wiki here.
>
>
> Vocabulary:
> ===========
>
> given that I think the main requirement has to be compatibility with LDP, I think adding the following
> definitions makes the rest of the text a bit easier to understand.
>
> ACG: An Access Control Graph ( as opposed to an Access Control List ), describes what agents can have
>      some mode of access to a resource, or collection of resources.
> ACG Resource: A resource whose representation contains one or more ACGs and which the LDP server relies upon
>    to make its access control decisions ( as far as the external world is concerned ).
>
> 2 Usecases
> ==========
>
> "Adam logs on to a server and requests: the ability to read a resource identified by a URL."
>
> That sounds more like the ability to edit the ACG, which I think is a use case in itself.
>
> But it could be understood to also mean:
>
> An Agents makes an HTTP request to either GET, PUT, DELETE, PATCH, ... a resource. The server allows or denies the request
> as required the by the ACG for the resource.
>
> I would add as use case:
>
> For each resource an authorized agent should be able to
>    • find using HTTP the related ACG for a resource
>    • edit the ACG to allow access in various modes by various groups described in various ways using HTTP verbs in a manner
>      fully compliant with LDP standards and cohesive with it.
>    
> Ok, let me put this in Use case language
>
> A. Ben's LDP browser goes to a resource and would like to let Ben know what kinds of access he has to the resource, so that
>   he can adapt the interface depending on what rights Ben can have.
>
>    • Can he write to the resource?
>    • Can he delete it?
>    • Can he append triples to it?
>    • Can he edit the metadata?
>    • Can he edit the ACL
>    • What group of people would he need to belong to to be able to get access ( e.g. becoming an Apache member would allow him write access )
>
>    depending on this the browser may or not enable certain features in the UI ( eg a view ACG button )
>
> B. Assuming Ben is allowed to edit the ACG Resource, Ben's LDP browser should be able to offer him a User Interface to
>    • add indivual agents, or groups of agents to the ACG
>    • add new ACGs
>    • delete ACGs
>    • browse ACGs, by following links
>
> C. LDP browsers are able to follow links across the web, so it should be easy for a browser to authenticate to any server with a globally but not centrally controlled identity.
>
>
>
> 3. Requirements:
> ================
>
> An additional requirement:
>
>   • A future standard consistent with LDP
>     - an ACG resource must be discoverable via linked data from a resource
>     - ACG resources must be editable via HTTP verbs such as PUT or PATCH and consistent with the way LDP edits LDPGs
>   • ACGs must be able to specify groups described remotely, resources specified remotely etc... ( ie the groups can be specified
>     as linked data resources )
>
> Currently I find:
>
> "• User must be able to authenticate herself to a server. After authentication user is handed a userId. (Usecase 1 and others.)"
>
> I am not sure why the Access Control page requires the user to be handed a userId. That is related to authentication, which would be
> a different section.
>
> I think we need to add an Authentication section.
>
> Since Linked Data cross domain boundaries, one important thing is to have global identity, so that a user does not need to create an identity for each system he logs into.  Access Control Graphs should be able to specify which agents can do which tasks using such a global identity system. Some global identies that are possible are: OpenID, WebID [1], e-mail identifiers, ...
>
> One may want to consider global access via abilities ( ie tokens too ).
>
> Some of the requirements such as:
>    • the ability to create a group of user ids or a group of resources
> seems to me to be something that can allready be done with LDP, so that I don't see that as a requirement
> on an Access Control spec. The requirement of an access control spec is that one just be able to use such identities
> and groups (  described in RDF as linked data ) to specify access to a resource. Still I think that is just a confusion
> about "create a collection" which we now hear as create an LDPC. IF it is "create a description of a group of users or a collection
> of resources" that would be easier to understand, especially if one then adds: in order to describe what mode of access such a collection of resource allows which group of agents.
>
>
>
>
>
> [1] http://www.w3.org/2005/Incubator/webid/spec/identity/
>
>
>
>> -- 
>> All the best, Ashok
>>
> Social Web Architect
> http://bblfish.net/
>
>
>

Received on Tuesday, 13 May 2014 12:05:13 UTC