<div dir="ltr">Hi Omri,<div><br></div><div>Thanks for the feedback and thanks for the additional feedback on the call. I think we are on the same page.</div><div><br></div><div><ol><li>Regarding binding, yes we definitely need one but I just want to make sure we keep message format/schema cleanly separate from transport so anyone can plug in their favorite transport layer. For the interop, we definitely need HTTP as a basic binding.</li><li>the request format: I think key-value pairs in a loosely structured way (based on SARE or PARC) is good enough. You can send in your ID that makes sense in the Zanzibar way. I don't think it precludes non-ABAC models. Thoughts?</li><li>On the topic of arrays... I have a little story to tell. When I wrote the first version of the XACML/JSON spec, I decided to allow a Subject field to either be an object (of type category) or an array. That led to really weird SDKs that had to test whether the field was an array or not. For the first interop, we can make it an object but quickly after, I'd recommend we make it an array and that would be the first official version of the AuthZEN standard. If we do that, we're giving us an easy way to achieve batch</li></ol><div><br></div></div><div>Thanks,</div><div>David</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 23, 2024 at 11:18 AM Omri Gazitt <<a href="mailto:omri@aserto.com">omri@aserto.com</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 dir="ltr"><div>David, thanks for writing this all down!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 22, 2024 at 9:25 PM David Brossard via Openid-specs-authzen <<a href="mailto:openid-specs-authzen@lists.openid.net" target="_blank">openid-specs-authzen@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 dir="ltr">Dear all,<div><br></div><div>Last week, it became apparent we need to start simple and low for the PEP-PDP API if we want to ship anything out and I'd like to propose a few principles:</div><div><ol><li>Keep transport and message separate</li><ol><li>The spec for what a request/response should look like should be decoupled from the underlying transport (HTTP or anything else)</li><li>As a result, nothing in the transport layer conveys any authZ meaning whatsoever</li><ol><li>For instance, 401/403 are indications you cannot use the authorization service. They don't convey anything about the request you sent or what the PDP (in the broad sense) would have said</li></ol></ol></ol></div></div></blockquote><div>For practical interop, I do think we need an HTTP (REST) binding.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><ol><li>Propose a first iteration of request/response that focuses exclusively on the easy "binary" yes/no use case</li><ol><li>No additional statements/obligations/advice</li><li>No batch</li><li>No search</li></ol></ol></div></div></blockquote><div><br></div><div>+100.  That was definitely where I landed after last week's conversations. We can layer other things once we've declared success on the simple cast. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><ol><li>Propose a model that is largely attribute-based (where an attribute is a key-value pair)</li></ol></div></div></blockquote><div>I would like to see this be generalized - otherwise you'll preclude all non-attribute-based systems, which seems like a big miss.</div><div><br></div><div>Specifically, the minimum amount of information that is needed to define a subject is a type and ID. Likewise an object/resource. Likewise an action.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><ol><li>Propose a model that follows the ALFA Subject/Action/Resource/Environment or the Cedar Principal/Action/Resource/Context</li></ol></div></div></blockquote><div>Terminology is important but the most important thing is to be consistent throughout. <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 dir="ltr"><div><ol><li>Publish the results using a standardized schema</li><ol><li>In the WS-* days of yore, it would have been WSDL</li><li>For us, would OpenAPI be good enough?</li></ol></ol></div></div></blockquote><div>OpenAPI is perfect. But it DOES imply that you need to specify an HTTP binding (and specifically, HTTP status codes).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>So with that being said, should we have a request that looks like the following:</div><div><ul><li>Made up of 4 objects of the same type (e.g. Category to use ALFA parlance):</li><ul><li>Subject, Action, Resource, Context</li><li>If these objects are arrays of the said type, then we are paving the way for batch requests</li></ul></ul></div></div></div></blockquote><div>I thought we were eliminating arrays from the simple case? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><ul><li>Each of these objects contains an array of attributes e.g. key-value pairs</li><ul><li>The attributes could be primitive types e.g. string, double, boolean</li><li>The attributes could be complex e.g. a JSON payload</li></ul></ul><div>The response should simply be the decision itself:</div></div><div><ul><li>Permit/Deny</li><ul><li>Again, if we want to plan ahead and think of batch requests then the response should be an array rather than an object.</li></ul><li>Optionally the list of identifiers of things (policies) used in the decision-making process</li></ul></div><div>Thoughts?</div></div></div>
-- <br>
Openid-specs-authzen mailing list<br>
<a href="mailto:Openid-specs-authzen@lists.openid.net" target="_blank">Openid-specs-authzen@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-authzen</a><br>
</blockquote></div></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">---<br>David Brossard<br><a href="http://www.linkedin.com/in/davidbrossard" target="_blank">http://www.linkedin.com/in/davidbrossard</a><br><a href="http://twitter.com/davidjbrossard" target="_blank">http://twitter.com/davidjbrossard</a><br><a href="http://about.me/brossard" target="_blank">http://about.me/brossard</a><br>---<br>Stay safe on the Internet: <a href="https://www.capefearnetworks.com/wp-content/uploads/2017/05/Internet-Fraud-Prevention-Tips-IC3.pdf" target="_blank">IC3 Prevention Tips</a><br>Prenez vos précautions sur Internet: <a href="http://www.securite-informatique.gouv.fr/gp_rubrique34.html" target="_blank">http://www.securite-informatique.gouv.fr/gp_rubrique34.html</a></div></div>