<div dir="ltr">Thanks all for your feedback and willingness to contribute. I've added Gert, Alex and Pieter as collaborators (based on the requests so far).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 28, 2023 at 10:51 AM Alex Babeanu 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 dir="ltr"><div dir="ltr"><div>Thanks for sharing this Atul,</div><div><br></div><div>Some additional comments:</div><div><br></div>> Re: Oauth2, I agree with Omri: I think this spec should just state that authentication is required, but out of scope of the doc. We could suggest Oauth2 that being said...<div><br></div><div>> I would also prefer to stick to "Subject" and "Resource" </div><div><br></div><div>3.5 - Principals ("Subjects")</div><div>> An ID should indeed suffice. Now it's probably a good idea to also <u>optionally</u> add some Subject claims here that the PDP can use (thinking JWT claims coming into the PEP, or environmental values for example). But in that case it should not be just "IP" and "DeviceID", but rather an array of "key"="Value" claim pairs, which may be completely custom and use-case-specific.</div><div><br></div><div>> It would be good to also have a Subject Type - make it optional if not needed (but we would need it for example). </div><div><br></div><div>3.6 - Assets</div><div>> ID should be mandatory I think.</div><div><br></div><div>3.7 - Actions</div><div>--> Omri, if "Action" is enough to represent relationships in your world, it isn't in mine. Just think of "HAS_FRIEND" relationships for example... Anyway, there's probably no point in adding any graph-modelling to this doc...</div><div><div><br></div><div>3.12.2 - Evaluation response</div><div>> I don't think we need an `exp` value: we can't "predict" how long an access rule would be true for: that's a business decision! Besides, in the spirit of Zero Trust, a decision is just made at 1 point in time, the next access request may yield a completely different response. Up to the PDP to do caching or whatever to speed-up processing.</div><div><br></div><div>> I don't think it's a good idea to reply with all language strings, this could be a huge response and it would probably slow-down the PDP too. Instead, have the client PEP request the language it wants its responses in, and just return that 1 reason string.</div><div><br></div><div>3.13 - Search API</div><div>> We also need the reverse query, i.e., who can access this given Resource ?</div><div>> Again, I don't think we need `exp` here.<br></div></div><div><br></div><div>Regards,</div><div><br></div><div>./\.</div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 27, 2023 at 10:48 PM Omri Gazitt 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 dir="ltr">Thanks Atul - it's clear you and the SGNL team put some thought into this.<div><br></div><div>I'm still looking through this but I like that you're specifying both a "check" function (Access Evaluation) and an "expand" function (Search API).  Both are important, but perhaps only the Access Evaluation API ought to be required.<div><br></div><div>I'm not sure what is the best way to provide feedback. Github issues? PRs? put it in a google doc and use comments?</div><div><br></div><div>Here are some thoughts (sorry, no particular order):</div><div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><br></span></div><div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">> Policy Distribution Point</span></div><div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">Nit - this should be "Policy Decision Point" (which you name correctly in other places in the doc)</span><br></div><div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><br></span></div><div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">> The Authorization API is itself authorized using OAuth 2.0 (</span><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">[<a href="https://sgnl-ai.github.io/authzapi/#RFC6749" style="text-decoration-line:none;color:rgb(34,34,238)" target="_blank">RFC6749</a>]</span><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">)</span></div><div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">I think this is </span>overspecified<span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">. I can certainly see clients that call an Authorization API using an API key.</span><br></div><div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><br></span></div><div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">> Terminology</span></div><div>A bit of a quibble, but perhaps we tip the hat to XACML and use the terms "subject" and "resource" instead of "principal" and "asset". I'm not religious about these terms, but "asset" in particular seems less common than "object" or "resource".</div><div><br></div><div>> Principals</div><div>In many systems, subjects will be extracted from a JWT "sub" claim, which is a string. I'm not sure that specifying that this must be a JSON structure, and further specifying two optional fields (ipAddress and deviceId) is necessary, and feels overspecified. </div><div><br></div><div>> Assets</div><div>Having a type and id makes sense, but could these be specified in a single string?  For example, zanzibar defines these as type:id </div><div><br></div><div>I do like having the ability to pass in properties in addition to the object identifier - but it seems like this should be a json object (key:value pairs), not just an array of attribute names.</div><div><br></div><div>> Actions</div><div>It's not clear to me that separating actions into "standard" and "custom" is useful. I think the types of actions you list (CRUD) are common examples but should not be normative.<br></div><div><br></div><div>I do think it's possible to use the generic concept of "Action" to encompass permissions and relations. </div><div><br></div><div>> Queries (as array)</div><div>I think that allowing a set of decisions to be requested at once is valuable, but IMO the spec should not mandate that implementations must support more than one query at a time. Some PDPs don't support that semantic and it should be considered optional.</div><div><br></div><div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><br></span></div><div><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><br></span></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 27, 2023 at 4:38 PM Atul Tulshibagwale 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 dir="ltr">Hi all,<div><br><div>Here's a proposal of an Authorization API that we would like to contribute to this group (in its current form or if / when we find a home in a standards body). This is similar to at least a few vendors' current offerings, so I hope everyone finds this helpful, and we can accelerate our standardization efforts as a result.</div><div><br></div><div>You can read the proposal in HTML format here: <a href="https://sgnl-ai.github.io/authzapi/" target="_blank">https://sgnl-ai.github.io/authzapi/</a></div><div><br></div><div>The sources (under the MIT License) are here: <a href="https://github.com/SGNL-ai/authzapi" target="_blank">https://github.com/SGNL-ai/authzapi</a></div><div><br></div><div>- Atul Tulshibagwale, Erik Gustavson and Marc Jordan</div><div><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><span><div dir="ltr" style="margin-left:0pt" align="left"><table style="border:none;border-collapse:collapse"><colgroup><col width="142"><col width="482"></colgroup><tbody><tr style="height:0pt"><td style="vertical-align:middle;overflow:hidden"><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><a href="https://sgnl.ai" target="_blank"><span style="font-size:11pt;font-family:"Work Sans",sans-serif;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><span style="border:none;display:inline-block;overflow:hidden;width:137px;height:68px"><img src="https://lh3.googleusercontent.com/aO7jB_JqOxA0tVDXsAotNQnsfEkxEORgtkVnVFrmkR7O8j3B4lbbRsGFuprzQhfDmri2YH8_dnjPiZnGMZxIcT9xRcdY6rYm-xGophLkgvl_v8istAefyh4qkSVINQtPfcmq5BZiKbfFHmursSUHyll1jEWBTd--nw26MIMKd86Br32rGZkvJwnEED_nzQ" width="137" height="68" style="margin-left: 0px; margin-top: 0px;"></span></span></a></p></td><td style="vertical-align:top;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:"Work Sans",sans-serif;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Atul Tulshibagwale</span></p><p dir="ltr" style="line-height:1.44;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:"Work Sans",sans-serif;color:rgb(102,102,102);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">CTO </span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><font size="1"><span style="font-family:"Work Sans",sans-serif;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><span style="border:none;display:inline-block;overflow:hidden;width:20px;height:27px"><a href="https://linkedin.com/in/tulshi" target="_blank"><img src="https://lh6.googleusercontent.com/ezm4lDcLtajK4RMqqHALoRgXyaC4HRlw0wWsR2Jvms0V9Wrxr3x5G66zsUrYpRXyeJ3RwLS3GdKUwO0Ui5mXPodSkUx8Xsarf_vj6WlJ05Y1qJoMFTlCZnEgtHvlJ7_7Dr7zWNjkvf3nMW9u1P5ye76SeHgz2QqGQ_rm-sjqYOS-vH1UZL7Yiewi4UO3Qw" width="20" height="27" style="margin-left: 0px; margin-top: 0px;"></a> </span></span><span style="font-family:"Work Sans",sans-serif;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><span style="border:none;display:inline-block;overflow:hidden;width:20px;height:27px"><a href="https://twitter.com/zirotrust" target="_blank"><img src="https://lh6.googleusercontent.com/HAnAvykj318aQf5zTUZkjIJDtwelDecFi5d-idBrpUDBj7aKTdup5Mfia6UIbXTAP46zg7gigNnroQ9he3j81Sf9qCRRSS-w_nZ3oSXJnYLbPlCXgt6IqoifgHXETuJSRvFIZRIdn_aAbtp8ilKFyIVuTXjVe6cNAfXc5KZNwJeYinwfZZxVvHHaR5uIdQ" width="20" height="27" style="margin-left: 0px; margin-top: 0px;"></a> </span></span><a href="mailto:atul@sgnl.ai" target="_blank"><img src="https://lh3.googleusercontent.com/63PpVJLMybZyfD61JVu0TVH_KkP_IhneeBpDNvbd1KeSFJn6KZzWCgp4hFbrTrIxfksYyM-_wOjNKbjEhSQ2khRXVI3XKcwABLNLI_bFjkN0_NgVoijs_nIRcVJKeQm0s0MRdtkUkCOp5Omyv1faqcNiQxGEUyAvmE9HkeeQCeHa-LxleK0oHSAyQrDY6g" width="21" height="21" style="background-color: transparent; color: rgb(0, 0, 0); font-family: Arial; white-space: pre-wrap; margin-left: 0px; margin-top: 0px;"></a></font></p></td></tr></tbody></table></div></span></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>
</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><img src="https://t.sidekickopen10.com/Cto/OT+23284/d4Kmcm04/R5R8b437GN56nP-_2fJzsW3yN-9Z25cBJVW22V4c31X0F74W1Gytc41YXSB1W23h7td1ZkRJlW1S27DG1S2cpyn24T1Ln4W1" alt="" style="display: none;" height="1" width="1"><div></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>
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>