<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">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>