Re: Feedback on Access Control Page

On 13 May 2014, at 14:03, Ashok Malhotra <ashok.malhotra@oracle.com> wrote:

> 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 completely agree that an ACG should work with any authentication mechanism. 


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

Well we have three implementations doing that with WebID ( see the newly released specs at http://www.w3.org/2005/Incubator/webid/spec/ )

 - rww.io
 - data.fm
 - stample.io

 It could be extended easily to work with OpenId, and probably with 
some tokening system. It is falls out of the box automatically because
we are using RDF. All one needs is a global identity system of which there
are a few such as OpenId or WebID or e-mail addresses. Here is how you 
describe a group of agents using all of those identifiers

   <grp#ldp> a foaf:Group;
       foaf:member [ foaf:mbox <mailto:ashok.malhotra@oracle.com> ];
       foaf:member <http://bblfish.net/people/henry/card#me> ;
       foaf:member [ foaf:mbox <mailto:lehors@us.ibm.com> ]
       foaf:member [ foaf:openid <http://dret.typepad.com/> ] . //assuming dret has an openid


It is easy then to specify access to some resource to members of that group.
Using https://www.w3.org/wiki/WebAccessControl one would do it like this:

  [acl:accessTo <ldpc>; acl:mode acl:Write; acl:agentClass <grp#ldp> ].

Here is an illustration:


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

I have updated it and split things into a few sections to make the different types of use cases a bit clearer.
I have also removed the notion that access control is about asking for authorisation. On the web you don't ask 
for authorisation to do something, you do something, and that doing is either allowed or not. Setting up complex
authorisation request systems would grow the number of http connections.

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

Social Web Architect
http://bblfish.net/