playground: "thing" labeled "user" in tuple/assertion not necessarily a user

[johakoch]

When you add tuples or assertions in the playground, the text field for the thing that is related to the object is labeled "user".

In the default authorization model, which contains, amongst others, types "user", "folder" and "doc", this is ok in some cases (like e.g. tuple user:u01 owner doc:d03). However, in other cases, I think it's inappropriate (like e.g. tuple folder:f05 parent folder:f03, because folder:f05 is not a user).

The concept of tuples in openfga looks very similar to RDF with its triples containing a subject, a predicate and an object. So, why not call the first part of the openfga tuple, a subject, which is a more general term as the (in some cases inappropriate) user?

I came along openfga only recently, so please bear with me, if my suggestion doesn't make sense.

[rhamzeh]

Hi @johakoch, the user is a tuple is different from the user type.

The user type in the models indicates that you have objects of type user. You can call it person or employee or whatever you wish (no types are hardcoded into theyl system). It's just that, a label to identify that object type.

The user in the tuple however, is different.
From: https://openfga.dev/docs/concepts#what-is-a-user

A user is is a combination of a type, an identifier and an optional relation.
For example,

• any object: e.g. user:anne, user:4179af14-f0c0-4930-88fd-5570c7bf6f59, workspace:fb83c013-3060-41f4-9590-d3233a67938f, repository:auth0/express-jwt or organization:org_ajUc9kJ
• a group or a set of users (also called a userset): e.g. organization:org_ajUc9kJ#members, which represents the set of users related to the object organization:org_ajUc9kJ as member
• everyone, using the special syntax: * (e.g. user:* means all objects of type user)

User, relation and object are the building blocks for relationship tuples.

So if you want to indicate that a user of type user can view a document, you can do:

- user: user:anne
  relation: can_view
  object: document:roadmap

If you want to indicate that Charlie follows Beth, you can do:

- user: user:charlie
  relation: follows
  object: user:beth

You might have a user such as this:

- user: subject:maths
  relation: subject
  object: topic:algorithms

The user, relation and object in the tuple must be there, they form the three required elements of a tuple. The types and relations: user, subject, document, topic can be any words you want, so long as they are defined in the authorization model.

Does this help?

[johakoch]

Hi @rhamzeh
I understand the difference between the tuple part and the type. But I still think that naming the generic "thing" related to the object a user is misleading, especially if the system is intended for authorization and so probably has a concept of user (the type) (see "Determining whether online users are authorized to access digital objects" in the Zanzibar paper abstract).

[rhamzeh]

Thanks for the feedback @johakoch

Re: the user naming and Zanzibar

In the 2019 Zanzibar paper itself, this is referred to as a user multiple times: (Page: 2, Section: 2.1 Relation Tuples)

⟨tuple⟩ ::= ⟨object⟩‘#’⟨relation⟩‘@’⟨user⟩

---

However your feedback re: naming confusion is well received

Will relay it to the core team for further consideration. However, I will note that changing this now will be a huge breaking change, so if it were to be considered, it probably will not be until OpenFGA 2.0 work has begun.

Once we get closer to that date, it would be good to get feedback from the rest of the community on this and decide whether we want to proceed with a rename.

[johakoch]

Yes, the grammar for triples in the Zanzibar has user and userset. And my critique applies to the paper, too. Additionally, I don't understand, why a folder named A with a no-meaning relation (folder:A#...) is an instance of a userset (commonly meaning "a set of users"). To me, this looks like pressing hierarchical objects (like folders or groups) into a syntax that was initially intended for real sets of users (group:eng#member).

Zanzibar triples are not structured in a way that need explicit labels. So it would be easier to change the naming in the grammar (and variables in the implementation). I understand that in openfga the labels are part of the user interface, at least in the JSON structure used in API requests and so cannot be renamed easily.