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

On 04/28/2014 10:36 AM, Ted Thibodeau Jr wrote:
> 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...

Yes, indeed.   People seem to prefer to call them 'vocabularies' now, 
though.

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

Well, that's still a protocol.   There has to be some way the clients 
and servers agree about where to get at the triples that are being used 
to perform access control.   One might call it a "convention" or 
"mechanism" if the term "protocol" doesn't feel right.

Incidentally, this is similar to how w3.org and rww.io work.    I think 
Eric built w3.org's ACL system this way in ... 1998?

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

Indeed, I didn't mean to suggest access control was only for RDF 
Sources.   I talked about how the access control triples might be in 
different places for RDF Sources and non-RDF Sources.

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

My inclination is to just do per-document access control.   If you want 
something more fine-grained, then use smaller documents.   I think it is 
reasonable, however, to track access control through merging -- so you 
might have a graph formed by merging 100 different graphs, and so a 
given user who can only see some of those hundred can only see part of 
the merged graph.  If you do the merge at request time, its easy 
enough.  If you want to pre-calculate the merge, it gets very tricky.   
Do you let the user know he's seeing a partially-obscured graph?  Probably.

In general, I think the policies are best thought of as logical 
reasoning problems.   Given an agent X trying to read resource Y, the 
server needs to determine logically whether { x allowedToRead y } is 
true.   If we have OWL RL reasoning, that's easy to implement and allows 
all sorts of nice logic for managing groups.

What's tricky, though is what you mention at the end, which is 
defeasible reasoning.  That's not offered in OWL, although it is in some 
rule systems.   It's NOT in the w3.org ACL system, which is kind of 
annoying, but we manage to live without it.   On w3.org, every resource 
has its own ACL; there are no groups of resources, so there's no need 
for exceptions.     I think it's an open question which style is more 
error prone.   As long as the logic is properly defined, it's at least 
computable whether given certain ACL triples whether { x allowedToRead y 
}.    Defeasible reasoning doesn't fit with RDF terribly well, because 
you'd usually use ordering to say what takes precedence, but I'm sure 
people have written papers about how to do it.

      -- Sandro



> 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 15:52:24 UTC