Notice: Deprecation of Schema Version 1.0 Models

[rhamzeh]

Hey folks!

We would like to thank you all for the feedback you have provided us regarding the new modeling language (the authorization model schema version 1.1) in OpenFGA.

Based on the overwhelmingly positive response regarding this change from a DX perspective as well as the performance improvements unlocked with this new model, as well as the team's willingness to reduce code clutter so early in the project's life-cycle, we have decided to announce the deprecation of the 1.0 model.

Timeline

1- February 13th 2023: Deprecation Notice

This deprecation notice is posted on GitHub and Discord.

2- March 15th 2023: Disallow writing and evaluating new 1.0 models with OpenFGA version 0.4.0

• The API will no longer accept writing new 1.0 models (affects WriteAuthorizationModel, WriteAssertions) unless the OPENFGA_ALLOW_WRITING_1_0_MODELS flag is used to override the setting. Note: reading those earlier models and their assertions will keep working.

• Query evaluations of any 1.0 models (Check, Expand, ListObjects) will, by default, no longer be accepted unless the OPENFGA_ALLOW_EVALUATING_1_0_MODELS flag is used to override the setting.

• ReadAuthorizationModel ,ReadAuthorizationModels and ReadAssertions will continue to serve results for 1.0 and 1.1 models.

3- March 31st 2023: Default model version in Syntax Transformer, Playground and Docs switch to 1.1

• The model schema version will be required in all new authorization models, and new authorization models without the version will be rejected.

 model
   schema 1.1

4- May 15th 2023: Code Removed with OpenFGA version 1.1.0

• OPENFGA_ALLOW_WRITING_1_0_MODELS and OPENFGA_ALLOW_EVALUATING_1_0_MODELS flags removed

• The code relating to branching and evaluating 1.0 models will be removed with the exception of ReadAuthorizationModel and ReadAuthorizationModels.

Benefits of Schema Version 1.1: Developer Experience and Performance Improvements

As a reminder, v1.1 should allow you to express the type restrictions on each relation, which greatly improves the readability of the model, especially by those who were not the initial authors of the model.

In schema version 1.0, you could have the following:

model
  schema 1.0
type user
type group
  relations
    define member as self

Notice that it is not clear what members of groups can be? Can they be users? Other groups? Other group members? All users?

In schema version 1.1 this can become:

model
  schema 1.1

type user
type group
  relations
    define member: [user, group#member]

In this someone reading the model would know that group members can only be users or another group's members.

Also because of that the OpenFGA API is also able to deduce these and properly validate against invalid tuples as well as optimize evaluation based on this knowledge.

How To Migrate

If you have not yet migrated your models to v1.1, we urge you to take a look at the documentation regarding the migration process.

Let us know your feedback!

The OpenFGA Team

[softwarecoolie]

"In this someone reading the model would know that group members can only be users or another group's members." is it only OR operation ? can we do AND?

[rhamzeh]

Can you explain more @softwarecoolie?

What is it that you are wishing to express?