A suggestion for improvement: consider using “version” instead of “name” for identifying authorization models. While stores benefit from having unique names tied to their domain, authorization models are better suited to identification through meaningful versions, such as 1.0.1 → 1.0.2 or Git commit hashes. The store already provides the domain context.

Hi @aaguiarz,

I'm thinking - instead of constraining the API with one extra name property - it could be more flexible to make it possible for the consumers to add any number of tags (inspired by k8s labels).

This can open the possibility for multiple use-cases. E.g:

• Use the tag to uniquely filter the authZ models by a unique tag known to the consumer. In this case the consumer can tag the model with the commit hash: commit-hash:1374e4b
• Use the tag for rolling out an authZ model to a specific environment. In this case the tag can be release_approved. For this to work though, I'd imagine extra changes are needed to select the latest model that has a specific tag, instead of selecting the latest available model - in case the user does not specify the model ID when calling the check/list users/list resources APIs.

This will also address the comment above by letting the consumer decide how to structure/call the tags (version vs name etc..).

Wdyt?

I think this current proposal gets us 90% of what we need. We can implement something akin to multiple tags simply by copying a model under multiple names. However for the last 10% we would (also?) need a tags model. Some requirements for a tags model are not met by this name model:

• We need a way to roll out a model without restarting all services that reference it:

  • Tags should be (optionally) mutable, meaning a single tag may be moved to point to a different model at a later date. This allows multiple "latest" tags for blue-green deployments or feature flagging. Eg: models could be tagged with latest, stable, beta. And those tags would be expected to move.
  • check / read / write endpoints should support specifying a tag instead of an authorization model id. So when the tag moves, the corresponding requests would begin to use the new model.
  • consistency rules should ensure results to batch requests must only return results for a single authorization model.
  • consistency rules may allow delayed use of new models in check requests.

• We need to be able to trace the origin(s) of an authorization model. We need to know which git commit, which PR, and which build generated a specific model. And currently json in ≠ json out, meaning we can't even to a text comparison.

  • Tags sharing the same authorization model should be discoverable. Eg: I might separately tag a model with the name of a git tag and a release number. I need to be able to find one tag using the other.
  • There should be a mechanism to retrospectivly tag a model. This enables flow from release-candidate to release without changing the model itself.

To be clear: I think this proposal would be great step forwards. I think a tags feature would also be useful. So I don't think the need for a tags feature would get in the way of proceeding with this unique name feature.

It's worth mentioning that openfga/roadmap#80 is titled "tagging" and references this RFC.

I'll echo above, I appreciate the concept of tags that can track a model in a way that means services don't need to be rolling reloaded to get model updates - this would make my kubernetes stack a tonne happier.

In fact anything that allows me to junk off the fragile and complicated CI system I have to use:

• Model changes trigger pipeline
• Pipeline pushes model to OpenFGA with a kubectl port-forward.
• Takes the resulting new random model ID and writes it into a secret in the openfga namespace.
• github.com/mittwald/kubernetes-replicator then replicates this annotated secret into multiple namespaces for applications to pickup (we have a monolithic model used by multiple microservices).
• github.com/stakater/Reloader then detects the secret change and triggers a deployment rolling restart
• Applications across the cluster restart and we hope all of the above worked so they point to the correct model id.

This is really unpleasant to deal with.

It's not much better in a docker compose local development stack either:

• Start Postgres
• Run OpenFGA migrations
• Start OpenFGA
• Run a custom init container with fga cli and jq in and a bash script with the model embedded
• Create a store, then add the model to OpenFGA
• Work out how to then take those FGA_MODEL_ID and FGA_STORE_ID values and use them in 4 other containers that get this configured via environment variables.

Anything that makes this somewhat less painful would be great - I was nearly going to implement a startup init script for each application to deduce these things via FGA CLI calls but stopped myself because that felt even worse.