Proposal: Allow negation

[elf-pavlik]

@RubenVerborgh it would be good if you and @ericprud document why in solid ecosystem having statements which take precedence over other statement doesn't cause issue. I believe @ericprud has good understanding of nuanced concern raised by @timbl, I recall @zenomt discussed negation with him on gitter.

[justinwb]

I added some thoughts on negation at https://github.com/solid/authorization-panel/issues/91#issuecomment-665372876, but for posterity will record my 👍 for pursuing negation in this thread as well.

[bblfish]

Negation as allowed by OWL2 would be definitely very useful. Ie. one wants to be able to saythat a class C of agents less another class N of agents can have access. It looks like one should be able to model this in OWL2 by saying that the desired class is the intersection of C and the complement of N.

Doing negation on ACLs, ie restricting ACLs, while respecting RDF monotonicity is also an important problem. I have a proposal in #91 comment which has an implementation to go with it using Linked Data follow-your-nose principles.

The problem bit comes if one tries to have two acls one that gives access to a resource and the other to class C of agents and another which tries to restrict it

[acoburn]

huge +1 to simplicity when it comes to ACL enforcement rules

[zenomt]

@RubenVerborgh the approach i took with exclusions in my implementation is substantially this; however, it's per acl:Authorization. that is: an acl:Authorization does not authorize an agent that is excluded by any exclusion rule, and if not excluded, then the acl:Authorization can explicitly allow that agent. the agent is granted the requested access if there is at least one acl:Authorization that allows the agent and that doesn't exclude the agent.

this allows you to say something like "all of my friends except for Bob, but all admins (including Bob)".

here's the comment for acl:excludeAgent: "No Authorization, where the Agent is the object of this triple, shall be eligible to authorize an Access." comments for excludeAgentGroup and excludeOrigin are worded similarly.

[ericprud]

We should probably include a little text like: [[ wac:deny MUST be expressed without inference. For instance, the following is not permitted:

my:deny rdfs:subPropertyOf wac:deny.
# ...
<#rule1> my:deny <http://...Ruben#id> .

]] for whatever property we come up with for DENY.

[bblfish]

I would suggest first trying to see what can be done with existing OWL standards, before inventing systems that break important reasoning principles and may lead us into the well studies complexity problems which were the reasons for the emergence of those projects and standards. That exercise will likely reveal sweet spots that allow early implementations that are open to future extensions. If we do this ad-hoc with defaults and without thinking things through, we are going to end up with a huge mess.

[ericprud]

The problem is that we don't want future extensions of a negation 'cause today's implementations will leak tomorrow's secrets. I think you're pretty much stuck with either a no-inference rule like above or an explicit list of denies, the expressivity of which must never be extended. The latter would mean that almost every ACL would have:

<#rulen> wac:deny () .

except for the few which actually had some entities in the deny.

[bblfish]

I am happy to look at this use case in detail and try to see what options are available using OWL and other existing standards (standards take forever to put togethe so one should not re-invent them). I am currently looking into the relation of Description Logics (OWL-RL in particular) and Functorial Database migration with @wisnesky from the MIT spinoff conexus.com, and access control is also part of my PhD. I think the consequences of a decision here are serious enough to warrant a serious formalisation.

[ericprud]

I have no issue with modelling this in OWL but executing ACLs with OWL would, IMO, pretty much kill its deployment. If you have negation, every implementation must confidently recognize it and either support that exact expression or abort (meaning no one gets access). If you allow inference of a negation, you must specify exactly what inference is allowed. (My proposal above is a degenerate form of that where no inference is allowed.)

[bblfish]

Yes, I think that modelling wACL in OWL would allow us to come up quickly with some ideas on how to tackle this and other problems. Such a model would allow us to get a better idea of the design space and allow us to see what other use cases could be covered by a more generic framework.

That would allow us to also find what I called sweet spots: namely pieces that can easily be implemented now, but that would be future proof as the system develops. (I understand your proposal as proposing such a sweet spot. I would just like to see clearly how it fits in a bigger picture to make sure it is well designed)

Having such an OWL model would also allow one to calculate the complexity of reasoning required for an fuller OWL version, enabling us to calculate the cost benefit advantages by seeing how many extra use cases can be resolved with it, and if needed get started now on building tools that can later be widely deployed.

[justinwb]

Just a reminder that “simple” is the keyword.

☝️ this 👆

...And I'd also add "predictable" as an equally important keyword. By its nature, access control should be very explicit, because one of the worst things that can happen in an access control system is for a rule created by a controller to not behave exactly as they intended it to behave.

Consequently, inferencing in general seems problematic in this context (which is what I believe @ericprud is getting at). A rule should be applied exactly as intended by the controller when they created it. I think this is also an essential part of simplicity.

[bblfish]

@RubenVerborgh

Just a reminder that “simple” is the keyword.

and so is future proof :-)

The answer we come to has to be simple, yes. But there are many seemingly simple answers that can lead to huge complexities further down the road.

• For example the folks who started the MetaWeblog API started with the loudly declared aim of simplicity. They understood simplicity in terms of what they knew ( Remote Procedure Calls (RPC)), developed XML-RPC, and ended up with SOAP, which was far from simple and even with the money poured into it by the software giants of the time, ended up popping like a bubble.
• One needs to consider problems in reasoning complexity that have been widely studied, and which show that sometimes adding a minor concept to a language can lead to a complexity explosion. Luckily a lot of the work has been done already and even standardised in OWL. So using that gives us the ability to reduce our work by drawing on existing work at the W3C on the subject.
• Since we are working at building a secure access control system, it seems that this requires a formal basis enabling one to be able to prove properties of the system. Such a basis will make it much simpler to reason about why certain features are problematic and which are needed. I don't think anything less will convince the professional skeptics and paranoids in the security industry that the system is solid (or predictable (wink to @justinwb ))