<div dir="ltr">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).<div><br></div><div>Imho a protocol that ignores GraphQL is not future-proof: <br>"<font color="#0b5394"><span style="font-family:Inter,system-ui,-apple-system,"system-ui","Segoe UI",Oxygen,Ubuntu,Cantarell,"Fira Sans","Droid Sans",Helvetica,Arial,sans-serif;font-size:16px;letter-spacing:-0.16px">A recent Gartner report predicts that although only 10% of </span><a href="https://www.postman.com/postman-enterprise/" style="box-sizing:border-box;text-decoration-line:none;height:24px;font-family:Inter,system-ui,-apple-system,"system-ui","Segoe UI",Oxygen,Ubuntu,Cantarell,"Fira Sans","Droid Sans",Helvetica,Arial,sans-serif;font-size:16px;letter-spacing:-0.16px">enterprises</a><span style="font-family:Inter,system-ui,-apple-system,"system-ui","Segoe UI",Oxygen,Ubuntu,Cantarell,"Fira Sans","Droid Sans",Helvetica,Arial,sans-serif;font-size:16px;letter-spacing:-0.16px"> had implemented GraphQL as their internal data layer in 2021, by 2025 that number will increase to over 50% of global enterprises.</span></font>"<br><a href="https://blog.postman.com/emerging-trends-graphql-apis-technology-future-of-data-exchange/">https://blog.postman.com/emerging-trends-graphql-apis-technology-future-of-data-exchange/</a> <br></div><div><br></div><div>Anyway, there's an opportunity to go beyond API definitions here, I think. I'd like to propose that we look at using <b>Authorization</b> <b>Events</b> instead, to convey authorization requests/responses: </div><div>--> Apps or PEPs publish request events, </div><div>--> PDPs subscribe to them, and publish response Events (to which PEPs and Apps subscribe).</div><div><br></div><div>Advantages:</div><div>- Just enhance the OpenID Shared Signals suite of standards to include AuthZ events (now we can focus on what such events would contain).</div><div>- Agnostics of protocol/methodology/API style.</div><div>- All the advantages of streaming: replay, speed, etc... See Apache Kafka et. al.</div><div>- Decouples all systems, making the whole thing resilient, etc.</div><div><br></div><div>Using streams of AuthZ events we could then define, and use, "Enterprise Authorization Meshes" (<b>AuthZ Mesh</b>,..?) , akin to data meshes. This would be in line with what most Organizations do already with their (often big) data.</div><div><br></div><div>Thoughts?</div><div><br></div><div>./\.</div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 13, 2023 at 1:19 PM Roland Baum via policy-charter <<a href="mailto:policy-charter@lists.openid.net">policy-charter@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi there,</p>
<p>may be this is a good chance to share a (very basic) API
description of a PDP I recently made for a ReBAC approach.</p>
<p>Link:
<a href="https://gist.github.com/tr33/2fbd45a07524e9aa0867d103aa11eb79" target="_blank">https://gist.github.com/tr33/2fbd45a07524e9aa0867d103aa11eb79</a></p>
<p>Its not much into generalized, but tries to cover the basic
aspects of request/response scheme between PEP/PDP.<br>
It's also pretty ReBAC-oriented, as one can see from the two
"update" and "delete" interfaces.</p>
<p>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).<br>
Related entities like "Identity" or "Policy" are yet not covered
by the scheme, but could be addressed in further versions.<br>
<br>
</p>
<p>Anyway, hope that helps to get some impressions and good ideas.</p>
<p><br>
</p>
<p>feedback welcome!<br>
</p>
<p><br>
</p>
<p>roland<br>
</p>
<div>Am 13.06.23 um 20:45 schrieb Alex
Babeanu via policy-charter:<br>
</div>
<blockquote type="cite">
<div dir="ltr">This is a good discussion, that said a PEP is
actually <b>not</b> mandated in all cases. For example you
would <b>not</b> use a PEP to secure GraphQL APIs nor COTS
software.<br>
<br>
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...
<div><br>
</div>
<div>Thanks,</div>
<div>./\lex.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jun 13, 2023 at
11:30 AM Allan Foster via policy-charter <<a href="mailto:policy-charter@lists.openid.net" target="_blank">policy-charter@lists.openid.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11pt">So I
am thinking we also want to set some scope of what
we want to cover?
</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Off
the top of my head…. I can put some more context
around these if they aren’t clear</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">The
Transport layer</span></p>
<p class="MsoNormal"><span style="font-size:11pt">The
Envelope Layer</span></p>
<p class="MsoNormal"><span style="font-size:11pt">The
request/response transaction layer</span></p>
<p class="MsoNormal"><span style="font-size:11pt">How
meta-data is handled? (both request and response)</span></p>
<p class="MsoNormal"><span style="font-size:11pt">Extension
mechanisms</span></p>
<p class="MsoNormal"><span style="font-size:11pt">Exception
mechanism</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Allan</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in">
<p class="MsoNormal" style="margin-bottom:12pt"><b><span style="font-size:12pt;color:black">From:
</span></b><span style="font-size:12pt;color:black">policy-charter
<<a href="mailto:policy-charter-bounces@lists.openid.net" target="_blank">policy-charter-bounces@lists.openid.net</a>>
on behalf of Omri Gazitt via policy-charter <<a href="mailto:policy-charter@lists.openid.net" target="_blank">policy-charter@lists.openid.net</a>><br>
<b>Date: </b>Tuesday, June 13, 2023 at 10:54<br>
<b>To: </b>Policy Charter Mail List <<a href="mailto:policy-charter@lists.openid.net" target="_blank">policy-charter@lists.openid.net</a>><br>
<b>Cc: </b>Omri Gazitt <<a href="mailto:omri@aserto.com" target="_blank">omri@aserto.com</a>><br>
<b>Subject: </b>Re: [policy-charter] PEP-PDP
Group</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11pt">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).</span></p>
<div>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11pt">Here
are three examples, to get us started:</span></p>
<div>
<ul type="disc">
<li class="MsoNormal">
<span style="font-size:11pt">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
<a href="https://www.openpolicyagent.org/docs/latest/rest-api/#execute-an-ad-hoc-query" target="_blank">
query</a> API, which allows you to pass
input and evaluate a rego query based on the
loaded policy document and the input. </span></li>
<li class="MsoNormal">
<span style="font-size:11pt">Auth0 FGA (one of
the zanzibar implementations) has a
<a href="https://www.openpolicyagent.org/docs/latest/rest-api/#execute-an-ad-hoc-query" target="_blank">
check</a> 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
<a href="https://www.postman.com/authzed/workspace/spicedb/documentation/21043612-9786e5f3-2014-4b31-86c1-39335236c0e2?entity=request-c58c40ff-9fc7-4c3e-9cca-f017160ba5b8" target="_blank">
check</a> API that takes a resource,
permission, and subject. </span></li>
<li class="MsoNormal">
<span style="font-size:11pt">Topaz (Aserto's
OSS authorizer) has a <a href="https://aserto.readme.io/reference/authorizerquery-1" target="_blank">
query</a> 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 <a href="https://aserto.readme.io/reference/authorizeris-1" target="_blank">is</a>
API that evaluates a policy (rule/decisions)
with an identity and resource context.</span></li>
</ul>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
</div>
</div>
</div>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt">On
Tue, Jun 13, 2023 at 1:54 AM Roland Baum via
policy-charter <<a href="mailto:policy-charter@lists.openid.net" target="_blank">policy-charter@lists.openid.net</a>>
wrote:</span></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><span style="font-size:11pt">I'm
in as well :-D<br>
<br>
<br>
<br>
Roland Baum<br>
umbrella.associates GmbH<br>
<br>
<br>
-- <br>
policy-charter mailing list<br>
<a href="mailto:policy-charter@lists.openid.net" target="_blank">policy-charter@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/policy-charter" target="_blank">https://lists.openid.net/mailman/listinfo/policy-charter</a></span></p>
</blockquote>
</div>
</div>
</div>
-- <br>
policy-charter mailing list<br>
<a href="mailto:policy-charter@lists.openid.net" target="_blank">policy-charter@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/policy-charter" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/policy-charter</a><br>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr"><a href="https://hihello.me/p/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5" rel="noopener" style="display:inline-block" target="_blank"><img alt="This is Alexandre Babeanu's
card. Their email is alex@3edges.com. Their phone number
is +1 604 728 8130." src="https://cdn.hihello.me/cards/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5/signature_logo.png?generated=1653502150176" style="display: inline-block; min-height: 100px;" width="360"></a><br>
</div>
</div>
<br>
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.<br>
<br>
<fieldset></fieldset>
</blockquote>
</div>
-- <br>
policy-charter mailing list<br>
<a href="mailto:policy-charter@lists.openid.net" target="_blank">policy-charter@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/policy-charter" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/policy-charter</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><a href="https://hihello.me/p/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5" rel="noopener" style="display:inline-block" target="_blank"><img alt="This is Alexandre Babeanu's card. Their email is alex@3edges.com. Their phone number is +1 604 728 8130." src="https://cdn.hihello.me/cards/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5/signature_logo.png?generated=1653502150176" width="360" style="display: inline-block; min-height: 100px;"></a><br></div></div>
<br>
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.<br>