<div dir="ltr"><div><div>I tend to agree with John that HEART is not the place to be designing specific scopes, be they sens, btg, or de-id. We simply don't have the relevant implementers at the table. That means HEART risks introducing "features" that EHR vendors or hospitals are unable or unwilling to implement. <br><br></div>HEART should stick to what makes us different from OAuth and valuable to implementers of OAuth which is *delegation*. Delegation can reduce the RSs liability for making authorization decisions and therefore it can reduce their costs of managing private data. The closer we can stay to that simple message, the better.<br><br></div>From this perspective of delegation, I do see that UMA may want to specify how some exceptions are handled. Sens, btg, de-id, seem to be variations of Adrian's Clause (where the RS decides to ignore the scope of an authorization ) should all be considered in UMA, not HEART. They represent exception patterns:<br><ul><li>sens: the scope says the data released should be labeled in a particular way and the RS may or may not be able to comply with the labeling request. If the RS is unable or unwilling to comply, then we have the Adrian Clause.<br></li><li>btg: as described by Eve, this seems to be just Adrian's Clause since the RS is making a decision beyond the scope of the unavailable or unwilling AS</li><li>de-id: this is just a different scope that an RS could offer. It's kind of like sens, if the RS did not register this scope then having the AS ask for it places liability on the RS to interpret a scope that they did not explicitly register. This also seems like a variant of the Adrian Clause.<br></li></ul><p>Adrian<br></p> <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 12, 2018 at 2:45 PM, John Moehrke <span dir="ltr"><<a href="mailto:johnmoehrke@gmail.com" target="_blank">johnmoehrke@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes I do have some comments on the topic of FHIR and de-identification.... Mostly warning, but some encouraging words. I am not convinced what needs to be done can be done using scopes.<div><br></div><div><a href="https://healthcaresecprivacy.blogspot.com/2017/09/fhir-and-bulk-de-identification.html" target="_blank">https://healthcaresecprivacy.<wbr>blogspot.com/2017/09/fhir-and-<wbr>bulk-de-identification.html</a><br></div><div><br></div><div>a bit older, but still relevant</div><div><a href="http://healthcaresecprivacy.blogspot.com/2015/06/fhir-does-not-need-deidentifytrue.html" target="_blank">http://healthcaresecprivacy.<wbr>blogspot.com/2015/06/fhir-<wbr>does-not-need-deidentifytrue.<wbr>html</a><br></div><div><br></div><div>on the break-the-glass, I also have plenty to say... but what I am hearing is that this is better handled as a http header, not as an OAuth mechanism. I question this, as I point out it is an authorization-override concept, but that the override must be previously authorized. </div><div><br></div><div>I would find break-the-glass to be an unusual concept for HEART functionality. It requires medical necessity, and professional judgement that it is medically necessary. This is in the healthcare professional space, not in the patient space. </div><div><br></div><div>John</div></div><div class="gmail_extra"><br clear="all"><div><div class="m_8671655064342060934gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">John Moehrke<br>Principal Engineering Architect: Standards - Interoperability, Privacy, and Security<br>CyberPrivacy – Enabling authorized communications while respecting Privacy</div><div dir="ltr">HITRUST Certified CSF Practitioner<br>M +1 920-564-2067<br><a href="mailto:JohnMoehrke@gmail.com" target="_blank">JohnMoehrke@gmail.com</a><br><a href="https://www.linkedin.com/in/johnmoehrke" target="_blank">https://www.linkedin.com/in/<wbr>johnmoehrke</a><br><a href="https://healthcaresecprivacy.blogspot.com" target="_blank">https://healthcaresecprivacy.<wbr>blogspot.com</a><br><span style="color:rgb(51,51,51);font-family:"courier new",courier,monospace;font-size:small">Postel's Law: Be strict when sending and tolerant when receiving</span><br></div></div></div></div></div></div>
<br><div class="gmail_quote"><div><div class="h5">On Sat, May 12, 2018 at 11:01 AM, Eve Maler <span dir="ltr"><<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>Justin and I have been discussing the idea of adding another specialty scope, somewhat similar to our existing mechanism for confidentiality/sensitivity scopes and the break-the-glass ("btg") scope, for indicating that the disclosed data should be de-identified.</div><div><br></div><div>The group did discuss this a bit, a long time back, but we put it on the back burner because de-identification can never be "complete" (i.e., you never reach full computational anonymization). But there are transformation processes that do "as good a job as possible", and I believe we can couch the capability in the right terms. As well, when I have talked with people about HEART (a lot of people when I was at the RSA conference, for example!), a demand for this type of feature came up.</div><div><br></div><div>Thoughts?</div><div><br></div><div>====</div><div><br></div><div>In addition, whether we have two (conf/sens and btg) or three (adding de-id) such mechanisms, I think the spec would really benefit from a bit more text explaining the consequences of how they work -- and possibly how they might compare to each other. We've got the bare minimum spec text right now. Currently, things work like this:</div><div><ul><li><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">In all cases: RS has the choice to advertise the capability to handle each scope, in OAuth, by including it in developer documentation, and in UMA, by registering the scope as part of a registered resource. (This means it's not possible for an AS to be caught unawares offering a scope that an RS can't handle.)</span></li></ul><ul><li>Conf/sens scopes: If the scope is MISSING from a client-presented access token, the RS SHOULD filter out the corresponding conf/sens data.<br><br>Implications that we don't describe anywhere yet:<br><br></li><ul><li>The SHOULD is a very strong word in spec writing, but we don't say what the rationales should be for <i>not</i> being able to filter out the data as "promised".<br><br></li><li>Given that <i>absence</i> of the scope is a signal to filter (this is because the scope names are based on the HL7 codes and the way the "logic direction" runs), "default policies" or similar in the patient's UX that automatically set up filtering would be a good idea.</li></ul></ul><ul><li>btg: If the scope is PRESENT in a client-presented access token, then the RS MUST leave a human-readable audit trail of access given on that basis.<br><br>Implications that we don't describe anywhere yet:<br><br></li><ul><li>Pre-set policies would be a big benefit here given that we say "The resource is intended to be accessed when the resource owner is unavailable", a UX consideration but an important one.<br><br></li><li>It's likely that setting up some sort of trust framework or similar will be needed for determining which claims would suffice for letting (say) an emergency responder get access when the resource owner is unavailable.</li></ul></ul></div><div>I suspect that if we add something like a "de-identify" scope, its logic would work OPPOSITE to the conf/sens scopes because we could name it in a more obvious fashion. And so if it were PRESENT in a client-presented access token, that would be the signal for the RS to do the de-identification operation on delivered content.</div><div><br></div><div>(Refer to <a href="http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/ascii&url=https://bitbucket.org/openid/heart/raw/master/openid-heart-fhir-oauth2.xml" target="_blank">this spec</a> for the relevant language.)</div><div><br></div><div>====</div><div><br></div><div>We do have a meeting on Monday, and I apologize for having to miss it -- I'll be in Munich at the EIC conference, presenting HEART status to the OpenID Foundation workshop, for one thing!</div><br clear="all"><div><div class="m_8671655064342060934m_4121745543241250012gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">
<table style="font-family:Times" cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="top"><a href="https://www.forgerock.com/" target="_blank"><img src="https://www.forgerock.com/img/ForgeRock_retina_email_bw_logo.png" alt="ForgeRock" width="185" border="0" height="70"></a></td><td style="font-family:arial,helvetica,verdana,sans-serif;font-size:12px;color:rgb(47,52,56);line-height:19.8px" valign="top" bgcolor="#ffffff" align="left"><strong>Eve Maler</strong><br>VP Innovation & Emerging Technology | ForgeRock<br><span style="color:rgb(249,76,35)"><strong>t</strong></span> (425) 345-6756 | <span style="display:inline-block"><span style="color:rgb(249,76,35)"><strong>e</strong></span> <a href="mailto:eve.maler@forgerock.com" style="color:rgb(47,52,56)" target="_blank">eve.maler@forgerock.com</a></span><br><span style="color:rgb(249,76,35)"><strong>twitter</strong></span> xmlgrrl | <span style="display:inline-block"><span style="color:rgb(249,76,35)"><strong>web</strong></span> <a href="https://www.forgerock.com/" style="color:rgb(47,52,56)" target="_blank">www.forgerock.com</a></span></td></tr></tbody></table></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
<br></div></div>______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openi<wbr>d.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span></div><div dir="ltr"><span style="color:rgb(31,73,125);font-family:Arial,sans-serif;font-size:10pt">DONATE: </span><span style="font-family:Arial,sans-serif;font-size:10pt;color:blue"><a href="https://patientprivacyrights.org/donate-3/" style="color:rgb(17,85,204)" target="_blank">https://patientprivacyrights.org/donate-3/</a></span></div></div></div></div></div></div></div></div></div>
</div>