Re: Access Control Charter

Also,
{ ?x :membersCanRead ?y }

Is a policy, or the result of processing a policy, that applies to that class/collection

On 4/27/2014 3:00 PM, Sandro Hawke 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).
>
>      -- 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
>>
>>
>

Received on Monday, 28 April 2014 00:03:16 UTC