[policy-charter] PEP-PDP Group

[Alex Babeanu]

This is a good discussion, that said a PEP is actually *not* mandated in
all cases. For example you would *not* use a PEP to secure GraphQL APIs nor
COTS software.

I'm going to share soon a doc, to all contribute on, that lists common
authorization design patterns. I think it would be a good basis for
discussion, and at least to scope what we're trying to do...

Thanks,
./\lex.

On Tue, Jun 13, 2023 at 11:30 AM Allan Foster via policy-charter <
policy-charter at lists.openid.net> wrote:

> So I am thinking we also want to set some scope of what we want to cover?
>
>
>
> Off the top of my head….   I can put some more context around these if
> they aren’t clear
>
>
>
> The Transport layer
>
> The Envelope Layer
>
> The request/response transaction layer
>
> How meta-data is handled?  (both request and response)
>
> Extension mechanisms
>
> Exception mechanism
>
>
>
> Allan
>
>
>
>
>
>
>
> *From: *policy-charter <policy-charter-bounces at lists.openid.net> on
> behalf of Omri Gazitt via policy-charter <policy-charter at lists.openid.net>
> *Date: *Tuesday, June 13, 2023 at 10:54
> *To: *Policy Charter Mail List <policy-charter at lists.openid.net>
> *Cc: *Omri Gazitt <omri at aserto.com>
> *Subject: *Re: [policy-charter] PEP-PDP Group
>
> I agree with David that looking at existing systems is a good place to
> start. If the idea is that PDPs can add a "standard" API that PEPs can
> call, then it would be good if the API supports the existing message
> exchange patterns (and doesn't mandate things that aren't supported).
>
>
>
> Here are three examples, to get us started:
>
>    - OPA is interesting in the sense that its primary REST API is very
>    document-oriented - you have a set of rules that are defined in a
>    JSON-style hierarchy and you issue a GET or POST on that resource in the
>    hierarchy to evaluate the rule that is rooted there. This seems like a
>    special case. OPA does have a generic query
>    <https://www.openpolicyagent.org/docs/latest/rest-api/#execute-an-ad-hoc-query>
>    API, which allows you to pass input and evaluate a rego query based on the
>    loaded policy document and the input.
>    - Auth0 FGA (one of the zanzibar implementations) has a check
>    <https://www.openpolicyagent.org/docs/latest/rest-api/#execute-an-ad-hoc-query> API
>    that takes a JSON payload containing a user key, relation name, and object
>    key, and returns an allowed decision (true or false). Most zanzibar
>    implementations seem to do something similar - e.g. SpiceDB has a check
>    <https://www.postman.com/authzed/workspace/spicedb/documentation/21043612-9786e5f3-2014-4b31-86c1-39335236c0e2?entity=request-c58c40ff-9fc7-4c3e-9cca-f017160ba5b8>
>    API that takes a resource, permission, and subject.
>    - Topaz (Aserto's OSS authorizer) has a query
>    <https://aserto.readme.io/reference/authorizerquery-1> API that takes
>    an identity and policy (rule/decisions to evaluate), and optionally a
>    resource context and additional input, and returns what OPA would return.
>    It also has a simpler is
>    <https://aserto.readme.io/reference/authorizeris-1> API that evaluates
>    a policy (rule/decisions) with an identity and resource context.
>
>
>
>
>
> On Tue, Jun 13, 2023 at 1:54 AM Roland Baum via policy-charter <
> policy-charter at lists.openid.net> wrote:
>
> I'm in as well :-D
>
>
>
> Roland Baum
> umbrella.associates GmbH
>
>
> --
> policy-charter mailing list
> policy-charter at lists.openid.net
> https://lists.openid.net/mailman/listinfo/policy-charter
>
> --
> policy-charter mailing list
> policy-charter at lists.openid.net
> https://lists.openid.net/mailman/listinfo/policy-charter
>


-- 
[image: This is Alexandre Babeanu's card. Their email is alex at 3edges.com.
Their phone number is +1 604 728 8130.]
<https://hihello.me/p/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5>

-- 
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments 
hereto, is for the sole use of the intended recipient(s) and may contain 
confidential and/or proprietary information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/policy-charter/attachments/20230613/a8a1330c/attachment-0001.html>