From 5de94c8b7ed5ccf0c3c454f452ee61def10a07e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= <anarcat@debian.org>
Date: Mon, 23 Nov 2020 16:08:04 -0500
Subject: [PATCH] clarify access admission and revocation

This is based on the current "vetting" policy but also includes a
reference to the Tor Core Membership policy, to which we delegate the
revokation bit. We also assert that admins MUST be core tor to have
access.
---
 policy/tpa-rfc-7-root.md | 36 +++++++++++++++++++++++++-----------
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/policy/tpa-rfc-7-root.md b/policy/tpa-rfc-7-root.md
index 47da5c89..6da30967 100644
--- a/policy/tpa-rfc-7-root.md
+++ b/policy/tpa-rfc-7-root.md
@@ -31,11 +31,8 @@ There are multiple possible access levels, often conflated:
     keys
 
 This approach is currently all-or-nothing: either a user has access to
-all of the above, or nothing.
-
-It's currently not clear how users are granted the above accesses, if
-that list is exhaustive, or under which condition or authority those
-accesses are revoked.
+all of the above, or nothing. That list might not be exhaustive. It
+certainly does not include the service admin access level.
 
 The current list of known administrators is:
 
@@ -97,12 +94,29 @@ stored offline.
 
 ## Admission and revocation
 
-TODO.
-
-Brainstorm: MIA process by which users get removed after X months of
-inactivity?
-
-How do we grant new users access? Document interop with TPI.
+Service admins and system administrators are granted access through a
+vetting process by which an existing administrator requests access for
+the new administrator. This is currently done by opening a ticket in
+the issue tracker with an OpenPGP-signed message, but that is
+considered an implementation detail as far as this procedure is
+concerned.
+
+A service admin or system administrator MUST be part of the "Core
+team" as defined by the [Tor Core Membership policy][] to keep their
+privileges.
+
+Access revocation should follow the termination procedures in the [Tor
+Core Membership policy][], which, at the time of writing, establish
+three methods for ending the membership:
+
+ 1. voluntary: members can resign by sending an email to the team
+ 2. inactivity: members accesses can be revoked after 6 months of
+    inactivity, after consent from the member or a decision of the
+    community team
+ 3. involuntary: a member can be expelled following a decision of the
+    community team and membership status can be temporarily revoked in
+    the case of a serious problem while the community team makes a
+    decision
 
 # Examples
 
-- 
GitLab