Update patch set 2

Patch Set 2:

(1 comment)

Patch-set: 2
Attention: {"person_ident":"Gerrit User 28271 \u003c28271@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_7973\u003e replied on the change"}
Attention: {"person_ident":"Gerrit User 7973 \u003c7973@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"REMOVE","reason":"\u003cGERRIT_ACCOUNT_7973\u003e replied on the change"}

f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0

@@ -104,6 +104,30 @@
       "revId": "f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0",
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
     },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "41e74725_21a4df48",
+        "filename": "specs/keystone/2023.1/domain-manager-role.rst",
+        "patchSetId": 2
+      },
+      "lineNbr": 52,
+      "author": {
+        "id": 7973
+      },
+      "writtenOn": "2024-02-08T17:06:49Z",
+      "side": 1,
+      "message": "We are already re-using roles for different scopes.  I think it is important to note that the authorization scope for a user is defined by the role-assignment, not the role itself.\n\nIn other words, when you assign a role you have to define what scope it is being assigned in.  This is how we currently differentiate between personas.\n\nWe can look at both the ``member`` and ``reader`` roles as they are currently used to define the System Member, System Reader, Domain Member, Domain Reader, Project Member and Project Reader personas, all with the same two roles.\n\nFor example, let\u0027s assume a fresh install has a ``member`` role with ID 123456.  To grant permissions for the System Member persona to a user with ID 111111, we need to assign this role on the system scope:\n\n    PUT /v3/system/users/111111/roles/123456\n\nSimilarly, to grant permissions for the Domain Member persona to a user with ID 222222, we need to assign that same role on a specific domain.  For argument\u0027s sake let\u0027s assume we have a domain with ID 456789.  So the role assignment will look like:\n\n    PUT /v3/domains/456789/users/222222/roles/123456\n\nLastly, to grant permissions for the Project Member persona to a user with ID 333333, we need to assign the same role on a specific project.  Assuming we have a project ID of 999999, then the role assignment will look like:\n\n    PUT /v3/projects/999999/users/333333/roles/123456\n\nNote that the same role was used for all three users.  In fact, since the ``manager`` role already exists, we can already assign this role on the scope of a domain to grant someone the Domain Manager persona:\n\n    PUT /v3/domains/$DOMAIN_ID/users/$USER_ID/roles/$MANAGER_ROLE_ID\n    \nThe only additional change we need to fully enable this persona is to modify the relevant API policies to accept tokens that have the ``member`` role on a domain scope.\n\nIt\u0027s important to note that even though the same role was used for all users, user 333333 does not have any permissions on the system and is unable to get valid system-scope tokens.  Likewise, the 222222 user only has permissions on that specific domain, and can\u0027t get valid tokens that are scoped to the system or some arbitrary project scope.\n\nThis is why I am opposed to adding a new role that can only be assigned on a domain scope.  It would further complicate role assignments for something that can already be accomplished with the existing roles using existing patterns.",
+      "parentUuid": "55b0f94e_30e8afe0",
+      "range": {
+        "startLine": 50,
+        "startChar": 0,
+        "endLine": 52,
+        "endChar": 44
+      },
+      "revId": "f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
     {
       "unresolved": true,
       "key": {