The permission is defined on the token. The resource and token have no relationship, but the view logic of the resource depends on the token

how will the resource relate to the token?

I don't think it can be through the user. To be more specific, right now tokens are associated with applications, which can be internal or external. The view logic of the resource is dependent upon the user and which application (which have associated permissions) it came from. I don't really know how to tie the resource to the token or the application because resources they are created by users. For a more concrete and less abstract example, let's say this is for Posts on a website (doesn't really matter if it's a blog or social media post or w/e). That post is created by users. Let's say the site also has an API where applications can read data from it. So the logic would be: 1. The post is viewable if the user is the owner. 2. The post is viewable if the application making the request has a specific permission. The request comes in with a token and that is associated with a user and application. The problem is I don't know how to define or link post to the token

ah

So is the idea you're getting at kinda like the following? I tried to use the more concrete example from the previous message.

definition user {}

definition extra_permission {}

definition token {
  relation user: user
  relation extra_perm: extra_permission
}

definition post {
  relation: token: token // so every time a token is created, it would need a link to all posts in the DB and same with if a post is created.
  relation owner: user
  permission view = owner + token->extra_perm
}

I think this implies that everytime a token is created we would have to enumerate all posts and create an entry in the DB linking them, same if a post is created, we have to enumerate all tokens and add a relation. Is that right?

only if the tokens are being granted access explicitly on a post

> I'm still not understanding how a token is supposed to relate to a post It's not. The business logic right now is the token permissions get passed around with requests and there are a number of them (like 20) which apply to different parts of the product. Those permissions are mainly there because users can authorize applications to read their data. So when a request comes in, there might be a normal authorization check to see if the user is authorized to view something, but also if the permissions on the token allow it to be viewed. Technically there are permissions on the token and on applications that are tied to the token. But we can ignore the ones on the token for now and go down the application path how you mentioned. Pulling from your example, the closest thing I could get to is something like this:

definition user {}
definition view_post_perm {}

definition application {
  relation view_post: view_post_perm
}

definition token {
  relation user: user
  relation application: application
}

definition post {
  relation owner: user
  relation viewer: token
  permission view = owner + viewer->application->view_posts
}

This solution supposes that we have to create a link between every token, and every post. Not sure if that would be tenable because we have millions of users, each with tens of tokens and ~10billion posts. Alternatively, I guess we could just not wrap this question all to one query and instead do two queries. Like this:

definition user {}
definition view_post_perm {}

definition application {
  relation view_post: view_post_perm
  permission view = view_post
}

definition token {
  relation user: user
  relation application: application
}

definition post {
  relation owner: user
  permission view = owner
}

Then ask

val userId = /read in
val appId = // read in
val check1 = post:123 view user:userId
val check2 = application:appId view
return check1 || check2

Seems like it defeats the purpose of zanzibar though.

not really; if you have two distinct types of subjects, then it makes sense

I believe so yes

are the tokens or their permissions dynamic or predefined?

both are predefined, the permissions are created when the token is

in this example:

definition post {
  relation owner: user
  relation viewer: token
  permission view = owner + viewer->application->view_posts
}

why do you have the viewer as a token? aren't you checking to see if the token can view the post?

Yeah I am. I thought I needed a relation on it, but that might be wrong, seems like you think it is!

right, so that means you need to reach the token from the post

Okay thank you so much. This is still new to me and I really appreciate the help. I might need to do a deeper look at our permissions because if we need to add token relations for every single entity, things may get tricky/costly

if you like, you can grab some time with us on https://authzed.com/contact and we can go over this in detail

Sounds great, will do. We will probably also be interested in trialing the product at some point 👍

great

I sent an inquiry on the contact page last week on monday or tuesday. Not sure if 1 week is within the normal turnaround time or if the email was missed, so I wanted to follow up

@connor email or did you sign up for a calendly time?

Email

okay; I'll double check and make sure it didn't somehow end up in spam accidentally

Yeah no problem. The reason I emailed was to set up correspondence first. My company's legal team typically wants NDAs if we'd discuss specifics about our companies data. Not sure if we would in an intro session, but didn't want to jump to a scheduled time yet. thank you

makes sense

Yeah no problem

got it

No worries. Glad I mentioned something

agreed