Re: Access Control Charter

Hi Henry:
I agree with your comments except for one requirement.
I think we also need to grant access control for some group of
resources.  So, I have changed your points a bit:

1. An ontology/vocabulary for describing access to/a resource or a group of/  resources by agents or groups of agents
2. A way to find from a http(s) resource the description of the acl rules for that apply for that resource
    ( clients may or may not be allowed to view those acl resources, but the server should follow those links to determine who has access )
/2a: A way for an agent to find what resources he can access//
//2b: Ability to add an agent to a group of agents//
//2c. Ability to add a resource to a group of resources./
3. a way to edit the acl resources/(GRANT / REVOKE)/  - LDP is the obvious candidate here
4. the server should grant or not grant access to the resource if the client can prove that he is an agent that has the correct read/write access to the resource

If you think we need to discuss, I can schedule a telcon providing we can
agree on a time :-)

All the best, Ashok

On 5/5/2014 10:04 AM, henry.story@bblfish.net wrote:
> On 27 Apr 2014, at 21:00, Sandro Hawke <sandro@w3.org> wrote:
>
>> On 04/27/2014 10:26 AM, ashok malhotra wrote:
>>> On 4/26/2014 5:47 PM, Sandro Hawke wrote:
>>>> It makes sense in general, but I'm not sure about the particulars. What do you mean by collection?  Why a collection at all?
>>> Hi Sandro:
>>> If we create a standard for Access Control should we specify policies or data structures?
>> Neither, I think.   In my mind what's needed is:
>>
>> 1.  an RDF vocabulary with terms like :allCanRead, defined as { ?x :membersCanRead ?y } means every member of RDF Class ?x is allowed to see the state of resource ?y.   There might need to be some tweaking about what it means to be a a thing allowed access -- is it a person, a system holding the user's credentials, a system holding its own credentials but authorized by the user, etc.    Also: :membersCanAppend, and :membersCanModify, etc.
>>
>> 2.  a "protocol" so that clients can learn and modify those access control triples.   The simplest design would be to say access control triples are part of the graph for RDF Sources and part of the metadata for non-RDF Sources.   That might be too simple, but it's a starting point.  Other things one might want include: a way to set default ACL for new resources in a container; a way to set the ACL for a new resource being POSTed; a way to give people the ability to change the data without changing the ACL (separate write and admin privs).   Those would require a more complex structure, such as a specific ACL graph, and the ability to POST multiple graphs at once (which I put on the wishlist, and almost no one thought was important).
> I agree. We just need
>
>   1. An ontology/vocabulary for describing access to resources by agents or groups of agents
>   2. A way to find from a http(s) resource the description of the acl rules for that apply for that resource
>     ( clients may or may not be allowed to view those acl resources, but the server should follow those links to determine who has access )
>   3. a way to edit the acl resources - LDP is the obvious candidate here
>   4. the server should grant or not grant access to the resource if the client can prove that he is an agent that has the correct read/write access to the resource
>   
> There is another topic that is often confused with ACL and that is filtering. It may be another orthogonal spec that specify how a server should filter representations
> returned by a resource so that a client would perhaps see only some parts of what others see.
>
> If the above is then done carefully it would be possible to write those statements in more general rule like manners. One can do quite a lot with OWL
> such as specifying groups of people by attributes they have.
>
>
> All of the above should be done in a Linked Data manner so that groups can be defined on other servers. I would like to be able to grant access
> to group of friends of my friends to be able to write to an LDP Collection for example. Or I would like to make an LDPC that is only accessible
> by people who went to a conference where that group is specified on the conference web site and used by reference.
>
>
>>      -- Sandro
>>
>>> My thought was that policies are situation dependent, so we could standardize the data structures
>>> and use policies to connect the data structures.  The collections could be populated by query
>>> or by enumeration or by some sort of policy.
>>>
>>> Ashok
>>>
>>>
>>
> Social Web Architect
> http://bblfish.net/
>
>