this might make an interesting additional API however, so feel free to put together a proposal as an issue

Because user maintenance is complex in our case, can't link group to the users inside spiceDB

then yeah, you'll need to check per group

since SpiceDB won't have any way to know how the user is related

Default permission idea

I have a few questions on the Caveats proposal. Here's the original text for reference

Allow small fragments of policy to be associated with individual relationships in a new field called “caveats”. As we attempt to evaluate permissions these pieces of policy will be combined and surfaced as immutable caveats that apply to the result sets as they are collected. Before the result is returned to the user, a final policy is assembled and evaluated against user-supplied attributes, and a final decision is made.

Because the caveats are immutable and apply to the sub-problem, they can be cached at every level of the decision making process.

Will the policy language be built around a fixed set of attributes like time, day ... or would there be a way for an application to define the attributes. - When you say 'user-supplied' attributes, what do you mean? - When are these attributes supplied? - How are these attributes expressed? - Do you plan to support different data types for these attributes? Just wanted to add that I find the Caveats proposal super useful and would greatly help address some of our use cases around time based and location based access.

We don't have a concrete design yet to answer all of those questions; there are a few different options we've discussed that would have different properties. If you can give examples of the time and location based accesses (ideally in the github issue so we don't lose track!) that will help us evaluate designs going forward But not to leave you hanging, these are my best-effort answers to what things might look like: > When you say 'user-supplied' attributes, what do you mean? If you have a relationship with a time caveat, you provide us with the "current" time to evaluate against. > When are these attributes supplied? Likely when you make an api call like

Check

. This proposal makes a distinction between the policy/attributes associated with a relationship (which would be provided when the relationship is written) and attributes that you provide at query time to evaluate against the stored relations. > How are these attributes expressed? TBD, but ideally in a way that won't tank cache hit ratios. I would think something datalog-y so that rule evaluation is order-independent, but we don't have any concrete proposal yet. > Do you plan to support different data types for these attributes? Also TBD, but probably. Distinguishing time at a minimum seems valuable to me, but other folks may have other ideas.

How can we have attribute based access, Like If user belongs to marketing department has access to marketing document, if belongs to finance department has access to finance document. Department is an attribute of user.

Thank you. It works well now.

Usually you would set up department as a group, make the user a member of that group, and share the document with the group

Look at the google docs sharing example in the playground and just change the usergroup to department

i saw that there's an

authzed/zed

container on the docker hub registry, but it's currently empty. it'd be nice to use it for CI with schema validation and the like. is there a plan to get a tag published?

looking at https://hub.docker.com/r/authzed/zed

use quay.io/authzed/zed:latest

looks like an oversight in the publish for zed; I'll get it fixed

thank you!

Some thoughts. Attributes fall into three buckets: - Attributes of an user or a resource - Attributes passed in with the Check request - Environmental attributes such as time In order to support #1 in an elegant fashion, we would need a way to talk about instances of objects (and not just relations). Force fitting attributes of objects on to relations seems like an ugly hack. At the moment, I can't think of any use case in our domain that would need #2 If the time zone can be set as an attribute of the object, then the caveat can express the time based condition on the user's or the resource's frame of reference.

I will add some notes to the github shortly

> based condition on the user's or the resource's frame of reference

that's why the proposal is for time to be passed into the Check

SpiceDB doesn't know the environmental conditions, so it would be up to the caller to specify them

definition group {
    relation member: user | group#member
}

I am taking this from the example of sub relation. How are the group has to be related to here ? is it recursive in nature?

yes

you can relate a group's member to include the members of another group using that syntax

@Joey How do I create relation between the groups?

you mean the actual relationship?

in playground syntax:

group:firstgroup#member@group:secondgroup#member

in the API, you specify the second group as the subject of the relationship, with

OptionalRelation

set to

member

@Joey thanks