[policy-charter] PEP-PDP Group

[Allan Foster]

Alex, I am not sure I fully agree with your statement!

Although you might not use a PEP to protect those resources, There is still a reasonable use case to treat the spec as the API and transport for those resources to call out to a centralized AuthZ server.

I think there are at least two use cases for standardization (as we discussed at IDentiverse)

1. A standardized interface between PEPs or agents and the PDP. This would allow de-weaponization of agents, and interoperability at the agent level….
2. A standardization athe policy level so that IF the PDP cannot be centralized, the interop would be at the Policy level. Enabling the Policy Management to be centralized.

A SaaS might not be willing to call out to a central PDP for AuthZ (and all the performance problems that brings) but might well be willing to accept the Policy definition into its own AuthZ system

I see these as complimentary.

On another note, We want to ensure that whatever we do at the PEP/PDP level, we allow for real time decisions. AuthZ decisions are not necessarily entitlements, and the decision may well depend on environmental issues at the time of the request.

Allan

> On Tuesday, Jun 13, 2023 at 11:45, Alex Babeanu <alex at 3edges.com (mailto:alex at 3edges.com)> wrote:
> 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 (mailto: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 (mailto:policy-charter-bounces at lists.openid.net)> on behalf of Omri Gazitt via policy-charter <policy-charter at lists.openid.net (mailto: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 (mailto:policy-charter at lists.openid.net)>
> > Cc: Omri Gazitt <omri at aserto.com (mailto: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 (mailto: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 (mailto:policy-charter at lists.openid.net)
> > > https://lists.openid.net/mailman/listinfo/policy-charter
> > >
> >
> >
> >
> >
> > --
> > policy-charter mailing list
> > policy-charter at lists.openid.net (mailto:policy-charter at lists.openid.net)
> > https://lists.openid.net/mailman/listinfo/policy-charter
>
>
> --
>
>
> 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/20230614/b3ef4961/attachment.html>