Notes & Principles for a Simple PEP-PDP API

1. Keep transport and message separate
   1. The spec for what a request/response should look like should be decoupled from the underlying transport (HTTP or anything else)
   2. As a result, nothing in the transport layer conveys any authZ meaning whatsoever
      a. For instance, 401/403 are indications you cannot use the authorization service. They don't convey anything about the request you sent or what the PDP (in the broad sense) would have said
2. Propose a first iteration of request/response that focuses exclusively on the easy "binary" yes/no use case
   1. No additional statements/obligations/advice
   2. No batch
   3. No search
3. Propose a model that is largely attribute-based (where an attribute is a key-value pair)
4. Propose a model that follows the ALFA Subject/Action/Resource/Environment or the Cedar Principal/Action/Resource/Context
5. Publish the results using a standardized schema
   1. In the WS-* days of yore, it would have been WSDL
   2. For us, would OpenAPI be good enough?
6. Propose a fully-decoupled REST binding for the initial interop
   1. The HTTP REST codes do not convey AuthZ meaning
   2. A successful invocation returns 200
   3. 401/403 means the client with which you authenticated to the 'PDP' isn't authorized/allowed to use the endpoint
7. Propose an 'extended' REST binding
   5. Gabriel: propose a configurable binding whereby the PDP returns 200 or 403 based on the decision itself (Permit/Deny)

Suggested Initial Design

Request proposal

• Made up of 4 objects of the same type (e.g. Category to use ALFA parlance):
  • Subject, Action, Resource, Context
  • If these objects are arrays of the said type, then we are paving the way for batch requests
• Each of these objects contains an array of attributes e.g. key-value pairs
  • The attributes could be primitive types e.g. string, double, boolean
  • The attributes could be complex e.g. a JSON payload e.g. structures from schema.org

Response

The response should simply be the decision itself:

• Permit/Deny
  • Again, if we want to plan ahead and think of batch requests then the response should be an array rather than an object.
• Optionally the list of identifiers of things (policies) used in the decision-making process