- From: <henry.story@bblfish.net>
- Date: Sat, 10 May 2014 18:46:21 +0200
- To: ashok.malhotra@oracle.com
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
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 Saturday, 10 May 2014 16:46:54 UTC