<div dir="ltr">Thanks Eve, added a comment to the PR... <br>I fail to see how this will help if we don't formalize this context block in the response. How would a PDP know what key/value pairs to add in there ? Is this supposed to be implementation-specific?<div><br></div><div>Cheers,</div><div><br></div><div>./\.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 10, 2024 at 8:15 PM Omri Gazitt 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="auto">The PR I created yesterday puts the reason-code etc under the context. </div><div dir="auto"><br></div><div dir="auto"><div><a href="https://github.com/openid/authzen/pull/90" target="_blank">https://github.com/openid/authzen/pull/90</a></div><br clear="all"><br clear="all"><div dir="auto"><div dir="ltr" class="gmail_signature"><div dir="ltr"><table style="font-family:tahoma,sans-serif;border:medium;border-collapse:collapse;color:rgb(34,34,34)"><tbody style="font-family:tahoma,sans-serif"><tr style="height:0pt;font-family:tahoma,sans-serif"><td style="vertical-align:top;padding:5pt;overflow:hidden;font-family:tahoma,sans-serif"><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt;font-family:tahoma,sans-serif"><a href="http://www.aserto.com/" style="font-family:tahoma,sans-serif" target="_blank"><img src="https://raw.githubusercontent.com/aserto-dev/artwork/main/logo/horizontal/color/aserto-horizontal-color.png" width="96" height="35" style="font-family: tahoma, sans-serif;"></a></p></td><td style="vertical-align:middle;padding:5pt;overflow:hidden;font-family:tahoma,sans-serif"><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt;font-family:tahoma,sans-serif"><span style="font-family:Roboto,sans-serif;font-weight:700;vertical-align:baseline;white-space:pre-wrap;background-color:transparent;color:rgb(0,0,0)"><span style="font-size:10pt;font-family:Roboto,sans-serif">Omri Gazitt</span><span style="font-weight:normal;font-family:Roboto,sans-serif"><span style="font-family:Arial;vertical-align:baseline;background-color:transparent"><span style="white-space:pre-wrap;font-family:Arial"> </span></span></span><span style="font-size:10pt;font-family:Roboto,sans-serif">| </span></span><span style="font-family:Roboto,sans-serif;font-size:10pt;white-space:pre-wrap;background-color:transparent;color:rgb(0,0,0)">CEO</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt;font-family:tahoma,sans-serif"><span style="font-size:10pt;font-family:Roboto,sans-serif;vertical-align:baseline;white-space:pre-wrap;background-color:transparent;color:rgb(0,0,0)"><a href="http://www.aserto.com/" style="font-family:Roboto,sans-serif" target="_blank">Aserto</a> Inc.</span><span style="font-family:Arial;vertical-align:baseline;background-color:transparent"><span style="white-space:pre-wrap;font-family:Arial">       </span></span><span style="font-family:Roboto,sans-serif;font-weight:700;white-space:pre-wrap;font-size:10pt;color:rgb(0,0,0)">| </span><span style="font-family:Roboto,sans-serif;font-size:10pt;white-space:pre-wrap;background-color:transparent;color:rgb(0,0,0)">(425) 765-0079</span></p></td></tr></tbody></table></div></div></div></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 10, 2024 at 4:57 PM <<a href="mailto:eve@xmlgrrl.com" target="_blank">eve@xmlgrrl.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>Awesome!<div><br></div><div>This might be a dumb question and I might be looking in the wrong place, but: Would the still-extant reason-object be a candidate to go under context (as one kind of context, vs., say, another kind like required-actions or something), or would it ultimately turn into the context block everywhere?</div><div></div></div><div><div><div>
<div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)"><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)"><div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)"><div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)"><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-family:Helvetica;color:rgb(0,0,0)"><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-family:Helvetica;color:rgb(0,0,0)"><div style="font-family:Helvetica"><br>Eve Maler | cell and Signal <a href="tel:+1-425-345-6756" style="font-family:Helvetica" target="_blank">+1 (425) 345-6756</a><br>Visit the <a href="http://vennfactory.com/" style="font-family:Helvetica" target="_blank">Venn Factory</a><br>Request a <a href="https://fantastical.app/eve/15" style="font-family:Helvetica" target="_blank">15-minute consultation</a></div></div></div></div></div></div></div>
</div>
<div><br><blockquote type="cite"><div>On Apr 10, 2024, at 6:04 PM, Omri Gazitt <<a href="mailto:omri@aserto.com" target="_blank">omri@aserto.com</a>> wrote:</div><br><div><div dir="ltr">Thanks Eve!<div><br></div><div>As you point out, since we (now) have <font face="monospace" style="font-family:monospace;color:rgb(0,0,0)">context</font> in both the request and response payloads, we should have the mechanism to achieve PEP-PDP capability negotiation in exactly the manner you describe. </div><div><br></div><div>That mechanism is flexible enough to support various negotiation scenarios, e.g.:</div><div><ul><li>a PEP may pass a capability in its context and outright reject a PDP that doesn't respond appropriately</li><li>a PDP may look for a required capability from the PEP and deny any request that doesn't contain it</li></ul><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 10, 2024 at 3:26 PM eve--- 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>On this week’s call, I alluded to mechanisms in HEART that allow for communication between entities about their commonly understood “layered semantics". Below I explain; I thought they might be interesting as examples (and probably go some way to explaining why I thought of the phrase “obligation scopes”...).<div><div><br></div><div>====<br><div><br></div><div>By “layered semantics”, I mean switchable sets of functionality. They could be provided natively by the base spec, or could be published by third parties, or have a mix. That’s why I’m not saying “extension”, and why I’m not implying there has to be a hardcore assignment of “obligation” vs. “advice” about it.</div><div><br></div><div>HEART incorporates by reference a set of semantics/structures coming from the FHIR API/data model, which HEART variously maps to resource types and scopes. Here’s the start of the several sections where the FHIR artifacts are referenced: <a href="https://openid.net/specs/openid-heart-fhir-oauth2-1_0.html#Resource" target="_blank">https://openid.net/specs/openid-heart-fhir-oauth2-1_0.html#Resource</a></div><div><br></div><div>HEART adds highly prescribed ways in which the special set of confidentiality and sensitivity scopes (example: <font face="Courier New" style="font-family:"Courier New";color:rgb(0,0,0)">sens/ETH</font> means sensitive data about “Substance abuse”*), and the special break-the-glass scope, must be handled.</div><div><br></div><div>The <b>confidentiality/sensitivity</b> trick requires the resource server to know what it’s doing if it “advertises” its ability to handle this set of scopes. Quoting from <a href="https://openid.net/specs/openid-heart-fhir-oauth2-1_0.html#ConfidentialitySensitivity" target="_blank">https://openid.net/specs/openid-heart-fhir-oauth2-1_0.html#ConfidentialitySensitivity</a> (emphasis mine):</div><div><br></div><div>“This specification makes no assumptions regarding the ability of resource servers to tag and filter data. A resource server that is capable of filtering information <b>MUST advertise</b> this capability through the use of these scopes. Resource servers SHOULD use this access information to filter out data being returned to a client, if possible. If an access token <b>does not contain</b> a given confidentiality or sensitivity marker, the resource server SHOULD assume that the client does not have access to that information and <b>SHOULD apply appropriate filters to the data, where possible</b>.”</div><div><br></div><div>(“Advertising” could merely mean OAuth-protected API documentation; if UMA is in use, HEART additionally imposes formal scope registration: <a href="https://openid.net/specs/openid-heart-fhir-uma2-1_0.html#resource-reg" target="_blank">https://openid.net/specs/openid-heart-fhir-uma2-1_0.html#resource-reg</a>)</div><div><br></div><div>So if a client carries back to the RS a token that <i>doesn't</i> have, say, the <font face="Courier New" style="font-family:"Courier New";color:rgb(0,0,0)">sens/ETH</font> scope associated, that’s effectively an instruction for the RS to actively <i>filter out</i> sensitive substance abuse data in the manner the RS claimed it could do. If the scope is present, then that data is “safe” to share.</div><div><br></div><div>The <b>break-the-glass</b> trick is simpler. The <font face="Courier New" style="font-family:"Courier New";color:rgb(0,0,0)">btg</font> scope is baked into the spec and it works in the more usual way: its presence says to give access. But resource servers are obligated (ha) to take various operational-level actions upon giving access using it, such as logging access in a resource owner-friendly way, and (in UMA) enabling user-offline ways to set policies that can meaningfully control the parameters of break-the-glass access.</div><div><br></div><div>====</div><div><br></div><div>So let’s say we have a generic <font face="Courier New" style="font-family:"Courier New";color:rgb(0,0,0)">context</font> block coming from a PDP that doesn’t imply what the PEP should/must do about it. Can we imagine empowering anyone (including ourselves) to profile <font face="Courier New" style="font-family:"Courier New";color:rgb(0,0,0)">context</font>-related communications to enable, say, a) obligations to be imposed by PDPs (as in <font face="Courier New" style="font-family:"Courier New";color:rgb(0,0,0)">btg</font>), b) PEPs to pre-declare their ability to handle different kinds of advice-or-obligations (as in conf/sens), and even c) PDPs and PEPs to dynamically negotiate what the PEP should try next? (I do have an example of that one too, but will leave it out for now!)</div><div><br></div><div>*A former colleague who’s a paramedic told me the ETH code comes from the word “ether”.</div><div><div>
<div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-family:Helvetica"><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-family:Helvetica"><div style="font-family:Helvetica"><br>Eve Maler | cell and Signal <a href="tel:+1-425-345-6756" style="font-family:Helvetica" target="_blank">+1 (425) 345-6756</a><br>Visit the <a href="http://vennfactory.com/" style="font-family:Helvetica" target="_blank">Venn Factory</a><br>Request a <a href="https://fantastical.app/eve/15" style="font-family:Helvetica" target="_blank">15-minute consultation</a></div></div></div></div></div></div></div>
</div>

<br></div></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></div></div></blockquote></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><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>