Re: [Web? Internet? LDP?] Access Control Draft Charter

for ease of reference... https://www.w3.org/2012/ldp/wiki/AccessControlTake2 


**** 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?


*** On 04/27/2014 10:26 AM, ashok malhotra wrote:
>>> If we create a standard for Access Control should we
>>> specify policies or data structures?


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

Sounds like an Access Control Ontology, to me...


>> 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'm not sure that a *new* protocol is needed, but perhaps
some examples that say how to use existing protocols (like,
oh, say, LDP) with/for Access Control documents.

As an implementation example, we have various documents in
a WebDAV repository, which have associated ACLs in nearby
Turtle docs (which may have their own associated ACL docs).
Changes made to the ACL TTL(s) have immediate effect on 
accessibility of the associated document(s).



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


* On Apr 27, 2014, at 07:51 PM, ashok malhotra wrote:
> Some reactions ...
> 
> First, I don't want to restrict access control to RDF

I don't think such restriction is integral to what Sandro had 
to say, though his wording could be read as focusing on RDF
and RDF-related examples.



> Second, when you say "every member of some RDF calls can
> read ..."  I guess you mean that the class consists of a
> collection of identities and all the identities in the
> class can ... ?
> 
> Third, it's too onerous to specify access to a single
> resource. Better to specify access to a collection/class
> of resources.

At this stage of development (use-cases, requirements, basic
comprehension and problem analysis), I think that while we do 
need to remember that implementations and deployments will 
require the ability to control access at the class/collection/
group/directory level, we should start focus at the atomic[*] 
level, and expand/refine on that with groups/classes/etc.

[*] I am not certain what the atomic level really is here -- 
    document, triple, subject, subject+predicate -- but I am
    fairly certain it's at least document, and being able to
    say that "most documents are WORLD-READ, but *this one*
    is OWNER-READ, WORLD-NONE" seems key.

Regards,

Ted


--
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
         10 Burlington Mall Road, Suite 265, Burlington MA 01803
     Weblog   -- http://www.openlinksw.com/blogs/
     LinkedIn -- http://www.linkedin.com/company/openlink-software/
     Twitter  -- http://twitter.com/OpenLink
     Google+  -- http://plus.google.com/100570109519069333827/
     Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers

Received on Monday, 28 April 2014 14:36:52 UTC