the first prototype was actually written in python though!

There are also lots of databases written in Go and we can reuse some of their efforts. For example, we use dgraph's ristretto library for caching.

ohh I see. That's fantastic. A working background in Go certainly helps

awesome to see the launch.. and thanks for supporting Postgres as a backend

Yep, only one real issue to note with the postgres datastore: https://github.com/authzed/spicedb/issues/144

Hi! Never deployed an external permission system in prod, but I've experimented some with OPA. SpiceDB looks really interesting though!

@User let us know if you have any questions

Hi

👋

We just cut another release of zed with some fixes. It also installs shell auto-completion on install:

brew upgrade zed

or check out the release notes: https://github.com/authzed/zed/releases/tag/v0.1.1

I'm playing around a bit with the zed CLI, and I'm not sure if I'm just using it wrong or if there's a bug in `permission lookup`; the gRPC service spec says the response should be a repeated string, but the actual response ends up being just a single resource, which changes. So in my sample, I have access to two resources through a relation (user attached to a company, company attached to two things), and I'd expect to get both listed. Instead, half the responses come back with ID 1, and the others with ID 2

And for a question on modelling permissions: does it make sense to model guest permissions through this kind of system too, and if so, what's the best approach? I suppose more generically, this is a question of "how does it make sense to model global permissions" – in our case we do recruitment software, so the guest user might be a job applicant, who naturally should have the permission to submit an application

What version of zed? We pushed a fix just recently because lookup had some bugs in it

It can make sense to model guests, but also it makes sense to just not check any permissions if it's public. We've got an issue open for adding the concept of "public" to make things easier: https://github.com/authzed/spicedb/issues/1

Yep, what I'm looking to achieve is for the authz layer to decide on if an action can be performed on an entity, which is why I'd like to defer that to the authz layer. Of course, I can also build the authz service on top of zed/spicedb, but not keeping it in the db means I can't log it for auditing in a consistent way.

And further, is there a reasonable way to model attribute-aware authz within spice, or should I keep an additional layer on top and combine zed policy decisions with attribute-based decisions?

This makes a ton of sense. We're still fleshing the UX on this out a ton. I would post on the GitHub issue wrt to public and maybe make a new issue that asks about auditing. We've discussed auditing a bit internally, but want to collect use cases from users before implementing anything concrete. The v0 API has a "watch" functionally that can be used to tail all changes, but that might lose context from your app. In the past, we've typically kept audit logs at the app layer so we could attach as much metadata as possible.

This is another space we want to invest in simplifying in our schema language. It is possible today, but more complicated than it should be. I could link a paper on the subject, but I'll need to dig to find some example schemas for it. During the work week, we'll be writing docs and checking in more examples.

Examples and papers would be an extremely useful starting point. To follow up on a related matter, if we wanted all authorisation logic to happen in one place, that also means authz decisions based on data like IP address (for a hypothetical, let's say an internal system that can be used by our staff and requires access to be on-prem/VPN. How do you reason about that in authz logic? Since that requires some ephemeral data (IP being request-bound). You could of course do it through attributes, just asking the question out loud more than anything to see if there are good ideas

in general, we draw a distinction between "dynamic" decisions (IP, time of day, etc) and "structural" decisions: the former is a just-in-time decision, while the latter is a permission. If the data the decision is being made upon is truly dynamic, the recommendation at the moment is to use code or a policy engine (like OPA) to make the decision, while having said code or engine call Authzed/SpiceDB to retrieve the permission. We have an experimental integration with OPA in zed here: https://github.com/authzed/zed/blob/main/cmd/zed/experiment.go. Alternatively, if the data is updated on a periodic basis or based on a user action, then you can write said data into SpiceDB as a relationship, and

check

it from there. For example, a valid IP address could be written for a user, and then a user's permission could only succeed if that IP address `check`s

we're currently investigating how to make these two halves of authz more integrated

Just to make sure I understand the Zed part in this – storing an IP would require some form of attributes right? I guess theoretically you could have another definition for an IpAddress and let it's identifier be the IP or something crazy, but yeah, makes sense to treat dynamic and static ones separately (or rather, as distinct things, even if in one system)

attributes are one option, yes. You could also use a definition as stated, and then

check

the IP

the latter would be used if you don't expect the IP to change often

for example, if you had an IP whitelist, you'd store it as a relationship

Sure, yeah

we've found that, in practice, the vast majority of authz decisions are based on relationships established previously

Hello World, I am rishabh mishra, I work at Gojek Bangalore. We are working on Authorisation for internal tools and using casbin for that. We are facing some performance problems with that setup. I am interested in trying out SpiceDB.

> the recommendation at the moment is to use code or a policy engine (like OPA) to make the decision Is it a long term goal to add features to SpiceDB and not have to use something like OPA? or is it a design goal for SpiceDB to run alongside a policy engine?

This is actually totally open for discussion. I mentioned in this thread that we've discussed having some kind of server-side component for processing policies as well. https://github.com/authzed/spicedb/issues/158