[diggs]

A use case that I wish authorization service providers would talk more about is support for "list" queries e.g. What resources of type foo can the user read?

In really simple cases you may model this as a one-shot check on a logical collection resource e.g. If I have an organization, and an organization owns many repositories, I may check for action:read on resource:/organizations/:id/repositories. It's very limiting though. What if I want to list all repositories across all organizations I have access to? What if I have multiple levels I want to cut across? Do I need to do all the sub-queries and aggregations myself? Do I need to do a one-shot check on every potential resource? What if the answer is "no" for every one, and I end up doing a table scan of the entire DB just to produce an empty result set? etc.

[jschorr]

The problem you're describing is sometimes called the "ACL Aware Indexing" problem [1]. In a permissions service based on Zanzibar, this can partially be solved by walking the permissions graph in a reverse fashion: SpiceDB exposes this API as the LookupResource API [2]. However, even this approach has performance implications for very large datasets, so we're also working on improving resource lookup via a LookupWatch API [3], which can be used by consumers to actively cache the available set of resources as access changes over time.

[1]: https://authzed.com/blog/acl-filtering-in-authzed/

[2]: https://buf.build/authzed/api/docs/main:authzed.api.v1#authz...

[3]: https://github.com/authzed/spicedb/issues/207

[jen20]

According to one of the original designers of Zanzibar, they specifically designed the semantics to be able to answer this [1]. Whether a given implementation is able to do this efficiently is another matter though!

[1]: https://mobile.twitter.com/leakissner/status/141001671864303...