[policy-charter] PEP-PDP Group

Tue Jun 13 20:53:07 UTC 2023

Thanks Roland... that is cool, but not really usable in all cases, in mine
at least. For instance, I'd need GraphQL . Additionally, I'd need to be
able to CRUD any multi-hop relationships too (not just 1-hop).

Imho a protocol that ignores GraphQL is not future-proof:
"A recent Gartner report predicts that although only 10% of enterprises
<https://www.postman.com/postman-enterprise/> had implemented GraphQL as
their internal data layer in 2021, by 2025 that number will increase to
over 50% of global enterprises."
https://blog.postman.com/emerging-trends-graphql-apis-technology-future-of-data-exchange/

Anyway, there's an opportunity to go beyond API definitions here, I think.
I'd like to propose that we look at using *Authorization* *Events* instead,
to convey authorization requests/responses:
--> Apps or PEPs publish request events,
--> PDPs subscribe to them, and publish response Events (to which PEPs and
Apps subscribe).

Advantages:
- Just enhance the OpenID Shared Signals suite of standards to include
AuthZ events (now we can focus on what such events would contain).
- Agnostics of protocol/methodology/API style.
- All the advantages of streaming: replay, speed, etc... See Apache Kafka
et. al.
- Decouples all systems, making the whole thing resilient, etc.

Using streams of AuthZ events we could then define, and use, "Enterprise
Authorization Meshes" (*AuthZ Mesh*,..?) , akin to data meshes. This would
be in line with what most Organizations do already with their (often big)
data.

Thoughts?

./\.

On Tue, Jun 13, 2023 at 1:19 PM Roland Baum via policy-charter <
policy-charter at lists.openid.net> wrote:

> Hi there,
>
> may be this is a good chance to share a (very basic) API description of a
> PDP I recently made for a ReBAC approach.
>
> Link: https://gist.github.com/tr33/2fbd45a07524e9aa0867d103aa11eb79
>
> Its not much into generalized, but tries to cover the basic aspects of
> request/response scheme between PEP/PDP.
> It's also pretty ReBAC-oriented, as one can see from the two "update" and
> "delete" interfaces.
>
> The intent was to design a useful but simple communication scheme between
> PEP (application) and PDP decisions - independent from the (ReBAC oriented)
> backend used by the PDP (which is OPA, in this case).
> Related entities like "Identity" or  "Policy" are yet not covered by the
> scheme, but could be addressed in further versions.
>
> Anyway, hope that helps to get some impressions and good ideas.
>
>
> feedback welcome!
>
>
> roland
> Am 13.06.23 um 20:45 schrieb Alex Babeanu via policy-charter:
>
> 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.
>
> --
> 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/547492df/attachment-0001.html>