<html xmlns="http://www.w3.org/1999/xhtml"><head> <title></title> <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no"> </head> <body style="font-family:Helvetica;color:#000000;font-size:13px;"><img id="AD07948957141DF08A5D6A4ADB81455C" alt="" width="0px" src="https://receipts.canarymail.io/track/AE980BFE3A76DE71B7ADC1325DB56676_AD07948957141DF08A5D6A4ADB81455C.png" height="0px"><div id="CanaryBody"> <div> <br> </div> <div>Alex, I am not sure I fully agree with your statement!</div><div><br></div><div>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.</div><div><br></div><div>I think there are at least two use cases for standardization (as we discussed at IDentiverse)</div><div><br></div><div>1. A standardized interface between PEPs or agents and the PDP. This would allow de-weaponization of agents, and interoperability at the agent level…. </div><div>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. </div><div><br></div><div>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</div><div><br></div><div>I see these as complimentary.</div><div><br></div><div>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. </div><div><br></div><div>Allan</div><div><br></div> </div> <div id="CanarySig"> <div> <div><br></div> <div><br></div> </div> </div> <div id="CanaryDropbox"> </div> <blockquote id="CanaryBlockquote"> <div> <div>On Tuesday, Jun 13, 2023 at 11:45, Alex Babeanu <<a href="mailto:alex@3edges.com">alex@3edges.com</a>> wrote:<br></div> <div><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></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">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 class="msg7822307950296278208"> <div lang="EN-US" style="overflow-wrap: break-word;"> <div class="m_7822307950296278208WordSection1"> <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? <u></u><u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></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<u></u><u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt">The Transport layer<u></u><u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt">The Envelope Layer<u></u><u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt">The request/response transaction layer<u></u><u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt">How meta-data is handled? (both request and response)<u></u><u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt">Extension mechanisms<u></u><u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt">Exception mechanism<u></u><u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt">Allan<u></u><u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></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<u></u><u></u></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).<u></u><u></u></span></p> <div> <p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p> </div> <div> <p class="MsoNormal"><span style="font-size:11pt">Here are three examples, to get us started:<u></u><u></u></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. <u></u><u></u></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. <u></u><u></u></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.<u></u><u></u></span></li></ul> </div> <div> <p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p> </div> </div> </div> <p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></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:<u></u><u></u></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><u></u><u></u></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" 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></div> </div> </blockquote> </body></html>