Checking contextual integrity

[Cantor, Scott]

> Well I also forgot that there may be a NOT in the works as well.  That
> basically puts the lie to my assertion that there is a universal "safe"
> solution.

Yeah, I guess so.

> Tom and I kicked it around and it's not obvious how to do this in a modular
> fashion (bearing in mind that you could be deep in a nest of logical
> operations).  This is where I start holding my nose and thinking about
> exceptions:   You capture the exception at the level in which you have the
> knowledge and "do the right thing".

Yeah, maybe so. Or implement it tri-state with indeterminate.

> The other possibility is to add code to doInitialize to pass down a "Fail
> state" boolean (via an extra method that functors would need to get).  NOT
> could just invert it on the way down.  Permit and Permit rules would say
> true, the deny rules would say false.

Other way around, I think?

> What does the SP do, or does this situation not arise?

I guess I should have looked first. No, I didn't deal with it, I went with "define behavior" and just punted. The SP cases are slightly less nasty because the SP always has an issuer to look at, for example. Many of the edge cases don't exist.

One example I saw: if you use a scoped attribute filtering rule against an unscoped attribute, it returns false. If that was inside a NOT in a Permit rule, obviously it would be the wrong outcome. Sort of.

In the anonymous requester case, saying "Deny if requester is X" seems like a good use case to look at. What should that do? Honestly I have no idea, but probably it should deny, which would be the example we're looking for. For Permit we want it to return false, but for Deny we want true (I'm speaking of the underlying predicate). That makes me think exception or indeterminate result is the right solution here.

The analogy there in the SP is my access control layer. There I did use tri-state, and I did it for exactly this kind of reason, to guarantee consistent "favor deny" results.

-- Scott