doc: split access control docs into separate files

1 files changed, 62 insertions, 0 deletions

diff --git a/doc/share/authz/ReBAC.md b/doc/share/authz/ReBAC.md
new file mode 100644
index 0000000..b62bd7f
--- /dev/null
+++ b/doc/share/authz/ReBAC.md
@@ -0,0 +1,62 @@
+# Relationship-Based Access Control (ReBAC)
+
+> Authorization decisions are based on the relationship between the resource owner
+> and the resource accessor in a social network maintained by the protection
+> system.
+
+A Social Network System (SNS) maintains a social network for at least two reason:
+
+1. It is used by the users to navigate the information space of the system
+2. The social network is used as a basis for formulating the access control
+   policies of user contributed resources.
+
+Access Control Paradigm:
+
+1. the explicit tracking of one or more social networks by the protection system
+1. the expression of access control policies in terms of the relationship
+   between the resource owner and the resource accessor
+
+Suited for domains in which relationship and authorization decisions are from
+the structure of trust that is inherent in the application domain rather than
+subjective assessment of users.
+
+It is more natural to base authz decisions on whether the resource owner and
+accessor are in a particular kind of relationship.
+
+In a standard RBAC system, when a permission `p` is assigned to role `R`, we are
+essentially formulating the following policy: `grant p to user u if R(u)`.
+
+PriMA is another recently proposed privacy protection mechanism for SNSs.
+
+Policy
+
+Let `U` be the set of all users in the system.
+Accesses are directed against resources. A resource may represent one or more
+objects or certain system operations. Let `R` be the set of resources protected
+by the SNS. A typical member of `R` is denoted by `r`.
+
+Assocated with every access request are therefore the following:
+
+* a protected resource that is being accessed
+* the owner of that resource
+* the accessor of that resource who requests access.
+
+Owner of a resource implies that the accessor must be in a specific kind of
+relationship with the owner in order be granted. Huh?
+
+Associated with every resource is an `access control policy`.
+Policy is modeled as a ternary predicate: `U x U x G(U, I) => {0, 1}`.
+
+A protection system N is a 7-tuple (I, U, R, C, C0, policy, owner) where:
+
+* `I` is the set of relation identifiers (See my question in the README about resource identifiers in our system)
+* `U` is a finite set of users in the system
+* `R` is a finite set of resources to be protected by the system.
+* `C` is a _infinite_ universe of `access contexts`.
+  * `C0` is the root context. (* Could this be the root `Organization` that a `User` belongs to?)
+* `R => PP(U, I)` assigns a policy predicate to every resource in the system. (This means that every resource is addressable through a universal identifier, right? Goodbye `bigint`? Yay!)
+* `owner: R -> U` is a function that assigns an owner to every resource in the system.
+
+## See also
+
+* [Relationship-Based Access Control: Protection Model and Policy Language by Philip W. L. Fong](https://cspages.ucalgary.ca/~pwlfong/Pub/codaspy2011.pdf)