and if it is

true

, then

not_restricted

is

false

, causing the each

viewer

relationship written to use that caveat to become "hidden"

in either case, you're either writing a single relationship when it becomes restricted, or just passing it to the Check

thank you, that's interesting. I think I simply need to learn every single schema language feature and then it will be more obvious how to do things

we're happy to continue answering questions here too 🙂

Hi, Is there a way to disable permission inheritance from parent and assign new permissions? similar to windows file system? I assume the answer is no but wanted to ask. I read the docs. I know Auth0 FGA has this block_parent relation that does this but that is not part of Zanzibar paper. Can this be done with exclusion?

not sure what you mean, exactly. can you give an example?

In windows, files and folders inherit permissions such as groups read,write, execute. On a specific folder or file you can disable inheritance and provide total different permissions. Different groups that are not on the parent folder. This allows you to block the parent folder to see or read/write the child files or folders. It is an ACL (access control list). Example; folder1 has folder2 as child and file1 is under folder2. folder1->folder2->file1. folder2 and file1 inherit permissions from folder1. You can disable inheritance on folder2 and add totally different permissions on folder2. file1 inherits from folder2. I know this seems weird but normal use case in a windows file system.

but you want this inheritance to occur sometimes?

yes most of the time the inheritance is wanted.

it would be fairly easy to define a schema where inheritance only occurs if you wish it to do so

if you don't, you could just not write the

parent

relationship

interesting, makes sense. will noodle on that. So, on folder2 above I would remove the parent relationship to stop the inheritance.

yep

you could also have a different relation, like

parent_inherited

, if you need the

parent

for something else

write both if you want to inherit; otherwise, only write

parent

assuming you even need the parent for something else

you could use exclusion to "remove" the parent permissions, but why add them in the first place if you'll just remove them? 🙂

right. Thank you. This was super helpful. The parent is a container that can't access its children. It knows they are there (list but not read/write).

yep; the only relationships that exist are those you create. if you don't need it, don't add it

Hey 👋 I'm in the part of my integration where I'm considering the ZedToken usage. I have a multi tenant setup where ressources are stored into Organizations and can be shared inside the Organizations. As each Organizations are standalone, from a ressource sharing stand point, I'm thinking to store a ZedToken on the Organization records, update it everytime there is a write happening on an Organization ressource and use it for all reads.

Problem is, my APIs can be used to fetch data from different Organizations at once -> it is possible to list all records a user have access accross all different Organizations he has access to

(some customers have a multi organization setup to manage different envirronment and we use this capability for support enquiries internally as well)

When no organization is passed in the APIs, I can fetch all organizations the current user has access to and get their ZedTokens but I'll have multiple ZedToken and no idea of which one is the latest one. Is there a way to compare the freshness of two ZedTokens to select the fresher one to make the reads calls (checkPermission, ressourceLookup)?

Should I put a "updated_at" next to the stored "organization ZedToken" and use it to select the latest ZedToken when performing a cross organization API call?

I'm struggeling to see how to principially solve this problem: I have a ressource that can have users of type 1 and 2, any type 1 user may read all type2 users special info if they are related to the same ressource, otherwise not. But any type 1 cannot read other special infor of type1 users. And type2 cannot read other type2 users special info regardless if they are on the same ressource. . This tell me that it should not be modelled on the user definition as its the ressource relationship that creates the permission link. It should be possible to have several ressources that could reuse the same type 1 and 2 users in some instances, and then be able to remove a single ressource with the accompanying permisisons while still respect that other ressources ay still be actice and allow for the same permission. definition ressource{ relation user_type1 : some_user telation user_type2 : some_user } defintion some_user{ permission can_read_special_info = ? } any suggestions ?

does anybody has the permission definition for this project? https://github.com/authzed/prom-authzed-proxy/tree/main

you use whatever permission you like; its passed on the command line as part of the flags

mhh, thx for your answer. can you eplain me a little bit more?

ZedTokens are only necessary if you need to ensure that you're checking consistently against a version of content that changed; in the vast majority of cases,

minimize_latency

is perfectly safe, so long as you're okay with there being a slight delay between a relationship update and the associated check result changing

rarely, if ever, do you need a ZedToken at the "top" level