OK... I've been hit by a late breaking requirement that permissions have to be a function of the subject and azp claims in the JWT token. For example, normally if the subject is an investor, they don't have read access to deals they aren't invested in. But if the authorized party is a specific type of widget developed by us and administered by a client organization that owns that deal, the user does have read access. Any tips on modeling that without rewriting my model from scratch? I'm mostly thinking that that azp goes into userset namespace and the client has to make 2 spicedb calls; if either call returns

PERMISSIONSHIP_HAS_PERMISSION

the API proceeds.

yeah, you have two different subjects so that would be the way to do it for now

another idea I had would be taking the cross join of AZP and user and making that into a resource

yeah that would also work but that sounds awful, you would have to know what all of the azps are to add a user

Can I have it by 4/1? That's our in-production go-live 😅

no

But I'm talking about qualified no's 💦

i mean... it's a no where there are no possible exceptions haha

We have triggers handling our spicedb population so that's not the worst thing, but insert performance would be felt.

insert performance should be fine because you can write all of the relationships in the cross product in a single

WriteRelationships

call

We can't use the API to write relationships

how many azps are there?

We have DMS inserting records from MySQL

how many do you expect there to ever be?

Hundreds?

sure, but these can also insert multiple relationships in one TX, right?

Yep they can.

I would probably just do two calls until you have caveats

But the trigger thing is solved-ish. We have subsecond inserts which is fine.

for posterity: with caveats you would just write a relationship from the resource to

users:*

with the caveat that azp == "the whitelisted always allowed azp"

Yeah that sounds like it'll do what we need.... eventually