[policy-charter] PEP-PDP Group

Tue Jun 27 18:43:41 UTC 2023

Hi David, the difference between the direct and indirect requests are interesting. The Direct request feels like a  request for a decision while the indirect request feels like policy retrieval (with some parameters to scope retrieval of policies as it relate to Alice and claims). Can you describe the use cases for when the direct vs when the indirect approach is used?

From: policy-charter <policy-charter-bounces at lists.openid.net> On Behalf Of David Brossard via policy-charter
Sent: Tuesday, June 27, 2023 4:17 PM
To: Policy Charter Mail List <policy-charter at lists.openid.net>
Cc: David Brossard <david.brossard at gmail.com>
Subject: Re: [policy-charter] PEP-PDP Group

I agree with Allan. There's another aspect to runtime authZ: it eliminates the need to define entitlements up front. It eliminates the need for role, permissions, and entitlements engineering, and consequently provisioning and de-provisioning.

This makes me think another area of investigation for this WG is bridging the runtime authz world (XACML, OPA...) with the non-runtime authz world (OAuth scopes & claims, SCIM entitlements...) AuthZ frameworks should be capable of generating dynamic claims that are fed into a token. CAEP could be used to update/revoke/enrich such tokens.

This means we need different ways to query a policy. And perhaps different ways to write policies. Let's assume a business authz policy:

  *   Policy: Claims processors can approve a claim in their region if the amount claimed is less than the approver's limit.
  *   Direct request: Can Alice approve claim #123? (in the background, attribute retrieval is run to figure out who Alice is and what claim 123's region and amount are)

     *   Answer: Permit/Deny + obligations

  *   Indirect request: tell me what Alice can do on claims

     *   Answer: approve + claim amount < $500 + region = Moose Jaw.

On Wed, Jun 14, 2023 at 8:15 AM Allan Foster via policy-charter <policy-charter at lists.openid.net<mailto:policy-charter at lists.openid.net>> wrote:

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

--
[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.
--
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

--
---
David Brossard
http://www.linkedin.com/in/davidbrossard
http://twitter.com/davidjbrossard
http://about.me/brossard
---
Stay safe on the Internet: http://www.ic3.gov/preventiontips.aspx
Prenez vos précautions sur Internet: http://www.securite-informatique.gouv.fr/gp_rubrique34.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/policy-charter/attachments/20230627/0a8c44b3/attachment-0001.html>