but are tokens granted permissions independently as well?

e.g. I grant a user

viewer

and then have to grant the token it as well?

Technically I don't care to strict this on a create relationships level, but I want to have this to be checked on a check permission level

or is it "because user is viewer, token is viewer"

I have two options: 1. When token inherits all user permissions by default

user:user_id#inheritor@user:access_key

2. A user creates a token with restricted permissions, for example: just read only access. But if user has no access to some resource even to read, the token should not have an access too

Currently I solve this on the App level, To check permission for access token I do: 1. Check permission for the user the token belongs to 2. Check permission for the token 3. If both checks

true

token has access So I do 2 checkPermission API call, which seems incorrect.

but you always want to check the token itself, as the subject, correct?

so, at a high level you could use an intersection to do this:

definition token {}

definition user {
  relation token: token
}

definition resource {
  relation viewer: user | token
  permission view = viewer->token & viewer
}

check

resource:foo view token:whatever

but if you do ^, you need to add the token and user independently as relationships (if that's your intention)

alternatively, you could just say "any token reachable through the user":

definition token {}

definition user {
  relation token: token
}

definition resource {
  relation viewer: user#token
  permission view = viewer
}

now you'd say "all the tokens for a specific user are viewer"

Yes, that's correct

so it really depends on whether you want to add the users and tokens independently, or if you want to always say "all of this user's tokens"

It doesn't matter if they are added independently or not, I just need to find a solution to ask the database not to grant access to a token if an associated user had no access. An intersection might work.

intersection is only necessary if they are independent; if they are dependent, you can use

user#token

Currently user and token are independent, But it looks like I need to use access token as a user relation

user.token

Have you picked a syntax yet for representing caveated assertions in the playground? Context name and value in json format would get my vote

its in development as we speak, but likely:

assertTrue:
- 'document:foo#view@user:bar with {"some":"context"}'

Hello everyone, We are planning to add Spicedb to our existing docker-compose based environment, currently we are using Eureka for service discovery. Is there any way/walkthrough to register Spicedb as a service within Eureka? Thanks

currently we only support DNS and Kubernetes based discovery, but I imagine it wouldn't be too hard to add support for another discovery mechanism, so long as it has a good API

reader + writer means reader OR writer? is this some kind of graph syntax that I'm not aware of, that seems incredibly counter intuitive

yes; it means it'll consider users found in

reader

or

writer

, because its actually a set: you're saying "find users in the set of `readers+writers`"

ah ok

https://authzed.com/blog/check-it-out/ if you want a visual representation of how the set-like semantics work

weird why it's so hard for me to wrap my mind around this. Can I ask an example, let's say I have a document and everyone has permission to view it. But somebody adds gore to the document, now only admins can view it until the gore content is removed. Is this still possible with authzed/spikedb, because wouldn't that mean that I constantly have to rewrite permissions for all users, adding specific exceptions for a specific document? it could be an incredibly write heavy load on the spikedb right?

this is doable using an exclusion: you'd write a relationship removing all users like so:

definition user {}

definition document {
  relation admin: user
  relation restricted: user:*
  relation viewer: user

  permission view = (viewer - restricted) + admin
}

normally you'd leave

restricted

empty

but if you need to restrict it, you could write a relationship to

user:*

, causing

viewer - restricted

to be empty

alternatively, you could use a caveat if you expected the restricted status to be more dynamic:

definition user {}

caveat not_restricted(is_restricted boolean) {
  !is_restricted
}

definition document {
  relation admin: user
  relation viewer: user with not_restricted

  permission view = viewer + admin
}

is_restricted

would be passed into the

CheckPermission

request