[Openid-specs-authzen] The PEP-PDP API

[Omri Gazitt]

David, thanks for writing this all down!

On Mon, Jan 22, 2024 at 9:25 PM David Brossard via Openid-specs-authzen <
openid-specs-authzen at lists.openid.net> wrote:

> Dear all,
>
> Last week, it became apparent we need to start simple and low for the
> PEP-PDP API if we want to ship anything out and I'd like to propose a few
> principles:
>
>    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
>          1. 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
>
> For practical interop, I do think we need an HTTP (REST) binding.

>
>    1. 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
>
>
+100.  That was definitely where I landed after last week's conversations.
We can layer other things once we've declared success on the simple cast.

>
>    1. Propose a model that is largely attribute-based (where an attribute
>    is a key-value pair)
>
> I would like to see this be generalized - otherwise you'll preclude all
non-attribute-based systems, which seems like a big miss.

Specifically, the minimum amount of information that is needed to define a
subject is a type and ID. Likewise an object/resource. Likewise an action.

>
>    1. Propose a model that follows the ALFA
>    Subject/Action/Resource/Environment or the Cedar
>    Principal/Action/Resource/Context
>
> Terminology is important but the most important thing is to be consistent
throughout.

>
>    1. 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?
>
> OpenAPI is perfect. But it DOES imply that you need to specify an HTTP
binding (and specifically, HTTP status codes).


> So with that being said, should we have a request that looks like the
> following:
>
>    - 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
>
> I thought we were eliminating arrays from the simple case?

>
>    - 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
>
> 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
>
> Thoughts?
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240123/359da654/attachment-0001.html>