User incorrectly granted access due to an invalid relationship about keto

[cmmoran]

Ah. You have hit the heart of the challenge that the ory:keto creators faced when they decided to create the OPL. The OPL parser is not a compiler. It's a loose transpiler at best. To be completely unfair, calling it a converter would not be totally wrong either.

The point is: while the OPL looks like typescript, it is most definitely NOT true typescript. It makes sense though. What OPL really does is it gives developers the ability to define keto's configuration using a language that we're familiar with. While our IDE's give us nice typechecking, when the permission model is built by keto, the namespace models are not fully typechecked and there are ways (as you have discovered) to "fool" the typechecking that is being done.

As a case-in-point, during a traverse, the parser determines the types for the relation being traversed (which in your example is: parents). And it will discover that type to be Organization. A check is performed to ensure that parents in-fact exists on the current namespace (Organization) and within the traversal the relation view is checked to ensure that it exists in All of the relevant types (see above) associated with the parents relation. That's it. No check is made to ensure that the thing is, in-fact of type X or Y. From keto's perspective of a subject, it's irrelevant.

I say that but you hit on a weakness of OPL as it stands today. Right now the types associated with related fields is, in the words of Hector Barbossa (youtube link): "more whatcha call guidelines than actual rules". What that means is this: the type only matters when it comes down to either 1. traversing that relation or 2. resolving a permits on that relation. Keto's parser will check that the type associated with that relation (for example parents) has the associated relation to be traversed (for example: viewers) or the associated permits (for example: view). In this case, unfortunately (and rightly confusingly) Shop does, in fact have a relation (a dynamic one under permits) called view. But so does Organization. What this means is that, when rules are checked, if a relation is created that associates a Shop where only an Organization is expected, it will work not as you intended but it will work as it was designed because both namespaces have the relation named view, so the typechecks will pass.