More adaptions.

docs/src/development/proposals/MEP4/README.md

@@ -31,13 +31,17 @@ These are some general requirements / higher objectives that MEP-4 has to fulfil
   - Simple to start with, more complex options for production setups
 - Should utilize auth mechanisms that we have already in place to best possible degree
 - Fine-grained access permissions (every endpoint maps to a permission)
-- Tenant scoping (disallow resource access to resources of other tenants, except a user acts "on-behalf")
-- Project scoping (disallow resource access to resources of other projects, except a user acts "on-behalf")
+- Tenant scoping (disallow resource access to resources of other tenants)
+- Project scoping (disallow resource access to resources of other projects)
 - Access tokens in self-service for technical user access
 
+Non-goals:
+
+- Provide "tenant acts on-behalf" functionality (because we want only admins and these can act on-behalf)
+
 ## Implementation
 
-We gathered a lot of knowledge while implementing the backend for metalstack.cloud. The goal is now to use the same technology and adopt that to the metal-api, this includes:
+We gathered a lot of knowledge while implementing a multi-tenancy-capable backend for metalstack.cloud. The goal is now to use the same technology and adopt that to the metal-api, this includes:
 
 - gRPC in combination with connectrpc
 - OPA for making auth decisions
@@ -51,16 +55,19 @@ This repository contains the `proto3` specification of the exposed metal-stack a
 
 Client implementations for the most relevant languages (go, python) are generated automatically.
 
-This api is divided into end user and admin access at the top level. The proposed APIs are:
+This api is divided into end-user and admin access at the top level. The proposed APIs are:
 
 - `api.v2`: For end-user facing services
 - `admin.v2`: For operators and controllers which need access to unscoped entities
 
-The methods of the API can have different role scope:
+The methods of the API can have different role scopes (and can be narrowed down further with fine-grained method permissions):
 
 - `tenant`: Tenant-scoped methods, e.g. project creation (tenant needs to be provided in the request payload)
+  - Available roles: VIEWER, EDITOR, OWNER
 - `project`: Project-scoped methods, e.g. machine creation (tenant needs to be provided in the request payload)
+  - Available roles: VIEWER, EDITOR, OWNER
 - `admin` Admin-scoped methods, e.g. unscoped tenant list or switch register
+  - Available roles: VIEWER, EDITOR
 
 And has methods with different visibility scopes:
 
@@ -78,18 +85,14 @@ With these tokens, users can create Access Tokens for CI/CD or other use cases.
 
 JWT Tokens can be revoked by admins and the user itself.
 
-❓ Discuss: Should we create a new repository (https://github.com/metal-stack/api-server) or can we locate the new API in the existing metal-api project beneath v2.
-
-#### Relationship to the metal-api
-
-To allow consumers to migrate to the `v2` API gradually, the business logic of the metal-api must be maintained in parallel with the new `v2` api.
-
-To achieve this with it is required to extract the backend implementation, currently the `cmd/internal` package should be factored out to a consumable repository at `github.com/metal-stack/api-server/pkg/`. We will try to migrate the rethinkdb backend implementation to a generic approach during this effort.
+❓ Discuss: Should we create a new repository (https://github.com/metal-stack/api-server) or can we locate the new API in the existing metal-api project beneath `v2`?
 
 ### Migration of the Consumers
 
 To allow consumers to migrate to the `v2` API gradually, both apis, the new and the old, are deployed in parallel. In the control-plane both apis are deployed side-by-side behind the ingress. `api.example.com` is forwarded to `metal-api` and `metal.example.com` is forwarded to the new `api-server`.
 
+The the business logic of the metal-api must be maintained during the switch to the new `v2` api. To achieve this with it is required to extract the backend implementation, currently the `cmd/internal` package should be factored out to a consumable repository at `github.com/metal-stack/api-server/pkg/`. We will try to migrate the rethinkdb backend implementation to a generic approach during this effort.
+
 There are a lot of consumers of metal-api, which need to be migrated:
 
 - ansible