1 files changed, 0 insertions, 103 deletions
diff --git a/doc/share/authz/RBAC.md b/doc/share/authz/RBAC.md
deleted file mode 100644
index 2f0054a6..00000000
--- a/doc/share/authz/RBAC.md
+++ /dev/null
@@ -1,103 +0,0 @@
-# Role-Based Access Control (RBAC)
-
-Assigns permissions to roles, which are collections of permissions related to specific job functions. [1][1]
-
-This style of access control aligns with how humans organize themselves within
-organizations by assigning job functions to roles. This model is simple and
-aligns well with how humans operate within their job function.
-
-This model also helps to align security objectives with higher level
-organizational policy (.e.g. ethics, privacy, administration). This type of
-model requires centralized control and enforcement.
-
-> The act of granting membership and specifying transactions for a role is loosely
-> analogous to the process of clearing users (granting membership) and the
-> labeling (associate operation sensitivities) of objects ... - Role-Based Access Controls by Ferraiolo, Kuhn Et el.
-
-> A role can be thought of as a set of transactions that a user or set of users
-> can perform within the context of an organization. - Role-Based Access Controls by Ferraiolo, Kuhn Et el.
-
-Roles are group oriented and they provide a means of naming and describing
-many-to-many relationships between individuals and rights.
-
-1. For each subject, the active role is the one that the subject is currently using:
-
-    ```
-    AR(s: subject) = { the active role for subject s}.
-    ```
-
-2. Each subject may be authorized to perform one or more roles:
-
-    ```
-    RA(s: subject) = { authorized roles for subject s }.
-    ```
-
-3. Each role may be authorized to perform one or more transactions:
-
-    ```
-    TA(r: role) = { transactions authorized for role r}.
-    ```
-
-4. Subjets may execute transactions. The predicate `exec(s,t)` is true if
-   subject `s` can execute transaction `t` at the current time, otherwise it is
-   false:
-
-    ```
-    exec(s :subject, t: tran) = true iff subject `s` can execute transaction `t`
-    ```
-
-Three basic rules are required:
-
-1. Role assignment: A subject can execute a transaction only if the subject has
-   selected or been assigned a role
-2. Role authorization: A subject's active role must be authorized for the
-   subject
-3. Transaction authorization: A subject can execute a transaction only if the
-   transaction is authorized for the subject's active role
-
-Another user of RBAC is to support integrity. One aspect of integrity is a
-requirement that data and processes be modified only in authorized ways by
-authorized users.
-
-The problem of determining whether data have been modified only in authorized
-ways can be as complex as the transaction that did the modification. For this
-reason, the practical approach is for transactions to be certified and
-trusted. If transactions must be trusted then _access control can be incorporated
-directly into each transaction_.
-
-RBAC makes a decision based on the subject's association with a role. RBAC does
-not easily support multi-factor decisions. RBAC role assignments tend to be
-based upon more static organizational positions, presenting challenges in
-certain RBAC architectures where dynamic access control decisions are required
-(.e.g. `CI_JOB_TOKEN`). Trying to implement these kidns of access control
-decisoins would require the creation of numerous roles that are ad hoc and
-limited in membership, leading to what is often termed "role explosion".
-
-ABAC avoids the need for explicit authorizations to be directly assigned to
-individual subjects prior to a request to perform an operation on the object.
-
-> ABAC: An access control method where subject requests to perform operations on
-> objets are granted or denied based on assigned attributes of the subject,
-> assigned attributes of the object, environment conditions, and a set of
-> policies that are specified in terms of those attributes and conditions.
-
-* Attributes: characteristics of the subject, object, or environment conditions.
-* Subject: is a human or or non-person entity (NPE) that issues access requests
-  to perform operations on objects.
-* Object: a system resource for which access is managed by the ABAC system
-* Operation: is the execution of a function at the request of a subject upon an
-  object. (e.g. read, write, edit, delete, copy, execute and modify)
-* Policy: is the representation of rules or relationships that makes it possible
-  to determine if a requested access should be allowed.
-* Environment conditions: operational or situational context in which the access
-  request occurs.
-
-> Roles can inherit from each other and imply permissions. - [1][1]
-
-## See also
-
-* [Role-Based Access Controls][1]
-* [Zanzibar][2]
-
-[1]: https://csrc.nist.gov/files/pubs/conference/1992/10/13/rolebased-access-controls/final/docs/ferraiolo-kuhn-92.pdf
-[2]: https://storage.googleapis.com/gweb-research2023-media/pubtools/5068.pdf