Too modest set of operations exposed by Checking Permissions API

[rzarzecki-equinix]

** Too modest set of operations exposed by Checking Permissions API**
Permissions API allow to check whether a given subject can perform a given action on a given resource. That is not enough to support operations on a set of resources from the domain perspective. For example if there is a need for a domain to expose REST API that responds with a list of resources, then to authorize "read" action on them would require a separate request to .../allow Permissions API for everyone of them.

Add a new operations to Checking Permissions API that respons with a list of resources a given subject can perform a given action on
To support authorization of resource sets, Checking Permissions API could expose a new operation that for a given subject and a given action would respond with ordered and paginated list or resources.
The below example is using different domain language, but it is only as an illustration of an idea:

POST .../authorization/decisions --oauth2-bearer "$AUTH_TOKEN" --data
'{
  "action": "read",
  "resources": [
    {
      "type": "service"
    }
  ]
}'

response:

{
  "type": "allows", 
  "createdDateTime": "2021-03-18T06:43:49.980+0000"
  "subject": {
     "type": "user",
     ...
  "action": "read",
  "scope": "particular",
  "resources": [
    {
      "type": "service",
      "id": "af011004-bf0a-446b-a48f-bcdcca68a9f4"
      "policy": { ... }
   }
}

Embed Authorization Decision Point into domain services
Following OPA approach we could distributed asynchronously authorization policies definitions to the domains. Domains would subscribe to only those policies they are interested in. Either with a module or side-car the authorization could happen at the domain service level as opposed to centralised approach.