docs: add ntoes from zanzibar paper

3 files changed, 61 insertions, 2 deletions

diff --git a/doc/share/authz/POLICY.md b/doc/share/authz/POLICY.md
index 207c1cc..4e809bb 100644
--- a/doc/share/authz/POLICY.md
+++ b/doc/share/authz/POLICY.md
@@ -20,6 +20,8 @@ authorized to perform an action against a resource.
   end
 ```
 
+* [Zanzibar](./ZANZIBAR.md)
+
 ## Policy Language
 
 A policy language facilitates:
diff --git a/doc/share/authz/RBAC.md b/doc/share/authz/RBAC.md
index cbf05e0..2f0054a 100644
--- a/doc/share/authz/RBAC.md
+++ b/doc/share/authz/RBAC.md
@@ -1,6 +1,6 @@
 # Role-Based Access Control (RBAC)
 
-Assigns permissions to roles, which are collections of permissions related to specific job functions.
+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
@@ -92,6 +92,12 @@ individual subjects prior to a request to perform an operation on the object.
 * 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](https://csrc.nist.gov/files/pubs/conference/1992/10/13/rolebased-access-controls/final/docs/ferraiolo-kuhn-92.pdf)
+* [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
diff --git a/doc/share/authz/ZANZIBAR.md b/doc/share/authz/ZANZIBAR.md
new file mode 100644
index 0000000..fc49ab2
--- /dev/null
+++ b/doc/share/authz/ZANZIBAR.md
@@ -0,0 +1,51 @@
+# Zanzibar
+
+Zanzibar is a planet-scale distributed ACL storage and evaluation system.
+Zanzibar's data model supports permissions, users, groups, and inheritance as
+found in the above systems. [1][1]
+
+Zanzibar servers delegate checks and reads to each other based on consistent
+hashing. Both the caller and the callee sides of the delegated operations cache
+the results to prevent hot spots. Zanzibar handles 22 million internal RPCs per
+second. In-memory caching handles approximately 200 million lookups per second
+at peak.
+
+Clients include:
+
+* Google Calendar
+* Google Cloud
+* Google Drive
+* Google Maps
+* Google Photos
+* YouTube
+
+Lessons learned
+
+* Access control patterns vary widely
+* Freshness requirements are often but not always loose. (i.e. moderate staleness during ACL evaluation is okay)
+* Performance optimizations
+  * Request hedging is key to reducing tail latency. (Search issues 10s-100s of authz checks to serve a single set of search results.)
+  * Hot-spot mitigation is critical for high availability: some workloads create hot spots in ACL data that can overwhelm database servers.
+  * Performance isolation is indispensible to protect against misbehaving clients. (e.g. new feature launch that is popular. Unpredicatable usage patterns.)
+
+Roles are similar to Zanzibar relations. Roles can inherit from each other and
+imply permissions. Clients have implemented RBAC policies on top of Zanzibar's
+namespace configuration.
+
+Most IAM systems offer:
+
+* assigning users to roles or groups
+* domain-specific policy languages
+* API to edit ACLs.
+
+These systems have a communit unified ACL storage and and RPC-based API.
+
+It evaluates deeply or widely nested group membership with Leopard, a
+specialized index for efficient computation of set operations with snapshot
+consistency.
+
+## See Also
+
+* [1][1]
+
+[1]: https://storage.googleapis.com/gweb-research2023-media/pubtools/5068.pdf