Expand does not include userset rewrites

[rdurell]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Cloud project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe the bug

Using the data from the userset-rewrites example, the expand route does not include implicit tuples from defined by the userset rewrites. A check command will return "Allowed" but the corresponding expand command returns an empty tree.

Reproducing the bug

Note: You may need to include --insecure-disable-transport-security flag for the commands below.

1. Load the tuple data referenced from the userset-rewrites example
2. Run "keto relation-tuple get" and ensure the output is as follows:

NAMESPACE OBJECT RELATION NAME SUBJECT
Folder keto/ viewers Group:developer#members
Folder keto/src/ parents Folder:keto/
File private owners User:Henning
Group developer members patrik
Group developer members User:Henning
File keto/src/main.go parents Folder:keto/src/
File keto/README.md parents Folder:keto/
Group developer members User:Patrik

3. Run "keto check User:Henning edit File private"
   Note the output is "Allowed"
4. Run "keto expand edit File private"
   Note the output is "Got an empty tree. This probably means that the requested relation tuple is not present in Keto."
   Expected -- The tree would include some implicit tuple representing the rewrite.
5. Run "keto expand owners File private"
   Note that the output includes the explicit tuple loaded from the sample data:

or :#@file:private#owners
└──∋ :#@user:Henning️

Relevant log output

No response

Relevant configuration

No response

Version

0.10.0-alpha.0

On which operating system are you observing this issue?

Linux

In which environment are you deploying?

Binary

Additional Context

No response

[hans]

yup I'm struggling to understand the subject-set rewrites for precisely this reason. The permits attribute of the namespace configuration seem to allow you to specify subjet-set rewrites. That the permits section is effectively the subject-set rewrite feature is also not well explained in my opinion. I couldn't build that bridge in my mind, until I read the original paper. But back to the point, the edit permission is effectively a relation and in my opinion should be represented by an edge in the tree of the flattened DAG. Which is what the expand command should be doing no?

[Robin van Boven]

I wonder if this rationale should also apply to the List API.

If the permits section is "just" a way to define a relation using subject-set rewrites. Then supporting the subject-set rewrites for both the expand and list endpoint's relation argument would be consistent right?

But yes, would love to see this feature 👍 since as it stands the only workarounds appear to be:

• Duplicate your understanding of the rewrites in your application, by listing the normal relationships instead.
• Do a large number of check queries for each potential tuple.