Clarify and Define Namespace Ownership and Format

[BryanttV]

Description

In a recent PR discussion, we agreed to move forward with the current scope format for now. However, there are still open questions about namespacing and namespace ownership that need to be clarified to avoid potential collisions or unintended issues in the future.

Related comments

• [FC-0099] feat: add casbin model configuration (CONF) #49 (comment)
• [FC-0099] feat: add casbin model configuration (CONF) #49 (review)

Open Questions

• Namespace clarity Should all scopes include an explicit namespace, even when they don’t naturally have one?

  Example:

  • With namespace: course:course-v1:OpenedX+DemoX+DemoCourse
  • Without namespace: org:OpenedX

• Namespace ownership

  Who defines and owns the existing namespaces (org, lib, course, etc.)?

  How should new extensions or custom scopes define their namespace to avoid collisions?

• Consistency across entities

  Do we need to adjust definitions for other entities like role:<x>, act:<x>, user:<x>, etc., to keep the same format conventions?

• Alternative notations

  Is there value in adopting a different separator (e.g., @ instead of :) to make IDs clearer and reduce ambiguity?

  Example:

  • Current: lib:lib:DemoX:CSPROB
  • Alternative: lib@lib:DemoX:CSPROB

[BryanttV]

My opinion on this is as follows:

1. Even if the scope ID already has a natural namespace, for example (course-v1:, lib:), we should still include the explicit namespace it belongs to. Having some like org:MIT and others like course-v1:OpenedX+DemoX+DemoCourse without an external namespace will only create more inconsistencies. Therefore, we should normalize everything to the namespace:id format:

   • org:MIT
   • course:course-v1:OpenedX+DemoX+DemoCourse
   • lib:lib:OpenedX:CSPROB

   The problem with this approach is that it becomes confusing because of the excessive use of :. A possible solution is to replace that separator with something more distinctive, such as @, _, etc.

2. The platform should define the default namespaces, for example, course:, org:, lib:. We should have a centralized registry for each namespace. Any type of extension to these namespaces should be registered and validated to avoid collisions.

3. Yes, we should adjust the other prefixes for consistency. That is, if we make a change in the format, we should apply the same rule across all prefixes to maintain a uniform pattern. For example:

   • user:alice → user@alice
   • role:admin → role@admin
   • act:read → act@read

4. I definitely think we should use another separator, and personally, I believe @ provides better readability. However, we can evaluate other separator options as well.

@bmtcril @mariajgrimaldi @MaferMazu

[BryanttV]

Another point we’ve been discussing is:

Should we keep using the prefix act to refer to permissions? Maybe it would be better to use something like perm (for permission)?. In that case, instead of act:read it would become perm:read.

[bmtcril]

1. From an API perspective it would be good to abstract the details of prefixes and separators away. So my thoughts from the top down would be:

• Create an abstract class like AuthzScope that handles the separator across all scopes and presents an API for getting the scope string.
• Concrete classes like CourseAuthzScope(AuthzScope) that have their own prefix, and ways of instantiating (ex: an OrgAuthzScope could take a course key, organization id, or just the org string) and consistently returns the correct separator-joined scope string
• Create a registry checks for the existence of a prefix in registered AuthzScopes when adding a new one, and errors if the prefix already exists

I think this would limit the potential confusion around, for example, what an "org" is for permissions and give us a clean way to disambiguate prefixes. In this world I don't much care what the separator is since it's rarely visible and just an internal implementation detail. My slight preference would be to go for something that's less frequently used like ^ or |, but it matters a lot less.

2. Totally agree!

3. I'm still wrapping my head around all of the ways users, roles, etc will be defined and used so I'm not sure what the analogs of a higher level class based API might look like for those, but I'd hope that we could do something similar to abstract away the separator / concatenation for them as well.

In regards to using act or perm I'm fine with it either way, but do hope we can abstract it. Do we have an idea if we're going to have a fixed list of permissions or would we want those to be extensible? I'm having a hard time coming up with a case that can't be flattened down to create, read, edit, delete, list, or manage.

[MaferMazu]

@BryanttV, to me, it makes sense to always maintain the namespace, as you mentioned, for consistency.
The idea of @bmtcril to manage namespaces programmatically with the API also makes sense, and for the default rules (those directly in the policy), we should only follow the format we decide.

Regarding the namespace, we should also have it for actions/permissions. - like: 'my_app.view_report'. It is how it currently works, and also avoids collisions between permissions.

In regards to using act or perm I'm fine with it either way, but do hope we can abstract it. Do we have an idea if we're going to have a fixed list of permissions or would we want those to be extensible? I'm having a hard time coming up with a case that can't be flattened down to create, read, edit, delete, list, or manage.

In the long term, this should be extensible via plugins, but for the MVP, we have a fixed list of permissions.

[mariajgrimaldi]

I'm following a similar approach to what @bmtcril described here #65 (comment), which involves abstracting our naming conventions from the application layer so that the APIs are more friendly for checks and extensibility: #75

It's not as flexible as Ty's proposal but I think for our MVP this would be enough, I'll make sure to add TODO comments to follow up on the registry for new scopes. Also I'm still using : as the separator, but I'll make sure to change it to one of your suggestions: @, | or even ^ whichever looks better since we're still going to add an abstraction layer.

Now, on the permission naming with app's namespaces mentioned by @MaferMazu above, I think those could be easily part of each policy metadata so it's dynamically discovered - this way we don't have to hardcode it in the authz.policy.