Repository navigation
Clarify and Define Namespace Ownership and Format #65
Description
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
- With namespace:
-
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
- Current:
Metadata
Metadata
Type
Projects
- Status
Activity
BryanttV commentedon Sep 26, 2025
My opinion on this is as follows:
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 likeorg:MITand others likecourse-v1:OpenedX+DemoX+DemoCoursewithout an external namespace will only create more inconsistencies. Therefore, we should normalize everything to thenamespace:idformat:org:MITcourse:course-v1:OpenedX+DemoX+DemoCourselib:lib:OpenedX:CSPROBThe 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.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.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@alicerole:admin→role@adminact:read→act@readI 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 commentedon Sep 26, 2025
Another point we’ve been discussing is:
Should we keep using the prefix
actto refer to permissions? Maybe it would be better to use something likeperm(for permission)?. In that case, instead ofact:readit would becomeperm:read.bmtcril commentedon Sep 26, 2025
AuthzScopethat handles the separator across all scopes and presents an API for getting the scope string.CourseAuthzScope(AuthzScope)that have their own prefix, and ways of instantiating (ex: anOrgAuthzScopecould take a course key, organization id, or just the org string) and consistently returns the correct separator-joined scope stringI 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.Totally agree!
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
actorpermI'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 tocreate,read,edit,delete,list, ormanage.MaferMazu commentedon Sep 26, 2025
@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 the long term, this should be extensible via plugins, but for the MVP, we have a fixed list of permissions.
mariajgrimaldi commentedon Oct 1, 2025
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.
MaferMazu commentedon Oct 1, 2025
@mariajgrimaldi I suggest we use | or ^, as this will maintain consistency in the separators while avoiding conflicts. Reasoning: Users can have an '@' in their usernames, which could create problems. Reference: https://github.com/openedx/edx-platform/blob/master/openedx/envs/common.py#L2274
Okay, so for the MVP, we will maintain the permissions as they are in the
authz.policyin #75, right?mariajgrimaldi commentedon Oct 22, 2025
This was done as part of #75