docs: add notes on ABAC and weakness of RBAC

1 files changed, 6 insertions, 99 deletions

diff --git a/doc/share/authz/README.md b/doc/share/authz/README.md
index 7ab8166..d99f1a6 100644
--- a/doc/share/authz/README.md
+++ b/doc/share/authz/README.md
@@ -28,103 +28,10 @@ Criteria for evaluating policy languages:
 
 Ideally, we must be able to model the following relationships:
 
-* `user-to-resource`
-* `resource-to-resource`
+| type                   | required     |
+| ----                   | --------     |
+| `user-to-resource`     | required     |
+| `resource-to-resource` | required     |
+| `user-to-user`         | not required |
 
-Note that `user-to-user` relationships are not currently represented in the existing access control model.
-
-## Organizational Hierarchy
-
-How does a permission cascade down a group hierarchy?
-
-```
-Organization
-  Group A
-    * Roles
-      * Developer
-      * Maintainer
-      * Custom A
-        * base: developer
-        * permissions:
-          * admin_vulnerability: true
-            * read_vulnerability: true (implicitly)
-      * Custom B
-        * base: maintainer
-        * permissions:
-          * Doesn't really matter because Maintainer has all the permissions available via a custom role. <- Fact check this
-    Group Aa
-      Project Aa1
-      Project Aa2
-    Group Aaa
-      Project Aaa1
-      Project Aaa2
-```
-
-If a user has a membership at `Group A`, does the permissions associated with that
-membership cascade down to `Group Aa` and `Group Aaa`?
-
-## Scope
-
-1. Single resource
-1. Nested resources
-1. Individual Attributes on a resource
-
-### Current:
-
-### Desired:
-
-#### Option 1
-
-| permission | scope                                                                         | description                                         |
-| ---------- | -----                                                                         | -----------                                         |
-| `read`     | `gid://app/Organization/1`                                                    | Can read Org 1 resource                             |
-| `read`     | `gid://app/Organization/1/*`                                                  | Can read every resource below Org 1 hierarchy       |
-| `read`     | `gid://app/Organization/1/Group/1`                                            | Can read Group 1 resource                           |
-| `read`     | `gid://app/Organization/1/Group/1/*`                                          | Can read every resource below Group 1 hierarchy     |
-| `read`     | `gid://app/Organization/1/Group/1/Project/1`                                  | Can read project 1                                  |
-| `read`     | `gid://app/Project/1`                                                         | Can read project 1 resource (short circuit example) |
-| `read`     | `gid://app/Organization/1/Group/1?attributes[]=name&attributes[]=description` | Can read name and description of Group 1 resource   |
-
-Example:
-
-The following example allows the subject of the token to read all of the descendant resources of `Project 1` and `Project 2` and it can read `Project 3`.
-
-```json
-{
-  "sub": "gid://User/17",
-  "scope": {
-    "read": [
-      "gid://app/Organization/1/Group/1/Project/1/*",
-      "gid://app/Organization/1/Group/1/Project/2/*",
-      "gid://app/Organization/1/Group/2/Project/3"
-    ]
-  }
-}
-```
-
-#### Option 2
-
-Encode access and scope directly into the name of the permission.
-
-| permission                                                               | description                                         |
-| ----------                                                               | -----------                                         |
-| `read:organization:1`                                                    | Can read Org 1 resource                             |
-| `read:organization:1:*`                                                  | Can read every resource below Org 1 hierarchy       |
-| `read:organization:1:group:*`                                            | Can read Group 1 resource                           |
-| `read:organization:1:group:1:*`                                          | Can read every resource below Group 1 hierarchy     |
-| `read:organization:1:group:1:project:1`                                  | Can read project 1                                  |
-| `read:project:1`                                                         | Can read project 1 resource (short circuit example) |
-| `read:organization:1:group:1:attributes[]=name&attributes[]=description` | Can read name and description of Group 1 resource   |
-
-Example:
-
-```json
-{
-  "sub": "gid://User/17",
-  "scope": [
-    "read:organization:1:group:1:project:1:*",
-    "read:organization:1:group:1:project:2:*",
-    "read:organization:1:group:2:project:3"
-  ]
-}
-```
+Note: `user-to-user` relationships are not in the current access control model.