@User the batching could still be done at ~5000 per, and in series for now

we can look into making sure it works on the SpiceDB side

I imagine we could get reasonable parallelism by limiting it to, say, 100 concurrent calls

@User https://github.com/authzed/zed/issues/94

Thanks for creating that issue! ✨

Any thoughts on how one might model a reduced set of privileges? For example, under normal circumstances, a client might present my service with a bearer identity token. My service would then ask spicedb if the subject identified in the validated identity token has permission to perform the current operation. I'm imagining wanting to give a client a token with some sort of privilege mask. Maybe that means a reduced set of group memberships or only read-only operations. One way to do this would be to create a new identity and only add that identity to a subset of groups, but maintaining a separate identity in lock step with a client's primary identity seems difficult.

@User if you wanted to do this solely via SpiceDB, you could do so by having the subject you're checking be granted relationships on specific sub-relations. as an example:

definition user {
    relation viewer_only: user
    permission all = viewer_only
}

definition document {
    relation writer: user#all
    relation reader: user#all | user#viewer_only

    permission edit = writer
    permission view = reader + edit
}

in this example, you grant a role on

document

to either

user#all

or to

user#viewer_only

. Then, at check time, you can check for

user:whomever#all

as the subject or

user:whomever#viewer_only

, and it'll "scope down" based on that. Since

#all

also includes the lower "scopes", it'll handle that case too Playground link here: https://play.authzed.com/s/NvrMRnPDnnT4/

if, however, your descoping is fully dynamic, you'll need to do it on your end currently

Interesting. I'm trying to grok what a recursive relation like that means. Do you have to store a tuple mapping whomever to whomever with the viewer_only relation?

in this case, no

since you're directly referencing the relation in

writer

and

reader

so how it works in the above example is:

if you issue, say,

check document:somedoc#view@user:someuser#all

as soon as SpiceDB sees

#all

in the

reader

or

writer

, then its found the subject and terminates

if you instead issue

check document:somedoc#view@user:someuser#viewer_only

, SpiceDB will walk

#all

(if it exists for that user) to

viewer_only

and then stop there

so there isn't a need to actually put any data in the

viewer_only

relation (in this example)

I see, so you are essentially declaring that the subject has that relation at check time?

yes

that's why you can use it to "downscope" the user identity

you're saying "check for the

viewer_only

of the user" rather than the user as a whole

I seem to have run into an issue and was wondering if it works how it's expected to work

simplified schema and relations: > definition folder { > relation parent: folder > relation reader : user | group#member > permission read= reader + parent->read > } > definition group{ > relation user: user > relation group: group#member > permission member = user + group->user > } > > folder:bottom#parent@folder:one_up > folder:one_up#parent@folder:top > group:1#member@user:1337 > folder:top#reader@group:1#member

LookupResources on folder#read by user:1337 only gives back top and one_up folders (and as such bottom is missing) it seems it only resolves 1 relation deeper

direct permission check on folder:bottom#read verifies the permission and resolves in having permission

It is however missing from the lookupresources response, is this as expected?

Basically I'd like to know all folders that are reachable for that user/group

It should return all reachable. It’s not obvious to me from the sample why it wouldn’t be.

That's what I thought as well

(it's queried with fully consistent consistency by the way)

Can you file a bug on the spicedb repo?